Multi-Paradigm ModelingMulti-Paradigm Modeling

Multi-Paradigm Software EngineeringMulti-Paradigm Software Engineering

Multi-dimensional separation of concerns– Hyperslices

Subject-oriented programming Aspect-oriented programming Multi-perspective specifications

– ViewPoints Multi-paradigm specifications

Two key issues– Composition– Consistency

Universe of Modeling LanguagesUniverse of Modeling Languages

Process algebras Temporal and non-temporal logics Algebraic languages State-based languages Set-theoretic languages Automata Grammars Type systems

On the Fringes of the UniverseOn the Fringes of the Universe

Programming paradigms– Functional programming– Logic programming– OO programming– Query / data definition languages for DBMS

Semi-formal and informal languages– Flow diagrams– Decision tables or trees– Gantt charts

What are Multi-Paradigm What are Multi-Paradigm Specifications?Specifications?

System models expressed in multiple,

heterogeneous formal notations– Z– Finite automata– Petri nets– First-order predicate logic

Each partial model describes one aspect of

a system The combination of the models describes

the entire system

Why are Multi-Paradigm Specs Important?Why are Multi-Paradigm Specs Important? Achieving SE goals directly depends on our ability to separate

all concerns in a system– A software system is a collection of artifacts– Overlapping concepts across artifacts

Simultaneous separation of overlapping concerns in multiple dimensions is key– Data– Function– Feature– Configuration

How do we separate concerns?– Identify units of an artifact– Compose units into modules– Do so for each key concern– Compose modules as needed

Two Options for Multi-Paradigm Two Options for Multi-Paradigm SpecsSpecs

“Primary” notation with extensions– Potentially easier to control, compose, and

ensure consistency– Suffers from “the tyranny of the dominant

decomposition”

Federation of “equal” notations– More “democratic” and useful– Composition and consistency may be more

challenging

Primary Notation ApproachPrimary Notation Approach

Notation 1

Notation 2

Notation 3

Notation 4

Federation of Notations ApproachFederation of Notations Approach

Notation 2

Notation 1Notation 4

Notation 3

Why Multi-Paradigm Specs?Why Multi-Paradigm Specs?

Different formal modeling languages have

different strengths– Excel at modeling different problems and different

aspects of a single problem

Unlike PLs, formal modeling languages are not

necessarily Turing complete Their development and selection is guided by

trade-offs– Expressiveness vs.

understandability vs.analyzability vs.focus

This is a General ProblemThis is a General Problem

Software interoperability– Reuse– Interaction and consistency among components

implemented in different PLs– Platform heterogeneity– Distribution– Rearchitecting

How do you enable?Ada Java C Lisp Prolog– All of these are Turing complete

Example ProblemExample ProblemAugmenting C2SADEL with StateChartsAugmenting C2SADEL with StateCharts

C2SADEL– Allows specification of component state,

interface, and behavior– State

Set of typed variables

– Interface Operation signatures Optional typed parameters and return values

– Behavior Component invariant Operation pre- and post-conditions Described in first-order logic

