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

Common Modeling Techniques

Modeling Different Views of a System

When you model a system from different views, you are in effect constructing your system simultaneously from multiple dimensions. By choosing the right set of views, you set up a process that forces you to ask good questions about your system and to expose risks that need to be attacked. If you do a poor job of choosing these views or if you focus on one view at the expense of all others, you run the risk of hiding issues and deferring problems that will eventually destroy any chance of success.

To model a system from different views,

• Decide which views you need to best express the architecture of your system and to expose the technical risks to your project. The five views of an architecture described earlier are a good starting point.

• For each of these views, decide which artifacts you need to create to capture the essential details of that view. For the most part, these artifacts will consist of various UML diagrams.

• As part of your process planning, decide which of these diagrams you'll want to put under some sort of formal or semi-formal control. These are the diagrams for which you'll want to schedule reviews and to preserve as documentation for the project.

• Allow room for diagrams that are thrown away. Such transitory diagrams are still useful for exploring the implications of your decisions and for experimenting with changes.

For example, if you are modeling a simple monolithic application that runs on a single machine, you might need only the following handful of diagrams.

If yours is a reactive system or if it focuses on process flow, you'll probably want to include state diagrams and activity diagrams, respectively, to model your system's behavior.

Similarly, if yours is a client/server system, you'll probably want to include component diagrams and deployment diagrams to model the physical details of your system.

Finally, if you are modeling a complex, distributed system, you'll need to employ the full range of the UML's diagrams in order to express the architecture of your system and the technical risks to your project, as in the following.

Modeling Different Levels of Abstraction

Not only do you need to view a system from several angles, you'll also find people involved in development who need the same view of the system but at different levels of abstraction. For example, given a set of classes that capture the vocabulary of your problem space, a programmer might want a detailed view down to the level of each class's attributes, operations, and relationships. On the other hand, an analyst who's walking through some use case scenarios with an end user will likely want only a much elided view of these same classes. In this context, the programmer is working at a lower level of abstraction, and the analyst and end user are working at a higher level of abstraction, but all are working from the same model. In fact, because diagrams are just a graphical presentation of the elements that make up a model, you can create several diagrams against the same model or different models, each hiding or exposing different sets of these elements and each showing different levels of detail.

Basically, there are two ways to model a system at different levels of abstraction: by presenting diagrams with different levels of detail against the same model or by creating models at different levels of abstraction with diagrams that trace from one model to another.

To model a system at different levels of abstraction by presenting diagrams with different levels of detail,

• Consider the needs of your readers, and start with a given model.

• If your reader is using the model to construct an implementation, she'll need diagrams that are at a lower level of abstraction, which means that they'll need to reveal a lot of detail. If she is using the model to present a conceptual model to an end user, she'll need diagrams that are at a higher level of abstraction, which means that they'll hide a lot of detail.

• Depending on where you land in this spectrum of low-to-high levels of abstraction, create a diagram at the right level of abstraction by hiding or revealing the following four categories of things from your model:

  1. Building blocks and relationships :
     Hide those that are not relevant to the intent of your diagram or the needs of your reader.

  2. Adornments :
     Reveal only the adornments of these building blocks and relationships that are essential to understanding your intent.

  3. Flow :
     In the context of behavioral diagrams, expand only those messages or transitions that are essential to understanding your intent.

  4. Stereotypes :
     In the context of stereotypes used to classify lists of things, such as attributes and operations, reveal only those stereotyped items that are essential to understanding your intent.

The main advantage of this approach is that you are always modeling from a common semantic repository. The main disadvantage of this approach is that changes from diagrams at one level of abstraction may make obsolete diagrams at a different level of abstraction.

To model a system at different levels of abstraction by creating models at different levels of abstraction,

• Consider the needs of your readers and decide on the level of abstraction that each should view, forming a separate model for each level.

• In general, populate your models that are at a high level of abstraction with simple abstractions and your models that are at a low level of abstraction with detailed abstractions. Establish trace dependencies among the related elements of different models.

  Trace dependencies are discussed in Chapter 32 .

• In practice, if you follow the five views of an architecture, there are four common situations you'll encounter when modeling a system at different levels of abstraction:

  1. Use cases and their realization :
     Use cases in a use case model will trace to collaborations in a design model.

  2. Collaborations and their realization :
     Collaborations will trace to a society of classes that work together to carry out the collaboration.

  3. Components and their design :
     Components in an implementation model will trace to the elements in a design model.

  4. Nodes and their components :
     Nodes in a deployment model will trace to components in an implementation model.

The main advantage of the approach is that diagrams at different levels of abstraction remain more loosely coupled. This means that changes in one model will have less direct effect on other models. The main disadvantage of this approach is that you must spend resources to keep these models and their diagrams synchronized. This is especially true when your models parallel different phases of the software development life cycle, such as when you decide to maintain an analysis model separate from a design model.

For example, suppose you are modeling a system for Web commerceone of the main use cases of such a system would be for placing an order. If you re an analyst or an end user, you'd probably create some interaction diagrams at a high level of abstraction that show the action of placing an order, as in Figure 7-1.

On the other hand, a programmer responsible for implementing this scenario would have to build on this diagram, expanding certain messages and adding other players in this interaction, as in Figure 7-2.

Both of these diagrams work against the same model, but at different levels of detail. The second diagram has additional messages and roles. It's reasonable to have many diagrams such as these, especially if your tools make it easy to navigate from one diagram to another.

Modeling Complex Views

No matter how you break up your models, there are times when you'll find it necessary to create large and complex diagrams. For example, if you want to analyze the entire schema of a database encompassing 100 or more abstractions, it really is valuable to study a diagram showing all these classes and their associations. In so doing, you'll be able to see common patterns of collaboration. If you were to show this model at a higher level of abstraction by eliding some detail, you'd lose the information necessary to make these insights.

To model complex views,

• First, convince yourself that there is no meaningful way to present this information at a higher level of abstraction, perhaps eliding some parts of the diagram and retaining the detail in other parts.

  Packages are discussed in Chapter 12; collaborations are discussed in Chapter 28 .

• If you've hidden as much detail as you can and your diagram is still complex, consider grouping some of the elements in packages or in higher-level collaborations, then render only those packages or collaborations in your diagram.

• If your diagram is still complex, use notes and color as visual cues to draw the reader's attention to the points you want to make.

• If your diagram is still complex, print it in its entirety and hang it on a convenient large wall. You lose the interactivity that an online version of the diagram brings, but you can step back from the diagram and study it for common patterns.