Use Case Diagrams
Use Cases (uc) = the externally visible services that a system provides – as well as the actors that invoke and participate in those use cases. A black box of the system.
ConOps = Concept of Operations
A use case has the following properties:
– Use case is a service – a behavior – that your system will perform
– The use case name is always a verb phrase
– Not every behavior the system performs is a use case, instead only those that an external actor can directly invoke or participate in
– An actor can be a person or an external system
– Actors that invoke the use case are called primary actors, the ones that participate are called secondary actors, and a primary actor can be a secondary actor
– Each use case should represent primary actor’s goal
– Use case name does not convey the whole information, this is done in the use case specification
Use case specifications has the following:
– Use case name
– Scope
– Primary actor
– Secondary actor
– Stakeholder
– Preconditions
– Postconditions (guarantees)
– Trigger
– Main success scenario
– Extensions (alternative branches)
– Related information
Sometimes a graphical SysML activity diagram can be used – which tends to be more concise and less ambiguous than traditional use case specification
Sometimes a use case maybe defined too broadly, leading to many decision points and many paths of execution. This should be a red flag to rewrite the use case more concisely.
Scenarios
Scenarios are different than a use case in that within a single use case, there can be multiple scenarios. A scenario is a path of execution from beginning to end.
A sequence diagram graphically represents a single scenario. Commonly, a single use case specification is represented either by text or activity diagram – which then creates a set of sequence diagrams, one per scenario, which in turn can be used as test cases later.
Use Case Diagram
A use case diagram looks like the following. Note it has a uc denotation with a [package], model, [modelLibrary] and the view.
Use Cases can also be generalized and specialized – generalization meaning inheritance. In example above (5.1), the Send Stored Command use case is a subtype (or specialization) of Send Command use case.
System Boundary
System Boundary (subject) – represents the system that owns and performs the use case on the diagram – noted by the rectangle enclosing the use cases (not the whole diagram frame boundary). Example above is the DellSat-77.
Actors
Actors – noted as a stick figure or arectable iwht keyword <<actor>> preceding the name. Actors can also display generalizations – have a subtype that inherits the structural and behavioral features of its supertype (using triangular arrowhead). Can also utilize multiplicity – the number of instances for a use case.
Some restrictions of use cases are:
– Cannot have composite association between an actor and a use case. (a use case cannot be composed from an actor, or part of an actor, or vice versa)
– Cannot have an association between two actors
– Cannot have an association between two use cases
– Primary actor is not associated with include use cases (only the base ones)
Base Use Case
Base use case = any use case that is connected to a primary actor via an association relationship – meaning the base use case represents the primary actor’s goal. In 5.1 example, there are 4 base use cases and 1 included use case and 2 specialized use cases.
Included Use Case
Included Use Case = any use case that is the target, the element at the arrowhead end – of an include relationship – which is noted with an <<include>> marker. The include use does not convey where the included behavior is executed, only that it is executed. User would have to see the text description, activity diagram or sequence diagram to determine when and where the include use case fires.
And include use case is generally used for reuse, as during the system design/analysis, many base use cases may point to the same action, at which point that action can be communized into an include use case.
Extending Use Case
Extending use case = any use case that is the source – or element at tail end = of an extend relationship. This is not a kind of dependency, despite the similar notation of an arrowhead line. The extend use case may or may not run so its actually independent of the other use case. The triggering condition for the extend use case could be included in the diagram (like below) or it could be left out and in the activity diagram. Like included use cases, an extend use case is not to be associated with the primary actor.
Functionality with Use Cases
[1] What is the diagram kind for a use case diagram? ANS = uc; model element type is either package or block;
Use case diagram = frame represents package or block; content of diagram has set of actors and use cases with relationships; header has this form:
uc [model element type] model element name [diagram name]
[2] Which types of model elements can a use case diagram represent? ANS = package or block
[3] What does an actor represent? ANS = actor = person, organization or external system that uses some system; classified using the standard generalization relationship (ex child/specialized actor participates in all use cases of general/parent actor);
[4] How are actors represented on a use case diagram? ANS = stick figure with name underneath or rectangle with keyword <<actor>> and name; actors and use cases cannot have composite association!
[5] If one actor specializes another, what does that imply? ANS = has all use cases of the general actor and possible more of their own (specialized use cases);
[6] What does a use case represent? ANS = some functionality that system must provide to achieve some user goal; noted with an oval with name inside; neither use case nor actor can have properties – therefore their relationship is noted as a line only (no arrows);
[7] What is another term for the system under consideration? ANS = the system that provides the functionality or in focus based on the current user; or could also be called subject and represented as a block; system = subject;
[8] How does a scenario differ from a use case? ANS = scenarios paths the actors can take through the use case base on circumstances;
[9] How is an inclusion relationship represented? ANS = inclusion relationship allows one use case (base use case) to include functionality from another use case (include use case); this is not a functional decomposition but rather just and include; noted as dashed line arrow <<includes>>; the base use case may have dependencies on the include use case;
[10] Apart from a base and extending use case which two other pieces of information might an extension relationship have? ANS = the extending use case is usually a fragment that is not considered part of the base use case; base use case has no dependency on extending use case though extending use case does have dependency on the base; extending use case must have two info: noted as dashed line arrow <<extends>>
– extension points = represents places where extension occurs; ex during a particular step in the base use case;
– condition = constraints and whatever necessary for extension to occur
[11] If a use case specializes another, what does that imply about its scenarios? ANS = the specialized use case takes all the base case scenarios;
Text-based use case description should be used to provide additional information about use case definition; description should include the following:
– Precondition = conditions that must be true for use case to begin
– Postcondition = condition that must be true once use case completed
– Primary flow = the nominal flow scenarios
– Alternate / Exception flows = scenarios that are less likely to happen / off nominal
– Other information = ..
[12] How may use case participants and the system under consideration represented on an internal block diagram?
[13] How are use case participants and the system under consideration represented in interactions?
[14] How are use case participants and the system under consideration represented in activities?