Technical University of MunichDepartment of Computer ScienceD-80290 Munich, Germany

On the Formality of Graphical Descriptions

Manfred Broy

Manfred Broy 2Graz, May 19th, 2001

Overview

• Motivation

• The role of diagrams

• An example MSC Semantics

• Property Specification with MSCs

• Summary and Outlook

Manfred Broy 3Graz, May 19th, 2001

Motivation: Modeling in Software Engineering

Systematic development of distributed interactive software systems needs basic system models:

Description techniques are to provide specific views and abstractions of systems such as:

the data view,

the interface view,

the distribution view,

the process view,

the interaction view,

the state transition view.

The development of systems concentrates on working out these views that lead step by step to an implementation.

Manfred Broy 4Graz, May 19th, 2001

Software development as modeling tasks

Software development:

Modeling and description of various aspects

application domains, their data structures, laws, and processes

software requirements, based on data models, functions, and processes

software architectures, their structure and principles

software components, their roles, interfaces, states, and behaviors

programs, their internal structure, their runs and their implementation

Manfred Broy 5Graz, May 19th, 2001

What is a model in software engineering?

An annotated graph or diagram?

A collection of class names, attributes, and method names?

In engineering, a model is always:

A collection of formulas, diagrams, tables expressed in some notation with a mathematical theory!

Hence:

Software engineering needs mathematical modeling theories of digital systems – algebra, logic, model theory!

Manfred Broy 6Graz, May 19th, 2001

Overview

• Motivation

• The role of diagrams

• An example MSC Semantics

• Property Specification with MSCs

• Summary and Outlook

Manfred Broy 7Graz, May 19th, 2001

Practice Today: Diagrams

In practice, today we find many diagrammatic methods for modeling and specification

(SA, SADT, SSADM, SDL, OMT, UML, ROOM, ...).

Design of universal modeling languages is a great idea - but ...

A closer look shows, however, how ad hoc most of these ”methods” are:

At best, they reflect deep engineering insights in engineering particular applications.

Manfred Broy 8Graz, May 19th, 2001

The Consequence

Never have practical diagrammatic modeling been justified on the basis of a comprehensive

mathematical foundation.

As a result, tool support is shallow, development steps are ad hoc and descriptions are ambiguous.

Manfred Broy 9Graz, May 19th, 2001

Three bad examples:

• UML and its statecharts dialect with its endless discussions about its semantics.

• Specification of interfaces of classes and components in object oriented modeling techniques in the presence of call backs – where ”specifying” means not only to list all methods and attributes, but a precise description of their functioning.

• Concurrency and cooperation: Most of the practical methods especially in object orientation seem to live in the good old days of sequential programming and do not properly address the needs of highly distributed, mobile, asynchronously cooperating software systems.

Manfred Broy 10Graz, May 19th, 2001

From VDL to VDM to UM back to UML

The vision – an academic view! Foundations: A tractable scientific basis, understanding, and

theory for modeling, specifying, and refining in programs, software and system

Powerful models supporting levels of abstractions, multi-view modeling, domain modeling

Comprehensive description techniques based on these foundations

A family of justified engineering methods based on these foundations

A flexible process model combining these methods

Comprehensive tool support including validation, consistency checks, verification and code generation by algorithms and methods justified by the theories

Finally: modeling and its theory as integral of software construction as an engineering discipline.

Manfred Broy 11Graz, May 19th, 2001

Overview

• Motivation

• The role of diagrams

• An example MSC Semantics

• Property Specification with MSCs

• Summary and Outlook

Manfred Broy 12Graz, May 19th, 2001

LM RMCtrl

An example MSC Semantics

General Context: Specification of Component Interfaces

Control

UNLD

LCKD

LM RM

lmrrmr

msc crash

crsclup

crup

Control

LCKD

UNLD

LM RM

lmr

rmr

msc unlocking

unlcklup

rup

Control

UNLD

LCKD

LM RM

lmr

rmr

msc locking

lckldn

rdn

LM RMCtrl

Manfred Broy 13Graz, May 19th, 2001

What is an MSC

message arrow

state marker

component axis

Control

UNLD

LCKD

LM RM

lmrrmr

msc locking

lckldn

rdn

What are MSCs?

Manfred Broy 14Graz, May 19th, 2001

Goal:

Seamless, methodologically founded integration of MSCs into the development process for distributed, reactive

systems

The role of MSCs in the developmewnt process

Control

UNLD

LCKD

LM RM

lmrrmr

msc crash

crsclup

crup

Control

LCKD

UNLD

LM RM

lmr

