The document discusses patterns, frameworks, mechanisms, and how to model them in UML. It defines patterns as common solutions to common problems, frameworks as architectural patterns providing extensible templates, and mechanisms as design patterns applying to classes. It recommends modeling mechanisms as collaborations and frameworks as stereotyped packages. It provides examples of modeling the Command design pattern as a collaboration and the Blackboard architectural pattern as a stereotyped package framework.
The document discusses patterns, frameworks, mechanisms, and how to model them in UML. It defines patterns as common solutions to common problems, frameworks as architectural patterns providing extensible templates, and mechanisms as design patterns applying to classes. It recommends modeling mechanisms as collaborations and frameworks as stereotyped packages. It provides examples of modeling the Command design pattern as a collaboration and the Blackboard architectural pattern as a stereotyped package framework.
The document discusses patterns, frameworks, mechanisms, and how to model them in UML. It defines patterns as common solutions to common problems, frameworks as architectural patterns providing extensible templates, and mechanisms as design patterns applying to classes. It recommends modeling mechanisms as collaborations and frameworks as stereotyped packages. It provides examples of modeling the Command design pattern as a collaboration and the Blackboard architectural pattern as a stereotyped package framework.
The document discusses patterns, frameworks, mechanisms, and how to model them in UML. It defines patterns as common solutions to common problems, frameworks as architectural patterns providing extensible templates, and mechanisms as design patterns applying to classes. It recommends modeling mechanisms as collaborations and frameworks as stereotyped packages. It provides examples of modeling the Command design pattern as a collaboration and the Blackboard architectural pattern as a stereotyped package framework.
• All well-structured systems are full of patterns.
• A pattern provides a common solution to a common problem in a given context. • A mechanism is a design pattern that applies to a society of classes. • A framework is typically an architectural pattern that provides an extensible template for applications within a domain. • You use patterns to specify mechanisms and frameworks that shape the architecture of your system. Mechanisms and Frameworks • In the UML, you will typically model design patterns, also called mechanisms which you can represent as collaborations. • Similarly, you will typically model architectural patterns as frameworks, which you can represent as stereotyped packages. Patterns and architecture
• Helps to visualize , specify , construct and
document the artifacts of a software intensive system. • Two different patterns – Design patterns – specify the structure and behavior of a society of classes – Architectural patterns (Frameworks) – specify the structure and behavior of an entire system. Mechanisms
• A mechanism is just another name for a design pattern that
applies to a society of classes. • A mechanism simply names a set of abstractions that work together to carry out some common and interesting behavior. You model these mechanisms as plain collaborations because they just name a society of classes. • Zoom into that collaboration, and you'll see its structural aspects (typically rendered as class diagrams), as well as its behavioral aspects (typically rendered as interaction diagrams). Figure shows a mechanism names a template for a set of abstractions that work together to carry out some common and interesting behavior. In this example, the Subject and the Observer of the pattern are bound to the concrete classes TaskQueue and SliderBar, respectively. Frameworks • A framework is bigger than a mechanism. • In fact, you can think of a framework as a kind of micro architecture that encompasses a set of mechanisms that work together to solve a common problem for a common domain. • When you specify a framework, you specify the skeleton of an architecture, together with the slots, tabs, knobs, and dials that you expose to users who want to adapt that framework to their own context. • A framework as a stereotyped package. Figure illustrates such a framework, named CyclicExecutive. Among other things, this framework includes a collaboration (CommonEvents) encompassing a set of event classes, along with a mechanism (EventHandler) for processing these events in a cyclic fashion. A client that builds on this framework (such as Pacemaker) could build on the abstractions in CommonEvents via subclassing and could also apply an instance of the EventHandler mechanism. Modeling Design Patterns • To model a design pattern, – Identify the common solution to the common problem and reify it as a mechanism. – Model the mechanism as a collaboration, providing its structural as well as its behavioral aspects. – Identify the elements of the design pattern that must be bound to elements in a specific context and render them as parameters to the collaboration. Modelling a Design Pattern Figure shows a use of the Command design pattern. As the model indicates, this design pattern has four parameters that, when you apply the pattern, must be bound to elements in a given context. This model shows such a binding, in which Application, PasteCommand, OpenCommand, MenuItem, and Document are bound to the design pattern's parameters. Modeling Architectural Patterns • To model an architectural pattern, – Harvest the framework from an existing, proven architecture. – Model the framework as a stereotyped package, containing all the elements (and especially the design patterns) that are necessary and sufficient to describe the various views of that framework. – Expose the plug-ins, interfaces, and parameters necessary to adapt the framework in the form of design patterns and collaborations. For the most part, this means making it clear to the user of the pattern which classes must be extended, which operations must be implemented, and which signals must be handled. Modelling an Architectural Pattern Figure shows a specification of the Blackboard architectural pattern. The heart of this architecture is the Blackboard design pattern, which dictates how KnowledgeSources, a Blackboard, and a Controller collaborate. This framework also includes the design pattern Reasoning engine, which specifies a general mechanism for how each KnowledgeSource is driven. Finally, as the figure shows, this framework exposes one use case, Apply new knowledge sources, which explains to a client how to adapt the framework itself.
References: Booch, Grady. The unified modeling language user guide. Pearson Education India, 2005.