An article by rohitha
First and foremost, before delving headfirst into the basics, let’s ascertain what Use case Diagrams are in the first place. Use case diagrams can be defined as behavior diagrams that are used to illustrate a set of actions or use cases that a system or systems (subject) can perform in tandem with one or more external users of the system (actors). Each use case must offer some observable and valuable result to the actors of the system.
Use case diagrams, which are both behavior diagrams and structure diagrams – as a special case of class diagrams
where classifiers are restricted to be either actors or use cases related with association. Use case diagrams are used to illustrate:
- (external) requirements on a subject, required usages of a system – to capture what a system under construction is supposed to do;
- the functionality provided by a subject;
- the requirements, which the specific subject poses on its environment – by illustrating how the environment should interact with the subject so that it will be able to perform its services.
The elements of the use case diagram are indicated below.
Subject in Use Case Diagrams
The subject when it comes to use cases is the system under design or analysis to which a set of use cases are applied. The subject could be numerous things like a business, company, device, software systemor physical system, or a smaller subsystem. A subject may be regarded as a use case classifier playing the role of a ”subject”. The use case classifier is classifier extended with the ability to own use cases. The required behavior of the subject is indicated by one or more use cases, which are defined as per the needs of actors. The subject is shown via a rectangle with subject name in the upper corner with applicable use cases inside the rectangle and actors – outside of the system boundaries.
Business Model Subject
Use cases may be utilized to model business to analyse business processes, identify the problems being experienced, determine the opportunities to better serve customers. Subject of use cases in this case is business, enterprise, company or its division, department, team. Examples of business subjects:
- Department Store
UML provides no standard stereotypes to model business processes but we can use custom stereotypes like «business» or «department», if needed for clarity.
Example below shows «business» Restaurant with business actors Customer, Advertiser and Supplier and related business use cases.
Example below shows typical misconception for the «business» Restaurant with business actors mistakenly including Waiter and Cashier. These are both working for the restaurant and are part of the business. They should not be shown as actors because actors are external users (customers) of the business (system).
Software System Subject
System use cases describe a system that automates some business use case(s) or process. The subject in this case is software and/or hardware system, subsystem, component or device. Examples of systems:
- Web Site
- Payment System
- Automated Teller Machine (ATM)
- Point of Sale (POS) Terminal
Applicability of Use Cases
Use cases visually located inside the system boundaries are use cases applicable to the subject (but not necessarily owned by the subject).
It is possible for some use cases to be applicable to multiple subjects.
Ownership of Use Cases
In UML 2.4 subject could own some or all of applicable use cases. This owning (nesting) of a use case is represented using the standard notation for nestedclassifier.
With that wrapping up today’s post, stay tuned for more on Use Case Diagrams on this space soon!