software system modeling

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 1

Software system modeling System models – Abstract descriptions of

systems whose requirements are being analysed Formal methods – Techniques and notations for

the unambiguous specification of software Objectives

• To explain why the context of a system should be modelled as part of the requirements engineering process

• To describe behavioural modelling, data modelling and object modelling

• To introduce some of the notations used in the Unified Modeling Language (UML)

• To introduce formal methods and formal modeling approaches


The Unified Modeling Language Devised by the developers of object-oriented analysis and design methods Has become an effective standard for software modelling Has nine different notations

Use CaseDiagrams

Use CaseDiagrams

Use CaseDiagrams

ScenarioDiagrams

ScenarioDiagrams

CollaborationDiagrams

StateDiagrams

StateDiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagrams

StateDiagrams

ObjectDiagrams

ScenarioDiagrams

ScenarioDiagramsStatechartDiagrams

Use CaseDiagrams

Use CaseDiagramsSequenceDiagrams

StateDiagrams

StateDiagrams

ClassDiagrams

ActivityDiagrams

Models


Software modeling and models Software modeling helps the engineer to

understand the functionality of the system Models are used for communication among

stakeholders Different models present the system from

different perspectives• External perspective showing the system’s context or

environment• Process models showing the system development process as

well as activities supported by the system• Behavioural perspective showing the behaviour of the system• Structural perspective showing the system or data architecture


Context model

Auto-tellersystem

Securitysystem

Maintenancesystem

Accountdatabase

Usagedatabase

Branchaccounting

system

Branchcountersystem


Process (activity) model

Get costestimates

Acceptdelivery ofequipment

Checkdelivered

items

Validatespecification

Specifyequipmentrequired

Choosesupplier

Placeequipment

order

Installequipment

Findsuppliers

Supplierdatabase

Acceptdelivered

equipment

Equipmentdatabase

Equipmentspec.

Checkedspec.

Deliverynote

Deliverynote

Ordernotification

Installationinstructions

Installationacceptance

Equipmentdetails

Checked andsigned order form

Orderdetails +

Blank orderform

Spec. +supplier +estimate

Supplier listEquipment

spec.


Behavioral models – Data Processing

Designeditor

Designcross checker

Designanalyser

Reportgenerator

Designdatabase

Code skeletongenerator

Designdatabase

Inputdesign

Validdesign

Checkeddesign

Designanalysis

Userreport

and

Referenceddesigns

Checkeddesign Output

code

CASE toolset data flow diagram (DFD)


Semantic data (a.k.a. ER) modelsDesign

namedescriptionC-dateM-date

Link

nametype

Node

nametype

links

has-links

12

1 n

Label

nametexticon

has-labelshas-labels

1

n

1

n

has-linkshas-nodes is-a

1

n

1

n1

1


Data dictionary models


Object models Object models describe the system in terms of

object classes An object class is an abstraction over a set of

objects with common attributes and the services (operations) provided by each object

Various object models may be produced• Inheritance models

• Aggregation models

• Interaction models

Library class hierarchyCatalogue numberAcquisition dateCostTypeStatusNumber of copies

Library item

Acquire ()Catalogue ()Dispose ()Issue ()Return ()

AuthorEditionPublication dateISBN

Book

YearIssue

MagazineDirectorDate of releaseDistributor

Film

VersionPlatform

Computerprogram

TitlePublisher

Published item

TitleMedium

Recorded item


Object aggregation

Videotape

Tape ids.

Lecturenotes

Text

OHP slides

Slides

Assignment

Credits

Solutions

TextDiagrams

Exercises

#Problems Description

Course titleNumberYearInstructor

Study pack


Object interaction

:Library User

Ecat:Catalog

Lookup

Issue

Display

:Library Item Lib1:NetServer

Issue licence

Accept licence

Compress

Deliver


Objectives of formal methods To be unambiguous, consistent, complete, and provable Requirements specification

• clarify customer’s requirements• reveal ambiguity, inconsistency, incompleteness

System/Software design• structural specifications of component relations• behavioral specification of components• demonstrating that next level of abstraction satisfies higher level

Verification• “are we building the system right?”• proving that a realization satisfies its specification

Validation• “are we building the right system?”• testing and debugging

Documentation• communication among stakeholders


Why use formal methods? Formal methods have the potential to improve both

quality and productivity in software development• to enhance early error detection

• to develop safe, reliable, secure software-intensive systems

• to facilitate verifiability of implementation

• to enable simulation, animation, proof, execution, transformation

Formal methods are on the verge of becoming best practice and/or required practice for developing safety-critical and mission-critical software systems

To avoid legal liability repercussions To ensure that systems meet regulations and standards


Why not? Emerging technology with unclear payoff Lack of experience and evidence of success Lack of automated support Existing tools are user unfriendly Ignorance of advances High learning curve Perfection and mathematical sophistication required Techniques not widely applicable Techniques not scalable


Myths of formal methods Formal methods can guarantee that software is perfect

• how do you make sure the spec you build is perfect? Formal methods are all about program proving

• they are about modeling, communicating, demonstrating Formal methods are only useful for safety-critical systems

• may be useful in any system (e.g., highly reusable modules) Formal methods require highly trained mathematicians

• many methods involve no more than set theory and logic Formal methods increase the cost of development

• the opposite is often the case Formal methods are unacceptable to users

• users will find them very helpful if properly presented Formal methods are not used on real, large-scale software

• they are used daily in many branches of industry


Formal specification language types Axiomatic specifications

• defines operations by logical assertions

State transition specifications• defines operations in terms of states and transitions

Abstract model specifications• defines operations in terms of a well-defined math model

Algebraic specifications• defines operations by collections of equivalence relations

Temporal logic specifications• defines operations in terms of order of execution and timing

Concurrent specifications• defines operations in terms of simultaneously occuring events


Example problem – Clock Initially, the time is midnight, the bell is off, and

the alarm is disabled Whenever the current time is the same as the alarm

time and the alarm is enabled, the bell starts ringing• this is the only condition under which the bell begins to ring

The alarm time can be set at any time Only when the alarm is enabled can it be disabled If the alarm is disabled while the bell is ringing, the

bell stops ringing Resetting the clock and enabling or disabling the

alarm are considered to be done instantaneously


Axiomatic specification – VDM INIT()

ext wr time:N, bell:{quiet, ringing}, alarm:{disabled, enabled}

pre truepost (time’ = midnight) /\ (bell’ = quiet) /\ (alarm’ =

disabled) TICK()

ext wr time:N, bell:{quiet, ringing} rd alarm_time:N, alarm:{disabled, enabled}pre truepost (time’ = succ(time)) /\ (if (alarm_time’ = time’) /\ (alarm’ = enabled) then (bell’ = ringing) else (bell’ = bell))


Abstract model specifications – Z

BellStatus : {quiet,ringing}AlarmStatus : {disabled,enabled}

Clocktime, alarm_time : Nbell : BellStatusalarm : AlarmStatus

InitClockClock

(time’ = midnight) /\ (bell’ = quiet) /\(alarm’ = disabled)


Algebraic specifications – Obj Functionality

init: CLOCKtick, enable, disable: CLOCK CLOCKsetalarm: CLOCK x TIME CLOCKtime, alarm_time: CLOCK TIMEbell: CLOCK {ringing, quiet}alarm: CLOCK {on, off}

Relationstime(init) midnighttime(tick(C)) time(C) + 1time(setalarm(C,T)) time(C)

alarm_time(init) midnightalarm_time(tick(C)) alarm_time(C)alarm_time(setalarm(C,T)) T


State Machine specifications In-class exercise…

software system modeling

Documents