02291: System Integration

Transcription

1 02291: System Integration Week 2 Hubert Baumeister huba@dtu.dk DTU Compute Technical University of Denmark Spring 2018

2 Contents Requirements Model Domain model Use Case and Use Case Diagram

3 Activities in Software Developement Understand and document what kind of the software the customer wants Requirements Analysis external behaviour: what not how Determine how the software is to be built Design Build the software Implementation Validate that the software solves the customers problem Testing Verification Evaluation: e.g. User friendlieness

4 User Requirements vs System Requirements 1. User Requirements Used for business decision: go / no-go Used to solicit offers from software houses Done by the customer 2. System Requirements Define how the system is to be built Foundation for planning the project and cost estimations Done by the software house

5 Example of user requirements vs system requirements Ian Sommerville, Software Engineering - 9

6 Travel Agency Example: User requirements The travel agency TravelGood comes to you as software developers with the following proposal for a software project: Problem Description TravelGood wants to offer a trip-planning and booking application to its customers. The application should allow the customer to plan trips consisting of flights and hotels. First the customer should be able to assemble the trip, before he then books all the flights and hotels in on step. The user should be able to plan several trips. Furthermore it should be possible to cancel already booked trips.

7 Types of Requirements Functional Requirements Describe what the system should do The user should be able to plan and book a trip Non-functional Requirements Everything which is not functionality Where should the software run (e.g. operating system, software environment,... ) What kind of UI the user prefers (e.g. stand alone application, Web application, command line interface, graphical interface,... )

8 Categories of non-functional requirements Ian Sommerville, Software Engineering - 9

9 Characteristics of good requirements Testable Test whether the system satisfies the requirements or not Measurable Makes non-functional requirements testable

10 Example of measurable requirements The system should be easy to use by medical staff and should be organised in such a way that user errors are minimised

11 Example of measurable requirements The system should be easy to use by medical staff and should be organised in such a way that user errors are minimised Better: Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use.

12 Possible measures Ian Sommerville, Software Engineering - 9

13 Requirements engineering process Ian Sommerville, Software Engineering - 9

14 Requirements Engineering Process: Techniques Elicitation Interviews Domain Model Use Cases / User Stories Specification Domain Model Use Cases / User Stories Validation Criteria: Validity, Consistent, Complete, Realistic,... Techniques: Inspection, Test-case generation, Prototyping

15 Requirements documentation How to document requirements 1 Use cases for functional requirements 2 Domain model (class diagram, glossary,... ) to explain the domain 3 Non-functional requirements Requirements documentation are important to record the requirements to agree upon requirements with the customer

16 Requirements issues As a developer:refrain from inventing requirements Problem descriptions can be very vague Discuss with the customer Customer knows what he does not want Requirements can change e.g. after the customer has seen a first version of the software the business situation has changed (cf. finance crises)

17 Contents Requirements Model Domain model Use Case and Use Case Diagram

18 Domain model Capture the customer s knowledge of the problem domain Common language Necessary to define the concepts used Glossary Relationships between concepts: class diagram business processes: UML Activity Diagrams

19 Glossary List of terms with explanations Terms can be nouns (e.g. those mentioned in a problem description) but also verbs or adjectives e.t.c. Warning Capture only knowledge relevant for the application Don t try to capture all possible knowledge

20 Example Part of a glossary for a library application Book A book is a is a conceptual entity in a library. A book is defined by its title, the name of his authors, the publisher and the edition. A library can have several copies of the same book. Copy... A copy is a physical copy of a particular book. For example, the library has three copies of the book Using UML by Perdiate Stevens....

21 Concepts and their relations Class diagrams Usually Classes (for nouns) Associations: for static relationships Generalizations Often without attributes and operations Warning customer knowledge Not be biased by implementation

22 Domain model (terms and their relations)

23 Activity Diagram: Business Processes Ian Sommerville, Software Engineering 9, 2010 Helps finding the requirements of a system Next week more on activity diagrams

24 Contents Requirements Model Domain model Use Case and Use Case Diagram

25 Definition Use Case Introduced by Ivar Jacobson in the early 1990 s Travel Agency Plan Trip Customer Use Case A Use Case is a scenarios describing the interaction of one or several actors with the system serving a common goal. Do something : verb + noun Interaction Anything the actor does with the system System responses Effects visible/important to the customer Don t: How the system works

26 Use Case Different views on the same concept 1. Use case diagrams Graphical notation Overview over actors and use cases 2. Detailed use case description Textuel notation Interaction of the actors with the system: scenarios Follows a use case template

27 Use Case Diagrams Concepts Use case diagram = special type of class diagram

28 Another example of a use case diagram

