integration floppy by HC1208070724

VIEWS: 0 PAGES: 62

									 A General Framework for
Formalizing Object-Oriented
   Modeling Techniques
                 Betty H. C. Cheng
Software Engineering and Network Systems Laboratory
  Department of Computer Science and Engineering
              Michigan State University
           East Lansing, Michigan 48824
               Chengb@cse.msu.edu
             www.cse.msu.edu/~chengb
                                                  1
              Acknowledgements
   Joint work with the following people:
       Robert Bourdeau
       Laura Campbell
       William McUmber
       Enoch Wang
       Ryan Stephenson
   Sponsored in part by:
       National Science Foundation Grants:
            (CCR-9633391, CCR-9901017, EIA-0000433)
       DARPA Grant (EDCS Program): F30602-96-1-0298
       Motorola
       Eaton Corporation
       Siemens Automotive
       Detroit Diesel Corporation

                                                       2
              Bridge the Gap Between Informal and Formal Methods




                                     Apply Formalization Framework
Object-Oriented “Blueprints”                                             Formal Representations

                                                                     Formal Methods:
                                                                     • Well-defined language
                                                                     • Set of rules for reasoning



                                                                     Formal Specifications:
                                                                     + Automated Analysis
  Informal specifications,                                                •Consistency, completeness
   + graphical models,                                                    •Rapid Prototyping
   + easy for humans to                                                   •Behavior Simulation
    formulate,                                                       + Design Transformations
   - may be inconsistent and                                         + Automated Test Case generation
    incomplete.                                                      - May be difficult to construct/modify
                                                                                                    3
            Overview

   Introduction
   Background
   Formalization Framework
   Validation:
       Tool Support
       Case Study
   Related Work
   Conclusions and Future Investigations


                                            4
                Objectives and Results
   Overarching goals:
       Broaden base of developers who can use rigorous software
        engineering techniques
       Provide palatable path to more rigorous SE techniques
       Leverage existing expertise and technology
   Specific Goals
       Enable use of intuitive diagrammatic notations (UML) for embedded
        system design
       Provide path from UML to existing formal languages
            Existing user base
            Support Tools
       Enable automated analyses of model
            Simulation
            Model checking

                                                                            6
Domain: Embedded Systems




                           7
            Background: Embedded
            Systems
   Code difficult to design and analyze
       Time-dependent
       difficult to instrument
       often highly concurrent
   High level of robustness required
       control real-world, physical processes




                                                 8
Informal Modeling Notation




                             9
             Background: UML

Unified Modeling Language
   “General-purpose” visual modeling language
       de facto Standard

   (At least) nine different diagrams
       use case, class, state, interaction (2), implementation (2), etc

   Diagrams described by metamodels:
       A graphical model that describes syntax of model

   Therefore, nine different metamodels

                                                                           10
     UML Class Diagram

                                        Named association
  “type of”
  indicator                 Talks-to
              Class A   1                 0..1
                                                 Class X

                                                    multiplicities
Class A1      Class A2        Class A3

                            Contains aggregations
                            of Class B

              Class B                   Contains components



                                                                     11
        UML Metamodel

   Metamodel defines UML syntax using
    class diagram notation.
   Semantics not defined by metamodel


   Note: Any language or diagram syntax can
    be defined with a metamodel

                                           12
Example Metamodel

                Program




         0..*
                 Block




    Compound               Simple
    Statement             Statement




                                      13
      Metamodel - Diagram -
      System Relationship


                             UML
Metamodel     Constrains    Diagram      Specifies      System
               syntax                    aspect of
                           Instance


   Uses class diagram       Specific diagram shows
   notation to describe     some aspect of the system
   diagram component        being constructed
   relationships

                                                             14
Target Formalization
    Languages




                       15
        Background: VHDL

   IEEE standard language
   Intended for abstract description of hardware
   Uses multiple, concurrent, communicating
    processes
       Communication through “signals”
   Syntax is Ada-like, procedural in nature
   Models can be “executed” in simulation.



                                                    16
            Background: Promela
            (SPIN)
   Promela is language for SPIN model checker
       Simulation and model checking of concurrent systems
   SPIN: commonly used in telecommunication
    domain
       Developed by Bell Labs (now Lucent part)
       Protocol verification
   Guarded Command Language + CSP + C
   Collection of processes, channels, and variables



                                                              18
                 Background: Promela Example

                        typdef A_type {
                        int x;                                          “structure” typedef
   declarations         int y;
                        bool unused;
                        mtype vals;                                   Channel declaration
                        }
                        chan queue=[3] of {mtype};

  “initial” procedure
                        A_type A;
                        mtype={on, off, none};
                                                                      Instantiation of “A_type”

                        init {                                        Executed as one stmt
Guarded                 atomic {A.x = 1; A.y = 2}
statement               run abc()
                        }
                                                          Proctype instantiation
                                                                              Basic proctype
 Proctype declaration   proctype abc() {
                        int I;
                        do
  do-od loop            :: A.x > 1 -> A.y = A.y + 1; A.x = A.x + 1;
                        od;
                        queue!on;
                                                                                    Channel
   if-fi block          if                                                           write
                        :: queue?vals                                     Channel
                        :: A.y > 4 -> goto skip1                           read
                        fi}


                                                                                                  19
