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

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

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.

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

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.}

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

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

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

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

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

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

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.

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

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.

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

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

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.

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 email gebruikersnaam en wachtwoord via email. 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.

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 email gebruikersnaam en wachtwoord via email. 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.

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

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

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

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 e-mail

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>>

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

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

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

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

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

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.

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.

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.

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 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

Template of use case text

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

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

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)

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

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