Gregory M. Kapfhammer

Chapter Seven: Diagrams

We can use Unified Modeling Language (UML) diagrams to model the static and dynamic aspects of a software system. Briefly review diagrams that associated with these static and dynamic parts of software. There are many different types of UML diagrams that can be used in many different situations. What steps would you take to determine which types of UML diagrams you will use to express the design of your software system? Briefly discuss some general principles that the authors provide for drawing diagrams. Can you provide any more principles?

1. The diagrams that are associated with the static diagrams are Class Diagrams, Object Diagrams, Component Diagrams, and Deployment Diagram.

The diagrams that allow for the view of dynamic parts of a system are Use Case Diagram, Sequence Diagram, Collaboration Diagram, and Activity Diagram.

No matter what the diagram you choose for you project, they will all contain a unique name and most likely, it will be contained in a package.

2. First you would decide which views you best be expressed by technical risks to your project. For this you can use the five views of architecture. Then for each of the views, you have to decide which artifacts you need and don't need. Then you will have to decide which of the diagrams you will want to put under some sort of formal and semi-formal control. These diagrams will preserve the documentation for the project. After these things, you will have to allow for room of diagrams you don't need. There will be a period of dicision making and also changes.

3. Always consider the needs of your reader. Make sure that your diagrams have a lot of detail and also make sure that your diagrams are in a good spectrum of low-to-high levels of abstraction. Depending on the abstraction, there are 4 different categories you can fall into. The first is the Building blocks of relationships, second is adornments, 3rd is the Flow and the 4th is the Stereotypes.

Chris Howell

---

1) Static diagrams:
1. Class diagrams
2. Object diagrams
3. Component diagrams
4. Deployment diagrams

Dynamic diagrams:
1. Use case diagrams
2. Interaction diagrams:
2a. Sequence diagram
2b. Collaboration diagram
3. Statechart diagram
4. Activity diagram

2) The first step you would take is to decide which views will best show your architecture of the system and also to expose the technical risk of your system. You may want to consider using the five views of an architecture. Then you want to figure out for each of the five views, the artifacts you need to create to capture the essential details of that view. Then decide which diagrams you would want to keep as documentation for the project. Finally leave some diagrams be able to be thrown away. These are the diagrams that you use to experiment with changes during the project.

3) First you must remember your reasoning behind the diagrams, to visualize, specify, construct, and document. Also remember that not all of the diagrams are made to be kept. Some will be thrown away after they serve their purpose. Do not clutter your models. Stay away from redundant diagrams. Keep it simple, but not so simple the reader can not get your point. Leave out details so that your reader does not get confused. Keep a nice balance between static and dynamic diagrams. Do not create large or small diagrams. Large ones are sometimes hard to read and small ones may not get your point across. Keep your diagram organize and be sure that it expresses your idea clearly. Give your diagram a specific name that has to do with its purpose. Lay out its elements to minimize lines that cross. Organize its elements out spatially, such that elements that are semantically close be physically close. Use notes and colors to help visualize the important parts. I think one thing to keep in mind it to remember that these are for the reader. Keep things simple enough so that the reader can understand without the knowledge that you have about the project.

John Pacino

---

1. The static diagrams are: Class diagrams, Object diagrams, Component diagrams, and Deployment diagrams.
the dynamic diagrams are: Use case diagrams, Sequence diagrams, Collaboration diagrams, Statechart diagrams, and Activity diagrams.
all require a unique name, and should be organized into packages.

2.

1. Decide which views to use to express the architecture of the system and expose the thecnical risks of the project.
2. Decide which artifacts (UML diagrams) are needed to create to capture the details of that view.
3. Decide which diagrams to put under control, these will be used to schedule reviews and to preserve as documentation for the project.
4. Allow room for diagrams to be thrown away, to be used to explore the implications of decisions and to experiment on.

3. Start with a given model and consider the readers needs. Remember that diagram are the means to the end of deploying an executible system. its okay to create a throwaway diagram. try not to have redundant diagrams. keep them simple but detailed, not too big or too small. give them unique and meaningful names and grouped into packages. use tools to help design the diagram. use notes and visual cues to highlight important features. provide written explanations, for others.

---

Deb Wright

Here is a question for everyone: you all mentioned that you must try to create a diagram that exposes the technical risks that are associated with a project. What are these technical risks? How do you initially identify these technical risks?

Also, do you feel that it is necessary to always use a tool like ArgoUML to draw your UML diagrams? Or, is it better to spend some time just drawing them on the whiteboard? Finally, how will you know when it is appropriate to throw away a diagram? How do you determine that a diagram has little or no utility? Greg

---

Link to this Page

• Software Design last edited on 14 October 2004 at 2:29 pm by aldenv28.allegheny.edu