1. 1 Abstract Model Specification

2. 2 Explicitly describes behavior in terms of a model using well-defined types (viz. set, sequences, relations, functions) & defines operations by showing effects on model Specification includes type - syntax of object being specified model - underlying structure invariant - properties of modeled object pre/post conditions – semantics of operations

3. 3 Notation Is used to test the results Independent of program code Mathematical Data model Represent both static and dynamic aspects of a system

4. 4 Features( Z-notation) Decompose specification into small pieces (Schemas) Schemas are used to describe both static and dynamic aspects of a system Data Refinement Direct Refinement You can ignore details in order to focus on the aspects of the problem you are interested in

5. 5 Schema Static Aspect  The state can occupy.  The invariant relationships that are maintained as the system moves from state to state

6. 6 Schema(cont.) Dynamic Aspect  The operations that are possible  The relationship between their inputs and outputs.  The change of state that happen.

7. 7 Notation - Example Some variables are declared. Relationship between the values of the variables Name Init Birthday Book Known =  Birthday Book

8. 8 Example Birthday book known: NAME birthday: NAME DATE Known : dom birthday Add Birthday Birthday Book name?: NAME date?: DATE name?  known birthday’ = birthday { name? date}

9. 9 Example(cont.) Find Birthday Birthday book name?: NAME date? : DATE name?  Known date != birthday(name?)

10. 10 Race condition We have not handled the condition when user tries to add a birthday, which is already known to the system, or tries to find the birthday of someone not known. Handle this by adding an extra result! To each operation. Result := of| already_known | not_known Success Result! : REPORT Result! = ok

11. 11 Operators  (Conjunction of the two predicate parts) – any common variables of the two schemas are merged V (the effect of the schema operator is to make a schema in which the predicate part is the result of joining the predicate parts of its two arguments with the logical connective V ).

12. 12 Logical Conjunction Operator The conjunction operator  of the schema calculus allows us to combine this description with our previous description of AddBirthday AddBirthday  Success This describes an operation which, for correct input, both acts as described by AddBirthday and produces the result ok.

13. 13 Logical Disjunction operator This declaration specifies that if error occurs, the state of the system should not change. Robust version of AddBirthday can be RAddBirthday  (AddBirthday  Success) V Alreadyknown AlreadyKnown BirthdayBook name? : NAME result?: REPORT Name?  known Result! = already_known

14. 14 Use of Operators RAdd Birthday  Birthday Book name?: NAME date?: DATE result!: REPORT (name?  known  birthday’= birthday  {name? Date?}  result!= ok) V (name?  known  birthday’ = birthday  result != already_known)

15. 15 Data Refinement “ to describe the concrete data structures which the program will use to represent the abstract data in the specification, and to derive description of the operation in terms of the concrete data structures” Direct Refinement: method to go directly from abstract specification to program in one step From specification to design

16. 16 Data Refinement Data Structures: Two arrays : names [1…] of NAME dates [1…] of DATES names’ = names  {i v} ; names[i] := v the right side of this equation is a function which takes the same value as names everywhere except at the argument i, where it takes the value ‘v’.

17. 17 Example(Data and Direct Refinement) FindBirthday1 BirthdayBook1 name?:NAME date?:DATE  i : 1.. hwm name?=names(i)  date! = dates(i) Procedure FindBirthday(name: NAME; var date : DATE); var i: INTEGER; begin i:=1; while names[i]  name do i := i+1; dates := dates[i] end;

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

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

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

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

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

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

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

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

26. 26 Formalizing Style to Understand Descriptions of Software Architecture

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

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

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

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

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

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

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

34. 34 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))

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

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

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

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

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