requirements engineering with uml [software modeling] [computer science] [vrije universiteit...

Software and Services research group (S2)

Department of Computer Science, Faculty of SciencesVrije Universiteit Amsterdam

VRIJEUNIVERSITEITAMSTERDAM

Requirements engineering with UML

Software modeling (401016) – 2016/2017

Ivano [email protected]


Announcement

The template for Deliverable 1 will be available today on BlackBoard!

2


Roadmap

• Introduction to UML• What is UML?• Main characteristics of UML• UML diagrams

• Requirement engineering• Use case diagrams

3


What is UML?

• In the 80s there were multiple OO approaches• each approach had its own notation• then Rational Inc. (now IBM)

4

Booch notation Jacobson‘s OOSE Rumbaugh's Technique


What is UML?

• UML = Unified Modeling Language• De facto standard software design language

• Developed by OMG

• A “Swiss Army Knife” of notations

5


Why UML in this course?

The most used language for modeling software

6

34 job postings requiring UML in Amsterdam (as of last week)


Who uses UML?

7


Main characteristics of UML

• It is not tied to any development process• à waterfall, agile, whatever…

• Can be used across the whole life cycle• promotes iterative refinement of models

• General purpose• it can be used for modeling a mobile app, but also a satellite

• It has different representations:• graphical • textual • others…

8



• It is comprehensive• all parts of a system can be described using UML

• It is scalable• you can zoom in with additional details when needed

• Originally intended for descriptive models• Now it also supports prescriptive models

• models execution• code generation

• but more importantly…

9



UML is a formal modeling language

à all its concepts have a well-defined meaning

10

Modeling with code Informal model

UML model


Where are the “meanings” of UML concepts?

The UML superstructure

640 pages like this! à

Don’t read it, use it only as a manual in case of doubts

http://www.omg.org/spec/UML/2.5/

11


UML diagrams

A UML model is represented graphically by diagrams

12


UML structure diagrams

• Emphasize the static description of the elements of the system being modeled

• ex: student submission system à

• Structural elements may have an associated behavior

13


UML behavioural diagrams

• Behavior = the direct consequences of an action of at least one object

• It affects how the states of objects change over time

• Behavior can either be• specified through the actions

of a single object

•

• result from interactions between multiple objects à

14

Su

bm

issi

on


Which diagrams you will see in this course

• Use case diagram• to specify the basic functionality of a software system• aka requirements

• Class diagram• to define which objects or which classes are involved in the

realization of this functionality

• State machine diagram• to define the intra-object behavior

• Sequence diagram• specifies the inter-object behavior and communication

15

In your project you can use additional UML diagrams à BONUS in the final grade


Models != diagrams

• A UML model contains everything related to your system• it is complete

• Diagrams are just “windows” on your model• technically they can be considered as projections of the

same model• a particular diagram will show some parts of your model but

not necessarily everything (recall abstraction?)

16

representedby

System Model

Class diagram

Sequence diagram

State machinediagram


Models and diagrams in Papyrus

17

Diagram creation


Models and diagrams in Papyrus

18The model

The diagrams


Requirements engineering

19


Requirements engineering

• The process of establishing • the services that a customer requires from a system• the constraints under which it operates and is developed

• A requirement may range between• a high-level abstract statement of a service

• Example: all the robots must avoid obstacles autonomously

• a detailed mathematical functional specification• Example: each robot must communicate its position to the

central station every 1 second

20


Functional and non-functional requirements

Functional requirementsa. Services the system should provideb. How the system should react to particular inputs c. How the system should behave in particular situationsd. May state what the system should not do

Non-functional requirementsa. Constraints on the services or functions offered by the system

I. example: timing constraints, constraints on the development process, standards, etc.

b. Often apply to the system as a whole rather than individual features or services

21


Functional requirements

• Precise• Ambiguous requirements may be interpreted in different

ways by developers and users à problems

• Complete• They should include descriptions of ALL facilities required

• Consistent• There should be no conflicts or contradictions in the

descriptions of the system facilities

• In UML they are represented using Use case diagrams

22


Non-functional requirements

• System properties and constraints • e.g. reliability, response time and storage requirements• Constraints are I/O device capability, system

representations, etc.

• Non-functional requirements may be more critical than functional requirements

• e.g., safety requirements

• Non-functional requirements may affect the overall architecture of a system rather than the individual components

• For example, to ensure that performance requirements are met, you may have to organize your system to minimize communications between robots

23


Types of non-functional requirements

24

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Dependabilityrequirements

Securityrequirements

Regulatoryrequirements

Ethicalrequirements

Legislativerequirements

Operationalrequirements

Developmentrequirements

Environmentalrequirements

Safety/securityrequirements

Accountingrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements


Robotic systems MUST be dependable

25


Ways of writing requirements specifications

26

Notation DescriptionNatural language The requirements are written using numbered sentences in natural language.

Each sentence should express one requirement.

Structured naturallanguage

The requirements are written in natural language on a standard form ortemplate. Each field provides information about an aspect of the requirement.

Design descriptionlanguages

This approach uses a language like a programming language, but with moreabstract features to specify the requirements by defining an operational modelof the system. This approach is now rarely used although it can be useful forinterface specifications.

Graphicalnotations

Graphical models, supplemented by text annotations, are used to define thefunctional requirements for the system; UML use case and sequence diagramsare commonly used.

Mathematicalspecifications

These notations are based on mathematical concepts such as finite-statemachines or sets. Although these unambiguous specifications can reduce theambiguity in a requirements document, most customers don’t understand aformal specification. They cannot check that it represents what they want andare reluctant to accept it as a system contract


Natural language specification

• Requirements are written as natural language sentences• Used for writing requirements because it is expressive,

intuitive and universal. • These requirements can be understood by users and

customers

• Guidelines:• Invent a standard format and use it for all requirements• Use language in a consistent way

• Use “shall” for mandatory requirements, “should” for desirable requirements

• Use text highlighting to identify key parts of the requirement• Avoid the use of computer jargon• Include an explanation (rationale) of why a requirement is

necessary

27


Example

28

R1. The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.)