General Formalization
    Framework




                        20
         Homomorphisms

  Preserve operations, hence structure
  and semantics
                                         With the mapped objects

  h(a  b)  h(a )  h(b)
This operation in this system
with these objects (a & b)
                          Does the “same thing” as this operation
                          in this system




                                                                    21
            Metamodel mapping


         UML                         Formal language
       metamodel   Homomorphism        metamodel



Describes                          Describes
instance                           instance


         UML                         Formal description
                   Mapping Rules
       diagram                           of system




                                                          22
               Unified Class/Dynamic
               Metamodel
     Class related                   Model
     Dynamic related

       Behavior          Class                    Relationships



State Vertex             Instance
                         Variables       Aggregation         Generalization

           Transition
                                                   Association


 Rest of dynamic model

                                                                         23
               Dynamic Model Portion of
               Unified Metamodel
                         To Class
                                                   Behavior
                                                                                   Guard
                                                        1..*                           0..1
                          1                                                        1
                                     0..1
                      State Vertex                                        Transition
                                     0..1

                                            0..1               0..1
        Pseudostate            State                                  ActionSequence
                                            0..1               0..1
    0..1
  CompositeState                     SimpleState                           Event

Start        Join

                                                   SignalEvent         TimeEvent         ChangeEvent
Final         History




                                                                                                       24
             Example Metamodel
             Mapping
                                                          Target
Source
                         h:

                        h:

              R
         A          B         h:

                                         R’
                                   B’                A’      D’
         hasComp(A,C)
                              h:

         C                          hasPart(A’,C’)
                         h:
                                                     C’



                                                                   25
            Introduction to Mapping
            Rules
   VHDL used for embedded systems
       VHDL contains timing notations
       Many commercial tools available
       Comprehensive simulation capability


   SPIN used in industry
       Spin provides model simulation and checking


   Concurrency is a feature of both

                                                      26
        Promela Class Diagram
        Mapping Rules

   Classes (objects) map to proctypes.

   Relationships map to channels.

   Instance variables map to global typedef
    structures.

                                               31
         Promela Dynamic Model
         Mapping Rules
   Simple states map to blocks of Promela
    statements.
   Transitions map to goto and run()
   Composite states map to proctypes
   Events map to channel writes/receives
   Pseudo-states map to blocks of various Promela
    statements


                                                     32
            SPIN Analyses

   Random simulation
   Exhaustive search of states
       State transition system checked by temporal logic assertions
       Often provides counter-examples (path to problem state)
       “Easier” than theorem proving
   Better than simulation when precise timing not
    required




                                                                       33
        Summary of Mappings

  VHDL             Structure      Promela
Ent/Arch             Class       proctype

Port signature    Relationship   channels

procedure            State       Labeled block
                                 of statements
Ent/Arch
                  Composite
                    State        proctype
                                 Channel
Write to signal      Event       assignment
                                                 34
Tool Support




               35
                 Tool Support

                                    Analysis results



UML                           HIL                      Spec*   Analysis
             MINERVA                   Hydra                    Tool*


      Diagram          Analysis
       reports         reports




                                                                          37
      Architecture of Minerva
                                                  Diagram
                                                  reports
                     Diagram in
                    DoME format

UML   UML diagram                                             HIL
        editors                        Plug-ins

                    Visualization
                     commands                Analysis results
                                             (processed)



                                    Text processing
                                         scripts
                                                         Analysis
                                                         reports

                                              Analysis
                                              results (raw)
                                                                    38
          Hydra Translation Tool
                                         Modular per
                                       formal language
           Uses library and parser
             to implement rules


               HIL                            Language
Minerva                       Hydra            Language
                                            Specific Class
                              parser         Specific Class
                                                Library
                                                 Library




                     Formal
                     Specifications

                                       Implements mapping rules
                                         for specific language
                                                              39
Industrial Case Study




                        40
 Smart Cruise Requirements

                                      Desired trail distance

