OK, we are now ready to start exploring UML. The one point worth repeating is UML is not a method or process (such as RUP). It is a modeling language and defines a set of notations and associated rules for designing systems.
Note, UML is most often used for designing software but it is not tied to this industry. UML can be used for modeling any system, such as an airplane or car.
UML defined twelve types of diagrams. These are divided into three categories which are structure, behavior and model management.
Ø Structural Diagrams – class diagrams, object diagrams, component diagrams and deployment diagrams
Ø Behavior Diagrams – use case diagrams, sequence diagrams, activity diagrams, collaboration diagrams and state chart diagrams.
Ø Model Management Diagrams – packages, subsystems and models
Where are the diagrams used in the development process? This is often one question asked by people learning UML.
Ø Requirements Gathering – use case diagrams. Often a “Vision Document” is also created to document business drivers, influences and overall goals of the system. As was mentioned before, use cases are done in the language of the problem domain, which is the language of the users. For instance, terminology is used that accountants understand in describing a book keeping system.
Ø Analysis – high-level class, sequence and state chart diagrams. Use cases are revised from the language of the problem domain to the language of the solution domain.
Ø Design – package diagram to describe the structure of the system. Class, sequence and state chart diagrams are revised. Component diagrams are used to describe system architecture and how pieces of the system will work together. Collaboration, object, sequence and activity diagrams may be used. Finally, deployment diagrams are used to show how the system will look when installed.
Ø Build – actually none of the diagrams are specifically used in this phase, though use case diagrams should have considerable input to testing.
A lot of designers champion the idea of not drawing a diagram for the sake of saying it has been used. As a minimum use cases are usually done to understand the requirements and class diagrams for design of the system.
So, with this introduction behind us, we will start looking at the different diagram types.
Working through a process is not new in software development. This is what we call scenarios and the benefit of this was realized very soon by software developers. However, they were not often documented or at a minimum and in a manner that was difficult for users to understand.
When working with use cases in the initial stages, Requirement Gathering, the language should be the language of the users and one should attempt not to think of solutions. This is important for gaining an understanding of the current system without outside influences (This is easier said than done).
The roots of Use Cases came from Ivar Jacobsen and his Objectory method. He was the one who started calling them use cases instead of scenarios. When he joined Rational they became a core element of UML.
A Use Case is used to describe an interaction within a system. This may be a user or another computer system. Uses cases have the following properties:
Ø Captures some user visible function
Ø May be small or large. There is no specified size.
Ø It achieves a discrete goal for the user
Use cases are described by talking to different users and discussing (in their language) the various ways they may want to use the system. This is of course built on their experience with the current system or manual processes.
Often the best way is to give this a name and write up a paragraph on each interaction. These should be reviewed by you to see similarities and to make sure you are using a common language and naming conventions (that are the same used by the users).
Also, the granularity (the size or detail), of a use case is not specified. Again, this depends on the person gathering requirements and the type of system being studied. Some experts suggest that a project should not contain more than 30 use cases. If there are more, it possibly should be broken into sub-projects.
Two main components make up a use case. They are Actors and Use Cases. Below a very simple use case is shown.
This shows 4 actors and 3 use cases. Notice how actors have interaction with multiple use cases and that an actor does not have to be a person (though shown as a stick person).
Actor is a role that a person or system plays with respect to the system. An actor is not a person, a physical person may play multiple roles with a system and multiple people may carry out a role.
One hint often given when doing use case diagrams is not to start with use cases but instead start with a list of actors. Then it is easier to determine the use cases, which is the ultimate goal. Actors are important to see who uses which part of the system and determine conflicts as well as configuring the system for different users.
A use case is a name of a process, interaction or scenario (take your pick!) in a system. In our example above we had three, Maintain ATM, Use ATM and Audit. The use cases are interactions with the system and you know that the resulting system will need to implement this requirement. How many use cases are specified is one point of argument. It is usually specified as many as are needed to understand the system to the level you want. The beauty of iterative development is that you don’t dig into the details until you need to. Also, as in the case above if you can take a use case such as Audit and understand this function and which actors are involved, you don’t need to do go any further (for the moment).
An actor will have an association with a use case. This is shown with a straight line. Normally they are simple straight lines, though arrows may be used. When an arrow points to a use case this means the actor is active. Active means they initiate the interaction. When the arrow points to the actor, the actor is passive. This means the system initiates the interaction with the actor (often external systems).
Also, use cases may have an extend link between themselves. This is generally the used when there is two use cases that are similar and one does a bit more than the other. This is done not to “clutter” and existing use case. This is shown with a link between two use cases and the arrow pointing to the general use case and away from the more specific.
An include link is used to decompose a use case into smaller interactions. This is done when an initial use case was at such a high level it became difficult to describe it or as you learn more it became bigger than at first sight. This is done as shown below. Notice the dashed arrows with the arrows pointing to the sub tasks. These in turn will probably become use cases in their own right.
To learn more about the Use Case technique and an excellent book on object oriented design in general see Object-Oriented Software Engineering, A Use Case Driven Approach by Ivar Jacobson et. Al.