Upload
ian-bibby
View
222
Download
1
Embed Size (px)
Citation preview
1
Abstract Model Specification
Tarang Garg
Srikumar Nagaraj
2
Abstract Model Specification
• 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
Notation
• Is used to test the results
• Independent of program code
• Mathematical Data model
• Represent both static and dynamic aspects of a system
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
Schema
Static Aspect The state can occupy. The invariant relationships that are
maintained as the system moves from state to state
6
Schema(cont.)
Dynamic Aspect The operations that are possibleThe relationship between their inputs and
outputs.The change of state that happen.
7
Notation - Example
Some variables are declared.
Relationship between the values of the variables
Name
Init Birthday Book
Known =
Birthday Book
8
ExampleBirthday book
known: NAME
birthday: NAME DATE
Known : dom birthday
Add BirthdayBirthday Book
name?: NAME
date?: DATE
name? known
birthday’ = birthday { name? date}
9
Example(cont.)
Find Birthday Birthday book
name?: NAME
date? : DATE
name? Known
date != birthday(name?)
10
Race conditionWe 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
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
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
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? : NAMEresult?: REPORT
Name? knownResult! = already_known
14
Use of OperatorsRAdd 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
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
Data RefinementData Structures:
Two arrays : names [1…] of NAME
dates [1…] of DATES
names’ = names{i v} ; names[i] := vthe 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
Example(Data and Direct Refinement)FindBirthday1
BirthdayBook1 name?:NAME date?:DATE
i : 1.. hwmname?=names(i) date! = dates(i)
Procedure FindBirthday(name: NAME; var date : DATE);var i: INTEGER;
begini:=1;while names[i] name do i := i+1;dates := dates[i]
end;
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
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
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
Alloy: A Lightweight Object Modeling Notation
22
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”
23
Example
File System
DirEntry NameObject
contents
!
name!
Parent(~children)
entries!
DirFile
Root!
24
Example (File System)model FileSystem {domain {Object, DirEntry, fixed Name}state {
partition File, Dir: static ObjectRoot: fixed Dir!entries: Dir! -> DirEntryname: 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.parentall 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 & DirEntryd.entries’ = d.entries + esall x: Dir – d | x.entries’ = x.entries }
op Create (d: Dir!, o: Object’!, n: Name) {n! in d.entries.namesome 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’}}
25
Example (File System)
• Structure of the model– Domain paragraph
– State paragraph
– Definition paragraph
– Invariants
– Condition
– Assertions
– Operations
– Assertions
26
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.
27
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.
28
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.
29
Design Faults
• Omission of the let construct & relational operators
• No integers
• No distinction between attributes and relations
30
Formalizing Style to Understand Descriptions of Software
Architecture
31
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
32
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
33
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
34
How is it done?
• Demonstrate analysis within & between formally defined architectural styles
35
Abstract Syntax of Software Architectures
• Component:– Relationship between component & it’s
environment is defined as a collection of interaction points or ports:
• [PORT, COMPDESC]
Componentports : P PORT
description : COMPDESC
36
Abstract Syntax of Software Architectures
• Connectors:– Connector has an interface that consists of a set
of roles:• [ROLE, CONNDESC]
Connectorroles : P ROLE
description : CONNDESC
37
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
38
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 = oDom 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))
39
Step 1 (Define Semantic Model)
Pipe
source, sink : DATAPORTalphabet : P DATA
source = sink
40
Step 2
Define Concrete SyntaxFilterDescriptions : P COMPDESCPipeDescription : P CONNDESC
41
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
42
Step 4
• Highlight the constraints in the syntax
LegalPFComponentComponent
Description FilterDescriptions
43
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