What are the different types of UML diagrams?
Use case diagrams
Depicts the typical interaction between external users (i.e. actors) and the system. The emphasis is on what a system does rather than how it does it. A use case is a summary of scenarios for a single task or goal. An actor is responsible for initiating a task. The connection between actor and use case is a communication association.
Capturing use cases is one of the primary tasks of the elaboration phase of RUP. In its simplest usage, you capture a use case by talking to your users and discussing the various things they might want to do with the system.
When to use ‘use case’ diagrams?
- Determining user requirements. New use cases often generate new requirements.
- Communicating with clients. The simplicity of the diagram makes use case diagrams a good way for designers and developers to communicate with clients.
- Generating test cases. Each scenario for the use case may suggest a suite of test cases.
Class diagram technique is vital within Object Oriented methods. Class diagrams describe the types of objects in the system and the various static relationships among them. Class diagrams also show the attributes and the methods. Class diagrams have the following possible relationships:
: A relationship between instances of 2 classes.
Aggregation: An association in which one class belongs to a collection (does not always have to be a collection. You can also have cardinality of “1”). This is a part of a whole relationship where the part can exist without the whole. For example: A line item is whole and the products are the parts. If a line item is deleted then the products need not be deleted.
: An association in which one class belongs to a collection (does not always have to be a collection. You can also have cardinality of “1”). This is a part of a whole relationship where the part cannot exist without the whole. If the whole is deleted then the parts are deleted. For example: An Order is a whole and the line items are the parts. If an order is deleted then all the line items should be deleted as well (i.e. cascade deletes).
: An inheritance link indicating that one class is a superclass of the other. The Generalization expresses the “is a” relationship whereas the association, aggregation and composition express the “has a” relationship.
: Implementation of an interface.
: A dependency is a weak relationship where one class requires another class. The dependency expresses the “uses” relationship. For example: A domain model class uses a utility class like Formatter etc.
When to use class diagrams?
- Class diagrams are the backbone of Object Oriented methods. So they are used frequently.
- Class diagrams can have a conceptual perspective and an implementation perspective. During the analysis draw the conceptual model and during implementation draw the implementation model.
To simplify complex class diagrams you can group classes into packages.
When to use package diagrams?
- Package diagrams are vital for large projects.
Object diagrams show instances instead of classes. They are useful for explaining some complicated objects in detail about their recursive relationships etc.
When to use object diagrams?
- Object diagrams are a vital for large projects.
- They are useful for explaining structural relationships in detail for complex objects.
Sequence diagrams are interaction diagrams which detail what messages are sent and when. The sequence diagrams are organized according to time. The time progresses as you move from top to bottom of the diagram. The objects involved in the diagram are shown from left to right according to when they take part.
Collaboration diagrams are also interaction diagrams. Collaboration diagrams convey the same message as the sequence diagrams. But the collaboration diagrams focus on the object roles instead of the times at which the messages are sent.
The collaboration diagrams use the decimal sequence numbers as shown in the diagram below to make it clear which operation is calling which other operation, although it can be harder to see the overall sequence. The top-level message is numbered 1. The messages at the same level have the same decimal prefix but different suffixes of 1, 2 etc according to when they occur.
When to use an interaction diagrams?
When you want to look at behavior of several objects within a single use case. If you want to look at a single object across multiple use cases then use statechart diagram as described below.
State chart diagrams
Objects have behavior and state. The state of an object depends on its current activity or condition. This diagram shows the possible states of the object and the transitions that cause a change in its state.
When to use a state chart diagram?
Statechart diagrams are good at describing the behavior of an object across several use cases. But they are not good at describing the interaction or collaboration between many objects. Use interaction and/or activity diagrams in conjunction with a statechart diagram.
Use it only for classes that have complex state changes and behavior. For example: the User Interface (UI) control objects, Objects shared by multi-threaded programs etc.
This is really a fancy flow chart. The activity diagram and statechart diagrams are related in a sense that statechart diagram focuses on object undergoing a transition process and an activity diagram focuses on the flow of activities involved in a single transition process.
In domain modeling it is imperative that the diagram conveys which object (or class) is responsible for each activity. Activity diagrams can be divided into object swimlanes that determine which object is responsible for which activity. The swimlanes are quite useful because they combine the activity diagram’s depiction of logic with the interaction diagram’s depiction of responsibility. A single transition comes out of each activity, connecting to the next activity. A transition may join or fork.
When to use activity diagrams?
The activity and statechart diagrams are generally useful to express complex operations. The great strength of activity diagrams is that they support and encourage parallel behavior. The activity and statechart diagrams are beneficial for workflow modeling with multi-threaded programming.
Component and Deployment diagrams
A component is a code module. Component diagrams are physical diagrams analogous to a class diagram. The deployment diagrams show the physical configuration of software and hardware components. The physical hardware is made up of nodes. Each component belongs to a node.