Software Specification and Architecture 2IW80 Julien Schmaltz (slides partly from M. Mousavi and A. Serebrenik) Lecture 03: Use Cases
Before we start The system shall give access to the database to any computer connected to the secured network. This is an example of: a. An ill-formed requirement. b. A requirement written in a structural language. c. What the heck? 2
Before we start The system shall give access to the database to any computer connected to the secured network. This is an example of: a. An ill-formed requirement. b. A requirement written in a structural language. c. What the heck? 3
Requirements documents in practice / SET / W&I 04/02/15 4
Requirements documents What should a user be able to do? / SET / W&I 04/02/15 5
Requirements documents What should a user be able to do? / SET / W&I 04/02/15 6
Requirements documents What should a user be able to do? Is this all? / SET / W&I 04/02/15 7
Requirements documents What should a user be able to do? Is this all? / SET / W&I 04/02/15 8
Requirements documents What should a user be Is this all? able to do? Is this all? / SET / W&I 04/02/15 9
Requirements documents What should a user be Is this all? able to do? Is this all? / SET / W&I 04/02/15 10
We need a better way» Goal: specify how different parties (users, administrators, external systems, ) can interact with our system Recall: unambiguous, realistic, verifiable and evolvable» Plain-text does not work» A more structured way is needed / SET / W&I 04/02/15 11
Use cases - Goal» Specify how different parties (users, administrators, external systems, ) can interact with the system» Use cases provide a more structured way than plain text requirements. 12
A simple example What can you do with a phone? System = A phone 13
Possible answers Place a call Control the volume Receive a call Repeat the last call 14
A basic use case diagram Place a call Control the volume Receive a call Caller Repeat the last call 15
Some essential constituents Use case Place a call Actor Association Control the volume Receive a call Caller Repeat the last call 16
Use Case - Definition» Specification of a contract between the stakeholders of a system about its behaviour. [Cockburn 01]» Applications:» Initial steps into the development process» Classifying user requirements» Guiding the rest of the development process» Base of (acceptance) test-cases. 17
Use Case - Common mistakes» individual methods are NOT use cases» internal events/operations are NOT cases» Usually, use case is a large end-to-end processes comprising several (inter)actions 18
Actor - Definition» A class of entities (human or computer), falling beyond the system boundaries, interacting with the system» N.B:» An actor can be an external software system» One might have multiple actors in a use case» One user might be represented by multiple actors. 19
Use case description» pre-condition: when a use case is available to its user» trigger: what interactions initiate the use case» guarantee (post-condition): what the use case achieves through this use case» scenarios:» main scenario: typical course of actions» alternatives: re-consider each step, what can go wrong 20
Place a call - Main scenario 1. The user picks up the telephone hook connected to the telephone line A 2. If the line is free, the user receives a dial tone sent by the line. 3. The user dials number B. 4. The call request is forwarded to the switch center. 5. If line B is not busy, the call request is forwarded to B and a tone is sent to A. 6. B s telephone rings. 7. If somebody at B picks up the hool, the ringing tone at A is stopped and a telephone connection will start. 21
Place a call - Alternatives 2. a. If the telephone line is engaged in a conversation, the user will be connected to the same conversation. 2. b. If the user does not dial a number for a certain amount of time, a permanent tone is emitted by the switch center, no further call will be accepted and the user has to replace the hook. 22
Alternatives - Exercise» 5. If line B is not busy, the call request is forwarded to B and a tone is sent to A.» Think for a few minutes about an alternative. 23
Alternatives - Possible solution» 5. If line B is not busy, the call request is forwarded to B and a tone is sent to A.» Possible solutions» 5.1: If line B is busy, and B does not have a call waiting the user at A will receive a busy tone.» 5.2: If line B is busy, and B has a call waiting the user at A will receive a call waiting tone from the switch center. When line B becomes free, sub-scenario 5-7) follows. 24
Exercise for at home» Think about alternatives for 5 and 7 25
Use case description» Pre-condition: when a use case is available to its user» The telephone set is connected to the telephone line A, it is on-hook and there is no incoming call (it is not ringing) 26
Use case description» Pre-condition: when a use case is available to its user» The telephone set is connected to the telephone line A, it is on-hook and there is no incoming call (it is not ringing)» Trigger: action that initiates the use case» The user picks up the telephone hook connected to the telephone set (connected to line A ) and dials number B. 27
Use case description» Pre-condition: when a use case is available to its user» The telephone set is connected to the telephone line A, it is on-hook and there is no incoming call (it is not ringing)» Trigger: action that initiates the use case» The user picks up the telephone hook connected to the telephone set (connected to line A ) and dials number B.» Post-condition: what does the user achieve through the use case.» A communication between A and B is started. 28
Use case description» Pre-condition: when a use case is available to its user» The telephone set is connected to the telephone line A, it is on-hook and there is no incoming call (it is not ringing)» Trigger: action that initiates the use case» The user picks up the telephone hook connected to the telephone set (connected to line A ) and dials number B.» Post-condition: what does the user achieve through the use case.» A communication between A and B is started.» Main scenarios» Alternatives 29
User presses a Day Return button is a a) Trigger b) Pre-condition c) Guarantee (postcondition)
User presses a Day Return button is a a) Trigger b) Pre-condition c) Guarantee (postcondition)
Summary so far / SET / W&I 04/02/15 32
Exercise at home» Make a use case description for the Receive a call use case 33
Use case extraction» Identify system boundaries and actors» What are the goals of each actor w.r.t. the system» What are the external events that the system should react to? 34
Use Case - A more complex example A file system In the file system, users can create new files, execute, display (on different output devices) and delete existing files. There is a special type of delete, which removes the file permanently from the file system. The file system makes use of an access right system which specifies who the owner of each file is and what operations are allowed by which users. The owner of each file may change the access rights to the file and give or take other people s permissions to access the file. In addition to the person who creates the file, the administrator is considered the owner of all files. 35
Identify actors» Actor = A class of entities (human or computer) falling beyond the system boundaries, interacting with the system» Hence:» 1. Identify system boundaries» 2. Identify interactions» 3. Classify the interacting entities 36
Actors A file system In the file system, users can create new files, execute, display (on different output devices) and delete existing files. There is a special type of delete, which removes the file permanently from the file system. The file system makes use of an access right system which specifies who the owner of each file is and what operations are allowed by which users. The owner of each file may change the access rights to the file and give or take other people s permissions to access the file. In addition to the person who creates the file, the administrator is considered the owner of all files. 37
Actors In the file system, users [ ]who the owner of each file is [ ] the administrator is considered the owner of all files. User File owner Administrator 38
Use cases» Use case = a contract between the stakeholders of a system about its behaviour» Usually, large end-to-end processes comprising several interactions.» Hence:» 1. Identify goals of the actors» 2. Check whether they are end-to-end 39
Use Cases A file system In the file system, users can create new files, execute, display (on different output devices) and delete existing files. There is a special type of delete, which removes the file permanently from the file system. The file system makes use of an access right system which specifies who the owner of each file is and what operations are allowed by which users. The owner of each file may change the access rights to the file and give or take other people s permissions to access the file. In addition to the person who creates the file, the administrator is considered the owner of all files. 40
Use cases In the file system, [ ]create new files, execute, display [ ] delete existing files. [ ] delete permanently [ ] change the access rights [ ] Create Execute Display Delete Delete permanently Change access rights 41
Who does what? - Associations Create Change access rights Execute File owner Display User Delete Delete permanently Administrator 42
Not all actors have been created equal» Some users are file owners, but all file owners are users» File owner is a special kind of user» Some file owners are administrators, but all administrators are file owners» Recall: the administrator is considered the owner of all files» Administrator is a special kind of a file owner User File owner Administrator 43
What about use cases?» There is a special type of delete, which removes the file permanently from the file system» Some deletions are permanent ones, but all permanent deletions are deletions» Permanent deletion is a special use case of deletion Delete Delete permanently 44
Generalisation» Definition: A use case / actor is a special case of another one.» Substitutability principle: A specialised class (use case, actor) can always replace the general one.» Example: Administrator can do everything the user can do General Specific A Generalisation is a relationship between a more general [Use Case] and a more specific [Use Case]. Each instance of the specific [Use Case] is also an instance of the general [Use Case]. 45
Putting it all together: so far Change access rights Execute File owner Create Display User Delete Delete permanently Administrator 46
What we have missed so far» The file system makes use of an access right system which specifies who the owner of each file is and what operations are allowed by which users» What does this mean for the Execute, Create, Display, and Delete use cases? 47
What we have missed so far» The file system makes use of an access right system which specifies who the owner of each file is and what operations are allowed by which users» What does this mean for the Execute, Create, Display, and Delete use cases?» Sub-use case included in these use cases Check access rights 48
Including a use case in another one User File owner Administrator Delete Display Execute <<include>> <<include>> Create <<include>> Change access rights <<include>> <<include>> Delete permanently Check access rights 49
Dependencies» A use case depends on another use case for realising its goal» The target use case is always used by the source Execute <<include>> Check access rights» What if the use case is used only sometimes?» Alternatives in the use cases» Extension Get Help on Registration <<extend>> Register 50
Example Patient Hospital Admission <<include>> Patient Registration <<extend>> Schedule Patient Appointment http://www.uml-diagrams.org/examples/hospital-management-use-case-diagram-example.html 51
Include and Extend stereotypes Include: <<include>> <<extend>> Read A includes B B extends A A can operate without B no A B A B yes B is aware of A no yes An Include relationship specifies that a UseCase contains the behaviour defined in another UseCase. Extend: A relationship from an extending UseCase to an extended UseCase that specifies how and when the behaviour defined in the extending UseCase can be inserted into the behaviour defined in the extended UseCase. 52
What is wrong with the following diagram? a) A-B b) B-C c) C-D d) A-D e) nothing / SET / W&I Example 04/02/15 due to Ivanov and Novikov 53
What is wrong with the following diagram? a) A-B The only correct one b) B-C c) C-D d) A-D e) nothing / SET / W&I Example 04/02/15 due to Ivanov and Novikov 54
Actor A is associated with a) C b) D c) E d) F e) none / SET / W&I Example 04/02/15 due to Ivanov and Novikov 55
Actor A is associated with a) C b) D c) E d) F e) none / SET / W&I Example 04/02/15 due to Ivanov and Novikov 56
Which model is correct? A digital learning environment supports students learning through quizzes. Given your knowledge of this kind of systems which of the following models would be correct? Provide Hint <<extend>> Make a quiz Report results <<extend>> Provide Hint <<extend>> Make a quiz Report results <<include>> Provide Hint <<include>> Make a quiz Report results <<extend>> Provide Hint <<include>> Make a quiz Report results <<include>> A B C D 57
Which model is correct? A digital learning environment supports students learning through quizzes. Given your knowledge of this kind of systems which of the following models would be correct? Provide Hint <<extend>> Make a quiz Report results <<extend>> Provide Hint <<extend>> Make a quiz Report results <<include>> Provide Hint <<include>> Make a quiz Report results <<extend>> Provide Hint <<include>> Make a quiz Report results <<include>> A B C D 58
Use case diagrams as specification?» Unambiguous?» formal rules how to compose use case diagrams, but ambiguity may be hidden in textual descriptions» Realistic?» allows to model interaction with the external world but may be too simplistic to capture complex interactions» Verifiable?» yes, through testing» Evolvable?» if too many use cases are present the diagram becomes cluttered and less suited for evolution 59
UML» Use case diagram - one of the UML diagram types» Unified Modelling Language (UML) is a standardised (ISO/IEC 19501:2005), general-purpose modelling language in the field for software engineering» includes graphic notation techniques to create visual models of object-oriented software-intensive systems» started in the 1990 s» UML 1.1 1997» UML 2.0 2005» UML 2.4 2011» UML 2.5 2015 60
UML 2.5 http://www.omg.org/spec/uml/2.5/ 794 pages I do not expect you to learn UML specification by heart, but please consult it in case of doubt. 61
UML diagram types 62
Reminder: Assignment Requirements» Deadline: 18-02-2016 23:59» Groups» software developers usually work in groups» learning to work together» 20% of the grade of 2IW82 63