Some key definitions related to Architecture, design principles, design patterns and overall object oriented analysis and design for quick reference.
The extent to which software is divided into components, called modules, which have high internal cohesion, low coupling between each other, and simple interfaces.
A measure of the extent to which related aspects of a system are kept together in the same module, and unrelated aspects are kept out.
Creating a module to contain some algorithm or data structure, thus hiding its details behind the module's interface. Allows changes to code to be more easily made since one can be confident that 'outsiders' are not relying on too many details
The ability for software to be run in a variety of different hardware or software environments with no or minimal changes.
"Subclasses" are more specialized versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce their own.
Simplifying complex reality by modelling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.
Polymorphism allows the programmer to treat derived class members just like their parent class's members. More precisely, Polymorphism in object-oriented programming is the ability of objects belonging to different data types to respond to calls of methods of the same name, each one according to an appropriate type-specific behavior. One method, or an operator such as +, -, or *, can be abstractly applied in many different situations.
Decoupling allows for the separation of object interactions from classes and inheritance into distinct layers of abstraction. A common use of decoupling is to polymorphically decouple the encapsulation, which is the practice of using reusable code to prevent discrete code modules from interacting with each other. However, in practice decoupling often involves trade-offs with regard to which patterns of change to favor. The science of measuring these trade-offs in respect to actual change in an objective way is still in its infancy.
A HLD provides an overview of a solution, platform, system, product, service, or process. Such an overview is important in a multi-project development to make sure that each supporting component design will be compatible with its neighbouring designs and fits in the big picture. HLD should briefly describe all platforms, systems, products, services and processes that it depends upon and include any important changes that need to be made to them. A high-level design document will usually include a high-level architecture diagram depicting the components, interfaces and networks that need to be further specified or developed. The document may also depict or otherwise refer to work flows and/or data flows between component systems. In addition, there should be brief consideration of all significant commercial, legal, environmental, security, safety and technical risks, issues and assumptions. The idea is to mention every work area briefly, clearly delegating the ownership of more detailed design activity(LLD-Low-Level Design) whilst also encouraging effective collaboration between the various project teams. Today, most high-level designs require contributions from a number of experts, representing many distinct professional disciplines. Finally, every type of end-user should be identified in the high-level design and each contributing design should give due consideration to customer experience.
It is like detailing the HLD. It defines the actual logic for each and every component of the system. Class diagrams with all the methods and relation between classes comes under LLD. Programs specs are covered under LLD. LLD describes each and every module in an elaborate manner so that the programmer can directly code the program based on this.There will be at least 1 document for each module and there may be more for a module.The LLD will contain: - detailed functional logic of the module in pseudo code - database tables with all elements including their type and size - all interface details with complete API references(both requests and responses) - all dependency issues -error message listings - complete input and outputs for a module. LLD is supposed to be used as program specifications for the developer.
UML is a standardized general-purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group. UML includes a set of graphic notation techniques to create visual models of software-intensive systems.
Layering decomposition is some ordering of principles, typically abstraction. The layers may be totally or partially ordered, such that a given layer x uses the services of layer y, and x in turn provides higher-level services to any layer that uses it. Layering can be by layers or tiers. Layering is usually a top-level decomposition and is followed by one of the other rules.