Real-time requirements

Intro to Software Engineering

Software Development Process Models
Formal methods in software specification
Structured Analysis
Object-oriented analysis and the UML

Use Cases

Object-oriented analysis
Use Case

Use Case diagram of inertial measurement system.

Context diagram

Inertial Measurement System

Example: Library Use Case

Diagram
Acomputerizedlibrarysystemfora
universitykeepstrackofallbooksand
periodicalsinthelibraryandtheircheckout
status.Checkoutandreturnareautomated
throughabarcodereader(anexternal
device).Thelibrarysystemalsointerfaces
withanexternalrelationaldatabasewhich
storesinformationaboutthelibraryusers
(students,faculty,andstaff),including
whethertheyhaveanylibraryitemschecked
out..Libraryuserscanaccessthecatalog
andrecallbooksandperiodicals.Library
employeeshavethesameaccessaswellas
additionalcapabilities(e.g.,listingthestatus
ofanitem).(Note:thelibrarycatalogispart
ofthelibrarycomputersystemsoitisnot
shownasanactor.)

EmployeeLogin

CheckIn
LibEmployee
CheckOut

LibUser

BarCodeReader

CheckAvailability
UsersDB

Recall

Use Case for Employee

Login
1. Employeeinitiatesusecase
byenteringusername
2. Systempromptsfor
password
3. Ifpasswordisvalid,
employeeisloggedonand
nowhasaccesstoemployee
commands
StartingandEnding
Conditions?
Exceptions?e.g.,cannotfind
theemployeelogin

EmployeeLogin

CheckIn
LibEmployee
CheckOut

LibUser

BarCodeReader

CheckAvailability
UsersDB

Recall

Use Case for

Check book availability
1. User/Employeeinitiatesusecase
2.
3.
4.
5.

byselectingthecheckbook
availabilityoption
Systempromptsforchoiceof
searchbytitle,author,orcall
number
Usermakesselectionandenters
title,authororcallnumber
Systemperformssearchthrough
thelibrarycatalogdatabase
Ifamatchisfound,system
displaysitemstatus(notchecked
out,checkedoutandduedate,
overdue)

StartingandEndingConditions?
Exceptions?

EmployeeLogin

CheckIn
LibEmployee
CheckOut

LibUser

BarCodeReader

CheckAvailability
UsersDB

Recall

<<Include>>: Functional
Decomposition

Problem:

A function in the original problem statement is too

complex to be solvable immediately

Solution:

Describe the function as the aggregation of a set of

simpler functions. The associated use case is
decomposed into smaller use cases
CreateDocument

<<include>>

<<include>>

<<include>>

Scan

OCR

Check

<<Include>>: Reuse of Existing

Functionality

Problem:

Solution:

How can we reuse existing functions?

The include association (A delegates to B)

Note: The base case cannot exist alone. It is always

called with the supplier use case
<<include>>
OpenIncident

BaseUse
Case

ViewMap
<<include>>
AllocateResources

Supplier
UseCase

HomeAutomationexample
factoroutcommonfunctionality
<<include>>
ToggleHotTub
TeaPot

<<include>>
ToggleAppliance
ToggleShades
<<include>>

Shades
ToggleTeaPot

HotTub
User

AnotherHomeAutomationexample
factoroutcommonfunctionality

ControlLights

<<include>>

Lights
(from Use Case View)

User
(from Use Case View)

<<include>>

FeedDogs

LogFunctions

DogFeeder

10

<<Extend>> Association for Use

Cases

Problem:

Solution:

The functionality in the original problem

statement needs to be extended.
An extend association: B is an extension of A.

Note: In an extend association, the base use case can be

executed without the use case extension
BaseUse
Case
FieldOfficer

B
Help

A
ReportEmergency

<<extend>>

11

Home Automation example

<<extend>>
False Alarm
User

Sound Alarm
Entry Sensor

12

Generalization association in use

cases

Problem:

You have common behavior among use cases and

want to factor this out.

Solution:

The generalization association factors out common

behavior.
CheckPassword

Parent
Case

ValidateUser
CheckFingerprint

Child
UseCase

13

Exampleusing<<extend>>

BuyOneWayTicket

<<extend>>

TransactionAborted

<<extend>>
Traveler

BuyWeeklyCard

BuyMonthlyCard

<<extend>>
<<extend>>
<<extend>>
<<extend>>
DistributorOutOfChange

CentralCompSys

UpdateTariff

14

Simplifiedwithanabstractusecase

BuyOneWayTicket

TransactionAborted
<<extend>>

Traveler

BuyWeeklyCard

<<extend>>
<<extend>>

DistributorException
DistributorOutOfChange

BuyMonthlyCard

CentralCompSys

UpdateTariff

15

Anesthesia Machine Use Cases

16

Decomposition of the Deliver Anesthesia Use Case

17

Use Case Activity Breakdown

18

Ventilator Use Cases

19

User Interface Use Cases

20

Vaporizer Use Cases

21

SPO2 Monitor Use Cases

22

CO2 Monitor Use Cases

23

Agent Monitor Use Cases

24

Breathing Circuit Use Cases

25

Bad Use Case Modeling

26

Adding a
Textural
Characterization

27

Use Case Relations

28

Relating Text and Scenarios

29

Use Case Sequence Diagram

30

Deliver Anesthesia Collaboration

31

Elaborated Scenario Part 1

32

Elaborated Scenario Part 2

33

Alarm On Critical Event Statechart

34

Statecharts
and
Sequence
Diagrams

35

Display Waveform Activity Diagram

36

Use Case
Timing
Diagram

37

Best practices in specifying

requirements

Bad:

The systems shall be completely reliable.

The system shall be modular.
The system shall be maintainable.
The system will be fast.
Errors shall be less than 99%.

Better:

Response times for all level one actions will be less than 100
ms.
The cyclomatic complexity of each module shall be in the
range or 10 to 40.
95% of the transactions shall be processed in less than 1 s.
An operator shall not have to wait for the transaction to
complete.
MTBF shall be 100 hours of continuous operation.

38