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 [email protected]
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