Document Actions

Share or Embed Document

Chapter 7.

Diagrams
· Diagrams, views, and models · Modeling different views of a system · Modeling different levels of abstraction · Modeling complex views · Organizing diagrams and other artifacts

System , Subsystem, Model , Diagram
A system is a collection of subsystems organized to accomplish a purpose and described by a of models, possibly from different viewpoints. A subsystem is a grouping of elements, of which some constitute a specification of the behavior offered by the other contained elements. A model is a semantically closed abstraction of a system, meaning that it represents a complete and self consistent simplification of reality, created in order to better understand the system. In the context of architecture, a view is a projection into the organization and structure of a system's model, focused on one aspect of that system. A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships).

You could never visualize the structure or behavior of that system by staring at one large diagram containing all these classes and all their relationships. You'd likely
. along with other classes. Instead. For example. in another diagram that presents an API that's used by client applications. and Office. For example. each focused on one view.Diagram
A diagram is just a graphical projection into the elements that make up a system. you might have several hundred classes in the design of a corporate human resources system. such as Person. you'd want to create several diagrams. Some of these same classes. Department. assembled to construct a database schema. you might find one class diagram that includes classes.

Object diagram 3. Deployment diagram
. 1. Component diagram 4.Static parts of a system using one of the four following diagrams. Class diagram 2.

Class Diagram
A class diagram shows a set of classes. interfaces. .
. Class diagrams that include active classes are used to address the static process view of a system. Class diagrams are the most common diagram found in modeling object-oriented systems. and collaborations and their relationships.

You use component diagrams to illustrate the static implementation view of a system. Component diagrams are related to class diagrams in that a component typically maps to one or more classes. Object diagrams address the static design view or static process view of a system just as do class diagrams. interfaces. the static snapshots of instances of the things found in class diagrams.
. You use object diagrams to illustrate data structures. 2.Object Diagram
An object diagram shows a set of objects and their relationships. or collaborations. but from the perspective of real or prototypical cases. A component diagram shows a set of components and their
relationships.
Component Diagram
1.

. 2. A deployment diagram shows a set of nodes and their relationships.Deployment diagrams are related to component diagrams in that a node typically encloses one or more components.Deployment Diagram
1. You use deployment diagrams to illustrate the static deployment view of an architecture.

1. Use case diagram : Organizes the behaviors of the system 2. Collaboration diagram : Focused on the structural organization of objects that send and receive messages 4. Statechart diagram : Focused on the changing state of a system driven by events 5. Sequence diagram : Focused on the time ordering of messages 3. Activity diagram Focused on the flow of control from activity to activity
.Behavioral Diagrams
The UML's behavioral diagrams are roughly organized around the major ways you can model the dynamics of a system.

Use Case Diagram
1.Use case diagrams are especially important in organizing and modeling the behaviors of a system.
. You use sequence diagrams to illustrate the dynamic view of a system. A sequence diagram shows a set of objects and the messages sent and received by those objects. The objects are typically named or anonymous instances of classes. 2. but may also representinstances of other things. and nodes.
Sequence Diagram
1. components. such as collaborations. 2.A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. You apply use case diagrams to illustrate the static use case view of a system.A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.

A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. 2 Statechart diagrams emphasize the event-ordered behavior of an object. They are especially important in modeling the behavior of an interface. 2. but may also represent instances of other things. and activities. links among those objects. and messages sent and received by those objects. A collaboration diagram shows a set of objects.Collaboration Diagram
1. consisting of states.
2.
1. You use state chart diagrams to illustrate the dynamic view of a system.
State chart Diagram
1. events. The objects are typically named or anonymous instances of classes. and nodes. class. which is especially useful in modeling reactive systems. transitions.
. A state chart diagram shows a state machine. components. You use collaboration diagrams to illustrate the dynamic view of a system. or collaboration. such as collaborations.

Activity Diagram
1. and objects that act and are acted upon.
. Activity diagrams are especially important in modeling the function of a system. An activity shows a set of activities. An activity diagram shows the flow from activity to activity within a system. You use activity diagrams to illustrate the dynamic view of a system. Activity diagrams emphasize the flow of control among objects. 2. the sequential or branching flow from activity to activity.

Modeling Complex Views
.Common Modeling Techniques 1. Modeling Different Levels of Abstraction 3. Modeling Different Views of a System 2.

For example.Modeling Different Views of a System
To model a system from different views. Allow room for diagrams that are thrown away.As part of your process planning. These are the diagrams for which you'll want to schedule reviews and to preserve as documentation for the project. you might need only the following handful of diagrams. 3. For the most part. 2. Such transitory diagrams are still useful for exploring the implications of your decisions and for experimenting with changes. The five views of an architecture described earlier are a good starting point.
. . if you are modeling a simple monolithic application that runs on a single machine. 4. decide which artifacts you need to create to capture the essential details of that view. these artifacts will consist of various UML diagrams. decide which of these diagrams you'll want to put under some sort of formal or semiformal control.
1. For each of these views. Decide which views you need to best express the architecture of your system and to expose the technical risks to your project.

3. Depending on where you land in this spectrum of lowto-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:
. she'll need diagrams that are at a higher level of abstraction. and start with a given model.Modeling Different Levels of Abstraction
To model a system at different levels of abstraction by presenting diagrams with different levels of detail. 1. If your reader is using the model to construct an implementation. 2. she'll need diagrams that are at a lower level of abstraction. which means that they'll hide a lot of detail. Consider the needs of your readers. If she is using the model to present a conceptual model to an end user. which means that they'll need to reveal a lot of detail.

1. expand only those messages or transitions that are essential to understanding your intent. reveal only those stereotyped items that are essential to understanding your intent.Contd«. Flow:
In the context of behavioral diagrams. such as attributes and operations.
. Adornments:
Reveal only the adornments of these building blocks and relationships that are essential to understanding your intent. Stereotypes:
In the context of stereotypes used to classify lists of things.
2.
4.
3. Building blocks and relationships:
Hide those that are not relevant to the intent of your diagram or the needs of your reader.

Interaction Diagram at a High Level of Abstraction
.

especially if your tools make it easy to navigate from one diagram to another.
. but at different levels of detail.Interaction at a Low Level of Abstraction
Both of these diagrams work against the same model. It's reasonable to have many diagrams such as these.

.

Modeling Complex Views
To model complex views. perhaps eliding some parts of the diagram and retaining the detail in other parts. First. convince yourself there's no meaningful way to present this information at a higher level of abstraction.
. then render only those packages or collaborations in your diagram. 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.

If your diagram is still complex. print it in its entirety and hang it on a convenient large wall. but you can step back from the diagram and study it for common patterns. If your diagram is still complex. You lose the interactivity an online version of the diagram brings.
.Contd«. use notes and color as visual cues to draw the reader's attention to the points you want to make.