Formal Methods in SE
Abstract Model Specification
Lecture # 19
1
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
2
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.
3
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.
4
Alloy: A Lightweight Object
Modeling Notation
5
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”
6
Example
File System
contents
!
!
Object
DirEntry
Parent
(~children)
File
Dir
!
name
Name
entries
Root!
7
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’}
}
8
Example (File System)
• Structure of the model
–
–
–
–
–
–
–
–
Domain paragraph
State paragraph
Definition paragraph
Invariants
Condition
Assertions
Operations
Assertions
9
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.
10
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.
11
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.
12
Design Faults
• Omission of the let construct & relational
operators
• No integers
• No distinction between attributes and
relations
13
Formalizing Style to Understand
Descriptions of Software
Architecture
14
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
15
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
16
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
17
How is it done?
• Demonstrate analysis within & between
formally defined architectural styles
18
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
19
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
20
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
21
Step 1 (Define Semantic Model)
Filter
Inputs, outputs : P DATAPORT
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 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))
22
Step 1 (Define Semantic Model)
Pipe
source, sink : DATAPORT
alphabet : P DATA
source = sink
23
Step 2
Define Concrete Syntax
FilterDescriptions : P COMPDESC
PipeDescription : P CONNDESC
24
Step 3
• Mapping from Abstract Syntax to Semantic
Model
PFComp : Connector
P Pipe
 c : Connector ; p1, p2 : Pipe | p1 e  PFComp (c )
• p2 e  PFComp (c )  p1.alphabet = p2.alphabet
25
Step 4
• Highlight the constraints in the syntax
LegalPFComponent
Component
Description e FilterDescriptions
26
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
27