1. UML Use Case Diagram / Use Case Text / Activity Diagram
NP 3,5-7,18,19
UML Use Case Diagram / Use Case Text / Activity Diagram
23 September 2010

2. Requirements analysis
Figure out what the users and customers of a software effort want the system to do.
A class diagram drawn from the conceptual perspective (, which can be a good way of building up a rigorous vocabulary of the domain)
Use cases, which describe how people interact with the system

3. Software requirements
problem
domain
Needs
Features
solution
domain
Software requirements
(stakeholders needs)
Responsibility to understand the needs of users and other stakeholders whose lives will be affected by our solution.
(features of the system)
1st , it will be helpful to sate what we learned in the problem domain and how we intend to resolve those issues via the solution.
such as the program will be web-enabled.
descriptions called features –feature = a service provided by the system that fulfills one or more stakeholder needs. {discovery}
(software requirements)
Established a feature and gained agreement with the customer, we can move on to defining the more specific requirements we will need to impose on the solution.

4. Use Case approach Library user Books database Library staff
library system
Lending services
Lending services
Library user
Books database
User administration
Library staff

5. Use Case modelling
Use Case model – A model that describes the functional requirements of a system in terms of use cases.
A use case model partitions system functionality into
requirements / goals / transactions (‘use cases’) that are
meaningful to users (‘actors’);
and is shown on a use case diagram
System developers and customers/end-users discuss a use case model. {In an iterative process, this lead to a requirement specification on which all agree.}
Use Case model: a view of a system that emphasizes the behaviour as it appears to outside users.
A use case model partitions system functionality into
goals / transactions (‘use cases’) that are
meaningful to users (‘actors’).
System developers and customers/end-users discuss a use case model. {In an iterative process, this lead to a requirement specification on which all agree.}

6. UML Views Implementa-tion view Design view Use Case view
vocabulary
functionality
system assembly
configuration management
Implementa-tion view
Design view
Een model maken van een complex systeem is een enorme opgave.
(modelling a system’s architecture)
Een systeem kan niet weergegeven worden in een schema omdat die niet alle informatie kan bevatten om dat systeem te beschrijven.
Het bestrijkt een aantal aspecten. Door een systeem in een aantal views te beschrijven, vormt elke view een projectie van de complete systeembeschrijving en een bepaald aspect van het systeem.
Elke view wordt uitgedrukt in een aantal diagrammen met informatie die een bepaald aspect van het systeem benadrukt.
Use case view een view die het gedrag, de functionaliteit van het systeem toont zoals deze door externe actors (externe entiteiten, bvb gebruikers) wordt waargenomen. Beïnvloed alle views maar specificeert niet echt de organisatie van een software systeem.
Design view: laat zien hoe de functionaliteit binnen het systeem is ontworpen, in termen van de statische structuur en het dynamisch gedrag van het systeem. (objecten en relaties) omvat classes, interfaces, and collaboratieons en vormt de vocabulaire van het probleem and haar oplossing.
static aspects  class & object diagrams; dynamic aspects in interaction diagrams, state diagrams en activity diagrams.
Interaction view: toont de flow of control among its various parts, including possible concurreny and synchornisation mechanisms. same kind of diagramas as design view but with the focus on active classes that control the system and messages that flow between them.
en die de concurrency in het systeem laat zien en (de communicatie- en synchronisatieproblemen van een parallel systeem aanspreekt.) opdeling van het systeem in processen en processors (niet functioneel kenmerk)
Implementation view: een view die de organisatie van de code-componenten weergeeft.implementatiemodules en hun afhankelijkheden. het realiseren van het fysieke systeem.
Deployment view Opstellingsview: een view die de inpassing van het systeem in de fysieke architectuur met computers en nodes aangeeft. (deployment) de fysieke opstelling van het systeem in termen van bvb computers en devices (nodes)
Logical = laat zien hoe de functionaliteit binnen het systeem is ontworpen, intermen van de statische structuur en dynamisch gedrag van het systeem (objecten en classes)
Physical = de inpassing van het systeem binnen de fysieke architectuur van computers en nodes (devices)
Use Case view
behaviour
Interaction view
Deployment view
performance
scalability
throughput
system topology
distribution
delivery
installation
physical
logical

