Chapter 8. Model-Based Design Concurrency: model-based design. Magee/Kramer 2 nd Edition

Similar documents
CSCI 5828: Foundations of Software Engineering

Concurrency week 3. Agenda. Thread safety. Immutable classes. Model-based design: yet another example Verification: from Java to FSP

Concurrency. State Models and Java Programs. Jeff Magee and Jeff Kramer. Concurrency: introduction 1. Magee/Kramer

Shared Objects & Mutual Exclusion

Introduction to Concurrency

Assessing, Comparing, and Combining Statechartbased testing and Structural testing: An Experiment

Multithreading Pearson Education, Inc. All rights reserved.

Safety & Liveness Properties

Java Threads. Written by John Bell for CS 342, Spring 2018

Formal Specification of a Truck Geo-Location Big- Data Application

CSCI 5828: Foundations of Software Engineering

Model Requirements and JAVA Programs MVP 2 1

CSCI 5828: Foundations of Software Engineering

Monitors & Condition Synchronization

Concurrency: State Models & Design Patterns

Monitors & Condition Synchronization

Q1. From post-it note. Question asked after Prev. Lecture. thread life-cycle in Java. Q2. Concurrency and parallelism. Definitions

COMP30112: Concurrency Topics 5.2: Properties

C340 Concurrency: Semaphores and Monitors. Goals

Contents. 6-1 Copyright (c) N. Afshartous

Concurrent processes. Processes and Threads. Processes and threads. Going back to Concurrency. Modelling Processes. Modeling processes

CSCI 5828: Foundations of Software Engineering

MCS-378 Intraterm Exam 1 Serial #:

COMP30112: Concurrency Topics 4.1: Concurrency Patterns - Monitors

Monitors & Condition Synchronisation

LTSA User Manual.

Monitors & Condition Synchronization

Answer the first question and two further questions. i. action prefix ( -> ) [3 marks]

Implementing Scheduling Algorithms. Real-Time and Embedded Systems (M) Lecture 9

Subsystem Hazard Analysis (SSHA)

Processes & Threads. Concepts: processes - units of sequential execution.

Chapter 2. Processes & Threads. Concurrency: processes & threads 1. Magee/Kramer

Deadlock. INF2140 Parallel Programming: Lecture 6. March 07, INF2140 Parallel Programming: Lecture 6 Deadlock

COMP 150-CCP Concurrent Programming. Lecture 12: Deadlock. Dr. Richard S. Hall

MCS-378 Intraterm Exam 1 Serial #:

3C03 Concurrency: Starvation and Deadlocks

$ Program Verification

CS11 Java. Fall Lecture 7

Software Architecture. Lecture 4

Introduction to Real-time Systems. Advanced Operating Systems (M) Lecture 2

CS18000: Programming I

Computation Abstractions. Processes vs. Threads. So, What Is a Thread? CMSC 433 Programming Language Technologies and Paradigms Spring 2007

Deadlock. Concepts: Models: Practice: Aim: deadlock avoidance - to design systems where deadlock cannot occur. Chapter 6. Deadlock

Informatica 3. Marcello Restelli. Laurea in Ingegneria Informatica Politecnico di Milano 9/15/07 10/29/07

Lecture 10: Introduction to Semaphores

Concurrent Programming

F. Tip and M. Weintraub CONCURRENCY

THE QUEEN S UNIVERSITY OF BELFAST

Syllabus Instructors:

This exam is open book. Each question is worth 3 points.

Advances in Programming Languages

CSCI 5828: Foundations of Software Engineering

Concurrency: Deadlock 1. Magee/Kramer 2 nd Edition

Object Orientated Analysis and Design. Benjamin Kenwright

Contribution:javaMultithreading Multithreading Prof. Dr. Ralf Lämmel Universität Koblenz-Landau Software Languages Team

Advanced Flow of Control -- Introduction

CS 351 Design of Large Programs Threads and Concurrency

Lecture 9: Introduction to Monitors

Java Threads. COMP 585 Noteset #2 1

CSCI 5828: Foundations of Software Engineering

Note: Each loop has 5 iterations in the ThreeLoopTest program.

