UML Weekend Crash Course™ - To Parent Directory

Session 3—How to Approach the UML 25
System
Use Case Diagram
Name
Assumptions
Pre-conditions
Dialog
Post-conditions
Exceptions
Future Enhancements
Open Issues
Use Case Narrative
Activity Diagram
Figure 3-2 Elements of the Functional View
This Use Case description can be written, but I often draw the logic with an Activity diagram,
a diagram that models logic very much like a flowchart. The Activity diagram is also
useful for modeling a workflow or a business process. It can be very useful when working
with clients to determine how things are or should be done. You can also use the Activity
diagram to assess the complexity of the application, and to verify the internal consistency
of your Use Case definitions. Later in the design, you need to specify the implementation
details for methods. When the details become complicated, being able to draw them out
using the Activity diagram makes the logic much easier to understand.
The Use Case diagram describes the features that the users expect the system to
provide.
The Activity diagram describes processes including sequential tasks, conditional
logic, and concurrency. This diagram is like a flowchart, but it has been enhanced
for use with object modeling.
Static View
The Static View includes those diagrams that provide a snapshot of the elements of the
system but don’t tell you how the elements will behave. It is very much like a blueprint.
Blueprints are comprehensive, but they only show what remains stationary, hence the term
Static View. Figure 3-3 illustrates the two diagrams that make up the Static View, the Class
diagram and the Object diagram. The Class diagram is the primary tool of the Static View. It
provides a fixed look at every resource (class) and its features. It is the one diagram nearly
always used for code generation and reverse engineering.