Software system modeling l l l System models

Software system modeling l l l 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, 6 th edition. Slide 1

The Unified Modeling Language l l l Devised by the developers of object-oriented analysis and design methods Has become an effective standard for software modelling Has nine different notations State Class Diagrams Use Case Diagrams Use Case Diagrams Sequence Diagrams Scenario Collaboration Diagrams Scenario Statechart Diagrams ©Ian Sommerville 2000 State Component Diagrams Models Activity Diagrams State Object Diagrams Component Diagrams Deployment Diagrams Software Engineering, 6 th edition. Diagrams Slide 2

Software modeling and models l l l 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, 6 th edition. Slide 3

Context model ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 4

Process (activity) model ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 5

Behavioral models – Data Processing CASE toolset data flow diagram (DFD) ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 6

Semantic data (a. k. a. ER) models ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 7

Data dictionary models ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 8

Object models l l l 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 ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 9

Library class hierarchy

Object aggregation ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 11

Object interaction ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 12

Objectives of formal methods l l To be unambiguous, consistent, complete, and provable Requirements specification • • l System/Software design • • • l “are we building the system right? ” proving that a realization satisfies its specification Validation • • l structural specifications of component relations behavioral specification of components demonstrating that next level of abstraction satisfies higher level Verification • • l clarify customer’s requirements reveal ambiguity, inconsistency, incompleteness “are we building the right system? ” testing and debugging Documentation • communication among stakeholders ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 13

Why use formal methods? l Formal methods have the potential to improve both quality and productivity in software development • • l l l 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 safetycritical and mission-critical software systems To avoid legal liability repercussions To ensure that systems meet regulations and standards ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 14

Why not? l l l l l 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, 6 th edition. Slide 15

Myths of formal methods l Formal methods can guarantee that software is perfect • l Formal methods are all about program proving • l the opposite is often the case Formal methods are unacceptable to users • l many methods involve no more than set theory and logic Formal methods increase the cost of development • l may be useful in any system (e. g. , highly reusable modules) Formal methods require highly trained mathematicians • l they are about modeling, communicating, demonstrating Formal methods are only useful for safety-critical systems • l how do you make sure the spec you build is perfect? 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, 6 th edition. Slide 16

Formal specification language types l Axiomatic specifications • l State transition specifications • l defines operations by collections of equivalence relations Temporal logic specifications • l defines operations in terms of a well-defined math model Algebraic specifications • l defines operations in terms of states and transitions Abstract model specifications • l defines operations by logical assertions 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, 6 th edition. Slide 17

Example problem – Clock l l 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 • l l 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, 6 th edition. Slide 18

Axiomatic specification – VDM l l INIT() ext wr time: N, bell: {quiet, ringing}, alarm: {disabled, enabled} pre true post (time’ = midnight) / (bell’ = quiet) / (alarm’ = disabled) TICK() ext wr time: N, bell: {quiet, ringing} rd alarm_time: N, alarm: {disabled, enabled} pre true post (time’ = succ(time)) / (if (alarm_time’ = time’) / (alarm’ = enabled) then (bell’ = ringing) else (bell’ = bell)) ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 19

Abstract model specifications – Z ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 20

Algebraic specifications – Obj l Functionality l Relations init: CLOCK tick, enable, disable: CLOCK setalarm: CLOCK x TIME CLOCK time, alarm_time: CLOCK TIME bell: CLOCK {ringing, quiet} alarm: CLOCK {on, off} time(init) midnight time(tick(C)) time(C) + 1 time(setalarm(C, T)) time(C) alarm_time(init) midnight alarm_time(tick(C)) alarm_time(C) alarm_time(setalarm(C, T)) T ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 21

State Machine specifications l In-class exercise… ©Ian Sommerville 2000 Software Engineering, 6 th edition. Slide 22