Www.ddss.arch.tue.nl 7M822 UML Use Case Diagram / Use Case Text / Activity Diagram 23 September...
-
Upload
addison-harvey -
Category
Documents
-
view
224 -
download
2
Transcript of Www.ddss.arch.tue.nl 7M822 UML Use Case Diagram / Use Case Text / Activity Diagram 23 September...
www.ddss.arch.tue.nl
7M822
UML Use Case Diagram /Use Case Text / Activity Diagram
UML Use Case Diagram /Use Case Text / Activity Diagram
23 September 2010
www.ddss.arch.tue.nl
7M822
Requirements analysisRequirements 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
www.ddss.arch.tue.nl
7M822
Needs
Features
Software requirements
problemdomain
solutiondomain
www.ddss.arch.tue.nl
7M822
Use Case approachUse Case approach
Lending services
User administration
Books database
Library user
Library staff
library system
Lending services
www.ddss.arch.tue.nl
7M822
Use Case modellingUse 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.}
www.ddss.arch.tue.nl
7M822
UML ViewsUML Views
Design view
Interaction view
Implementa-tion view
Deployment view
Use Case view
vocabularyfunctionality
behaviour
performancescalabilitythroughput
system assemblyconfiguration management
system topologydistributiondeliveryinstallation
physicallogical
www.ddss.arch.tue.nl
7M822
Use Case definitionUse Case definition
• Fowler:– 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.
www.ddss.arch.tue.nl
7M822
ActorActor
• 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
www.ddss.arch.tue.nl
7M822
Use CaseUse 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
www.ddss.arch.tue.nl
7M822
System boundarySystem boundary
• Represents the boundary between the (physical) system and the actors who interact with the (physical) system.
www.ddss.arch.tue.nl
7M822
Use Case DiagramUse Case Diagram
A diagram that shows the relationships among actors and use cases within a system.
Set Limits
Capture Deal
Price Deal
Analyze Risk
Value Deal
Update Accounting
Financial Trading System
Accounting System
Salesperson
Trading Manager
Trader
<<include>>
<<include>>
www.ddss.arch.tue.nl
7M822
Include (Uses) relationshipInclude (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.
www.ddss.arch.tue.nl
7M822
Use case relationshipsUse case relationships
Place Order
Supply CustomerData
Order Product Arrange Payment
Cash Payment Credit Payment
Request Catalog
<<include>> <<include>><<include>>
<<extend>>
These use cases are varieties of
Arrange Payment
generalization
www.ddss.arch.tue.nl
7M822
Generalization relationshipGeneralization 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.
www.ddss.arch.tue.nl
7M822
Use case relationshipsUse case relationships
Place Order
Supply CustomerData
Order Product Arrange Payment
Cash Payment Credit Payment
Request Catalog
<<include>> <<include>><<include>>
<<extend>>
These use cases are varieties of
Arrange Payment
generalization
www.ddss.arch.tue.nl
7M822
Use case relationshipsUse case relationships
Place Order
Supply CustomerData
Order Product Arrange Payment
Cash Payment Credit Payment
Request Catalog
<<include>> <<include>><<include>>
<<extend>>
These use cases are varieties of
Arrange Payment
generalization
condition: {user request catalog}extension point: more requests
Place Order___________
more requests
www.ddss.arch.tue.nl
7M822
Extend relationshipExtend 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.
www.ddss.arch.tue.nl
7M822
D2D exampleD2D 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
www.ddss.arch.tue.nl
7M822
D2D exampleD2D 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
Request for subscription
Inspect profile
Modify profile
Cancel subscription
Visitor
Subscriber
D2D
www.ddss.arch.tue.nl
7M822
Primary use cases : examplesPrimary use cases : examples
Request for subscription
Visitor
Inspect profile
Subscriber
Visitor
Modify profile
Subscriber
www.ddss.arch.tue.nl
7M822
Separation 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
www.ddss.arch.tue.nl
7M822
Secondary use cases : an exampleSecondary use cases : an example
Use cases that supports the use case request for a subscription
www.ddss.arch.tue.nl
7M822
Secondary use cases : an exampleSecondary 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 e-mail
www.ddss.arch.tue.nl
7M822
Secondary use cases : an example {uses include / extend relationships}
Secondary use cases : an example {uses include / extend relationships}
Request for subscription
Inspect profile
Modify profile
Cancel subscription
Visitor
Subscriber
D2D
Visitor
Request for subscription
Validate subscription
Import subscription
Import creditcard
Validate creditcard
Mail confirmation
<<include>>
<<include>>
<<include>>
<<include>>
<<extend>>
Request for subscription
Inspect profile
Modify profile
Cancel subscription
Visitor
Subscriber
D2D
www.ddss.arch.tue.nl
7M822
Secondary use cases : an example {uses generalization relationships}
Secondary use cases : an example {uses generalization relationships}
D2D
Renew subscription
Pay subscription
<<include>>
Pay subscription with Creditcard
Pay subscription via Collection
Pay subscription via Account
www.ddss.arch.tue.nl
7M822
Use Case diagram – secondary actorUse Case diagram – secondary actor
Visitor
Request for subscription
Validate subscription
Import subscription
Import creditcard
Validate creditcard
Mail confirmation
<<include>>
<<include>>
<<include>>
<<include>>
<<extend>>
Credit card company
www.ddss.arch.tue.nl
7M822
Use case descriptionUse 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
www.ddss.arch.tue.nl
7M822
Use case text example from Inspect a profileUse case text example from Inspect a profile
Visitor
Inspect profile
Inspect preferences
Look for profile
Inspect photo
Mail message
<<include>>
<<extend>>
Subscriber
<<extend>>
<<extend>>
www.ddss.arch.tue.nl
7M822
Use case text example from Inspect a profileUse case ‘mail a message’
Use case text example from Inspect a profileUse 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
www.ddss.arch.tue.nl
7M822
ScenarioScenario
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.
www.ddss.arch.tue.nl
7M822
Scenario for use case ‘log in subscriber’Scenario for use case ‘log in subscriber’
Description1. Validate number of invalid logins .
2. If number of invalid logins more than 2, stop.
3. Show web page.
4. Actor types in login name and password.
5. Actor confirms.
6. Application validates login.
7. If login valid
7.1 mark actor as subscriber.
8. If login invalid
8.1 raise the number of invalid logins.
8.2 repeat from step 1.
Chosen scenarioNumber of valid logins < 3.
Show web page.
Actor types in login name and password.
Actor confirms.
Login is valid.
Mark actor as subscriber.
www.ddss.arch.tue.nl
7M822
Scenario example 1 of 2Scenario 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.
www.ddss.arch.tue.nl
7M822
Scenario example 2 of 2Scenario example 2 of 2
Buy a ProductMain Success Scenario:
1. Customer browses through catalog and selects items to buy
2. Customer goes to check out
3. Customer fills in shipping information (address; next-day or 3-day delivery)
4. System presents full pricing information, including shipping
5. Customer fills in credit card information
6. System authorizes purchase
7. System confirms sale immediately
8. System sends confirming email 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
www.ddss.arch.tue.nl
7M822
Template of use case textTemplate of use case text
Name Name used to refer to a use case.
Actors All actors involved.
Preconditions Condition of the system at the start of the use case.
Description A complete stepwise description of the interaction between system and actor(s).
Exceptions Special and/or unexpected exceptional cases.
Result Condition of the system at the end of the use case.
www.ddss.arch.tue.nl
7M822
NS Ticket machine – a use case approachNS Ticket machine – a use case approach
Traveler
Purchase Ticket
Maintenance basic data
NSTake ticket
Destination
www.ddss.arch.tue.nl
7M822
NS Ticket machine – use case diagramNS Ticket machine – use case diagram
<<extend>>
<<include>>
Pay ticket
Buy NS ticket
Buy OV ticket
Traveler
www.ddss.arch.tue.nl
7M822
NS Ticket machine – use case textNS Ticket machine – use case textUse Case Buy OV Ticket
Actors Traveller
Preconditions Traveller has a valid pass
Description 1. Ticket device expects destination code
2. Traveller enters destination code
3. Extension point: NS ticket
4. Ticket device checks code and calculates the charge. Shows destination code & fare. Activates ticket machine for paying
5. Traveller pays (use case: Pay ticket)
6. Ticket device print and supplies ticket
7. 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)
www.ddss.arch.tue.nl
7M822
Activity diagramActivity diagram
Enter Destination
[else]
[ correct NS destination]
Choose single or return Choose reduction Y/N Choose 1st / 2snd class
[ bus&tram card]
Pay ticket
[ payment not OK]
Take ticket[ else]
Description can be modeled by an activity diagram
Make an activity diagram for the actor ‘Traveller’
www.ddss.arch.tue.nl
7M822
Study matterStudy matter
• Martin FowlerUML distilled , 2nd / 3rd edition – UML beknoptAddison Wesley
• Sander HoogendoornPragmatisch modelleren met UML 2.0Addison Wesley
• Grady Booch, James Rumbaugh, Ivar JacobsonThe Unified Modeling Language User Guide, 2nd editionAddison Wesley