1. 1 Formal Methods in SE Abstract Model Specification Lecture # 19

2. 2 Advantages  The flexibility to model a specification which can directly lead to the code.  Easy to understand  A large class of structural models can be described in Z without higher – order features, and can thus be analyzed efficiently.  Independent Conditions can be added later

3. 3 Chemical Abstract Model CHAM: for architectural description and analysis. Software Systems chemicals (whose reactions are controlled by explicitly stated rules). Where floating molecules can only interact according to a stated set of reaction rules.

4. 4 Features(CHAM) - Modular specification -Chemical reactions -Molecules (components) -Reactions (Connectors) -Solutions (States of CHAM) -This is used in areas where intended architecture will tend to be large, complex, and assembled from existing components. -Architectural elements: Processing elements, data elements, and connecting elements.

5. 5 Alloy: A Lightweight Object Modeling Notation

6. 6 Introduction Alloy –Is a modeling notation that describes structural properties –Has a declaration syntax compatible with graphical object models –Has a “set-based” formula syntax –Is based on “Z”

7. 7 Example File System DirEntryNameObject contents ! name ! Parent (~children) entries ! Dir File Root!

8. 8 Example (File System) model FileSystem { domain {Object, DirEntry, fixed Name} state { partition File, Dir: static Object Root: fixed Dir! entries: Dir! -> DirEntry name: DirEntry -> static Name! contents: DirEntry -> static Object! parent (~children) : Object -> Dir } def parent {all o | o.parent = o.~contents.~entries} inv UniqueNames {all d | all e1, e2: d.entries | e1.name = e2.name -> e1 = e2} inv Parents { no Root.parent all d: Dir – Root | one d.parent} inv Acyclic {no d | d in d.+parent} inv Reachable {Object in Root.*children} cond TwoDeep {some Root.children.children} assert FileHasEntry {all o | sole o.parent} assert AtMostOneParent {all o | sole o.parent} op NewDirEntries (d: Dir, es: DirEntry’) { no es & DirEntry d.entries’ = d.entries + es all x: Dir – d | x.entries’ = x.entries } op Create (d: Dir!, o: Object’!, n: Name) { n! in d.entries.name some e: DirEntry’ | NewDirEntries (d, e) && e.contents’ = o && e.name’ = n} assert EntriesCreated {all d: Dir, e: DirEntry’ | NewDirEntries (d, e) -> DirEntry’ = DirEntry + e} assert CreateWorks {all d, o, n | Create (d, o, n) -> o n d.children’} }

9. 9 Example (File System) Structure of the model –Domain paragraph –State paragraph –Definition paragraph –Invariants –Condition –Assertions –Operations –Assertions

10. 10 Analysis Alloy supports two kinds of analysis –Simulation: Consistency of an invariant or operation is demonstrated by generating a state or transition. –Checking: A consequence of a specification is tested by attempting to generate a counterexample. Together they enable an incremental process of specification.

11. 11 Based On Z Alloy is based on Z because: –Simple and intuitive semantics (based on sets). –Well suited for object oriented modeling. –Data structures are built from concrete mathematical structures.

12. 12 Features Automatic analysis –Theorem proving is deep & automatic. Easier to read and write. Plain ASCII notation. Relational operators are powerful. Incorporates mutability notions from informal notations.

13. 13 Design Faults Omission of the let construct & relational operators No integers No distinction between attributes and relations

14. 14 Formalizing Style to Understand Descriptions of Software Architecture

15. 15 Introduction Software architecture describes a software system Architectural descriptions are informal & diagrammatic Represented by boxes & lines –For one system they may mean filters & pipes –For another system boxes  abstract data types or objects & lines  procedure calls

16. 16 Introduction Different graphical conventions used to describe more than one kind of component or connection type in a single system Generalized meanings to architectural descriptions

17. 17 How is it done? Formalize abstract syntax for architectures For a given style: –Define the semantic model –Discuss concrete syntax for easing syntactic descriptions in a given style –Define the mapping from abstract syntax into semantic model –Make explicit the constraints on the syntax

18. 18 How is it done? Demonstrate analysis within & between formally defined architectural styles

19. 19 Abstract Syntax of Software Architectures Component: –Relationship between component & it’s environment is defined as a collection of interaction points or ports: [PORT, COMPDESC] Component ports : P PORT description : COMPDESC

20. 20 Abstract Syntax of Software Architectures Connectors: –Connector has an interface that consists of a set of roles: [ROLE, CONNDESC] Connector roles : P ROLE description : CONNDESC

21. 21 Abstract Syntax of Software Architectures Instances of components & connectors are identified by naming elements from the syntactic class [COMPNAME, CONNNAME] PortInst == COMPNAME x PORT RoleInst == CONNNAME x ROLE

22. 22 Step 1 (Define Semantic Model) Filter Alphabet : DATAPORT P DATAPORT States : P STATE Start : STATE Transitions : (STATE x (DATAPORT seq DATA)) (STATE x (DATAPORT seq DATA)) Inputs n outputs = o Dom alphabet = inputs u outputs Start  states Inputs, outputs : P DATAPORT s1, s2 : STATE ; ps1, ps2 : DATAPORT seq DATA ((s1, ps1), (s2, ps2))  transitions s1  states  s2  states  dom ps1 = inputs  dom ps2 = outputs  ( i : inputs ran (ps1(i))  alphabet(i))  ( o : outputs ran (ps2(o))  alphabet(o))

23. 23 Step 1 (Define Semantic Model) Pipe source, sink : DATAPORT alphabet : P DATA source = sink

24. 24 Step 2 Define Concrete Syntax FilterDescriptions : P COMPDESC PipeDescription : P CONNDESC

25. 25 Step 3 Mapping from Abstract Syntax to Semantic Model  PF Comp : Connector P Pipe  c : Connector ; p1, p2 : Pipe | p1   PF Comp (c ) p2   PF Comp (c )  p1.alphabet = p2.alphabet

26. 26 Step 4 Highlight the constraints in the syntax LegalPFComponent Component Description  FilterDescriptions

27. 27 Advantages Provides a templates for formalizing new architectural styles in a uniform way Provides uniform criteria for demonstrating that the notational constraints on a style are sufficient to provide meanings for all described systems Makes possible a unified semantic base through which different stylistic interpretations can be compared