UML Weekend Crash Course™ - To Parent Directory

Session 5—Understanding the Use Case Model 53
Dependency: Identifies a communication relationship between two Use Cases.
Generalization: Defines a relationship between two actors or two Use Cases where
one Use Case inherits and adds to or overrides the properties of the other.
Now comes the fun part. It’s finally time to learn the notation that will allow you to
begin developing diagrams.
Use Case system
One of the first tasks in a project is to set the context and scope of the proposed application.
You need to answer questions such as how much to include in the system, how this
system relates to other systems in your architecture, and who plans to use this system.
All this could be described in a lengthy document. But, as the saying goes, a picture is
worth a thousand words. This conviction helps explain the simplicity of the system notation,
a mere rectangle with a name (Figure 5-4). The system icon simply provides a context into
and around which you place all the elements that influence the construction of the system.
Note
Having said that, I must tell you that the system icon is rarely used. It tends
to be too restrictive and doesn’t add substantial information to the diagram.
Consequently, in most tools, you will only see Use Cases, actors, and their
relationships.
System Name
System Name
OR
Figure 5-4 System icon for the Use Case diagram
Think of the system in terms of encapsulation, which asserts that to use an object, you
need know only its interfaces, not its internal implementation. A system is like an object,
in that each has a purpose and an interface. The internal implementations of the object or
system may be replaced or enhanced without affecting other entities as long as the purpose
and the interfaces remain unchanged.
So, the priority in defining the system is to define its purpose and the required interfaces.
The purpose is the target of the project justification. The interfaces are the channels of communication
between the actors outside the system and the features of the system itself, the
Use Cases. Working inward from this fundamental requirement, you set the context for all
subsequent modeling of the system’s internal behavior.
Use Case actors
Systems always have users. Users in the classic sense are people who use the system. But
users can also be other systems or devices that trade information.