Processes and Basic LOTOS Team LOT ‘O Specs Cara Gibbs Terry Peckham Robert Cowles Manon Sanscartier Ergun Gurak.

Slides:



Advertisements
Similar presentations
© 2005 by Prentice Hall Appendix 3 Object-Oriented Analysis and Design Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Advertisements

Security attacks. - confidentiality: only authorized parties have read access to information - integrity: only authorized parties have write access to.
Object-Oriented Software Engineering Visual OO Analysis and Design
ARCHITECTURES FOR ARTIFICIAL INTELLIGENCE SYSTEMS
Semantics Static semantics Dynamic semantics attribute grammars
Models of Concurrency Manna, Pnueli.
C O N T E X T - F R E E LANGUAGES ( use a grammar to describe a language) 1.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
UML (Sequence Diagrams, Collaboration and State Chart Diagrams) Presentation By - SANDEEP REDDY CHEEDEPUDI (Student No: ) - VISHNU CHANDRADAS (Student.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 11: An introduction to CSP.
ISBN Chapter 3 Describing Syntax and Semantics.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
Winter 2007SEG2101 Chapter 41 Chapter 4 SDL – Structure and Behavior.
CS 330 Programming Languages 09 / 18 / 2007 Instructor: Michael Eckmann.
Chapter 8 . Sequence Control
1 Static vs dynamic SAGAs Ivan Lanese Computer Science Department University of Bologna/INRIA Italy.
Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Unified Modeling Language Visual language.
Describing Syntax and Semantics
Functional Modeling Chapter 6.
SE-565 Software System Requirements More UML Diagrams.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Why Analysis Process Refer to earlier chapters Models what the system will do makes it easier for understanding no environment considered (hence, system.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
1 Object-Oriented Modeling Using UML (2) CS 3331 Fall 2009.
The Architecture of Secure Systems Jim Alves-Foss Laboratory for Applied Logic Department of Computer Science University of Idaho By, Nagaashwini Katta.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
SDS Foil no 1 Process Algebra Process Algebra – calculating with behaviours.
Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Amending Choreographies Joint work with Fabrizio Montesi and Gianluigi Zavattaro.
1 Modeling interactions and behavior Lecturer Dr. Mai Fadel.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University.
9-1 © Prentice Hall, 2007 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
1 Advanced Behavioral Model Part 1: Processes and Threads Part 2: Time and Space Chapter22~23 Speaker: 陳 奕 全 Real-time and Embedded System Lab 10 Oct.
By: David Harel & Eran Grey Presenter: Elizabeth Antony CISC 836.
1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
An Axiomatic Basis for Computer Programming Robert Stewart.
CS 5204 Spring 99 1 A Simple Agent A CCS agent is described both by a structural diagram and one or more algebraic equations. The diagram is for readability.
School of Computer Science, The University of Adelaide© The University of Adelaide, Control Data Flow Graphs An experiment using Design/CPN Sue Tyerman.
Systems Analysis and Design in a Changing World, Fourth Edition
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Modelling Reactive Systems 4 Professor Muffy Calder Dept. of Computing Science University of Glasgow
1Computer Sciences Department. Book: INTRODUCTION TO THE THEORY OF COMPUTATION, SECOND EDITION, by: MICHAEL SIPSER Reference 3Computer Sciences Department.
FDT Foil no 1 MSC Structuring MSCs Using Message Sequence Charts for real systems.
7-1 © Prentice Hall, 2007 Topic 7: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
1 Chapter 11 Global Properties (Distributed Termination)
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
1 Introduction to LOTOS A LOTOS process is built up from events. An event is unstructured - just a (gate) name e.g. g, a, send, open structured - a name.
Describing Syntax and Semantics
Analysis Classes Unit 5.
Chapter 3 of Programming Languages by Ravi Sethi
Object-Oriented Analysis and Design
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Business System Development
Logical architecture refinement
Axiomatic semantics Points to discuss: The assignment statement
Software Architecture
Theory of Computation Languages.
Appendix 3 Object-Oriented Analysis and Design
COMPILER CONSTRUCTION
Presentation transcript:

Processes and Basic LOTOS Team LOT ‘O Specs Cara Gibbs Terry Peckham Robert Cowles Manon Sanscartier Ergun Gurak

Presentation Overview Cara LOTOS background & basics Terry Processes, basic LOTOS operators Robert Operational semantics: growing trees from expressions Manon Parallelism Ergun Process Controls

History & Background of LOTOS

Terms ISO International Organization for Standardization OSI Open Systems Interconnection FDT Formal Description Technique LOTOS Language of Temporal Ordering Specification ISO Health Care … OSI… Road Vehicles FDT Estelle LOTOS SDL

Purpose: Create standards to make life simpler. Increase reliability and effectiveness of goods and services. Standards Environment Health Care Natural Sciences Ship BuildingTelecommunications Food Technology ISO

OSI Standard for interconnection between any two points in network. Purpose: For equipment to consistently work with other equipment. Structure: 7 layer system

FDT Formal method for developing telecommunications services & protocols. Purpose: Produce unambiguous descriptions of OSI in a precise & comprehensive way. Three officially recognized FDT’s : Estelle, LOTOS, SDL.

LOTOS Developed during the years 1981 – Specification language. Built specifically for OSI. Can be used for concurrent & distributed systems also. Key Idea To ensure compatibility of communication and cooperation between machines.

Components of LOTOS 1.Processes & their interaction with each other and their environment. 2.Data structures and value expressions.

LOTOS Basics

Process Distributed, concurrent system. Performs external (observable) actions. Performs internal (unobservable) actions. Interacts with other processes and observer. (Environment)

Event An action synchronized between two or more processes. Occurs at interaction point. (Gate) Three kinds of events: 1.Pure Synchronization 2.Value Establishment 3.Value Negotiation

Process Representation PROCESS Environment a b c d e f Gates

Process Definition Defines a process by specifying its behavior. Behavior is given by a sequence of observable actions that may occur. Syntax Process P1[a, b, c, d, e, f]

Real World Example Process KNOWLEDGE[start_grade_1, learn_alpha, write_name, count_10, start_grade_2] KNOWLEDGE start_grade_1 learn_alpha write_name count_10 start_grade_2

Basic LOTOS

Describes process synchronization Covers basic operators Action prefix Inaction Choice Full LOTOS adds data types Covered in a future presentation by some other group

Process Definitions and Behaviour Expressions Key Bold for LOTOS commands Uppercase for process names Lowercase for event names

Process Example process MAX3 [ in1, in2, in3, out] := hide mid in (MAX2[in1, in2, mid] |[mid]| MAX2[mid, in3, out]) where process MAX2[a, b, c] := a; b; c; stop [] b; a; c; stop endproc

MAX3 Process Diagram

Process Definition Process definition is a description of the behaviour of a subsystem 3 main purposes: –Representation of recursivity (loops + infinite behaviours) –Create behaviour abstractions and hierarchies (top-down) –Gate re-labeling

Process Definition (cont.) Process process [ formal-gates] ( params): functions := behaviours where local-definitions endproc

Behaviour Expressions They are created by applying an operator to other behaviour expressions They may also include instantiations of other processes, whose definitions are provided in the where clause

Behaviour Example process MAX3 [ in1, in2, in3, out] := hide mid in ( MAX2[in1, in2, mid] |[mid]| MAX2[mid, in3, out]) where process MAX2[a, b, c] := a; b; c; stop [] b; a; c; stop endproc Process Definition Behaviour Expression Process Instantiation

Syntax Chart NameSyntax Inactionstop Action prefix - unobservable (internal)i ; Expression - observablegate ; Expression ChoiceExpression1 [] Expression2 Hiding hide gate1, gate2, …,gateN in Expression Process instantiation PROCESS_NAME [gate1, gate2, …gateN]

Syntax Chart (cont.) NameSyntax Parallel composition - general case Expression1 | [gate1, gate2, …, gateN] | Expression2 - pure interleaving Expression1 ||| Expression2 - full synchronization Expression1 || Expression2 Successful termination exit Sequential composition (enabling) Expression1 >> Expression2 disabling Expression1 [> Expression2

Operator Precedence OperatorPrecedence Level Action prefixHighest Choice Parallel composition Disabling Enabling HidingLowest

Action prefix ; May denote actions in sequence Composes an event and a behaviour description The action prefix cannot take 2 behaviours as arguments –Ex. Action ; Expressiona; b; c gate ; Expression i ; Expression

Inaction Operator stop Is the representation of a behaviour such that no event will ever be observed It can be used to express that a process finishes it’s execution It can be used to express deadlock situations –Ex. With MAX3 as basis c; stopb; c; stop a; b; c; stop

Choice Operator [] Offers to the environment two (or more) alternatives. This is, the system may behave in several ways Choice composes two alternative behaviour descriptions. The environment will select among both behaviour descriptions

Choice Operator [] (cont.) Ex Behaviour1 [] Behaviour2 - The system behaves as either Behaviour1 or Behaviour2 Ex. With the MAX3 as basis a; b; c; stop [] b; a; c; stop

Operational Semantics Growing Trees From Expressions

Operational Semantics From a behaviour expression we derive the actions that a process performs The application of an action to a behaviour expression produces a new behavior expression From the application of each action we derive a labeled transition

Operational Semantics Each transition is of the form: B  x  B’ Where B and B’ are behavior expressions and x is an action that changes B to B’.

Operational Semantics The actions that are performed are all user- defined. They include the observable actions – the user defined gates for the behavior. They also include the unobservable or internal actions. In the syntax of the paper, this is the set 

Operational Semantics We also need a special non-user definable action that shows the successful termination of the current process and the enabling of a subsequent process. The paper uses  for this action. The complete set of actions is the set  

Operational Semantics The action prefix behavior expression is defined by the axiom:  ; B    B In the context of the Max2 example, this becomes: a; b; c; stop  a  b; c; stop

Operational Semantics We can describe the entire behavior for a process by its sequence of transitions. This is represented by a transition tree or synchronization tree. The nodes of the tree are labeled by the behavior expressions and the arcs are labeled by the action that causes the transition.

Operational Semantics Drawing from the Max2 example: Given the process: a; b; c; stop we produce this transition tree.

Operational Semantics We can also represent this process in an action tree. We produce an action tree by omitting the labels from the nodes of a transition tree. i.e. by only labeling the arcs.

Operational Semantics However, we have only examined one part of the process in Max2. Max2 involves a choice operator: a; b; c; stop [] b; a; c; stop Max2 can behave like either process. The process that it actually behaves like is determined by our first choice of action.

Operational Semantics If action a is selected, it behaves like: a; b; c; stop If action b is selected, it behaves like: b; a; c; stop

Operational Semantics This is described by the inference rules: B1  +  B1’ implies B1[]B2  +  B1’ B2  +  B2’ implies B1[]B2  +  B2’ For Max2 we have: a; b; c; stop  a  b; c; stop implies a;b;c;stop[]b;a;c;stop  a  b; c; stop

Operational Semantics Max2 gives us the choice of two action trees

Operational Semantics Since both action trees have a common starting point we draw them with a common root node:

Operational Semantics This process can be expanded to grow a tree of any size

Operational Semantics

As you can see this rapidly becomes cumbersome. This is where parallelism can simplify the process.

Parallelism “A Time and Place for Every Event.”

The Idea Parallel operators are used to model concurrency. They are useful for the synchronization of events. We can think of parallelism as a means to event ordering, prioritizing, preconditioning.

The Operators Partial Synchronization (General Case) Interleaving (Pure Interleaving) Full Synchronization In LOTOS, there are 3 types of parallel operators:

Partial Synchronization B1 |[g1, g2, …, gn]| B2 Process B1 Process B2 Synchronization Gates g1, …, gn |[]| Partial Synchronization Operator Behavior Expression

What Does that Mean? Certain events must be synchronized. Starting school: (shopping; start_grade_1; new_crayons; new_friends; start_grade_2; ballet; YEAR) |[start_grade_1, start_grade_2]| (start_grade_1; learn_alpha; write_name; count_10; start_grade_2; KNOWLEDGE) There are certain things you must do before you start grade 1, while you are in grade 1, and when you are done grade 1.

Example in1 in2 mid in3 mid out MAX2[in1, in2, mid] |[mid]| MAX2[mid, in3, out] Recall the above trees… We now compute

in1 in2in1 in2 mid in3 mid out in2 midout mid in3out in3 midout in2in3 in1 mid out in1 in3 mid out mid out in3 in2 in1 mid in1 mid in2 out in1in3 in2 in3 MAX2[in1, in2, mid] |[mid]| MAX2[mid, in3, out]

Interleaving B1 ||| B2 Process B1 Process B2 Set of Synchronization Gates is EMPTY ||| Interleaving Operator Behavior Expression

What Does that Mean? No events need be synchronized (independent processes). Reading text books for different classes: (b1_c1; b1_c2; b1_c3; BOOK1) ||| (b2_c1; b2_c2; b2_c3; BOOK2) As long as you read the individual books in sequential order, you can divide your time between classes. You do not HAVE to read all of book 1 before you start book 2 (although you may.)

Example in2out2in1out1 ||| where process BOX[in, out]:= in;out;stop end proc process BOXES[in1, out1, in2, out2]:= BOX[in1, out1] |||BOX[in2, out2] end proc in1, out1, in2, out2 in1, in2, out1, out2 in2, in1, out1, out2 in1, in2, out2, out1 in2, out2, in1, out1 in2, in1, out2, out1 Possible Sequences:

Full Synchronization B1 || B2 Process B1 Process B2 Set of Synchronization Gates is ALL Gates || Full Synchronization Operator Behavior Expression

What Does that Mean? All events must be synchronized. Jumping in the water holding hands: (walk; jump; land; YOU) || (walk; jump; land; ME) Everything must be done at the same time.

Example where … process BOXES[mid1, mid2, mid3]:= BOX1[mid1, mid2, mid3] ||BOX2[mid1, mid2, mid3] end proc mid1, mid2, mid3 Possible Sequence: mid3 mid1 mid2

Summary Partial Synchronization B1 |[g1, g2, …, gn]| B2 Interleaving B1 ||| B2 Full Synchronization B1 || B2 Synchronization at NO gates Synchronization at ALL gates General Case Special Cases

LOTOS Process Controls

Types of Process Controls i)Hiding ii)Internal Actions iii)Non-Determinism iv)Process Instantiation v)Process Recursion vi)Process Termination vii)Sequential Composition (Enabling) viii)Disabling

