Sie sind auf Seite 1von 10

Example: Actors in a University Course

Registration Sys.
Student
o A student interacts with the system to register for courses
Lecturer
o A lecturer interacts with the system to select courses to teach
Registrar
o The Registrar interacts with the system to create the curriculum and to generate a timetable
for the semester , and also to maintain the information about courses, lecturers, and students
Billing System
o Billing System interacts with the system to obtain all the billing information on the system

Actors for Course Registration System




Use Case
Use case icon: ellipse;
Use case name: a label inside or below the ellipse icon;
Use case documentation: textual description (optional);
Use case generalisation to inherit behaviour;
Use case extension stereotypes <<include>> (to include factored out common behaviour) and
<<extend>> (to extend into variants by adding extra behaviour)
A typical use of a Computer System by an external user (actor) involving one or more sequences
of actions in the system on behalf of the user;
Capture of a system functionality (user requirement) in a use case;
Use case realized by a collaboration in the system;
Use case instance manifests as a scenario;
A use case encompasses all possible scenarios for it.
Use Case Icon



Documentation Property of Use Case
To fully specify a use case its documentation must contain:
1.
Purpose: goal being achieved, functionality provided by it
2.
User: actor initiating it
3.
Messages exchanged with actors: events, updates, retrievals, decision making
4.
Generalisations
5.
Extension stereotypes: <include>> & <<extend>>
6.
Scenarios as use case instances to complement use case description
7.
Alternative scenarios and Exceptions
8.
Succinct but informal for communicating with user
9.
Termination conditions, results returned to actors
10.
Activity diagrams to supplement the use case, if needed
11.
Example: Register for Course use case:
(a)
Use case started by Student
(b)
Provides facility to create, delete, modify, and/or review a student schedule for a specified term

Use Case Relationships
Communicates - Participation of an actor in a use case;
Generalisation - Inheriting parent behaviour, adding and overriding with the child's own behaviour;
<<include>> Relationship - One Use Case including another use case to include the latter's
behaviour
<<extend>> Relationship - One Use case is extended to another use case so that the latter has the
behaviour of the former in addition to its own; extension can only be done at extension points of the use
case being extended.
<<include>> Relationship
Behaviour common to many use cases - factored off into another use case used by the others
Example: Analyse Deal and Price Deal use cases both use Valuation use case
Example: Signing Car Insurance use case and Signing Life Insurance use case both use Signing
Insurance Policy use case


<<include>> use cases must be used by the use cases that use them before the latter can be
complete
Stereotyped Relationship
<<extend>> Relationship
A use case extends another use case to do more than the latter
Example: Capture Deal use case (keeps to the specified limits) is extended by Exceed Limits use
case (to include Capture Deal with limits exceeded)
Example: Signing Car Purchase Contract use case (normally not dealing with insurance) is
extended by Signing Insurance Policy use case (to include the car sale with an insurance for it)


<<extend>> adds more info to allow the already complete use case to extend its use (Stereotype)
Commentary
The notation for the relationship between use cases has changed more than once. The current usage is dashed line
with open arraow-head. For <<extend>> the arrow head is at the use case being extended. For <<include>> the
arrow head is at the included use case.
Use Case Diagrams
External actors outside the box representing current system
Use cases for the system inside the box
Determine the functionality of the system as seen by actors communicating to it
Communication association between actors and use cases
Generalisation relationship between use cases
Extend and Include relationship between use cases
Documentation property: textual documentation of functionalities
Sequence, collaboration and activity diagrams associated with the use case diagram for
information on flow of events
Use case model package containing use cases and actors with relations among them.

Use Case Diagrams



Example: University Course Registration
Determine Actors:
o Names
o Documentations (brief descriptions - iterative)
Determine Use Cases
o Names
o Documentations (brief descriptions, and also documentation of the flow of events - iterative)
Determine Use Case Relationships
Draw Use Case Diagrams
Actors in University Course Registration
Actor names:
o Student
o Lecturer
o Registrar
o Billing System
Actor documentations (brief descriptions)
o Student: a person registered to take classes at the University.
o Lecturer: a person who is certified to teach classes at the University.
o Registrar: the person who is responsible for the maintenance of the University Course
Registration System.
o Billing System: the external system responsible for student billing.
Actors


Use Cases in University Course Registration
Use case names
Use case documentations
Use case events flow documentations
Use case relationships
Use case diagrams
Use Case Names
Register for courses
Select course to teach
Request course roster (time-table)
Maintain course information
Maintain lecturer information
Maintain student information
Create course catalogue
etc.
Use Cases



Use Case Documentations
Register for courses: started by the Student; provides the capability to create, delete, modify, and/or
review a student schedule for a specified semester.
....
Use Case Event Flow Documentations
....
Select course to teach:
o Preconditions:
o Main Flow:
If the activity selected is ADD, then S-1: Add a Course Offering sub-flow is
performed.
...
o Sub-flows:
S-1: Add a Course Offering ...
S-2: ...
o Alternative Flows:
E-1: An invalid lecturer ID number is entered. The user can re-enter a lecturer id
number or terminate the use case.
E-2: ...
o ....
Use Case Relationships
Communication Association:
o Between an actor and a use case
o Uni-directional or bi-directional
o Uni-directional association shown by an arrow head to the destination
Relationships between use cases:
o Include or extend
o Stick arrow head is put nearest to the use case that is being used
o Stick arrow head is put next to the base use case that is being extended.
o Include and extend are stereotype associations between use cases
Example Use Case Relationship


Use Case Diagrams in Course Registration System
Main
o system boundary (actors)
o functionality (use cases)
o communication associations between actors and use cases
o use case relationships (if any): generalisation
o <<include>> and <<extend>> relationships between use cases: to include or extend
usecases
Additional use case diagrams:
o all the use cases for a selected actor
o all the use cases implemented in an iteration
o all the relationships (to actors and use cases) for a use case
o etc.
Main Use Case Diagram


Additional Use Case Diagram


Testing Use Cases
Validation: making sure that use case matches user requirement, i.e., use cases are correctly
specified.
o Walk-throughs with user to ensure that all the required use cases are there.
Verification: making sure that system built has the functionality of the use case, i.e., use-cases are
correctly implemented.
o Every use case is implemented to produce the functionality specified by it.
Realizing Use Cases
A use case is realized in a collaboration. A collaboration is an implementation of a use case in
terms of classes/objects and their relationships called its context. The interactions in the collaboration
achieve the functionality of the use case.
A collaboration is represented as a number of diagrams showing its context and interactions
between them. The context is made up of classes. The interactions are the collaboration diagrams, sequence
diagrams, and activity diagrams.
A scenario is an instance of a use case or a collaboration. The scenario is a specific execution path
(a specific flow of events) that represents a specific instantiation of the use case. Its external behaviour is an
instance of the use case. Its internal representation is the collaboration between the implementing
classes/objects and their interactions.
Commentary
Collaboration describes the sequence of class diagrams that implement the corresponding use case.
Scenario
Instance of a use case: one path in the flow of events for use case
Scenarios help to determine objects, classes, object interactions for a functionality specified by a
use case
Primary scenario: normal flow
Secondary scenario: what-if cases
Two types of interaction diagrams for scenarios: Sequence (time order), collaboration (object
linkage order)
Use Case Realization: Collaboration






Use Case, Collaboration, Scenario

Das könnte Ihnen auch gefallen