Example C2SADEL ComponentExample C2SADEL ComponentComponent IntStack is {

State {stk : \set Integer; top : \set Integer -> Integer;

}Invariant { #stk >= 0; }Services {

ip1: Push (i : Integer);prepost (~#stk = #stk + 1) \and (top(stk) = i);

ip2: Pop ( ) : Integer;pre #stk > 0;post (~#stk = #stk – 1) \and (\result = top(stk));

}}

What can I do with a C2SADEL Spec?What can I do with a C2SADEL Spec?

Parse Simple type check Ensure interface

conformance Ensure behavior

conformance Generate component

implementation skeletons

Stack

StackManipulation

Artist

What can’t I do with a C2SADEL Spec?What can’t I do with a C2SADEL Spec?

Model dynamic component semantics Generate complete component implementations Model interaction protocols

– These are implicit in C2SADEL– Only provision and requirement of services is

modeled Ensure interaction protocol conformance

– Once they are modeled, they can be analyzed StateCharts can do this!

StateChart Model of a StackStateChart Model of a Stack

EmptyStack Non-Empty

Stack

FullStack

Push(i) [#stk < max-1]

Pop [#stk = 1]

Push(i)[#stk < max-1]

Push(i)[#stk = max-1]

Pop[#stk = max]

Pop[#stk > 1]

Relating C2SADEL and StateChartsRelating C2SADEL and StateCharts

The two are modeling the same problem– But doing so in different ways and with

different foci

Are the two models consistent?– Why or why not?

How do we check for consistency?– Study the pairwise relationship between the two

notations’ features

Heterogeneous ADLsHeterogeneous ADLsADL Focus

ACME Architectural interchange, predominantly at the structural level

Aesop Specification of architectures in specific styles

C2 Architectures of highly-distributed, evolvable, and dynamic systems

Darwin Architectures of highly-distributed systems whose dynamism is guided by strict formal underpinnings

MetaH Architectures in the guidance, navigation, and control (GN&C) domain

Rapide Modeling and simulation of the dynamic behavior described by an architecture

SADL Formal refinement of architectures across levels of detail

UniCon Glue code generation for interconnecting existing components using common interaction protocols

Weaves Data-flow architectures, characterized by high-volume of data and real-time requirements on its processing

Wright Modeling and analysis of the dynamic behavior of concurrent systems

What is a Multi-Paradigm Spec?What is a Multi-Paradigm Spec?

A collection of partial specs Each partial spec is written in a different language

– Different from multi-paradigm languages, which are designed to share a common syntactic and semantic framework (e.g., UML?)

Specialized for expressing and analyzing specific system properties– Control– Data– Interactions– “Utilities”

Different semantic domains– e.g., Z and finite automata

Bridging the Semantic DomainsBridging the Semantic Domains

Find an underlying, common semantic domain The semantic domain must be sufficiently

expressive– General– Semantics of each specification language must be

conducive to composition– Partial specs must communicate

The underlying semantic domain need not be a superset– Some discrepancies in the mapped models’ semantics

are OK– e.g., First-order predicate logic does not fully encompass

Z

Predicate Logic as the Shared Predicate Logic as the Shared Semantic DomainSemantic Domain

The semantics of a language is a function for translating specifications in the language to assertions in predicate logic– The semantics of a particular specification is an

assertion in predicate logic The semantics of the composition of a set of

partial specifications is the conjunction of their assertions– PSa Λ PSb Λ PSc Λ …

A set of partial specifications is consistent iff the conjunction of their assertions is satisfiable

Model Composition in the Model Composition in the Common Semantic DomainCommon Semantic Domain

CommonCommonSemanticSemanticDomainDomain

Partial Model 1Notation 1

Partial Model 2Notation 2

Partial Model 3Notation 3

Partial Model 4Notation 4

Ensuring Consistency through Ensuring Consistency through Model CommunicationModel Communication

Component IntStack is {State {

stkstk : \set Integer; top : \set Integer -> Integer;

}Invariant { #stk >= 0; }Services {

ip1: PushPush (i : Integer);prepost (~#stk = #stk + 1) \and

(top(stk) = i);ip2: PopPop ( ) : Integer;

pre #stk > 0pre #stk > 0;post (~#stk = #stk – 1) \and

(\result = top(stk));}

}

EmptyStack

Non-EmptyStack

FullStack

PushPush(i) [#stkstk < max-1]

PopPop [#stk = 1#stk = 1]

PushPush(i)[#stkstk < max-1]

PushPush(i)[#stkstk = max-1]

PopPop[#stk = max#stk = max]

PopPop[#stk > 1#stk > 1]

Zave & Jackson’s Description GraphZave & Jackson’s Description Graph

FirstOrderLogic

FSA Z

Evt-a

Evt-b

Evt-c

Evt-d

Evt-e

Evt-f

Evt-g

Evt-i

Evt-j

Is Inconsistency Inherently Bad?Is Inconsistency Inherently Bad?

In purely scientific terms, it probably is This is software engineering Inconsistency may be unavoidable Removing inconsistency may be more

expensive than living with it– e.g., engineering a new component vs. reusing it off-

the-shelf

Key is to know how to deal with it– e.g., interface mismatch, interaction protocol mismatch,

behavior mismatch

Why do you Care?Why do you Care?

Shared problem– Shared vocabulary, events, states

Some notations will be better suited for

certain aspects of NeoChiron and C2 than

others– e.g., StateCharts and Petri nets for dynamism– e.g., Alloy and Z for structure