The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Common Modeling Techniques

Modeling Design Patterns

One thing for which you'll use patterns is to model a design pattern. When you model a mechanism such as this, you have to take into account its inside as well as its outside view.

When viewed from the outside, a design pattern is rendered as a parameterized collaboration. As a collaboration, a pattern provides a set of abstractions whose structure and behavior work together to carry out some useful function. The collaboration's parameters name the elements that a user of this pattern must bind. This makes the design pattern a template that you use in a particular context by supplying elements that match the template parameters.

When viewed from the inside, a design pattern is simply a collaboration and is rendered with its structural and behavioral parts. Typically, you'll model the inside of this collaboration with a set of class diagrams (for the structural aspect) and a set of interactions (for the behavioral aspect). The collaboration's parameters name certain of these structural elements, which, when the design pattern is bound in a particular context, are instantiated using abstractions from that context.

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.

For example, Figure 29-4 shows a use of the Command design pattern (as discussed in Gamma et al.,

Design Patterns , Reading, Massachusetts: Addison-Wesley, 1995). As its documentation states, this pattern "encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations." As the model indicates, this design pattern has three parameters that, when you apply the pattern, must be bound to elements in a given context. This model shows two such bindings, in which PasteCommand and OpenCommand are bound to separate bindings of the pattern.

The parameters are the AbstractCommand, which must be bound to the same abstract superclass in every case; the ConcreteCommand, which is bound to the various specific classes in various bindings; and the Receiver, which is bound to the class on which the command acts. The Command class could be created by the pattern, but making it a parameter permits multiple command hierarchies to be created.

Note that PasteCommand and OpenCommand are both subclasses of the Command class. Very likely, your system will use this pattern a number of times, perhaps with different bindings. The ability to reuse a design pattern like this as a first-class modeling element is what makes developing with patterns so powerful.

To complete your model of a design pattern, you must specify its structural as well as its behavioral parts, which represent the inside of the collaboration.

For example, Figure 29-5 shows a class diagram that represents the structure of this design pattern. Notice how this diagram uses classes that are named as parameters to the pattern. Figure 29-6 shows a sequence diagram that represents the behavior of this design pattern. Note that the diagram is only suggestive of the possibilities; a design pattern is not a rigid thing.

Modeling Architectural Patterns

The other thing for which you'll use patterns is to model architectural patterns. When you model such a framework, you are, in effect, modeling the infrastructure of an entire architecture that you plan to reuse and adapt to some context.

A framework is rendered as a stereotyped package. As a package, a framework provides a set of elements, includingbut certainly not limited toclasses, interfaces, use cases, components, nodes, collaborations, and even other frameworks. In fact, you'll place in a framework all the abstractions that work together to provide an extensible template for applications within a domain. Some of these elements will be public and represent resources that clients can build on. These are parts of the framework that you can connect to the abstractions in your context. Some of these public elements will be design patterns and represent resources to which clients bind. These are the parts of the framework that you fill in when you bind to the design pattern. Finally, some of these elements will be protected or private and represent encapsulated elements of the framework that are hidden from the outside view.

When you model an architectural pattern, remember that a framework is, in fact, a description of an architecture, albeit one that is incomplete and possibly parameterized. As such, everything you know about modeling a well-structured architecture applies to modeling well-structured frameworks. The best frameworks are not designed in isolation; to do so is an guaranteed way to fail. Rather, the best frameworks are harvested from existing architectures that are proven to work, and the frameworks evolve to find the slots, tabs, knobs, and dials that are necessary and sufficient to make that framework adaptable to other domains.

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.

For example, Figure 29-7 shows a specification of the Blackboard architectural pattern (as discussed in Buschmann et al.,

Pattern-Oriented Software Architecture , New York, NY: Wiley, 1996). As its documentation states, this pattern "tackles problems that do not have a feasible deterministic solution for the transformation of raw data into high-level data structures." 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.