Formal Methods in SE

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

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. 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. 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. Alloy: A Lightweight Object Modeling Notation

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. Example File System contents ! ! Object DirEntry Name name Parent (~children) ! entries Dir File Root!

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. Example (File System) • Structure of the model • Domain paragraph • State paragraph • Definition paragraph • Invariants • Condition • Assertions • Operations • Assertions

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. 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. 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. Design Faults • Omission of the let construct & relational operators • No integers • No distinction between attributes and relations

14. Formalizing Style to Understand Descriptions of Software Architecture

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. 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. 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. How is it done? • Demonstrate analysis within & between formally defined architectural styles

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. 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. 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. Step 1 (Define Semantic Model) Filter Alphabet : DATAPORT P DATAPORT States : P STATE Inputs, outputs : P DATAPORT Start : STATE Transitions : (STATE x (DATAPORT seq DATA)) (STATE x (DATAPORT seq DATA)) Inputs n outputs = o Dom alphabet = inputs u outputs Start e states • s1, s2 : STATE ; ps1, ps2 : DATAPORT seq DATA • ((s1, ps1), (s2, ps2)) e transitions • s1 e states L s2 e states • L dom ps1 = inputs L dom ps2 = outputs • L ( i : inputs • ran (ps1(i))  alphabet(i)) • L ( o : outputs • ran (ps2(o))  alphabet(o))

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

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

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

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

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