DESIGN PATTERN.pptx
- 2. DESIGN PATTERN • A design pattern is “a generalized solution to a commonly occurring problem.” • A design pattern is away of organizing a design that improves the optimality of a design with respect to one or a small set of design criteria, such as qualities of service(QoS). • A design pattern always has a focused purpose–which is to take one or a small set of these QoS properties and optimize them at the expense of the others. Each pattern optimizes some aspect of a system at the cost of deoptimizing some other aspects. These constitute a set of pros and cons.
- 3. BASIC STRUCTURE OF DESIGN PATTERNS • Name: The name provides a “handle” or means to reference the pattern. • Purpose: The purpose provides the problem context and the QoS aspects the pattern seeks to optimize. The purpose identifies the kinds of problem contexts where the pattern might be particularly appropriate. • Solution: The solution is the pattern itself. • Consequences: The consequences are the set of pros and cons of the use of the pattern.
- 4. NAME • The pattern name brings us two things. First, it allows us to reference the pattern in a clear, unambiguous way, with the details present, but unstated. • Secondly, it gives us a more abstract vocabulary to speak about our designs. • The statement “The system uses a Homogeneous Channel redundant architecture with Cyclic Executive Concurrency distributed across a set of processors with a Proxy Pattern” has a lot of information about the overall structure of the system because we can discuss the architecture in terms of these patterns.
- 5. PURPOSE • The statement “The system uses a Homogeneous Channel redundant architecture with Cyclic Executive Concurrency distributed across a set of processors with a Proxy Pattern” has a lot of information about the overall structure of the system because we can discuss the architecture in terms of these patterns. SOLUTION • The solution specifies the structure and behavior of the pattern itself. It identifies the elements of the pattern and their roles in the context of the pattern. • This pattern solution is integrated into your design in a process known as pattern instantiation.
- 6. CONSEQUENCES • The consequences are important because we always make trade offs when we select one pattern over another. • We must understand the pros and cons of the pattern to apply it effectively. • The pros and cons are usually couched in terms of improvement or degradation of some design properties, as well as a possible elaboration of problem contexts in which these consequences apply.
- 7. WHAT TO DO WHEN YOU’RE FACING DESIGN PROBLEMS?
- 8. PATTERN HATCHING–LOCATING THE RIGHT PATTERNS • Familiarize yourself with the patterns: Before starting your design, familiarize yourself with the patterns literature. Once you have increased your vocabulary to include patterns likely to be relevant to your application domain, you have more intellectual ammunition to face your design challenges. • Identify design criteria: In parallel with reading about potential design alternatives, you must identify design criteria. This step identifies the design optimizations that are important for this particular system in its operational and development contexts. • Rank design criteria: Not all optimizations are equally important. For this reason, the design criteria must be ranked to enable good trade off decisions to be made.
- 9. PATTERN HATCHING–LOCATING THE RIGHT PATTERNS • Identify potential design alternatives: This step finds patterns that optimize the design criteria of importance at a cost that seems reasonable. While it is possible to add a single pattern at a time in this way and repeat the work flow, it is also common to consider a set of compatible patterns together as a single design alternative. • Evaluate the design alternatives: Using the trade study approach suggested earlier, this step compares the design alternatives (consisting of one or more design patterns) against each other on the basis of their effectiveness against the design criteria, weighted with the relative importance of each.
- 10. PATTERN HATCHING–LOCATING THE RIGHT PATTERNS • Select and apply design alternative: Once a design alternative is selected, the patterns are usually added to the collaboration one at a time, including verification of the efficacy of the solution. • Verify design functionality: The collaboration of software elements worked before applying the design patterns. This task ensures that it still does. • Verify design goals are met: Once the design functionality is verified, we must also ensure that the optimization goals of the design decisions result in the right trade offs. If we’ve optimized the code for memory usage, the usage should be measured as the software runs.
- 11. PATTERN HATCHING–LOCATING THE RIGHT PATTERNS
- 12. PATTERN MINING-ROLLING YOUR OWN PATTERNS • Creating your own pattern is useful, especially when you have a depth of experience to understand the optimization issues in a particular area, and sufficient breadth to understand the general properties of the solutions enough to abstract them in to a generalized solution. • This is called pattern mining.
- 13. PATTERN INSTANTIATION–APPLYING PATTERNS IN YOUR DESIGNS • Pattern instantiation is the opposite of pattern mining. It is applying the pattern to a particular collaboration to gain the benefits of the pattern. • Patterns are normally applied to a collaboration of software elements, such as classes, types, functions, and/or variables. • The application or instantiation of a pattern in your design is a matter of identifying the elements in your collaboration that fulfill the pattern parameter roles.
- 14. AN EXAMPLE: DEBOUNCING PATTERN • Abstract: Push buttons, toggle switches, and electromechanical relays are input devices for digital systems that share a common problem–as metal connections make contact, the metal deforms or “bounces”, producing intermittent connections during switch open or closure. This pattern addresses this concern by reducing the multiple signals into a single one by waiting a period of time after the initial signal and then checking the state. • Problem: As the metal in input devices, used for embedded systems, moves into contact, physical deformation occurs resulting in an intermittent bouncing contact until the vibrations dampen down.
- 15. AN EXAMPLE: DEBOUNCING PATTERN • Pattern Structure: The basic solution is to accept the initial event, wait for the vibrations to dampen out, and then sample the data source for its state.
- 16. AN EXAMPLE: DEBOUNCING PATTERN • Collaboration Roles: 1. Application Client: This element is the ultimate recipient of the debounced event. Its operation deviceEventReceive() is only activated when the event is real (i.e., results in a changed device state). 2. Bouncing Device: The Bouncing Device represents the hardware for the device itself. The most common implementation of this device is completely in hardware. 3. Debouncer: The Debouncer is the software element that processes the incoming event, debounces it, and makes sure that it represents an actual device state change. 4. Debouncing Timer: This timer provides an on busy wait via its delay() service. This is often done with an OS call but might be done with specialty timer hardware as well.
- 17. AN EXAMPLE: DEBOUNCING PATTERN • Consequences: This pattern is not necessary for hardware that debounces before announcing events. In my experience, however, it often falls on the software to perform this task. This is a simple pattern that performs the debouncing so that the application need only concern itself with true events resulting from a change in device state. • Implementation Strategies: It is common for the device to use an interrupt vector to contact its client. It is common for the Bouncing Device to be entirely implemented in hardware so that when the event occurs, a hardware interrupt is created, and the device state must be verified by reading a memory location or portaddress. When the event interface is via an interrupt, the address of the DeviceClient::eventReceive() operation must be installed in the proper location in the interrupt vector table when the DeviceClient is initiated.
- 18. AN EXAMPLE: DEBOUNCING PATTERN EXAMPLE: