02291: System Integration Week 2 Hubert Baumeister

(1)

02291: System Integration

Week 2

Hubert Baumeister huba@dtu.dk

DTU Compute Technical University of Denmark

Spring 2018

(2)

Activities in Software Developement

I Understand anddocument what kind of the software the customerwants

→ Requirements Analysis

I external behaviour: whatnothow

I Determinehow the software is to be built

→ Design

I Build the software

→ Implementation

I Validatethat the software solves the customers problem

→ Testing

→ Verification

→ Evaluation:e.g. User friendlieness

(4)

User Requirements vs System Requirements

1. User Requirements

I Used for business decision: go / no-go

I Used to solicit offers from software houses

I Done by the customer 2. System Requirements

I Define how the system is to be built

I Foundation for planning the project and cost estimations

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

I The user should be able to plan and book a trip

Non-functional Requirements Everything which is not functionality

I Where should the software run (e.g. operating system, software environment, . . . )

I 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

(9)

Characteristics of good requirements

I Testable

I Test whether the system satisfies the requirements or not

I Measurable

I Makes non-functional requirements testable

(10)

Example of measurable requirements

I ”The system should be easy to use by medical staff and should be organised in such a way that user errors are minimised”

I 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.”

(11)

Example of measurable requirements

I ”The system should be easy to use by medical staff and should be organised in such a way that user errors are minimised”

I 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

(13)

Requirements engineering process

(14)

Requirements Engineering Process: Techniques

I Elicitation

I Interviews

I Domain Model

I Use Cases / User Stories

I Specification

I Domain Model

I Use Cases / User Stories

I Validation

I Criteria: Validity, Consistent, Complete, Realistic, . . .

I Techniques: Inspection, Test-case generation, Prototyping

(15)

Requirements documentation

I How to document requirements

1 Use casesfor functional requirements

2 Domain model (class diagram, glossary, . . . ) to explain the domain

3 Non-functional requirements

I Requirements documentation are important

I torecord the requirements

I to agree upon requirements with the customer

(16)

Requirements issues

I As a developer:Refrain from inventing requirements

I Problem descriptions can be very vague

→ Discuss with the customer

→ Customer knows what he does not want

I Requirements can change

I e.g. after thecustomer has seen a first version of the software

I thebusiness situationhas changed (cf. finance crises)

(17)

Domain model

I Capture thecustomer’s knowledgeof the problem domain

I Common language

→ Necessary to define theconcepts used

→ Glossary

I Relationshipsbetween concepts: class diagram

→ business processes: UML Activity Diagrams

(19)

Glossary

I List of terms with explanations

I Terms can be nouns (e.g. those mentioned in a problem description) but also verbs or adjectives e.t.c.

I Warning

I Capture only knowledge relevant for the application

I Don’t try to capture all possible knowledge

(20)

Example

Part of a glossary for a library application Book

I 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

I 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

I Class diagrams

I Usually

I Classes (for nouns)

I Associations: for static relationships

I Generalizations

I Often withoutattributesandoperations

I Warning

I customer knowledge

I Not be biased by implementation

(22)

Domain model (terms and their relations)

(23)

Activity Diagram: Business Processes

Ian Sommerville, Software Engineering – 9, 2010

I Helps finding the requirements of a system

→ Next week more on activity diagrams

(24)

Definition Use Case

Introduced by Ivar Jacobson in the early 1990’s

Travel Agency

Customer

Plan Trip

Use Case

A Use Case is a scenarios describing the interaction of one or several actors with the system serving a common goal.

I ”Do something”: verb + noun

I Interaction

I Anything theactor does with the system

I System responses

I Effects visible/important to the customer

I Don’t: How the system works

(26)

Use Case

Different views on the same concept 1. Use case diagrams

I Graphical notation

I Overview over actors and use cases 2. Detailed use case description

I Textuel notation

I Interaction of the actors with the system: scenarios

I Follows a use casetemplate

(27)

Use Case Diagrams Concepts

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

I Detailed use cases: lowest level only

UML Destilled, Martin Fowler

(32)

Example Business Use Cases

TravelAgency

Manage Hotels Manage Flights

Manage Trip User

Cancel Trip Book Trip

Plan Trip

Administrator

(33)

Example System Use Cases

Plan trip use cases

Delete Flight from Trip Delete Hotel from Trip

List Trip Add Flight to Trip

Add Hotel to Trip TravelAgency

User

Search Available Hotels Search Avaialbe Flights

Manage trip use cases

Save Trip

Book Trip

User Cancel Trip

Delete Trip

Edit Trip TravelAgency

(34)

Don’ts of Use case diagrams

I Use case diagrams don’t explain how a use case works, this is part of the detailed use case description

Select Trip Delete Trip

Login Travel Agency

User

Delete Trip Travel Agency

User

Delete Selected Trip Select Trip

Travel Agency

Login User

«include»

(35)

Use case refinement

I System boundary is important

I Deriving requirements of subsystems

I Example: Mobile Multi-User Dungeon (MUD) Game

(36)

Use case refinement

I Decompose the system into subsystems

Game Server Phone

MUD

* 1

I 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: shouldonly explain what the system does from the user’sperspective

alternative scnearios:Secondary scenarios;failscenarios (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

I 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

I Now the user has to be logged in, but does not have to login each time

(40)

How to use pre-conditions

(41)

How to use pre-conditions

(42)

Very Important

I 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

I Technique for capturing the functional requirements of a system

I Easy to understand

I Easy to check for completness

I Use case diagram

I Use case main vs. alternative scenarios: catch all possible interactions

I Test Cases (System, User Acceptance and Functional) can be directly derived from the use cases

(44)

Use Case Limitations

I Not good for capturing non-interaction based requirements e.g.

I algorithm or mathematical requirements

I non-functional requirements (such as platform, performance, timing, or safety-critical aspects)

I Abstracts away from the GUI

I Use case theory suggests that UI not be reflected in use cases

I but GUI mock ups (paper based, powerpoint based, etc.), prototypes may be more useful than abstract functionality

(45)

Tools

I Two classes: simpledrawing toolsandmeta-model based modelling tools

I Drawing tools

I UMLet (Eclipse pluginwww.umlet.com)

I Visio (Windows only; available though DTU agreement with Microsoft)

I Modeling tools

I Papyrus (htttps://www.eclipse.org/papyrus/)

I MagicDraw (http://downloads.cc.dtu.dk/)

I VisualParadigm (academic license file on CampusNet) (http://www.visual-paradigm.com/) (to be renewed)

. . .

(46)

Exercise: MUD Game

I Task: Modelling of a multi-user dungeon game

I Three parts

1. Requirements: 2 weeks

2. Design: ”Walking Skeleton”: 3 weeks

3. Design validation: ”Execution” of the use cases: 2 weeks

I Exam Project: 4 weeks

02291: System Integration Week 2 Hubert Baumeister