COMP 401 ANIMATION, THREADS, COMMAND OBJECTS. Instructor: Prasun Dewan

Composition of State Machines

CS360 Lecture 10 Multithreading

Threads Chate Patanothai

THREADS AND CONCURRENCY

1) Discuss the mutual exclusion mechanism that you choose as implemented in the chosen language and the associated basic syntax

Verification Finite-state process modeling and reachability analysis

Concurrency 6 - Deadlock

Embedded Real-Time Systems. Facts and figures. Characteristics

FSP Language Specification

What is a Thread? Why Multicore? What is a Thread? But a fast computer runs hot THREADS AND CONCURRENCY. Concurrency (aka Multitasking)

G52CON: Concepts of Concurrency

Java s Implementation of Concurrency, and how to use it in our applications.

CS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017

Real-time HOOD. Analysis and Design of Embedded Systems and OO* Object-oriented Programming Jan Bendtsen Automation and Control

Chapter 6. Deadlock Concurrency: Deadlock. Magee/Kramer 2 nd Edition

Exam Concurrent and Real-Time Programming

Pieter van den Hombergh. Fontys Hogeschool voor Techniek en Logistiek. September 9, 2016

MultiThreading. Object Orientated Programming in Java. Benjamin Kenwright

IN2305-II Embedded Programming

UML-AADL 09: Towards a Model- Driven Approach for Mapping Requirements on AADL Mathieu DELEHAYE Christophe PONSARD

SWE 760 Lecture 1: Introduction to Analysis & Design of Real-Time Embedded Systems

Reintroduction to Concurrency

Module - 4 Multi-Threaded Programming

Animation Part 2: MoveableShape interface & Multithreading

CS455: Introduction to Distributed Systems [Spring 2019] Dept. Of Computer Science, Colorado State University

i219 Software Design Methodology 11. Software model checking Kazuhiro Ogata (JAIST) Outline of lecture

Unit 4. Thread class & Runnable Interface. Inter Thread Communication

