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

of 27/27
1 Formal Methods in SE Abstract Model Specification Lecture # 19
  • date post

    17-Jan-2016
  • Category

    Documents

  • view

    212
  • download

    0

Embed Size (px)

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

  • *Formal Methods in SE

    Abstract Model SpecificationLecture # 19

  • *AdvantagesThe flexibility to model a specification which can directly lead to the code.Easy to understandA 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

  • *Chemical Abstract ModelCHAM: 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.

  • *Features(CHAM)- Modular specificationChemical reactionsMolecules (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.

  • *Alloy: A Lightweight Object Modeling Notation

  • *IntroductionAlloyIs a modeling notation that describes structural propertiesHas a declaration syntax compatible with graphical object modelsHas a set-based formula syntaxIs based on Z

  • *ExampleFile SystemDirEntryNameObject contents!name!Parent(~children)entries!DirFileRoot!

  • *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}}

  • *Example (File System)Structure of the modelDomain paragraphState paragraphDefinition paragraphInvariantsConditionAssertionsOperationsAssertions

  • *AnalysisAlloy supports two kinds of analysisSimulation: 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.

  • *Based On ZAlloy 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.

  • *FeaturesAutomatic analysisTheorem proving is deep & automatic.Easier to read and write. Plain ASCII notation.Relational operators are powerful.Incorporates mutability notions from informal notations.

  • *Design FaultsOmission of the let construct & relational operatorsNo integersNo distinction between attributes and relations

  • *Formalizing Style to Understand Descriptions of Software Architecture

  • *IntroductionSoftware architecture describes a software systemArchitectural descriptions are informal & diagrammaticRepresented by boxes & linesFor one system they may mean filters & pipesFor another system boxes abstract data types or objects & lines procedure calls

  • *IntroductionDifferent graphical conventions used to describe more than one kind of component or connection type in a single systemGeneralized meanings to architectural descriptions

  • *How is it done?Formalize abstract syntax for architecturesFor a given style:Define the semantic modelDiscuss concrete syntax for easing syntactic descriptions in a given styleDefine the mapping from abstract syntax into semantic modelMake explicit the constraints on the syntax

  • *How is it done?Demonstrate analysis within & between formally defined architectural styles

  • *Abstract Syntax of Software ArchitecturesComponent:Relationship between component & its environment is defined as a collection of interaction points or ports:[PORT, COMPDESC]

    Componentports : P PORTdescription : COMPDESC

  • *Abstract Syntax of Software ArchitecturesConnectors:Connector has an interface that consists of a set of roles:[ROLE, CONNDESC]

    Connectorroles : P ROLEdescription : CONNDESC

  • *Abstract Syntax of Software ArchitecturesInstances of components & connectors are identified by naming elements from the syntactic class[COMPNAME, CONNNAME]PortInst == COMPNAME x PORTRoleInst == CONNNAME x ROLE

  • *Step 1 (Define Semantic Model)FilterAlphabet : DATAPORT P DATAPORTStates : P STATEStart : STATETransitions : (STATE x (DATAPORT seq DATA))(STATE x (DATAPORT seq DATA))Inputs n outputs = oDom alphabet = inputs u outputsStart e states

    Inputs, outputs : P DATAPORT s1, s2 : STATE ; ps1, ps2 : DATAPORT seq DATA ((s1, ps1), (s2, ps2)) e transitionss1 e states L s2 e statesL dom ps1 = inputs L dom ps2 = outputsL( i : inputs ran (ps1(i)) alphabet(i))L ( o : outputs ran (ps2(o)) alphabet(o))

  • *Step 1 (Define Semantic Model)Pipesource, sink : DATAPORTalphabet : P DATAsource = sink

  • *Step 2Define Concrete SyntaxFilterDescriptions : P COMPDESCPipeDescription : P CONNDESC

  • *Step 3Mapping 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

  • *Step 4Highlight the constraints in the syntax

    LegalPFComponentComponent Description FilterDescriptions

  • *AdvantagesProvides a templates for formalizing new architectural styles in a uniform wayProvides uniform criteria for demonstrating that the notational constraints on a style are sufficient to provide meanings for all described systemsMakes possible a unified semantic base through which different stylistic interpretations can be compared

    *