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
DirEntry NameObject
contents
!
name!
Parent(~children)
entries!
DirFile
Root!
8
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’}}
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]
Componentports : P PORT
description : COMPDESC
20
Abstract Syntax of Software Architectures
• Connectors:– Connector has an interface that consists of a set
of roles:• [ROLE, CONNDESC]
Connectorroles : 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
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))
23
Step 1 (Define Semantic Model)
Pipe
source, sink : DATAPORTalphabet : P DATA
source = sink
24
Step 2
Define Concrete SyntaxFilterDescriptions : P COMPDESCPipeDescription : 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
LegalPFComponentComponent
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