R2. The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.)


Requirement validation checklist

29

• Validity• Does the system provide the functions which best support

the customer’s needs?

• Consistency• Are there any requirements conflicts?

• Completeness• Are all functions required by the customer included?

• Realism• Can the requirements be implemented given available

budget and technology

• Verifiability• Can the requirements be checked?

I will use it when grading your project


Use case diagrams

30


Contents

• Introduction• Use cases• Actors• Relationships between use cases and actors • Relationships between use cases• Relationships between actors• Description of use cases• Best practices• Typical errors• Notation elements

31


Introduction

Use case diagrams express the expectations of the customers/stakeholders

§ essential for a detailed design

The use case diagram is used during the entire analysis and design process

We can use a use case diagram to answer the following questions:

§ What is being described? (The system)§ Who interacts with the system? (The actors)§ What can the actors do? (The use cases)

32


Example: Student Administration System

System (what is being described?)

§ Student administration system

Actors (who interacts with the system?)

§ Professor

Use cases(what can the actors do?)

§ Query student data§ Issue certificate§ Announce exam


Use Case

• Describes functionality expected from the system under development

• Provides tangible benefit for one or more actors that communicate with this use case

• Set of all use cases describes the functionality that a system shall provide

• Alternative notations:


Actor (1/3)

Actors interact with the system§ by using use cases,

i.e., the actors initiate the execution of use cases§ by being used by use cases,

i.e., the actors provide functionality for the execution of use cases.

Actors represent roles that users adopt§ Specific users can adopt and set aside multiple roles

simultaneously

Actors are not part of the system, i.e., they are outside of the system boundariesAlternative notations:


Actor (2/3)

Usually user data is also administered within the system. This data is modeled within the system in the form of objects and classes.Example: actor Assistant

§ The actor Assistant interacts with the system Laboratory Assignment by using it

§ The class Assistant describes objects representing user data (e.g., name, ssNr, …).


Actor (3/3)

Human§ E.g., Student, Professor

Non-human§ E.g., E-Mail Server

Primary: has the main benefit of the execution of the use caseSecondary: receives no direct benefitActive: initiates the execution of the use casePassive: provides functionality for the execution of the use case

Examples:

8

Non-humanSecondaryPassive

HumanPrimaryActive

HumanPrimaryActive

HumanSecondaryActive


Relationships between Use Cases and Actors

• Actors are connected with use cases via solid lines (associations)

• Every actor must communicate with at least one use case• An association is always binary• Multiplicities may be specified


The behavior of one use case (included use case) is ALWAYSintegrated in the behavior of another use case (base use case)

Example:

Relationships between Use Cases«include» - Relationship

Base use caserequires the behavior of the included use case to be able to offer its functionality

Included use case may be executed on its own


Relationships between Use Cases«extend» - Relationship

• The behavior of one use case (extending use case) may be integrated in the behavior of another use case (base use case) but does not have to

• Both use cases may also be executed independently of each other

• A decides if B is executed• Extension points define at which point the behavior is

integrated• Conditions define under which circumstances the behavior is

integrated

Base use case

Extending use case


