Post on 31-Dec-2015
description
©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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 2
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 3
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 4
Context model
Auto-tellersystem
Securitysystem
Maintenancesystem
Accountdatabase
Usagedatabase
Branchaccounting
system
Branchcountersystem
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 5
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 6
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)
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 7
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 8
Data dictionary models
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 9
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 11
Object aggregation
Videotape
Tape ids.
Lecturenotes
Text
OHP slides
Slides
Assignment
Credits
Solutions
TextDiagrams
Exercises
#Problems Description
Course titleNumberYearInstructor
Study pack
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 12
Object interaction
:Library User
Ecat:Catalog
Lookup
Issue
Display
:Library Item Lib1:NetServer
Issue licence
Accept licence
Compress
Deliver
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 13
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 14
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 15
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 16
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 17
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 18
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 19
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))
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 20
Abstract model specifications – Z
BellStatus : {quiet,ringing}AlarmStatus : {disabled,enabled}
Clocktime, alarm_time : Nbell : BellStatusalarm : AlarmStatus
InitClockClock
(time’ = midnight) /\ (bell’ = quiet) /\(alarm’ = disabled)
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 21
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 22
State Machine specifications In-class exercise…