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

Common Modeling Techniques

Modeling Roles

Objects represent single individuals in a situation or execution. They are useful within concrete examples, but most of the time we want to show general parts within some context. A part within a context is called a role. Perhaps the most important thing for which you'll use roles is to model the dynamic interactions. When you model such interactions, you are generally not modeling concrete instances that exist in the real world. Instead, you are modeling roles within a reusable pattern, within which the roles are essentially proxies or stand-ins for objects that will appear within individual instances of the pattern. For example, if you want to model the ways objects in a windowing application react to a mouse event, you'd draw an interaction diagram containing roles whose types include windows, events, and handlers.

To model roles,

• Identify a context within which several objects interact.

• Identify those roles necessary and sufficient to visualize, specify, construct, or document the context you are modeling.

• Render these roles in the UML as roles in a structured context. Where possible, give each role a name. If there is no meaningful name for the role, render it as an anonymous role.

• Expose the properties of each role necessary and sufficient to model your context.

• Render these roles and their relationships in an interaction diagram or a class diagram.

Note

The semantic difference between concrete objects and roles is subtle but not difficult. To be precise, a UML role is a predefined part of a structured classifier, such as a structured class or a collaboration. A role is not an object, but a description; a role is bound to a value within each instance of a structured classifier. A role therefore corresponds to many possible values, just as an attribute does. Concrete objects appear in specific examples, such as object diagrams, component diagrams, and deployment diagrams. Roles appear in generic descriptions as interaction diagrams and activity diagrams.

Figure 28-5 shows an interaction diagram illustrating a partial scenario for initiating a phone call in the context of a switch. There are four roles: a (a CallingAgent), c (a Connection), and t1 and t2 (both instances of Terminal). All four of these roles represent conceptual proxies for concrete objects that may exist in the real world.

Note

This example is a collaboration, which represents a society of objects and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements. Collaborations have two aspectsone structural (representing the classifier roles and their relationships) and one dynamic (representing the interactions among those prototypical instances).

Modeling the Realization of a Use Case

One of the purposes for which you'll use collaborations is to model the realization of a use case. You'll typically drive the analysis of your system by identifying your system's use cases, but when you finally turn to implementation, you'll need to realize these use cases with concrete structures and behaviors. In general, every use case should be realized by one or more collaborations. For the system as a whole, the classifiers involved in a given collaboration that is linked to a use case will participate in other collaborations as well. In this way, the structural contents of collaborations tend to overlap one another.

To model the realization of a use case,

• Identify those structural elements necessary and sufficient to carry out the semantics of the use case.

• Capture the organization of these structural elements in class diagrams.

• Consider the individual scenarios that represent this use case. Each scenario represents a specific path through the use case.

• Capture the dynamics of these scenarios in interaction diagrams. Use sequence diagrams if you want to emphasize the time ordering of messages. Use communication diagrams if you want to emphasize the structural relationships among these objects as they collaborate.

• Organize these structural and behavioral elements as a collaboration that you can connect to the use case via realization.

For example, Figure 28-6 shows a set of use cases drawn from a credit card validation system, including the primary use cases Place order and Generate bill, together with two other subordinate use cases, Detect card fraud and Validate transaction. Although most of the time you won't need to model this relationship explicitly (but will leave it up to your tools), this figure explicitly models the realization of Place order by the collaboration Order management. In turn, this collaboration can be further expanded into its structural and behavioral aspects, leading you to class diagrams and interaction diagrams. It is through the realization relationship that you connect a use case to its scenarios.

In most cases, you won't need to model the relationship between a use case and the collaboration that realizes it explicitly. Instead, you'll tend to leave that in the backplane of your model. Then let tools use that connection to help you navigate between a use case and its realization.

Modeling the Realization of an Operation

Another purpose for which you'll use collaborations is to model the realization of an operation. In many cases, you can specify the realization of an operation by going straight to code. However, for those operations that require the collaboration of a number of objects, it's better to model their implementation via collaborations before you dive into code.

The parameters, return value, and objects local to an operation provide the context for its realization. Therefore, these elements are visible to the structural aspect of the collaboration that realizes the operation, just as actors are visible to the structural aspect of a collaboration that realizes a use case. You can model the relationship among these parts using a composite structure diagram that specifies the structural part of a collaboration.

To model the implementation of an operation,

• Identify the parameters, return value, and other objects visible to the operation. These become roles of the collaboration.

• If the operation is trivial, represent its implementation directly in code, which you can keep in the backplane of your model, or explicitly visualize it in a note.

• If the operation is algorithmically intensive, model its realization using an activity diagram.

• If the operation is complex or otherwise requires some detailed design work, represent its implementation as a collaboration. You can further expand the structural and behavioral parts of this collaboration using class and interaction diagrams, respectively.

For example, Figure 28-7 shows the active class RenderFrame with three of its operations exposed. The function progress is simple enough to be implemented directly in code, as specified in the attached note. However, the operation render is much more complicated, so its implementation is realized by the collaboration Ray trace. Although not shown here, you could zoom inside the collaboration to see its structural and behavioral aspects.

Note

You can also model an operation using activity diagrams. Activity diagrams are essentially flowcharts. So for those algorithmically intensive operations that you want to model explicitly, activity diagrams are usually the best choice. However, if your operation requires the participation of many objects, you'll want to use collaborations, because they let you model the structural, as well as behavioral, aspects of an operation.

Modeling a Mechanism

In all well-structured object-oriented systems, you'll find a spectrum of patterns. At one end, you'll find idioms that represent patterns of use of the implementation language. At the other end, you'll find architectural patterns and frameworks that shape the system as a whole and impose a particular style. In the middle, you'll find mechanisms that represent common design patterns by which the things in the system interact with one another in common ways. You can represent a mechanism in the UML as a collaboration.

Mechanisms are collaborations that stand alone; their context is not a single use case or an operation but, rather, the system as a whole. Any element visible in that part of the system is a candidate for participation in a mechanism.

Mechanisms such as these represent architecturally significant design decisions and should not be treated lightly. Typically, your system's architect will devise its mechanisms, and you'll evolve these mechanisms with each new release. At the end, you'll find your system simple (because these mechanisms reify common interactions), understandable (because you can approach the system from its mechanisms), and resilient (by tuning each mechanism, you tune the system as a whole).

To model a mechanism,

• Identify the major mechanisms that shape your system's architecture. These mechanisms are driven by the overall architectural style you choose to impose on your implementation, along with the style appropriate to your problem domain.

• Represent each of these mechanisms as a collaboration.

• Expand on the structural and behavioral part of each collaboration. Look for sharing, where possible.

• Validate these mechanisms early in the development lifecycle (they are of strategic importance), but evolve them with each new release, as you learn more about the details of your implementation.