Safety zone
                     Coast zone                   Closing zone



   About 400 ft - acquires target vehicle. Closing speed low enough to control.


        Starts coasting to match speed


                   Maintain proper trail distance - speeds match
Safe zone
                                         This is what we want


                                                    Closing speed too high.




                       Issues warnings to avoid this condition




                                                                                  42
      Class - Context Diagram

                             Target acquisition
                             target loss                       System boundary
                             distance
              Control                                  Radar
Warnings



     “set”
                                                               Distance
                Car speed
     brakes     throttle control      Car         Car speed




                                                                Target
     Brakes                                 Throttle
                                            Control


                                                                             43
Smart Cruise Class Model

                    •Target acquisition
                    •target loss
                    •distance to target
Control                                       Radar
                                  Car speed




            Car speed            Car
          throttle control




                                                      44
   High Level Radar Dynamic
   Model
    [target <= 400]^target-acquired
                                        Check
            [target > 400]
                                       distance

                                            Car-speed



Wait for         Ack-from-control
                                      Get car speed
 ack

                                            Turn-on


           Turn-off
                                          Off



                                                        45
              Car Dynamic Model

                                                   Set cruise speed
          car1
                                                                 car3
                 Get-speed[real=set]^speed
  Get-speed[realset]/{adjust real speed}^speed
                                                                Set-speed
updatex          Supply speed to radar             updatespd

                         Supply speed to control    Unset cruise speed

                 car4
                                                                   car1
           Get-speed^speed
                                                                Unset speed
dogetspd                                           dounset

                                                                              46
High Level Control Dynamic
Model

            target                                 set
                          Wait for target                      Wait for “set”
                                                                                      Ack
                                                                                   from car
                                                         [exceed
Get speed                                                 bounds]       Warning
   and                             Check bounds
                                                                        or Alarm
 distance

                            [trailing]
                                                [closing]
                     Maintain
                      Trail
                     position

                                         Closing on target




                                                                                              47
          SPIN Analyses Performed

   Random simulation
   State reachability
   State reachability with assertions
   Progress loop analysis (cycle checks)
   Model checking with temporal claim
   Model checking with temporal claim and non-
    deterministic execution paths.


                                                  48
          Use of Simulation

   Check that model runs (does not deadlock)
   Model appears to achieve basic requirements
   Model not erratic (simulation is random)
   Exercise common paths
   Explore extremes for initial proper behavior
   Basically, high level debugging strategy



                                                   49
       State Reachability Analysis

 Reachability    is exhaustive (unlike
  simulation)
 For common scenarios,
   ensure set of states is correct and
   exception states not entered

 For exception scenarios,
   ensure exception states entered




                                          50
               State Reachability for
               Normal Scenario
           = reached                                                                (Establish target trail)

                            target                                 set
                                          Wait for target                      Wait for “set”
                                                                                                          Ack
                                                                                                       from car
                                                                         [exceed
                Get speed                                                 bounds]        Warning
                   and                             Check bounds
 control         distance
                                                                                         or Alarm

dynamic                                     [trailing]
  model                                                         [closing]
                                     Maintain
                                      Trail
                                     position                                        Only unreached
                                                                                    state, as expected
                                                         Closing on target




                                                                                                                  51
         SPIN Progress Loop
         Analysis
   Ensures no cycles of only unmarked
    states.

   Reports cycles unless state(s) are marked.
     If nothing marked, reports cycles
     If known cycles are marked, reports
      unexpected cycles


                                             52
            Progress Cycle Analysis of
            Model
   Liveness check: Ensure state cycle “follow
    target” established
       Differs from reachability by ensuring cycle exists, not
        just state visit.


   Safety check: Ensure no unexpected cycles
    encountered




                                                                  53
       Progress Loop Checks

  1. Green states reported as cycle when unmarked

                    target                                 set
                                  Wait for target                    Wait for “set”
                                                                                                   Ack
                                                                                                from car
        Get speed                                                             Warning
           and                             Check bounds                       or Alarm
         distance                                                          shut off system

                                    [trailing]
                                                        [closing]
                             Maintain
                              Trail
                             position

                                                 Closing on target
                                                                                         None of
                                                                                      these reported
2. After marked, no other cycles appeared
        (complement of first check)


                                                                                                           54
          Model Checking Tests

   Car achieves trail position, and stays there.
    Three checks:
       Once in idle, model never comes back
       when target sent, ack replied
       Remove ack to demonstrate check works


   Brake application leads to return to idle state.
       Revealed missed an event on transition




                                                       55
   Ensure Target is Never Missed
   Demonstrate Check Works

             Target acquired

Control                            Radar
            acknowledgement




    Remove this message to force
            claim to fail