Hiding Syntax: hide gate 1, …, gate n in behaviour expression Semantics: Hiding allows one to transform observable (external) actions into unobservable (internal) actions, thus making them unavailable for synchronization with other processes.

Example: process OUTER [in1, in2, out] := hide mid in INNER [in1, mid] | [ mid ] | INNER [mid, in2, out] endproc Hiding mid in1in2 out OUTER INNER

Hiding in1 in2 mid out in1 in2 i out Action Tree (after hiding mid) Action Tree (before hiding mid)

Internal Actions Definition: An internal action is an unobservable action: it cannot be seen from the environment. Example: i in1in2 out OUTER INNER

Non-Determinism Definition: Non-determinism occurs when more than one result is possible for a particular behaviour expression. Examples: a; b; stop [] a; c; stop i; b; stop [] i; c; stop a c stop b ? ai c b ? i

Process Instantiation Syntax: process_identifier [comma-delimited list of actual gates] Semantics: A process instantiation is formed by a process identifier with an associated list of actual gates. Example: SIMPLEX_BUFFER [in, out] out SIMPLEX_BUFFER in

Process Recursion Semantics: A process P is recursive if it is able to call itself. Recursion in LOTOS is used to express infinite behaviours. Example: process REUSABLE_SIMPLEX_BUFFER [in, out] := in; out; REUSABLE_SIMPLEX_BUFFER [out, in] endproc out REUSABLE_SIMPLEX_BUFFER in

Process Termination Syntax: exit Semantics: Exit is a process whose only purpose is to perform a successful termination action and thus transform itself into the dead process stop. Example: process DO_SOMETHING [a, b, c] := a; b; exit [] b; c; exit endproc

Sequential Composition (Enabling) Syntax: B1 >> B2 Semantics: The execution of behaviour B2 is enabled if and only if behaviour B1 terminates successfully. Example: UNLOCK_DOOR [key] >> open_door

Disabling Syntax: B1 [> B2 Semantics: Behaviour B1 may or may not be disabled by behaviour B2 as follows: –If B1 terminates successfully, B2 is not executed. –Else, B2 interrupts B1 and is executed instead.

Disabling Example: take_bath [> answer_phone

Questions?