Multi-Paradigm Modeling

1. Multi-Paradigm Modeling

2. Multi-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

3. Universe of Modeling Languages • Process algebras • Temporal and non-temporal logics • Algebraic languages • State-based languages • Set-theoretic languages • Automata • Grammars • Type systems

4. On 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

5. What are Multi-Paradigm 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

6. 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

7. Two Options for Multi-Paradigm Specs • “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

8. Primary Notation Approach Notation 1 Notation 2 Notation 3 Notation 4

9. Federation of Notations Approach Notation 3 Notation 2 Notation 1 Notation 4

10. 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

11. This 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

12. Example ProblemAugmenting 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

13. Example C2SADEL Component Component IntStack is { State { stk : \set Integer; top : \set Integer -> Integer; } Invariant { #stk >= 0; } Services { ip1: Push (i : Integer); pre post (~#stk = #stk + 1) \and (top(stk) = i); ip2: Pop ( ) : Integer; pre #stk > 0; post (~#stk = #stk – 1) \and (\result = top(stk)); } }

14. What can I do with a C2SADEL Spec? • Parse • Simple type check • Ensure interface conformance • Ensure behavior conformance • Generate component implementation skeletons Stack StackManipulationArtist

15. 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!

16. Push(i)[#stk < max-1] Push(i) [#stk < max-1] Empty Stack Non-Empty Stack Push(i)[#stk = max-1] Pop [#stk = 1] Pop [#stk > 1] Pop[#stk = max] Full Stack StateChart Model of a Stack

17. Relating 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

18. Heterogeneous ADLs

19. 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

20. Bridging 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

21. Predicate Logic as the Shared Semantic 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

22. Model Composition in the Common Semantic Domain Partial Model 1Notation 1 Partial Model 3Notation 3 CommonSemanticDomain Partial Model 4Notation 4 Partial Model 2Notation 2

23. Ensuring Consistency through Model Communication Push(i)[#stk < max-1] Component IntStack is { State { stk : \set Integer; top : \set Integer -> Integer; } Invariant { #stk >= 0; } Services { ip1: Push (i : Integer); pre post (~#stk = #stk + 1) \and (top(stk) = i); ip2: Pop ( ) : Integer; pre #stk > 0; post (~#stk = #stk – 1) \and (\result = top(stk)); } } Push(i) [#stk < max-1] Empty Stack Non-Empty Stack Push(i)[#stk = max-1] Pop [#stk = 1] Pop [#stk > 1] Pop[#stk = max] Full Stack

24. Zave & Jackson’s Description Graph Evt-a Evt-e Evt-i Evt-b First Order Logic Evt-f Z FSA Evt-c Evt-j Evt-g Evt-d

25. 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

26. 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