Marc Geilen, Email: [email protected] Eindhoven University of Technology, Information and Communication Systems 1 Object-Oriented Modelling and Specification.

1 Marc Geilen, Email: [email protected]

Eindhoven University of Technology, Information and Communication Systems

Object-Oriented Modelling and Specification using SHE

M. Geilen, J. VoetenInformation and Communication Systems

Department of Electrical EngineeringEindhoven University of Technology

The Netherlands

>


Eindhoven University of Technology, ICS 2

Contents

• Introduction: SHE

• System Level Modelling

• The POOSL Language

• Example and tools

• Conclusions & Further Research

>



Software / Hardware

Engineering

>



1:a2:b

5:c

o1 o2 o3

Interaction Diagrams

InitialRequirements

POOSL

formalisation

functional behaviour,structure,

communication, real-time

Object o1(class A)

Object o2(class A)

Object o3(class B)

message b

message c

Message FlowDiagrams

RequirementsCatalogue

SHE Methodology Framework

Object Class Diagram

Messages:

Attributes:P: Class A

Relationship x

Messages: m

Attributes:P: Class B

Architecture StructureDiagrams

M2M1

network

Instance StructureDiagrams

Object o1(class A)

Object o3(class B)

Object o2(class A)



Object Class DiagramP:P roduc t_ In fo_K eeper

Attributes:

Messages:s to rere trievese rv iceP erfo rm edse rv iceO ffe red

D: P IAttributes:idN um ber

Messages:requ ires (S e rvice )m arkP end ing (S ervice )m arkP erfo rm ed(S erv ice )

D: R equ iredS erv ice

Attributes:se rv iceS ta te

Messages:m arkU nserv icedm arkP end ingm arkP erfo rm ed

D: D es tina tion

Attributes:nam eaddresszipcodec itys ta tecoun try

Messages:

P: T ranspo rte r_ Im age

Attributes:

Messages:w akeA tencoderP u ls

D: In itia lP os ition

Attributes:

Messages:

D: P os itionD e lta

Attributes:

Messages:

D: S peed

Attributes:

Messages:se tToZ erose tToM axim um

P: T ranspo rte r

Attributes:

Messages:m ove

D: P os ition

Attributes:

Messages:se tToZ eroinc rem ent+ (P os itionD e lta )-(P os ition )= (P os ition )as In itia lP os ition

keepstrack o f

m ode ls runs a t

con tro ls

d iffe r

P: F eed ing_U n it_ Im age

Attributes:

Messages:g iveS ta tusm oun tedno tM oun tedfeedm isF eddoub leF ed

D: S e rv ice

Attributes:typenam e

Messages:

provides

has



Feeder_Station

Feeder_Controller

Service_Scheduler

Product_Input_

Handler

Transporter_Image

Feeding_Unit

Product_Info_

Keeper

feed(PIKeeperId,InitialPosition)

schedule(PIKeeperId,

InitialPosition)

Product_Output_Handler

Transporter

encoderPuls

move(Speed)

giveStatus/notMounted,

mounted(Service)

wakeAt(Position,Id)/wakeup(Id)

accept(PI)

feedReady(ProductInfoKeeperId,

Service)

free(PIKeeperId)

store(PIKeeperId,PI)

productArrived

currentPosition(Position)


serviceOffered(PIKeeperId,

Service)/required,

notRequiredService_

Administrator

accept(PI)

Other_Functional_Units

Feeding_Unit_Image

Images_Of_Other_Functional_

Units

productArrived

retrieve(PIKeeperId)/take(PI)

stop,start


mounted,notMounted

feed

misFed,doubleFed

handOver(PIKeeperId,InitialPosition)

servicePerformed(PIKeeperId,Service)

SHE: Message Flow Diagram



Introduction:System Level

Modelling

>



Design Decisions and Models

Investigation of design alternatives to obtain a satisfying realisation.

Realising design alternatives to determine the values of these properties is too costly and time-consuming.

Values of properties must be determined from models.

A model is an abstract representation of some design realisation.

A model must be adequate for the properties that are relevant for making a design decision.

>



System Level Modelling

If a model is more abstract

it will in general be adequate for less properties with less accuracy;

it will be more difficult to realise;

it will be more compact;

it will take less time to develop;

it will be cheaper to deduce properties.

