Multi-Paradigm ModelingMulti-Paradigm Modeling

CSCI 599CSCI 599Formal Specifications in Software ArchitecturesFormal Specifications in Software Architectures

Nenad Medvidovic

Computer Science DepartmentUniversity of Southern California

Los Angeles, CA 90089-0781neno@usc.edu

http://sunset.usc.edu/~neno/

Multi-Paradigm Software EngineeringMulti-Paradigm Software Engineering

Multi-dimensional separation of concerns– Hyperslices

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

– ViewPoints Multi-paradigm specifications

Two key issues– Composition– Consistency

Universe of Modeling LanguagesUniverse of Modeling Languages

Process algebrasTemporal and non-temporal logicsAlgebraic languagesState-based languagesSet-theoretic languagesAutomataGrammarsType 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 problemUnlike PLs, formal modeling languages are

not necessarily Turing completeTheir 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 enableAda 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?

ParseSimple type checkEnsure interface

conformanceEnsure behavior

conformanceGenerate 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 semanticsGenerate complete component implementationsModel interaction protocols

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

modeledEnsure interaction protocol conformance

– Once they are modeled, they can be analyzedStateCharts 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 fociAre the two models consistent?

– Why or why not?How do we check for consistency?

– Study the pairwise relationship between the two notations’ features

What if we introduced a 3rd, 4th, …, nth notation?

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

Heterogeneous Languages Heterogeneous Languages Covered in ClassCovered in Class

Notation Focus Expressive Analyzable Understandable

Alloy

ANNA

CHAM

CSP

GIL

OBJ

Petri nets

StateCharts

Z

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– “ilities”

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 isThis is software engineeringInconsistency may be unavoidableRemoving inconsistency may be more

expensive than living with it– E.g., engineering a new component vs. reusing

it off-the-shelfKey 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?

Your final project is an exercise in multi-paradigm specifications

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

Final Project Presentation SceduleFinal Project Presentation Scedule

Thursday, November 30– T. Garg & Nagaraj — ZZ– Mehta and Patel — AlloyAlloy– Bhachech and Viswanathan — OCLOCL– Gao and Rampurwala — WrightWright

Thursday, December 7– Apcar and Jerejian — Petri netsPetri nets– Chiu and A. Garg — LarchLarch– Rakic and Roshandel — StateChartsStateCharts– Al-Said and Dincel — RapideRapide

Evaluation of Languages Used Evaluation of Languages Used for the Final Projectfor the Final Project

Notation Focus Expressive Analyzable Understandable

Alloy

Larch

OCL

Petri nets

Rapide

StateCharts

Wright

Z