On the Formality of Graphical Descriptions

On the Formality of Graphical Descriptions Manfred Broy

Overview • Motivation • The role of diagrams • An example MSC Semantics • Property Specification with MSCs • Summary and Outlook

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.

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

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!

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.

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.

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.

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.

LM LM Ctrl Ctrl RM RM An example MSC Semantics General Context: Specification of Component Interfaces

msc locking Control LM RM lck ldn rdn lmr rmr UNLD LCKD What is an MSC What are MSCs? component axis state marker message arrow

Analysis Specification Design Implementation The role of MSCs in the developmewnt process Goal: Seamless, methodologically founded integration of MSCs into the development process for distributed, reactive systems

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?

component name kc lc cr LM Control RM cl rc channel name MSC Semantics System class: distributed, reactive systems component channel System consists of • named components (with local state) • named channels driven by global, discrete clock

E Q eq qe infinite channel history t t+1 t+2 t+3 <a,d,a,b> <> content of channel qe at time t MSC Semantics Timed Streams: Semantic Model for Black-Box-Behavior Message set: M = {a, b, c, ...}

behavior time 0 arbitrary msc locking ... Control LM RM u kc:lck cl:ldn cr:rdn ... lc:lmr rc:rmr t ... arbitrary LCKD UNLD MSC Semantics

msc locking Control LM RM UNLD kc:lck cl:ldn cr:rdn maximal I/O segment maximal I/O segment lc:lmr rc:rmr ck:ok LCKD 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

F maximal I/O segment MSC Semantics Defining MSC Semantics via Component Properties P Predicate on the data/control states before the interaction i1 o1 Predicate on the data/control states after the interaction Q

F ... ... MSC Semantics MSC Semantics for Deterministic Systems F(i1ˆ ... înˆx) = o1ˆ ... ônˆF(x) (for all k, 1  k  n) o1ˆ ... ôk = F(i1ˆ ... îk) concatenation

a b msc success msc failure Sender TR Receiver d c Sender TR Receiver a:m a:m Sender TR Receiver b:ready b:ready c:N c:Y d:N d:Y b:m MSC Semantics MSC Semantics for Deterministic Systems – Example

msc success msc failure Sender TR Receiver a:m a:m Sender TR Receiver b:ready b:ready c:Y c:N d:N d:Y b:m MSC Semantics MSC Semantics for Deterministic Systems – Example f TR(a:m) = b:ready fTR(a:mˆc:Yˆx) = b:readyˆd:Yˆb:mˆ fTR(x) fTR(a:mˆc:Nˆx) = b:readyˆd:Nˆ fTR(x)

msc l1 msc locking msc locking msc l3 msc crash msc crash msc l2 msc unlocking msc unlocking Summary Semantic Integration Capturing/Composition of Scenarios Systematic Refinement Transformation into Component Behavior

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

Outlook 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 needshybridpeople that have a deep understanding in all three of these areas.

On the Formality of Graphical Descriptions