Relationships between Use Cases«extend» - Relationship: Extension Points

• Extension points are written directly within the use case• Specification of multiple extension points is possible

• Example:


Relationships between Use CasesGeneralization of Use Cases

Use case A generalizes use case B.B inherits the behavior of A and may either extend or overwrite it.B also inherits all relationships from A.B adopts the basic functionality of A but decides itself what part of A is executed or changed.A may be labeled {abstract}

§ Cannot be executed directly§ Only B is executable

Example:

Base use case

Sub use case


Relationships between ActorsGeneralization of Actors

Actor A inherits from actor BA can communicate with X and YB can only communicate with YMultiple inheritance is permittedAbstract actors are possible

Example:

Super-actor

Sub-actor

Professor AND Assistant neededfor executing Query student data

Professor OR Assistant neededfor executing Query student data


Description of Use Cases

Structured approach§ Name§ Short description§ Precondition: prerequisite for successful execution§ Postcondition: system state after successful execution§ Error situations: errors relevant to the problem domain§ System state on the occurrence of an error§ Actors that communicate with the use case§ Trigger: events which initiate/start the use case§ Standard process: individual steps to be taken § Alternative processes: deviations from the standard process

[A. Cockburn: Writing Effective Use Cases, Addison Wesley, 2000]


Description of Use Cases - Example

Name: Reserve lecture hallShort description: An employee reserves a lecture hall at the university for an event.Precondition: The employee is authorized to reserve lecture halls.Postcondition: A lecture hall is reserved.Error situations: There is no free lecture hall.System state in the event of an error: The employee has not reserved a lecture hall.Actors: EmployeeTrigger: Employee requires a lecture hall.Standard process: (1) Employee logs in to the system.

(2) Employee selects the lecture hall.(3) Employee selects the date.(4) System confirms that the lecture hall is free.(5) Employee confirms the reservation.

Alternative processes: (4’) Lecture hall is not free.(5’) System proposes an alternative lecture hall.(6’) Employee selects alternative lecture hall and confirms the

reservation.


Best PracticesIdentifying Actors

• Who uses the main use cases?• Who needs support for their daily work?• Who is responsible for system administration?• What are the external devices/(software) systems with which

the system must communicate?• Who is interested in the results of the system?


Best PracticesIdentifying Use Cases

• What are the main tasks that an actor must perform? • Does an actor want to query or even modify information

contained in the system?• Does an actor want to inform the system about changes in

other systems?• Should an actor be informed about unexpected events within

the system?


Best PracticesTypical Errors To Avoid (1/5)

Use case diagrams do not model processes/workflows!



Actors are not part of the system, hence, they are positioned outside the system boundaries!



§ Use case Issue information needs EITHER one actor Assistant OR one actor Professor for execution

ü



Many small use cases that have the same objective may be grouped to form one use case

ü



The various steps are part of the use cases, not separate use cases themselves! -> NO functional decomposition

ü


Name Notation Description

System Boundaries between the system and the users of the system

Use case Unit of functionality of the system

Actor Role of the users of the system

Notation Elements (1/2)


Name Notation Description

Association Relationship between use cases and actors

Generalization Inheritance relationship between actors or use cases

Extend relationship

B extends A: optional use of usecase B by use case A

Include relationship

A includes B: required use of usecase B by use case A

Notation Elements (2/2)


Exercise

Problem: flight booking system (FBS) A travel agency needs to manage flight bookings for its customers:

1) Airline companies offer various flights. It is the airline itself that decides to open and close the bookings for each flight, and that communicates it to the travel agencies. 2) A customer can book multiple flights and for different passengers. 3) A booking concerns a single flight and a single passenger. A booking can be opened, and then cancelled or confirmed. 4) When confirmed, the tickets are issued and delivered to the customer. 5) A flight has a departure airport and an arrival airport. A flight has a departure day and time, and an arrival day and time. 6) A flight may have stopovers in airports; a stopover has an arrival time and a departure time. 7) Each airport serves one or more cities.

55

LegendaRed: candidate actorsBlue: candidate use cases


What this lecture means to you?

• UML = general purpose modeling language • tailored to object-oriented software systems

• 1 UML model, many diagrams• Requirements

• functional vs non-functional• Functional = the WHAT

• text + use case diagrams + use case descriptions

• Non-functional = the HOW• text + rationale

• Use case diagrams rules and best practices

56


Readings

• UML@Classroom: An Introduction to Object-Oriented Modeling” – chapters 2 and 3

• Learning UML 2.0 – chapters 1 and 2

57

requirements engineering with uml [software modeling] [computer science] [vrije universiteit...

Technology