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

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

1

Formal Methods in SE

Abstract Model Specification

Lecture # 19

Page 2: 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

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

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.

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

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.

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

5

Alloy: A Lightweight Object Modeling Notation

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

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”

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

7

Example

File System

DirEntry NameObject

contents

!

name!

Parent(~children)

entries!

DirFile

Root!

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

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’}}

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

9

Example (File System)

• Structure of the model– Domain paragraph

– State paragraph

– Definition paragraph

– Invariants

– Condition

– Assertions

– Operations

– Assertions

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

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.

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

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.

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

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.

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

13

Design Faults

• Omission of the let construct & relational operators

• No integers

• No distinction between attributes and relations

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

14

Formalizing Style to Understand Descriptions of Software

Architecture

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

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

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

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

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

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

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

18

How is it done?

• Demonstrate analysis within & between formally defined architectural styles

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

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

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

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

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

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

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

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

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

23

Step 1 (Define Semantic Model)

Pipe

source, sink : DATAPORTalphabet : P DATA

source = sink

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

24

Step 2

Define Concrete SyntaxFilterDescriptions : P COMPDESCPipeDescription : P CONNDESC

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

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

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

26

Step 4

• Highlight the constraints in the syntax

LegalPFComponentComponent

Description FilterDescriptions

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

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