public class Shared0 { private static int x = 0, y = 0;

Concurrent Execution

INF 212 ANALYSIS OF PROG. LANGS CONCURRENCY. Instructors: Crista Lopes Copyright Instructors.

CS 455: INTRODUCTION TO DISTRIBUTED SYSTEMS [THREADS] Frequently asked questions from the previous class survey

Threads SPL/2010 SPL/20 1

Chapter 6 Parallel Loops

THREADS & CONCURRENCY

- Styles Investigated - Conceptual Features. - Motivation - Problem Statement and Approach. - Architectural Mismatches

Concurrency COMS W4115. Prof. Stephen A. Edwards Spring 2002 Columbia University Department of Computer Science

Implementing Coroutines. Faking Coroutines in Java

Midterm 1, CSE 451, Winter 2001 (Prof. Steve Gribble)

Transcription:

Chapter 8 Model-Based Design 1

Design Concepts: design process: requirements to models to implementations Models: Practice: check properties of interest: - safety on the appropriate (sub)system - progress on the overall system model interpretation - to infer actual system behavior threads and monitors Aim: rigorous design process. 2

8.1 from requirements to models Requirements goals of the system scenarios (Use Case models) properties of interest Any appropriate design approach can be used. identify the main events, actions, and interactions identify and define the main processes identify and define the properties of interest structure the processes into an architecture Model check traces of interest check properties of interest 3

a Cruise Control System - requirements When the car ignition is switched on and the on button is pressed, the current speed is recorded and the system is enabled: it maintains the speed of the car at the recorded setting. buttons Pressing the brake, accelerator or off button disables the system. Pressing resume or on reenables the system. 4

a Cruise Control System - hardware Parallel Interface Adapter (PIA) is polled every 100msec. It records the actions of the sensors: buttons (on, off, resume) buttons brake accelerator engine PIA polled CPU brake (pressed) accelerator (pressed) engine (on, off). wheel interrupt D/A throttle Wheel revolution sensor generates interrupts to enable the car speed to be calculated. Output: The cruise control system controls the car speed by setting the throttle via the digital-to-analogue converter. 5

model - outline design outline processes and interactions. Sensor Scan monitors the buttons, brake, accelerator and engine events. Sensors Engine Input Speed monitors the speed when the engine is on, and provides the current speed speed readings to speed control. Cruise Controller triggers clear speed and record speed, and enables or disables the speed control. Prompts Speed Control clears and records the speed, and sets the throttle accordingly when enabled. setthrottle Throttle sets the actual throttle. 6

model -design Main events, actions and interactions. on, off, resume, brake, accelerator engine on, engine off, speed, setthrottle clearspeed,recordspeed, enablecontrol,disablecontrol Identify main processes. Sensors Prompts Sensor Scan, Input Speed, Cruise Controller, Speed Control and Throttle Identify main properties. safety - disabled when off, brake or accelerator pressed. Define and structure each process. 7

model - structure, actions and interactions The CONTROL system is structured as two processes. The main actions and interactions are as shown. SENSOR SCAN INPUT SPEED Engine Sensors speed CONTROL CRUISE CONTROLLER Prompts SPEED CONTROL set Throttle CRUISE CONTROL SYSTEM THROTTLE set Sensors = {engineon,engineoff,on,off, resume,brake,accelerator set Engine = {engineon,engineoff set Prompts = {clearspeed,recordspeed, enablecontrol,disablecontrol 8

model elaboration - process definitions SENSORSCAN = ({Sensors -> SENSORSCAN). // monitor speed when engine on INPUTSPEED = (engineon -> CHECKSPEED), CHECKSPEED = (speed -> CHECKSPEED engineoff -> INPUTSPEED ). // zoom when throttle set THROTTLE =(setthrottle -> zoom -> THROTTLE). // perform speed control when enabled SPEEDCONTROL = DISABLED, DISABLED =({speed,clearspeed,recordspeed->disabled enablecontrol -> ENABLED ), ENABLED = ( speed -> setthrottle -> ENABLED {recordspeed,enablecontrol -> ENABLED disablecontrol -> DISABLED ). 9

model elaboration - process definitions set DisableActions = {off,brake,accelerator // enable speed control when cruising, disable when a disable action occurs CRUISECONTROLLER = INACTIVE, INACTIVE =(engineon -> clearspeed -> ACTIVE DisableActions -> INACTIVE ), ACTIVE =(engineoff -> INACTIVE on->recordspeed->enablecontrol->cruising DisableActions -> ACTIVE ), CRUISING =(engineoff -> INACTIVE DisableActions->disableControl->STANDBY on->recordspeed->enablecontrol->cruising ), STANDBY =(engineoff -> INACTIVE resume -> enablecontrol -> CRUISING on->recordspeed->enablecontrol->cruising DisableActions -> STANDBY ). 10

model - CONTROL subsystem CONTROL =(CRUISECONTROLLER SPEEDCONTROL ). Animate to check particular traces: - Is control enabled after the engine is switched on and the on button is pressed? - Is control disabled when the brake is then pressed? - Is control re-enabled when resume is then pressed? However, we need analysis to check exhaustively : Safety: Is the control disabled when off, brake or accelerator is pressed? Progress: Can every action eventually be selected? 11

model - Safety properties Safety checks are compositional. If there is no violation at a subsystem level, then there cannot be a violation when the subsystem is composed with other subsystems. This is because, if the ERROR state of a particular safety property is unreachable in the LTS of the subsystem, it remains unreachable in any subsequent parallel composition which includes the subsystem. Hence... Safety properties should be composed with the appropriate system or subsystem to which the property refers. In order that the property can check the actions in its alphabet, these actions must not be hidden in the system. 12

model - Safety properties property CRUISESAFETY = ({DisableActions,disableControl -> CRUISESAFETY {on,resume -> SAFETYCHECK ), SAFETYCHECK = ({on,resume -> SAFETYCHECK DisableActions -> SAFETYACTION disablecontrol -> CRUISESAFETY ), SAFETYACTION =(disablecontrol->cruisesafety). LTS? CONTROL =(CRUISECONTROLLER SPEEDCONTROL CRUISESAFETY ). Is CRUISESAFETY violated? 13

model - Safety properties Safety analysis using LTSA produces the following violation: Trace to property violation in CRUISESAFETY: engineon clearspeed on recordspeed enablecontrol engineoff off off Strange circumstances! If the system is enabled by switching the engine on and pressing the on button, and then the engine is switched off, it appears that the control system is not disabled. 14

model - Safety properties What if the engine is switched on again? We can investigate further using animation engineon clearspeed on recordspeed enablecontrol engineoff engineon speed setthrottle speed setthrottle The car will accelerate and zoom off when the engine is switched on again! using LTS? Action hiding and minimization can help to reduce the size of an LTS diagram and make it easier to interpret 15

Model LTS for CONTROLMINIMIZED minimal CONTROLMINIMIZED = (CRUISECONTROLLER SPEEDCONTROL ) @ {Sensors,speed. accelerator brake off engineon on engineoff engineon 0 1 2 3 4 5 off brake engineoff accelerator speed off brake accelerator speed on speed off brake accelerator speed speed off brake accelerator speed on resume engineoff using progress? 16

model - Progress properties Progress violation for actions: {accelerator, brake, clearspeed, disablecontrol, enablecontrol, engineoff, engineon, off, on, recordspeed, resume Trace to terminal set of states: engineon clearspeed on recordspeed enablecontrol engineoff engineon Cycle in terminal set: speed setthrottle Actions in terminal set: {setthrottle, speed Check the model for progress properties with no safety property and no hidden actions. 17

model - revised cruise controller Modify CRUISECONTROLLER so that control is disabled when the engine is switched off: CRUISING =(engineoff -> disablecontrol -> INACTIVE DisableActions -> disablecontrol -> STANDBY on->recordspeed->enablecontrol->cruising ), Modify the safety property: property IMPROVEDSAFETY = {DisableActions,disableControl,engineOff -> IMPROVEDSAFETY {on,resume -> SAFETYCHECK ), SAFETYCHECK = ({on,resume -> SAFETYCHECK {DisableActions,engineOff -> SAFETYACTION disablecontrol -> IMPROVEDSAFETY ), SAFETYACTION =(disablecontrol -> IMPROVEDSAFETY). Magee/Kramer OK 2now? nd Edition 18

revised CONTROLMINIMIZED engineon on accelerator brake off 0 1 2 3 off brake accelerator engineoff speed off brake accelerator speed on speed on resume off brake accelerator speed engineoff engineoff No deadlocks/errors 19

model analysis We can now proceed to compose the whole system: CONTROL = (CRUISECONTROLLER SPEEDCONTROL CRUISESAFETY )@ {Sensors,speed,setThrottle. CRUISECONTROLSYSTEM = (CONTROL SENSORSCAN INPUTSPEED THROTTLE). Deadlock? Safety? Progress? No deadlocks/errors 20

model - Progress properties Progress checks are not compositional. Even if there is no violation at a subsystem level, there may still be a violation when the subsystem is composed with other subsystems. This is because an action in the subsystem may satisfy progress yet be unreachable when the subsystem is composed with other subsystems which constrain its behaviour. Hence... Progress checks should be conducted on the complete target system after satisfactory completion of the safety checks. Progress? No progress violations detected. 21

model - system sensitivities What about progress under adverse conditions? Check for system sensitivities. SPEEDHIGH = CRUISECONTROLSYSTEM << {speed. Progress violation for actions: {accelerator, brake, engineoff, engineon, off, on, resume, setthrottle, zoom Trace to terminal set of states: engineon Cycle in terminal set: speed Actions in terminal set: speed The system may be sensitive to the priority of the action speed. 22

model interpretation Models can be used to indicate system sensitivities. If it is possible that erroneous situations detected in the model may occur in the implemented system, then the model should be revised to find a design which ensures that those violations are avoided. However, if it is considered that the real system will not exhibit this behavior, then no further model revisions are necessary. Model interpretation and correspondence to the implementation are important in determining the relevance and adequacy of the model design and its analysis. 23

The central role of design architecture Design architecture describes the gross organization and global structure of the system in terms of its constituent components. We consider that the models for analysis and the implementation should be considered as elaborated views of this basic design structure. 24

8.2 from models to implementations Model Java identify the main active entities - to be implemented as threads identify the main (shared) passive entities - to be implemented as monitors identify the interactive display environment - to be implemented as associated classes structure the classes as a class diagram 25

cruise control system - class diagram disp Applet CruiseControl car CarSimulator CarSpeed setthrottle() getspeed() control Controller Runnable CruiseDisplay brake() accelerator() engineoff() engineon() on() off() resume() sc SpeedControl enablecontrol() disablecontrol() recordspeed() clearspeed() disp cs SpeedControl interacts with the car simulation via interface CarSpeed. CRUISECONTROLLER SPEEDCONTROL 26

cruise control system - class Controller class Controller { final static int INACTIVE = 0; // cruise controller states final static int ACTIVE = 1; final static int CRUISING = 2; final static int STANDBY = 3; private int controlstate = INACTIVE; //initial state private SpeedControl sc; Controller(CarSpeed cs, CruiseDisplay disp) {sc=new SpeedControl(cs,disp); synchronized void brake(){ if (controlstate==cruising ) {sc.disablecontrol(); controlstate=standby; synchronized void accelerator(){ if (controlstate==cruising ) {sc.disablecontrol(); controlstate=standby; synchronized void engineoff(){ if(controlstate!=inactive) { if (controlstate==cruising) sc.disablecontrol(); controlstate=inactive; Controller is a passive entity - it reacts to events. Hence we implement it as a monitor 27

cruise control system - class Controller synchronized void engineon(){ if(controlstate==inactive) {sc.clearspeed(); controlstate=active; synchronized void on(){ if(controlstate!=inactive){ sc.recordspeed(); sc.enablecontrol(); controlstate=cruising; synchronized void off(){ if(controlstate==cruising ) {sc.disablecontrol(); controlstate=standby; synchronized void resume(){ if(controlstate==standby) {sc.enablecontrol(); controlstate=cruising; This is a direct translation from the model. 28

cruise control system - class SpeedControl class SpeedControl implements Runnable { final static int DISABLED = 0; //speed control states final static int ENABLED = 1; private int state = DISABLED; //initial state private int setspeed = 0; //target speed private Thread speedcontroller; private CarSpeed cs; //interface to control speed private CruiseDisplay disp; SpeedControl(CarSpeed cs, CruiseDisplay disp){ this.cs=cs; this.disp=disp; disp.disable(); disp.record(0); synchronized void recordspeed(){ setspeed=cs.getspeed(); disp.record(setspeed); synchronized void clearspeed(){ if (state==disabled) {setspeed=0;disp.record(setspeed); synchronized void enablecontrol(){ if (state==disabled) { disp.enable(); speedcontroller= new Thread(this); speedcontroller.start(); state=enabled; SpeedControl is an active entity - when enabled, a new thread is created which periodically obtains car speed and sets the throttle. 29

cruise control system - class SpeedControl synchronized void disablecontrol(){ if (state==enabled) {disp.disable(); state=disabled; public void run() { // the speed controller thread try { while (state==enabled) { double error = (float)(setspeed-cs.getspeed())/6.0; double steady = (double)setspeed/12.0; cs.setthrottle(steady+error);//simplified feed back control wait(500); catch (InterruptedException e) { speedcontroller=null; SpeedControl is an example of a class that combines both synchronized access methods (to update local variables ) and a thread. 30

Summary u Concepts l design process: from requirements to models to implementations l design architecture u Models l check properties of interest safety: compose safety properties at appropriate (sub)system progress: apply progress check on the final target system model u Practice l model interpretation - to infer actual system behavior l threads and monitors Aim: rigorous design process. 31

Course Outline 2. Processes and Threads 3. Concurrent Execution 4. Shared Objects & Interference 5. Monitors & Condition Synchronization 6. Deadlock 7. Safety and Liveness Properties The main basic Concepts Models Practice 8. Model-based Design Advanced topics 9. Dynamic systems 10. Message Passing 11. Concurrent Software Architectures 12. Timed Systems 13. Program Verification 14. Logical Properties 32