29 Relations between use cases extend: used to extract variant behaviour include: used to factor common behaviour of use cases UML User Guide, Grady Booch et al Use extend and include sparingly; if in doubt, don t use

30 Generalisation between actors

31 Types of use cases a) Business use cases (kite level use case (from Alistair Cockburn)) b) System use cases / sea level use case / fish level (from Alistair Cockburn) Detailed use cases: lowest level only UML Destilled, Martin Fowler

32 Example Business Use Cases TravelAgency Plan Trip Manage Flights Book Trip Manage Hotels Administrator User Manage Trip Cancel Trip

33 Example System Use Cases Plan trip use cases TravelAgency Search Avaialbe Flights Manage trip use cases TravelAgency Add Flight to Trip Save Trip Search Available Hotels Delete Trip Book Trip User Add Hotel to Trip Delete Hotel from Trip Delete Flight from Trip User Cancel Trip Edit Trip List Trip

34 Don ts of Use case diagrams Use case diagrams don t explain how a use case works, this is part of the detailed use case description Travel Agency Login Select Trip Delete Selected Trip User User Travel Agency Delete Trip «include» «include» Login Select Trip Travel Agency Delete Trip User

35 Use case refinement System boundary is important Deriving requirements of subsystems Example: Mobile Multi-User Dungeon (MUD) Game

36 Use case refinement Decompose the system into subsystems MUD Phone * 1 Game Server Determine use cases for the subsystems GameSever Join Player to Game Phone

37 Travel Agency: detailed use case list available flights name: list available flights description: the user checks for available flights actor: user main scenario: 1. The user provides information about the city to travel to and the arrival and departure dates 2. The system provides a list of available flights with prices and booking number alternative scenario: 1a. The input data is not correct (see below) 2. The sytem notifies the user of that fact and terminates and starts the use case from the beginning 2a. There are no flights matching the users data 3. The use case starts from the beginning note: The input data is correct, if the city exists (e.g. is correctly spelled), the arrival date and the departure date are both dates, the arrival date is before the departure date, arrival date is 2 days in the future, and the departure date is not more then one year in the future

38 Detailed use cases: Template Template to be used in this course for detailed use case descriptions name: The name of the use case description: A short description of the use case actor: One or more actors who interact with the system precondition: Possible assumptions on the system state to enable the use case (optoinal) main scenario: A description of the main interaction between user and system Note: should only explain what the system does from the user s perspective alternative scnearios: Secondary scenarios; fail scenarios (optional) postcondition: What has been achieved after the use case has been executed? (optional) note: Used for everything that does not fit in the above categories

39 How to use pre-conditions name: Delete trip actor: User main scenario: 1. login user 2. select trip 3. delete selected trip alternative scenario: 1. login user fails 2. systems reports that trips cannot be deleted without being logged in

40 How to use pre-conditions name: Delete trip actor: User main scenario: 1. login user 2. select trip 3. delete selected trip alternative scenario: 1. login user fails 2. systems reports that trips cannot be deleted without being logged in Issue: The user has to login each time

41 How to use pre-conditions name: Delete trip actor: User main scenario: 1. login user 2. select trip 3. delete selected trip alternative scenario: 1. login user fails 2. systems reports that trips cannot be deleted without being logged in Issue: The user has to login each time name: Delete trip actor: User precondition: user is logged in main scenario 1. login user 2. select trip 3. delete selected trip Now the user has to be logged in, but does not have to login each time

42 Very Important Use cases in use case diagrams and detailed use cases are the same Names of use cases and actors have to match Include/extends relationship needs to be visible in the detailed use case description

43 Use Case Benefits Technique for capturing the functional requirements of a system Easy to understand Easy to check for completness Use case diagram Use case main vs. alternative scenarios: catch all possible interactions Test Cases (System, User Acceptance and Functional) can be directly derived from the use cases

44 Use Case Limitations Not good for capturing non-interaction based requirements e.g. algorithm or mathematical requirements non-functional requirements (such as platform, performance, timing, or safety-critical aspects) Abstracts away from the GUI Use case theory suggests that UI not be reflected in use cases but GUI mock ups (paper based, powerpoint based, etc.), prototypes may be more useful than abstract functionality

45 Tools Two classes: simple drawing tools and meta-model based modelling tools Drawing tools UMLet (Eclipse plugin Visio (Windows only; available though DTU agreement with Microsoft) Modeling tools Papyrus (htttps:// MagicDraw ( VisualParadigm (academic license file on CampusNet) ( (to be renewed)...

46 Exercise: MUD Game Task: Modelling of a multi-user dungeon game Three parts 1. Requirements: 2 weeks 2. Design: Walking Skeleton : 3 weeks 3. Design validation: Execution of the use cases: 2 weeks Exam Project: 4 weeks