7. Use Case definition Fowler: Cockburn:
A use case is a typical interaction that a user has with a system in order to achieve some goals.
A use case is a description of a set of sequence of actions, including variants, that a system performs to yield an observable result of value to an actor.
Cockburn:
A use case describes a system’s behavior.
Use case: the specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside objects to provide a service of value.
The purpose of a use case is to define a piece of behavior of a classifier (including a subsystem or the entire system), without revealing the internal structure of the classifier. The classifier whose behavior is described is called the subject.
Actors – what exists outside the system (Rumbaugh) [external “participants”/”roles”
Associations to actors – an association between an actor and a use case indicates that the actor instance communicates with the subject instance to effect some result that is of interest to the actor.
Extend – kind of dependency

8. Actor
An actor is someone or something that interacts with the system. It is who or what uses the system.
An actor communicates with the system by sending and receiving messages.
An actor is a role that a user plays with respect to the system.
ActorName

9. Use Case
A use-case is a set of sequences of actions a system performs that yield an observable result of value to a particular actor.
A use-case describes a requirement for the system, that is, what it should do, but not how it should do it.
A use-case is a set of scenarios tied together by a common user goal.
UseCaseName

10. System boundary
Represents the boundary between the (physical) system and the actors who interact with the (physical) system.

11. Use Case Diagram
A diagram that shows the relationships among actors and use cases within a system.

12. Include (Uses) relationship
Include : this relationship is used when there is a common chunk of behaviour across more than one use case.
Primary use case includes the functionality of included use case.

13. Use case relationships
generalization
These use cases are varieties of Arrange Payment

14. Generalization relationship
Generalization is used when there is one use case similar to another.
Inheriting parent behaviour, adding and overriding with the child’s behaviour.
Sub use case inherits behaviour and semantics from super use cases.

15. Use case relationships
generalization
These use cases are varieties of Arrange Payment

16. Use case relationships
generalization
These use cases are varieties of Arrange Payment

17. Extend relationship
Extend is used to add behaviour to the primary use case at certain extension points.
A use case is optionally extended by functionality of another use case.

18. D2D example D2D is a commercial online dating service Requirements
Interest
Subscribe
Request for a subscription
Cancel a subscription
Profiles
Inspect a profile
Modify a profile
Messages
News
Singles kunnen in betrekkelijke anomiteit contact leggen met andere alleenstaanden.
Je abonneert je op d2d vias de website. Vult persoonlijke gegevens en de gegevns van de creditcard in.
Gegevens correct  via gebruikersnaam en wachtwoord via .
als abonnee up-to-date laten houden over interessante of gewijzigde profielen .
Identificeer processen waar het om gaat.
Interesseren – alle iniatieven opgenomen om bezoekers te interesseren voor abonnement.
Abonneren – als bezoeker geinteresseerd dan abonneren.
Activiteiten die abonnees kunnen ontplooien
Profielen – als een abonnee een interessant profiel vindt dan bericht sturen. De aangeschreven kan daarop reageren  berichtenverkeer = berichten.
Ook nieuws.
Splits een proces(diagram) zodra het onoverzichtelijk wordt. Verplaats een gehele tak.

19. Request for subscription
D2D example
D2D is a commercial online dating service
Requirements
Interest
Subscribe
Request for a subscription
Cancel a subscription
Profiles
Inspect a profile
Modify a profile
Messages
News
D2D
Request for subscription
Inspect profile
Modify profile
Cancel subscription
Singles kunnen in betrekkelijke anomiteit contact leggen met andere alleenstaanden.
Je abonneert je op d2d vias de website. Vult persoonlijke gegevens en de gegevns van de creditcard in.
Gegevens correct  via gebruikersnaam en wachtwoord via .
als abonnee up-to-date laten houden over interessante of gewijzigde profielen .
Identificeer processen waar het om gaat.
Interesseren – alle iniatieven opgenomen om bezoekers te interesseren voor abonnement.
Abonneren – als bezoeker geinteresseerd dan abonneren.
Activiteiten die abonnees kunnen ontplooien
Profielen – als een abonnee een interessant profiel vindt dan bericht sturen. De aangeschreven kan daarop reageren  berichtenverkeer = berichten.
Ook nieuws.
Splits een proces(diagraM0 zodra het onoverzichtelijk wordt. Verplaats een gehele tak.

20. Primary use cases : examples
Request for subscription
Inspect profile
Modify profile

21. Separation
If there are many requirements (also called processes in this stadium); a requirement can be managed separately.
In the case of D2D Profiles:
Inspect a profile
Look for a profile
Consult a profile
Modify a profile

22. Secondary use cases : an example
Use cases that supports the use case request for a subscription

23. Secondary use cases : an example
Use cases that supports the use case request for a subscription
Import a subscription
Validate a subscription
Import credit card
Validate credit card
Mail confirmation by

24. Secondary use cases : an example {uses include / extend relationships}
Request for subscription
Inspect profile
Modify profile
Cancel subscription
D2D
Request for subscription
Inspect profile
Modify profile
Cancel subscription
D2D
Request for subscription
Validate subscription
Import subscription
Import creditcard
Validate creditcard
Mail confirmation
<<include>>
<<extend>>

25. Secondary use cases : an example {uses generalization relationships}
Renew subscription
Pay subscription
<<include>>
Pay subscription with Creditcard
Pay subscription via Collection
Pay subscription via Account

26. Use Case diagram – secondary actor
Request for subscription
Validate subscription
Import subscription
Import creditcard
Validate creditcard
Mail confirmation
<<include>>
<<extend>>
Credit card company

27. Use case description
A use case can be described by a use case text, including the next characteristics:
Name: the name of the use case concisely
Actors: the involved actors
Precondition: condition of the system at the start of the use case
Stepwise description: interaction between system and actor(s)
Exception: exceptional cases
Result: post condition of the system

28. Use case text example from Inspect a profile
Look for profile
Inspect preferences
<<include>>
<<extend>>
Inspect profile
<<extend>>
Inspect photo
<<extend>>
Mail message

29. Use case text example from Inspect a profile Use case ‘mail a message’
Name mail a message
Actors subscriber, visitor
Precondition profile is known, actor is logged in
Description 1. get the profile
2. show web page
3. actor types in a new message
4. actor confirms mailing the message
5. application (d2d) sends message to profile
6. actor receives confirmation of sending a message
Result message mailed to profile; or actor has canceled

30. Scenario
A scenario is a sequence of steps describing an interaction between a user and a system.
A scenario is an instance of a use-case.
A scenario describes a possible interaction with the system.

31. Scenario for use case ‘log in subscriber’
Description
Validate number of invalid logins .
If number of invalid logins more than 2, stop.
Show web page.
Actor types in login name and password.
Actor confirms.
Application validates login.
If login valid
7.1 mark actor as subscriber.
If login invalid
8.1 raise the number of invalid logins.
8.2 repeat from step 1.
Chosen scenario
Number of valid logins < 3.
Show web page.
Actor types in login name and password.
Actor confirms.
Login is valid.
Mark actor as subscriber.

32. Scenario example 1 of 2
Consider a Web-based on-line store, we might have a ‘Buy a Product’ scenario that would say this :
The customer browses the catalogue and
adds desired items to the shopping basket.
When the customer describes the shipping and credit card
information and confirms the sale.
The system checks the authorization on the credit card and
confirms he sale both immediately and with a follow-up mail.

33. Scenario example 2 of 2 Buy a Product Main Success Scenario:
Customer browses through catalog and selects items to buy
Customer goes to check out
Customer fills in shipping information (address; next-day or 3-day delivery)
System presents full pricing information, including shipping
Customer fills in credit card information
System authorizes purchase
System confirms sale immediately
System sends confirming to customer
Extensions:
3a: Customer is regular customer
3a1: System displays current shipping, pricing, and billing information
3a2: Customer may accept or override those defaults, returns to MSS at step 6
6a: System fails to authorize credit purchase
6a1: Customer may re-enter credit card information or may cancel

34. Template of use case text

35. NS Ticket machine – a use case approach
Destination
Purchase Ticket
Traveler
Maintenance basic data NS
Take ticket

36. NS Ticket machine – use case diagram
<<extend>>
<<include>>

37. NS Ticket machine – use case text
Buy OV Ticket
Actors
Traveller
Preconditions
Traveller has a valid pass
Description
Ticket device expects destination code
Traveller enters destination code
Extension point: NS ticket
Ticket device checks code and calculates the charge. Shows destination code & fare. Activates ticket machine for paying
Traveller pays (use case: Pay ticket)
Ticket device print and supplies ticket
Traveller takes ticket
Extension
Destination code = NS station.
3a. Ticket device expects ticket type
3b. Traveller enters Single/Return, Discount Y/N, Class
Exceptions
Traveller interrupt the interaction or walk away
Traveller enters an incorrect destination code
Payment is not finished off successful
Result
Traveller has ticket.
(NS can look forward to the payment)

38. Activity diagram Description can be modeled by an activity diagram
Make an activity diagram for the actor ‘Traveller’

39. Study matter UML distilled , 2nd / 3rd edition – UML beknopt
Martin Fowler
UML distilled , 2nd / 3rd edition – UML beknopt
Addison Wesley
Sander Hoogendoorn
Pragmatisch modelleren met UML 2.0
Grady Booch, James Rumbaugh, Ivar Jacobson
The Unified Modeling Language User Guide, 2nd edition