This check failed (as expected)

                                           60
        Related Work

   Object-Orientation and Embedded
    Systems

   Formalization of UML

   Formalization of OO Modeling Techniques



                                              66
                 Embedded System Methodologies
   Ad Hoc (frequently used in industry)
   Structured methods - RTSA
       [Ward & Mellor, Hatley & Pirbhai]
       RTSA models semi-formal, uses top-down
   Hybrid OO -- RTOOSA [Ellis]
       Still structured, semi-formal - little object use
   OO, non-UML (ROOM) [Selic, Gullekson]
       Formal, but unusual OO model
   OO, UML based [Douglass]
       Semi-formal. No behavior verification


                                                            67
              Formalization of UML

Precise UML (pUML) based UML on Z
            [Evans, Clarks, Bruel, France, Lano]
       Attempts to provide direct manipulations of diagrams
       But no dynamic behavior mapping
       No way to verify behavior or properties, other than potential
        theorem prover

   Latella et al
       Formalized UML state diagram in terms of hybrid automata




                                                                        68
          Other OO Formalizations

   OCL shown to have problems
       [Mandel & Cengarle]
   Fusion well-defined process, but informal
    semantics [Coleman, et al]
   TROLL formally defined, but no checkers or
    simulation capability
       [Jungclaus, Saake, Hartman, Sernadas]
   Formalized OMT with rules but no general
    mapping framework [(Wang & Cheng), (Bourdeau & Cheng)]
       Rules specific to LOTOS


                                                             69
         Overview of Contributions

   General framework for providing semantics.
   Unified UML Class/Dynamic metamodel.
   Mapping to VHDL and Promela.
   Means to perform simulation and model checking
    from semi-formal diagrams.
   Systematic process for developing OO graphical
    models for embedded systems.


                                                     70
Where does this all fit in Big
        Picture?




                                 71
               Meridian: Automating Development of IDAs

PIs: B. Cheng, L. Dillon, P. McKinley, K. Stirewalt
   Interactive Distributed Applications (IDAs)
   Examples:
        On-board driver/pilot navigation systems.
        Computer-supported collaborative work
         environments.
        Distributed interactive simulation.




        Increasing interest fueled by:
           •The World-Wide Web.
           •Middleware technology (e.g., CORBA, DCOM,
           JavaBeans).
           •New network services and protocols.
                                                          72
                Meridian Research goals
   Improve quality of IDAs.
       Better IDAs (reliable, maintainable, extensible).
       Better development (faster, cheaper).
   Advance state of automated software-engineering (ASE)
    practice.
       Incorporate ASE techniques into mainstream development.
       Apply various formal methods in a new domain.
   Identify end-to-end automation techniques that take
    advantage of multiple phases of development.




                                                                  73
              Meridian Practical goals
   To have techniques adopted in practice:
       Must complement existing design methods and notations.
       Otherwise, acceptance must overcome stiff economic hurdles.
   Implications:
       Designers should not reformulate designs in a formal notation.
       Designers should not have to view the output of a formal analysis
        tool.
   We chose (UML) for representing IDA designs.




                                                                        74
                         Meridian Vision
 IDA Models                       IDA Constraints            IDA Interface        IDA Reuse     IDA External
                                                              Requirements        Repository    Parameters




                                                     Refined
                         Specifications              Specifications
                                                                               Code
                                                                    Design              Testing/
               Model                 Specification
                                                                  Processing           Simulation
               Editing                 Analysis
Requirements




                                                    Feedback
               User                                                       Test Cases




                                                                                                       75
             Summary of Contributions

   General framework for constructing mappings of
    diagrams to formal target languages
       Framework enables use of rigorous techniques to establish
        completeness, consistency, and correctness of mapping rules.
   A set of rules for generating VHDL and Promela
    specifications from UML
   Enable behavior simulation and analysis on informal
    diagrams via their formal specifications
   Systematic process for developing OO graphical models
    for embedded systems

                                                                       76
           Current and Future
           Research
   Consider other UML Diagrams:
       Use Case: provide high-level user goals
       Interaction Diagrams (Sequence and Collaboration):
        model behavior of specific scenarios
   Add temporal and real-time constraints
   Explore modified UML semantics
       Adapt semantics to application?



                                                             77
             Current/Future Research

   Mapping to SMV
       Different temporal logic (CTL)
       Different analysis capabilities (e.g., fairness)

   Explore the use of specification patterns to guide
    analysis capabilities
   Domain-specific refinement of UML diagrams
       Move closer towards implementation
       Use of Design Patterns and Frameworks



                                                           78
Discussion…




              79

								
To top