What are different types of design patterns?

The Composite View Design Pattern
- The context of composite view pattern is that it allows the development of the view more manageable through the creation of a template to handle common page elements for a view.
- The problem comes in modifying and managing the layout of multiple views.
- The solution is to use this pattern when a view is composed of multiple atomic sub-views. Each component of the template may be included into the whole and the layout of the page may be managed independently of the content.
- A benefit of using this pattern is that interface designer can prototype the layout of the page, plugging in static content on each component.
- The drawback is that there is a runtime overhead associated with it.

The Front Controller Design Pattern
- It provides a centralized controller for managing requests.
- The problem is that the system needs a centralized access point for presentation-tier request handling to support the integration of system data retrieval, view management, and navigation.
- The solution to the above problem is that a controller is used as an initial point of contact for handling a request. It centralizes decision-making controls.

Data Access Object Design Pattern
- It separates resource's client interface from its data access mechanisms.It allows data access mechanism to change independently of the code that uses the data.
- The problem is that data will be coming from different persistent storage mechanism and access mechanism varies based on the type of storage.
- The solution to the above problem is to use the Data Access Object to abstract and encapsulate all access to the data source. It implements the access mechanism required to work with the data source.

What are different characteristics of design patterns?

A design pattern is a general repeatable solution to a commonly occurring problem in software design.
- It is a proven solution to problems that keep recurring.
- They are reusable solutions to common problems.
- Design patterns are not frameworks.
- Design patterns are more abstract than frameworks.
- Design pattern cannot be directly implemented.
- Design patterns are more primitive than a framework.
- A design pattern cannot incorporate a framework.
- Patterns may be documented using one of several alternative templates.
- Design patterns can speed up the development process by providing tested, proven development paradigms.
- Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
- Patterns allow developers to communicate using well-known, well understood names for software interactions.

A pattern description includes the following elements:
- name of the pattern should be meaningful.
- context of the pattern represents the circumstances or preconditions.
- Problem description that pattern addresses should be provided.
- Solution is a description of the static and dynamic relationships amongthe components of the pattern.
The use of design patterns requires careful analysis of the problem that is to be
addressed and the context in which it occurs.

Technical Solution (TS) Process Area in Capability Maturity Models (CMM)

The purpose of Technical Solution (TS) is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combination as appropriate. It is an Engineering process area at Maturity Level 3.
The process area focuses on the following:
- Evaluating and selecting solutions (sometimes referred to as “design approaches,” “design concepts,” or “preliminary designs”) that potentially satisfy an appropriate set of allocated requirements.
- Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component).
-Implementing the designs as a product or product component.

Technical Solution specific practices apply not only to the product and product components but also to product-related lifecycle processes. Processes associated with the Technical Solution process area receive the product and product component requirements from the requirements management processes.

Specific Practices by Goal

SG 1 Select Product-Component Solutions
Product or product component solutions are selected from alternative solutions. Alternative solutions and their relative merits are considered in advance of selecting a solution. Key requirements, design issues, and constraints are established for use in alternative solution analysis. Architectural features that provide a foundation for product improvement and evolution are considered.
- SP 1.1 Develop Alternative Solutions and Selection Criteria.
The activity of selecting alternative solutions and issues to be subject to decision analyses and trade studies is accomplished by the involvement of relevant stakeholders. These stakeholders represent both business and technical functions and the concurrent development of the product and the product-related lifecycle processes (e.g., manufacturing, support, training, verification, and disposal).
- SP 1.2 Select Product Component Solutions.
Selecting product components that best satisfy the criteria establishes the requirement allocations to product components. Lower level requirements are generated from the selected alternative and used to develop the product component design. Interface requirements among product components are described, primarily functionally. Physical interface descriptions are included in the documentation for interfaces to items and activities external to the product.

SG 2 Develop the Design
Product or product component designs must provide the appropriate content not only for implementation, but also for other phases of the product lifecycle such as modification, procurement, maintenance, sustainment, and installation. The design documentation provides a reference to support mutual understanding of the design by relevant stakeholders and supports future changes to the design both during development and in subsequent phases of the product lifecycle.
- SP 2.1 Design the Product or Product Component.
Product design consists of two broad phases that may overlap in execution: preliminary and detailed design.
- SP 2.2 Establish a Technical Data Package.
A technical data package provides the developer with a comprehensive description of the product or product component as it is developed. Such a package also provides procurement flexibility in a variety of circumstances such as performance-based contracting or build to print.
- SP 2.3 Design Interfaces Using Criteria.
Design product component interfaces using established criteria. The criteria for interfaces frequently reflect critical parameters that must be defined, or at least investigated, to ascertain their applicability. These parameters are often peculiar to a given type of product (e.g., software, mechanical, electrical, and service) and are often associated with safety, security, durability, and mission-critical characteristics.
- SP 2.4 Perform Make, Buy, or Reuse Analysis.
The determination of what products or product components will be acquired is frequently referred to as a “make-or-buy analysis.” It is based on an analysis of the needs of the project. This make-or-buy analysis begins early in the project during the first iteration of design; continues during the design process; and is completed with the decision to develop, acquire, or reuse the product.

SG 3 Implement the Product Design
Product components are implemented from the designs established by the specific practices in the Develop the Design specific goal. The implementation usually includes unit testing of the product components before sending them to product integration and development of end-user documentation.
- SP 3.1 Implement the Design.
Once the design has been completed, it is implemented as a product component. The characteristics of that implementation depend on the type of product component. Design implementation at the top level of the product hierarchy involves the specification of each of the product components at the next level of the product hierarchy. This activity includes the allocation, refinement, and verification of each product component. It also involves the coordination between the various product component development efforts.
- SP 3.2 Develop Product Support Documentation.
Develop and maintain the end-use documentation. This specific practice develops and maintains the documentation that will be used to install, operate, and maintain the product.