Design decisions taken early in the design process (based on abstract models) have a large impact on property values.

>



Example: Switch Fabrics

Decision Properties

• Throughput

• Average Delay

• Jitter

• Quality of Service

Design Issues

• Queues

• Priorities

• Backpressure

• Scheduling

Modelling Concepts

• Modelling Entities

• Concurrency

• Communication/Synchronization

• Time/Stochasticity

>



Language Design Considerations/Alternatives

• Modelling Entities– Separate Data & Control Autonomous Objects– Structural Behavioural– ...

• Concurrency– Synchronous Asynchronous– Inherent to Modelling Entities Orthogonality

• Communication/synchronisation– Synchronous Asynchronous– Buffered Unbuffered– ...

• Time/stochasticity– Real-time Discrete-time Synchrony

Hypothesis– Stochastic Probabilistic Non-determinism– ...

>

Mathematical semantics

Small Expressive

Collection of Blending

Language Primitives

Selection

Conflicts

Orthogonality

POOSL



The POOSL

Language

>



Overview of POOSL

POOSL (Parallel Object-Oriented Specification Language) is a formal specification language based on a timed version of process algebra CCS and on the basic concepts of traditional object-oriented programming languages (Smalltalk, Java, C++).

A POOSL specification consists of

A Top-Level Cluster;

Clusters & Cluster Classes;

Process Objects & Process Classes;

Data Objects & Data Classes.

>



Example: Switch Fabric

>



Clusters

Hierarchical structural entities;

Statically interconnected in a topology of channels;

Connect to the channels through private ports;

Consist of process objects and other clusters;

Behave asynchronous concurrent;

Communicate by synchronous message passing;

Organised in cluster classes.

>



Example: Multistage Switch

>



Process objects

Behavioural asynchronous concurrent entities;

Statically interconnected in a topology of channels;

Communicate by synchronous message passing;

Contain data objects;

Compositional behaviour descriptions

Primitive statements: data,time,communication

Constructors: Parallel composition, interrupts, …

Behavioural abstraction: methods;

Are organised in process classes.

>



Example: Switch

>



Process Statements A method body consists of a process statement PS:

The execution of PS can result in Action Performance & Time Passage

PS ::= | ch!m(DE1,…,DEn){DS} synchronous send

| delay(DE) delay statement

| while E do PS od repetition

| DS {DS} data statement | if E then PS1 else PS2 fi selection

message receptionch?m(p1,…,pn | DE){DS}

| sel PS1 or … or PSn les choice statement | par PS1 and … and PSn rap parallel composition | PS1 interrupt PS2 interrupt statement | PS1 abort PS2 abort statement

| [DE]PS guarded command | m(DE1,…,DEn)(p1,…,pn) method call

| PS1;PS2 sequential composition

| timestamp x read model time



Example 1: Intuitive Semantics

initialize()()

ch!givePosition; delay(3.14); ch?position(point).

ch

initialize()()

ch?givePosition; ch!position(point).

instance variable

point

(10,12)

instance variable

point

givePosition

(10,12)

position( )

copy

>

Time: 0 3.14



Example 2: initial method startUp of Switch

startUp()()

outputBufferArray:=new(Array) size(2);outputBufferArray put(1,new(BoundedFIFOBuffer) size(bufferSize));outputBufferArray put(2,new(BoundedFIFOBuffer) size(bufferSize));par handleInput1()()and handleInput2()() and handleOutput1()()and handleOutput2()()rap.

>



Example 3: method handleInput1 of Switch

handleInput1()()

| cell: Cell |

i1?cell(cell | outputBufferArray at(cell destinationPort) isNotFull){outputBufferArray at(cell destinationPort) put(cell); cell nextDestinationPort};

delay(cellTime);handleInput1()().

>



Example 4: method handleOutput1 of Switch

handleOutput1()()

[outputBufferArray at(1) isNotEmpty]o1!cell(outputBufferArray at(1) firstElement){outputBufferArray at(1) removeFirstElement};

delay(cellTime);handleOutput1()().

>



Example 5: Process Class Source

>



Data objects

Behavioural sequential entities;

Can be created dynamically;

Communicate by message passing;

Invoke methods upon message reception;

Return results of method invocations to sender;

Are organised in data classes.

>



Example: Data class Exponential

>


Eindhoven University of Technology, ICS 27 >