rmr

msc unlocking

unlcklup

rup

Control

UNLD

LCKD

LM RM

lmr

rmr

msc locking

lckldn

rdn

S1

S4

S2

S3

UNLD LCKD

?lmr/!rdn

?lck/!ldn ?rmr

?rmr ?unlck/!lup

?lmr/!rup

Analysis

Specification

Design

Implementation

Manfred Broy 15Graz, May 19th, 2001

Motivation

Summary of important questions:

What is the formal meaning of

• a single MSC

• a set of MSCs for the individual components of a

system?How can several MSCs be combined?

What properties do MSCs specify?

What is the methodological role of MSCs?

Can MSCs serve as a precise and

comprehensive specification method?

Manfred Broy 16Graz, May 19th, 2001

System class: distributed, reactive systems

MSC Semantics

lc

clLM Control RMcr

rc

kccomponent

channel

System consists of• named components (with local state)• named channels

driven by global, discrete clock

channel name

component name

Manfred Broy 17Graz, May 19th, 2001

MSC Semantics

E

eq

qeQ

t t+1 t+2 t+3

<a,d,a,b> <>

Timed Streams: Semantic Model for Black-Box-Behavior

*Mcontent of channel qe at time t

infinite channel history

Message set:

M = {a, b, c, ...}

Manfred Broy 18Graz, May 19th, 2001

behavior(C S)

Control

UNLD

LCKD

LM RM

lc:lmrrc:rmr

msc locking

kc:lckcl:ldn

cr:rdn

arbitrary

arbitrary

MSC Semantics

time0

u

t

...

...

...

Manfred Broy 19Graz, May 19th, 2001

Control

UNLD

LCKD

LM RM

lc:lmrrc:rmr

msc locking

kc:lckcl:ldn

cr:rdn

ck:ok

MSC Semantics

Defining MSC Semantics via Component Properties

Underlying question:

What constraints does an

MSC specify with respect to

the individual components?

Idea:

Derive component

predicates by considering

maximal input/output (I/O)

segments

maximal I/O segment

maximal I/O segment

Manfred Broy 20Graz, May 19th, 2001

F

MSC Semantics

Defining MSC Semantics via Component Properties

1i

1o

2i

2o

maximal I/O segment

11i

1ni

11o

1ko

Predicate on the data/control states

before the interaction

Predicate on the data/control states

after the interaction

Q

P

i1o1

Manfred Broy 21Graz, May 19th, 2001

MSC Semantics

MSC Semantics for Deterministic Systems

FI

O

F : I O

... ...

concatenation

F(i1ˆ ... ˆinˆx) = o1ˆ ... ˆonˆF(x)

(for all k, 1 k n)

o1ˆ ... ˆok = F(i1ˆ ... ˆik)

Manfred Broy 22Graz, May 19th, 2001

MSC Semantics

MSC Semantics for Deterministic Systems – Example

msc success

Sender TR Receiver

d:Y

c:Y

a:m

b:ready

b:m

msc failure

Sender TR Receiver

d:N

c:N

a:m

b:ready

TRSender Receiver

ad

bc

Manfred Broy 23Graz, May 19th, 2001

MSC Semantics

MSC Semantics for Deterministic Systems – Example

msc success

Sender TR Receiver

d:Y

c:Y

a:m

b:ready

b:m

msc failure

Sender TR Receiver

d:N

c:N

a:m

b:ready

f TR(a:m) = b:ready

f TR(a:mˆc:Yˆx) = b:readyˆd:Yˆb:mˆ f TR(x)

f TR(a:mˆc:Nˆx) = b:readyˆd:Nˆ f TR(x)

Manfred Broy 24Graz, May 19th, 2001

Summary

msc l3msc l2

msc l1msc crash

msc unlockingmsc locking

Capturing/Composition of Scenarios

msc crashmsc unlocking

msc locking

Systematic Refinement

Transformation into Component BehaviorSem

anti

c In

teg

rati

on

Manfred Broy 25Graz, May 19th, 2001

Two issues: education and domain models

Education:

Modeling has to be an integral part of every software engineering curriculum

Impact on application areas:

In many application areas and engineering discipline software engineering modeling techniques play a major role in the development of the field

Manfred Broy 26Graz, May 19th, 2001

We need a much deeper and more intensive interaction between

researchers working on the foundations,

the designers of practical engineering methods and tools,

the programmers and engineers in charge of practical solutions,

application experts modeling application domains.

Successful work does not only require the interaction between these types of people - it also

needs hybrid people that have a deep understanding in all three of these areas.

Outlook