Data Statements and Expressions

DS ::= x:=DE | DS1;DS2

| while DE do DS | if E then DS1 else DS2 fi

| DE

assignment to variable or parametersequential compositionrepetitionselectiondata expression

•A method body consist of a data statement DS :

>

DE ::= x | new(C) | self | DE m (DE1,…,DEn)

| -1,0,’a’,’b’,3.14,true,false | nil

data object referenced by xnewly created data object of data class Cdata object evaluating this expressionmethod callconstants of primitive classes constantsundefined data object

• DE is a data expression, always evaluating to a data object:



mu

rand

withParam(m:Real):Exponential

mu:=m;

rand:=new(RandomGenerator);

return(self).

Example: Intuitive Semantics

Consider the execution of the following statement:exp:=new(Exponential) withParam(3)

3

some

Random

>



FormalSemantics

>



Formal Semantics: Transition System

• Plotkin-style Structural Operational Interleaving Semantics defines a labelled transition system:

Model M can perform action a and then behave as M’

Model M can delay for time t and then behave as M’

>

M M’a

• Compositional Definition with Axioms and Inference Rules

(Mod, Act,T,{ | a Act},{ | t T})a t

M M’t

delay(t)

tM1 || M2 M’1 || M’2

t

M2 M’2t

M1 M’1t M1 M’1

c!mM2 M’2

c?m

M1 || M2 M’1 || M’2



Action Urgency: Two-Phase Model

Asynchronous Execution of Actions

Synchronous Passage of Time

>

[X.Nicollin, J.Sifakis ’91]



Example: Lossy Channel

>



Transition System of a Lossy Channel

in?cell

out!ce ll

100

>



Analysis: Verification

• Analytical (Exhaustive)– Generate complete transition system using the mathematical

semantics– Exhaustive analysis of this transition system– Certain results but only applicable in case of relatively small (finite-

state) systems

• Empirical validation (By Simulation)– Generate one or more execution traces using the mathematical

semantics– Analysis of these execution traces– Uncertain results but applicable in case of large and even infinite-state

systems

>



Analysis: Performance

• Analytical (Exhaustive)– Generate complete transition system using the mathematical semantics– Exhaustive analysis of this transition system– Compute performance figures using Markov Reward Structures– Certain/precise results but only applicable in case of relatively small

finite-state systems

• Empirical (By Simulation)– Generate one or more execution traces using the mathematical

semantics– Analysis these execution traces– Estimate performance figures using statistical methods– Uncertain results but applicable in case of large and even infinite-state

systems

>



SupportingTools

>



Editing (1)

• Editing hierarchy and structure...



Editing (2)

• Editing behaviour of process and data classes...



Simulation

• Executing the behaviour of the model...



Validation

• Validating system behaviour...



Scenarios

• Using scenarios to focus on specific parts of the model...



Empirical Performance Estimation

>

• Automatic estimation of performance parameters.

With a confidence of 95% the mean

throughput is between 0.00871 and 0.00919



Conclusions & Further Research

>



Conclusion (1)

• POOSL

POOSL is a language developed for system level modelling.It combines a process part based on CCS with a data part based on traditional object-oriented programming languages

– Architecture structure and topology is modelled graphically by means of clusters and channels

– Complex real-time behaviour is modelled by asynchronous concurrent process objects

– Complex dynamic functional behaviour is expressed by (travelling) data objects

>



Conclusion (2)

• Mathematical semantics

POOSL is equipped with a complete mathematical semantics enabling analytical and empirical performance evaluation and formal verification

• Tools

Tools are available supporting

– modelling,

– simulation,

– validation

– performance analysis.

>



Further Research

• Performance evaluation

– Probabilistic extension of the formal semantics

– Model abstraction, analytical techniques based on stochastic processes

– Empirical parameter estimation techniques applied to full models

• Formal (real-time) verification

– Model abstraction, exhaustive model checking

– Non-exhaustive model checking applied to full models

• Software synthesis (C++)

– Rapid Simulation, Performance Analysis and Verification

– Automatic Implementation

>

Marc Geilen, Email: [email protected] Eindhoven University of Technology, Information and Communication Systems 1 Object-Oriented Modelling and Specification.

Documents

design process

design realisation

values of properties

poosl language example

objectoriented modelling

formal specification

poosl specification

process statement ps