Docstoc

Topics in Object-Oriented Methodology

Document Sample
Topics in Object-Oriented Methodology Powered By Docstoc
					Fundamental Concepts in Object-
    Oriented Methodology
         Takuya Katayama
              JAIST


                              1
                       Hi !
• Myself
  – Prof. at Japan Advanced Institute of Science
    and Technology
  – Working on formal and mathematical aspect of
    software engineering, especially
     • Object-Oriented Methodology
     • Software evolution
     • Fault-tolerant software
  – My family
     One wife, two daughters and one dog
                                                   2
                  Agenda
• Fundamental Concepts in Object-Oriented
  Methodologies
  – Objects, Classes, Structures among Classes
  – Behavior of Objects, State, State charts
  – UML
• Some Topics in OO Methodologies
  – Constraints and OCL
  – Proving Constraints

                                                 3
      What is Object-Oriented
         Methodology ?
• Software development method based on
  Object-Oriented Paradigm
  – Our world is a collection of collaborating
    entities called “objects”
  – Software has to be organized according to the
    structure of our world
     • It increases understandability.
     • It makes evolution of software easier.

                                                    4
    Object-Oriented Paradigm
• Our Word is a collection of collaborating
  entities
                President




   Factory                          Sales dept.



 Factory
 workers

                        Engineers      Scientists   5
        Object-Oriented Paradigm
 • Organize software according to the structure
   of the world
                Management Information
                Object
Factory
                                                    Sales
Management
                                                    Dept.
Object
                                                    Object




   Worker
   Object
                         Design Object   Laboratory Object   6
                         Requirement analysis,
          Problem        Specification, Design
          P⇒P'
                                       Platform M⇒M'
Real
World                    o
                         d
                         u
                         l
                         e
                         mA


W⇒W'                 o o o
                     d d d
                     u u u
                     l l l
                     e e e
                      B C D
                     m m m


                                 o
                                 d
                                 u
                                 l
                                 e
                                 mE

                         b       d
                                 (en
                                   u
                                   f
                                   re
                                   c
                                   s-
                                    w
                                    r
                                   (it
                 f   a       c   e (rrt n
                                    i-ee t
                                    f od- -
                                    (c (ui
                                    e c w re
                                     r u rr )
                                     r r ie )
                                     o    cfl
                                   ( rd
                                    i- i
                                    f if
                                    bsi
                                    u- d
                                     fm
                                     fo
                                     e  e
                         d          (c u u m
                                    dkr f e
                                     o or f )
                                     - ue e
                                     c tn r
                                      h (- n
                                      ec ba
                                         t-
                                 )
                                 ))

                Design D⇒D'        ()
                                   n)
                                   o
                                   vl
                                    u
                                    e
                                    a
                                   ( c--
                                    d kbf
                                    o ou a
                                    - uf m
                                    c tc e
                                     h co
                                     e
                                    (b 1
                                    s u)
                                     e f)
                                     t (
                                     q a
                                      cr
                                      -g
                                          n

                                    s fa
                                     e nr
                                     t ag
                                     q m2
                                      c e)
                                      o
                                    ( -(  )
                                    (lsa / f
                                    ie ( " c.
                                    f - c R -"
                                     (e o C b )
                                     |x n S u)
                                      (s c " "
                                      ft t
                                      ii      v
                                     p
                                     r
                                     (g
                                      n
                                      o
                                      m e e oi
                                       e " ww g
                                       s p a l"
                                       s l io )
                                       se t o
                                        aa, n
                                      ( g s nk
                                      e-- n
                                      xm c d
                                       e oo
                                       c nm
                                       ui m
                                        tt
                                      (e o a
                                       c.
                                       on
                                        c
                                        a
                                        t
                                       (..

        Programming, Test             m "
                                       e d
                                       s o
                                       s n
                                        a e
                                        g )
                                      ( e"

                                  Program S⇒S‘

                                                  7
             Software Evolution
The most difficult and costly part in software
  lifecycle
   – Missing design information
      • Legacy code problem
   – Difficulty of understanding and comprehending the
     entire system from the beginning of its development.
      • Complex systems can only be build only through evolution.
           Evolutionary prototyping
   – New applications require evolution
      • Open system
          – Need to adapt to unknown environments
 Computationally, Objects are…
• Elements of the world to be described
   – Autonomous behavioral elements
• Object=Attributes+Operations+Behavior
   – Attributes:Local data of object
   – Operations:For changing/referencing the attributes
   – Behavior:Upon receiving stimulus(event), the
     object (1) perform operations, (2) changes its states
     and (3) sends out events to other objects.
      • Usually, modeled as statecharts or event-driven program
• Object is encapsulated.
   – No internal state and attribute values can be seen
     from outside the object.
                                                                  9
Communication via events




 Attribute: position,color,...
 Operation: draw, paint, move,....
 Behavior:         e/move, e‟

                                     10
       Description of the World

• How do we describe the world?
   – Class concept + Relations among classes
• Class as a set of “similar objects” in the world
   – Abstraction :{professor Shinoda, professor Tan, …}
                        class “professor”
   – Instantiation : “professor”  professor Shinoda
   – Class concepts provides economy and reuse of
     thought and description.

                                                          11
          Objects and Classes

object:    Thai
  Laos              Myanmar abstraction
           Indonesia
                         instantiation
                                              class:
  Shinoda         Tan
                                             Country

                                         lives-in

                           class:
                           People
                                                       12
   Relationships Among Classes

• Class Hierarchy, Inheritance, “is a”
   – Generalization/Specialization
   – Mammal < Monkey < Human
• Composition, Aggregation, “has a”
   – Automobile=Body+Wheels+Steering+Engine
• Association, a general relation between classes
    People―(lives-in)―Country
• Dependency, Realization,...

                                                    13
   Two Major Issues in Object-
     Oriented Methodology

• Object-Oriented Analysis/Design
  – BOOCH, OMT, UML, Catalysis methods
  – Constraints, Formal Approach, Analysis
    Patterns,Unified Process, …
• Object-Oriented Programming
  – OO languages: Smalltalk, C++, Java
  – Design Patterns, Frameworks , Class Libraries
    …
                                                14
       Typical Object-Oriented
        Development Process
                                           Architecture design
           Analyzing                       Choice of impl. strategy
           requirement     Object model    Object design

Reqrmnts   Analysis       Dynamic model        Design         Coding

                                                          Coding in OO
                                                          language
                               ・
                               ・
                               ・
                         Analysis models

                                                                      15
        Multiple Analysis Models
• Description of a single model from multiple views
  which are almost independent
  company        division          section

               Object Model for classes in the         e1/e2, u=f(v)
  employee     world and their relationship       s1               s2

      main
    x
         sub1
                                             z   Dynamic Model for behavior
                            sub3
    y                                            description of each object
             sub2
  Functional Model for data flow in the world
• Eight Models + One Language in UML                                    16
                     UML

• Notations to describe every aspects of
  software development
  – From business systems to industrial
    embedded systems
• Unified notations in Booch method, OMT
  method(Rumbaugh), OOSE method
  (Jacobson)
• Becoming a standard language of software
  engineer
                                             17
    UML- Eight Diagrams and One
            Language
•   Use Case Diagram
•   Class Diagram/Object Diagram
•   State Diagram
•   Sequence Diagram
•   Collaboration Diagram
•   Activity Diagram
•   Component Diagram
•   Deployment Diagram
•   OCL(Object Constraint Language)
                                      18
          Use Case Diagram

• Use Cases describe a rough sketch of
  functions or “usage” of the system looked
  from the actors outside the system.
• System functions are described by a set of
  use cases.



                                               19
           Use Case Diagram
            Use cases :
            specifies functions of
            system
                                      Actor :
              Sign an insurance       human, machine,…
              policy                  interacting with the system

               Process sales
               statistics

              Process customer
Customer      statistics
                                     Insurance Salesperson

             Insurance System
                                                              20
          Description of Use Case
• By sentences or activity diagrams
   –   Purpose of use case
   –   How the use case is initiated
   –   Message flow between actors and use case
   –   Alternative flow
        • conditional/exceptional flow
        • do not go into too much details
   – Utilizing of other use cases : use case call
   – How the use case is terminated

                                                    21
Use cases are described
by activity diagrams if they      Insert coins

are well-defined.
                                  Enough coins
                                  inserted?


                                Show that drink
                                can be chosen
                                                     Show that drink
                                                     is not available
                                  Choose drink


    Drink customer                        drink not available

                        drink available

                                  Deliver drink


                                                                        22
    In OO development, use cases are used to find
    objects. Functions represented by the use cases
    are realized as collaborations among the objects.
                           <<realizes>>

       use case U                              collaboration
                                              <<implements>>


  use case description         class Button     class Drink    class Disp

1.the actor depresses an          op1              op1           op1
   button                         op2              op2           op2
2.action 1 is executed            op3                            op3
3.a message is sent to
  the actor
4. …
                                                                     23
                               discover classes
             Class Diagrams
• Classes in the system + Relations
• Relations among classes
  –   Inheritance
  –   Aggregation
  –   Association
  –   Dependency
  –   Realization

                                      24
            Class and Object

   Employee       Employee        Employee
  name:String    name:‟Smith‟    name:‟Sharp‟
  pos:String     pos:‟eng‟      pos:‟chief eng‟
    promote        promote         promote




Class Employee      Objects instantiated from
                    the class Employee

                                                  25
         Link and Association

• Link : Relation among objects instantiated
  from classes
  – Channel for event transmission
  – Access path for data access/navigation

       Person        workat      Company
      Joe Smith                  Simplex Co.



                                               26
• Association : Relation between classes
   – Abstraction of links between objects

     Person        workat        Company




Joe Smith∈Person            Simplex Co.∈Company




                                                  27
             Link and Classes
       R
・ If O1―O2 for some O1∈C1,O2∈C2
then
            R
          C1―C2

・ R⊆C1×C2
C represents objects instantiated from the class C



                                                     28
Direct Products of Sets and Relations

 • Direct Product
     C1×C2={(O1,O2)|O1∈C1,O2∈C2}
 • Relation R between C1 and C2 : R⊆ C1×C2
   – Parent relation P⊆Human×Human
      P={(x,y) | y is a parent of x, x,y are in Human}
   – Devisor relation D⊆N×N, N:the set of natural
     numbers
      D={(m,n) | n=km forR   some k in N}

 • When (O1,O2)∈R, we write O1ーO2
                                                         29
Association and Multiplicity
Line   2..*   0..*   Point
name   Intersect     name


Line                 Point
L1                   P1

Line
                     Point
L2
                     P1
                                   L2
Line
L3                                 P1    P2
                             L3
Line
L4
                     L5       L1        L4
Line
L5                                            30
                                                Equipment
                                              name
    Inheritance                               manufacturer
                                              weight
                                              cost
Attributes and operations
are inherited from super
classes
                              Pump              Heat exchanger      Tank
                        suction pressure         surface area      volume
                        discharge pressure       tube diameter     pressure
Diaphragm pump          flow rate                ….
name=P101
manufacture=Simplex
…                       Diaphragm pump       Plunger pump    Floating roof tank
suct pressure=1.1 atm
                        diaphragm material                     diameter
…
                                                               height
diaph material=Teflon

                                                                        31
                   Inheritance
  • A method for classifying classes according to
    their generality
  • Inheritance is not an association

                      B inherits attributes and operations
                      from A
super class   A
                         Attr*(B)=Attr*(A)∪Attr(B)
                         Op*(B)=Op*(A)∪Op(B)
                      where,
subclass      B          Attr*(C):attributes effective at C
                         Attr(C):attributes defined in C
                         Op, Op*: similarly
                                                          32
            Aggregation

                  Computer


1..*

Monitor   System box     Mouse       Keyboard


                              1..*       0..1
Chassis     CPU              RAM       Fan

                                             33
•  Aggregation is a special case of association
•  Object of the class A is together with objects
   of the Class B and C as OA(OB,OC).
1. State space of the object in the class A
     =V(Attr*(A))×V(Attr*(B))×V(Attr*(C))
    –   Attr*(X): attributes effective at class X
    –   V({a,b,...,c})=V(a)×V(b)×…×V(c)
    –   V(a)= set of values which the attribute a can take.


                                   A



                          B                    C
                                                              34
2. Operations of the object OA of the class A
  is delegated to its parts OB,OC

                                        OB         Attr B

        OA        Attr A

                                        OC         Attr C



Reacting to events from outside, OA send events to OB and OC
asking to perform the associated tasks. Their results are sent
back to OA.                                                      35
         An Example of Delegation



         having           copy            copy
Person       * document     * paragraph     * character

                  copy           copy            copy




                                                        36
   Aggregation and Inheritance
• Aggregation is inherited.
                  A



            B             C           D

                                       *
                                      E

Object of D has parts which are objects of B,C and E.
        OD(OB,OC,OE1,OE2,...)                     37
                          Lamp



     Fluores- Incandes-      Base     Cover   Switch Wiring
     ent Lamp cent Lamp




Ballast   Twist    Starter       Socket
          mount


                                                       38
 Recursive Aggregation

        program
                        program::={block}
                        block::=simple statement
            *                   |compound statement
    *    block          compound statement::={block}

                        {A}≡ε|A|AA|AAA|…
compound         simple
 sentence       statement

                                                39
                 Dependency


       class A                  class B


– Utilize class A in class B
   •   B has A as a parameter
   •   B accesses data in A
   •   B uses operations A
   •   Change of A affects B
                                          40
              Realization

                      R
    class A                       class B


– Class B is a realization of A
   • B is more concrete
   • A is more abstract
   • R: mapping B  A

                                            41
       Interface and Realization
• Interface is a special class with abstract operation.
  It is used with classes which realize/implement
  them.
   <<interface>>
                                          PopupMenu
   ChoiceBlock
                                          setDefault(choice:String)
   setDefault(choice:Choice)
                                          getChoice():String
   getChoice():Choice




       choice 1..*
                                                choice 1..*
       <<interface>>           realization
                                                       String
       Choice             specifier   implementation
                                                                  42
             Dynamical Views
• State Diagram/Statechart
   – Specify dynamics of individual object
• Sequence Diagram
   – Event sequence observed in collaborating objects
• Collaboration Diagram
   – Different notation of sequence diagram
• Activity Diagram
   – Action + Control structure
   – Flowchart

                                                        43
                  State Diagram

• Description of individual objects
• Fundamental concepts
   – event, state, scenario, event trace, state transition, state
     transition diagram, operation, action
• Advanced concepts
   – nested transition diagram, generalized state,
     concurrency, event dispatching, synchronization of
     concurrency


                                                                44
        Event and Event Trace

• Event
   – Stimulus which an object transmit to other
     objects
   – Object reacts to events and perform
     associated tasks
   – Event has no duration time.
   – Event may have attributes, which represents
     its contents

                                                   45
• Event Trace
  – Sequence of events
  – Scenario
     • Sequence of events observe when the system
       performs some function
• Event Trace Diagram/Sequence Diagam



                                                    46
 An Event Sequence in a Telephone System
                                         object
Caller        event              Phone line                  Callee
         caller-lifts-receiver

         dial-tone-begins

         dial(5)

         dial(1)


                                          callee-hangs-up

         connection-broken                connectin-broken

         caller-hangs-up

                                                                      47
                       State
• Status of object at a certain time
• Represented by attribute values and links
            s = ( attr1:12, attr2:5, L1:O1, L2:O3 )

                L1   attr1=12,attr2=5
                                        L2
                                                  O3∈C3
    O1∈C1
                        O2∈C2
       s∈state(C2)=V(attr1)×V(attr2)×C1×C3

                                                          48
Behavior of Object and Its State

• Object become active reacting by receiving
  event.
• On receiving events, the object performs
  operation and change its state. It performs
  the same operation at the same state.
• It remains in the state until it receives new
  events.

                                              49
                                             object
    Caller        event              Phone line                  Callee
             caller-lifts-receiver

state        dial-tone-begins

             dial(5)

             dial(1)


                                              callee-hangs-up

             connection-broken                connectin-broken

             caller-hangs-up



                                                                      50
      Characterization of State
• Sequence of events leading to the state from
  the initial state
                         e3
                    e2
               e1
       Sinit                                  S


                                e1e2e3....
           S≡{e1e2e3.... | S0     →      S}


                                                  51
• A predicate/condition which is true at the
  state
         S1      S2
                         state S≡ a predicate PS
         S3      S4
                         t ∈S ⇔ PS(t):true



                                               52
• acceptable input events+next states

                  e1      S1

           S
                  e2
                          S2



                                        53
              State Diagram
• “Input Event+Next state” style description of
  the behavior of objects




 State Diagram = (STATE, EVENT,Trans, Sinit)
     STATE: a set of states
     EVENT: a set of events
     Trans: STATE×EVENT→STATE
     Sinit : initial state
                                                  54
  State Diagram for “Phone line”
                              caller-hangs-up
             Idle

                caller-lifts-receiver
                            time-out
          Dial tone                     Time-out

                dial(n)
dial(n)                      time-out
           Dialing


                          callee-hangs-up
          Connected                             Disconnected
                                                           55
                   Guarded Transitions

  North/south        time-out[cars in N/S left lanes]       North/south
  may go straight                                           may turn left

                                      time-out
                                      [no cars in N/S left lanes]

time-out      time-out                                              time-out
              [no cars in E/W left lanes]



   East/west                                                East/west
   may turn left      time-out[cars in E/W left lanes]      may go straight

                                                                        56
       Transition with Actions

        right button down
        /display pop-up menu
Idle                           Menu visible
        right button up
        /erase pop-up menu
                                 cursor moved
                                 /highlight menu item


        Action for pop-up menu

                                                 57
    Unstructured State Transition
             Diagrams


    State1      event(attributes)[condition]/action      State2
do: Activity1                                         do: Activity2



 action: sending output events changing attribute values.
          It does not have duration.
 activity: operation done in a state.
          It may have duration

                                                                  58
            Generalized State

                                  push R
Transmission
                      Neutral                      Reverse
                                   push N
           push N               push F
 Forward
  stop               upshift             upshift
            First               Second                  Third
                    downshift            downshift




                                                                59
            Generalized State

                                  push R
Transmission
                      Neutral                      Reverse
                                   push N
           push N               push F
 Forward
  stop               upshift             upshift
            First               Second                  Third
                    downshift            downshift




                                                                60
Aggregation and Concurrent State Diagram
                Car

                      Ignition       Transmission       Brake   Accelerator

 Transmission                          push R                    Accelerator
                        Neutral                  Reverse
                                        push N                            On
               push N             push F
   Forward                                                      depress         release
     stop             upshift              upshift
              First               Second               Third              Off
                      downshift            downshift


                                                                 Brake
 Ignition    turn key to start                                            Off
              if Transmission in Neutral
                                                                   …               …
      Off                   Starting                   On
                                       release key
                                                                          On
                                                                                   61
                          turn key off
                Sequence Diagram
Print(file)
              :Computer      :PrinterServer        :Printer   :Queue


                      Print(file)      [printer free]
                                       Print(file)
                                       [printer busy]
                                       Store(file)




 ・Shows possible sequence(s) of messages among objects
 ・Inter-object behavior
                                                                       62
    Collaboration Diagram

 Computer                                        Queue

       1:Print(file)
                                  [printer busy]
                                  1.2: Store(file)


PrinterServer                                    Printer
                       [printer Free]
                       1.1: Print(file)


                                                           63
                  Activity Diagram
• Shows relationship among actions
   – Intra-object actions
   – Inter-object actions
 CustomerWindow:
   PrintAllCustomers
                       Show MessageBoxe      Create postscript
                       “Printing” onScreen         file



                           Remove            Send postscript
                          MessageBox          file to printer


                                                                 64
             Component Diagram
• Software components(source, binary and executable)
  and their relationship
         Window
         Handler
         (whnd.cpp)
                          Window
                          Handler          Graphics
                          (whnd.obj)         lib
         Comm
                                           (graphics.dll)
         Handler
         (comhnd.cpp)
                         Comm
                         Handler            Client
                         (comhnd.obj)       Program
      Main
                                            (client.exe)
      Class
      (main.cpp)
                          Main
                          Class
                          (main.obj)
                                                      65
        Deployment Diagram
• Machines, programs and connections


       MachineA                  MachineB
          :Gateway                  :Fujitsu
                          NetC
         Graphics                   Client
           lib                      Program
         (graphics.dll)             (client.exe)




                                                   66
Topics in OO Methodologies

(1) Object Constraint Language OCL

(2) Formal Approach to OO Analysis


                                     67
        Constraints and OCL
• Constraints
  – Description of systems and services using their
    properties
  – Usually, constraints are described by the results
    of the services rather than the procedure to
    realize them.
             What rather than How.
    “Any letter posted until 6:00 pm has to be
       delivered in the next working day”
                                                    68
• Constraints in UML
   – Constraints on attribute values in class diagram
   – Definition of operations in classes by pre/post-
     conditions
• Benefit of constraints
   – Provide means to attach semantic information to UML
     class diagrams
   – Allow declarative definition of behavior
• OCL : standard constraint language in UML
   – Based on first order predicate logic
                                                           69
       “Royal Loyal” Company

• Mileage Handling company
• LoyaltyProgram
   – Bonus point
   – Air flight mileage
   – Deduction
• ProgramParner: a company offering its customer a
  membership in a loyalty program
• Customer owns CustomerCard

                                                 70
                                                                                        Customer
                                                                                        name:String
                              LoyaltyProgram                                     0..*
                     1..*                        0..*                                   title:String
                                                                                        isMale:Boolean
                              enroll(c:Customer) program
                                                                                        dateOfBirth:Date
         1..* partners                                                                  age:Integer
ProgramPartner                                                                           owner
numberOfCustomers:Integer                        0..*
                                                        Membership
                            {ordered} 1..*                                                cards 0..*
                                 ServiceLevel                                    CustomerCard
                                                 actual                          valid:Boolean
                                                 Level                           validFrom:Date
                                                               0..1
    delivered                                                               card goodThru:Date
    Services 0..*                                  LoyaltyAccount                color:enum{silver,gold}
   Service                                         points:Integer                printedName:String
   condition:Boolean                               earn(i:Integer)
                            0..*                                                                 card
   pointsEarned:Integer                            burn(i:Integer)
   pointsBurned:Integer     available              isEmpty():Boolean
   description:String       Services
                                                transactions   0..*
                                             Transaction
                                        0..* points:Integer                     0..*
                               transactions date:Date                           transactions
                                             program():LoyaltyProgram
                                                                                         Date
                                                                                         $now:Date
                                                                                         isBefore(t:Date):Boolean
                                                                                         isAfter(t:Date):Boolean
                                                Burning               Earning            =(t:Bate):Boolean
                                                                                                                    71
                                                                                        Customer
                                          Customer
                              LoyaltyProgram
                                                 0..*                            0..*
                                                                                        name:String
                     1..*                                                               title:String
                                          age>=18
                              enroll(c:Customer) program
                                                                                        isMale:Boolean
                                                                                        dateOfBirth:Date
         1..* partners                                                                  age:Integer
ProgramPartner                                                                           owner
numberOfCustomers:Integer                        0..*
                                                        Membership
                            {ordered} 1..*                                                cards 0..*
                                 ServiceLevel                                    CustomerCard
                                                 actual                          valid:Boolean
                    CustomerCard                 Level
                                               0..1
                                                                                 validFrom:Date
    delivered                                                               card goodThru:Date
    Services 0..*   validFrom.isBefore(goodThru)
                                    LoyaltyAccount                               color:enum{silver,gold}
   Service                                         points:Integer                printedName:String
   condition:Boolean                               earn(i:Integer)
                            0..*                                                                 card
   pointsEarned:Integer                            burn(i:Integer)
   pointsBurned:Integer     available              isEmpty():Boolean
   description:String       Services
                                                transactions   0..*
                                             Transaction
                                        0..* points:Integer                     0..*
                               transactions date:Date                           transactions
                                             program():LoyaltyProgram
                                                                                         Date
                                                                                         $now:Date
                                                                                         isBefore(t:Date):Boolean
                                                                                         isAfter(t:Date):Boolean
                                                Burning               Earning            =(t:Date):Boolean
                                                                                                                    72
                                                                                      Customer
                                                                                      name:String
                              LoyaltyProgram                                   0..*
                     1..*                        0..*                                 title:String
                                                                                      isMale:Boolean
                              enroll(c:Customer) program
                                                                                      dateOfBirth:Date
         1..* partners                                                                age:Integer
ProgramPartner                                                                         owner
numberOfCustomers:Integer                        0..*
                                                        Membership
                            {ordered} 1..*                                              cards 0..*
                                 ServiceLevel                                   CustomerCard
                                                 actual                         valid:Boolean
                                                 Level                          validFrom:Date
                                                              0..1
    delivered                                                              card goodThru:Date
    Services 0..*                                  LoyaltyAccount               color:enum{silver,gold}
   Service                                         points:Integer               printedName:String
   condition:Boolean                               earn(i:Integer)
                            0..*                                                               card
   pointsEarned:Integer                            burn(i:Integer)
   pointsBurned:Integer     available              isEmpty():Boolean
        printName in CustomerCard is the concatenation of
   description:String       Services
                                  transactions 0..*
        name and title of Cutomer which holds it.
                                  Transaction
        CustomerCard         0..* points:Integer           0..*
                                  date:Date
        printedName=customer.title.concat(customer.name)
                    transactions
                                  program():LoyaltyProgram
                                                           transactions

                                                                                       Date
                                                                                       $now:Date
                                                                                       isBefore(t:Date):Boolean
                                                                                       isAfter(t:Date):Boolean
                                                Burning              Earning           =(t:Bate):Boolean
                                                                                                                  73
                                                                                       Customer
                                                                                       name:String
                             LoyaltyProgram                                     0..*
                     1..*                       0..*                                   title:String
                                                                                       isMale:Boolean
                             enroll(c:Customer) program
                                                                                       dateOfBirth:Date
         1..* partners                                                                 age():Integer
ProgramPartner                                                                          owner
numberOfCustomers:Integer                       0..*
                                                       Membership
                                     Program partner wants to restrict total points
                                                                      cards 0..*
                            {ordered} 1..*
                                      is less than 10000 points. CustomerCard
                                ServiceLevel
                                                actual                valid:Boolean
                                                Level                 validFrom:Date
    delivered
                                       LoyaltyProgram    0..1
                                                                 card goodThru:Date
    Services 0..*                      partners.deliveredServices.transaction
                                              LoyaltyAccount          color:enum{silver,gold}
                                              points:Integer          printedName:String
   Service                                       ->select(oclType=Burning)
                                              earn(i:Integer)
   condition:Boolean                                                                card
   pointsEarned:Integer
                            0..*                      ->collect(points)->sum<10000
                                              burn(i:Integer)
   pointsBurned:Integer     availble          isEmpty():Boolean
   description:String       Services
                                               transactions   0..*
                                             Transaction
                                        0..* points:Integer                    0..*
                               transactions date:Date                          transactions
                                             program():LoyaltyProgram
                                                                                        Date
                                                                                        $now:Date
                                                                                        isBefore(t:Date):Boolean
                                                                                        isAfter(t:Date):Boolean
                                               Burning               Earning            =(t:Bate):Boolean
                                                                                                                   74
• Defining operations by Pre-, Postcondition
  – precondition:specifies condition when the
    operation could be triggered.
  – postcondition: specifies condition which holds
    after the operation.

      precondition    P    postcondition


                                                     75
                                                                                      Customer
                                                                                      name:String
                             LoyaltyProgram                                    0..*
                     1..*                       0..*                                  title:String
                                                                                      isMale:Boolean
                             enroll(c:Customer) program
                                                                                      dateOfBirth:Date
         1..* partners                                                                age():Integer
ProgramPartner
numberOfCustomers:Integer
                                   LoyaltyAccount::isEmpty() owner
                                             0..*
                                                  Membership
                                   pre : -- none                   cards 0..*
                            {ordered} 1..*
                                   post : result = (points=0) CustomerCard
                                ServiceLevel
                                               actual                          valid:Boolean
                                               Level                           validFrom:Date
                                                             0..1
    delivered                                                             card goodThru:Date
    Services 0..*                                LoyaltyAccount                color:enum{silver,gold}
   Service                                       points:Integer                printedName:String
   condition:Boolean                             earn(i:Integer)
                            0..*                                                               card
   pointsEarned:Integer                          burn(i:Integer)
   pointsBurned:Integer     availble             isEmpty():Boolean
   description:String       Services
                                              transactions   0..*
                                             Transaction
                                        0..* points:Integer                   0..*
                               transactions date:Date                         transactions
                                             program():LoyaltyProgram
                                                                                       Date
                                                                                       $now:Date
                                                                                       isBefore(t:Date):Boolean
                                                                                       isAfter(t:Date):Boolean
                                              Burning               Earning            =(t:Bate):Boolean
                                                                                                                  76
A Formal Approach to Object-
     Oriented Analysis




                               77
      Formal OO Methodology

• Problems of Current OO Methodologies
   – Formality is very low and effective computer support is
     difficult, especially in the analysis phase.
   – Quality of the analysis models is not good, which
     determines the overall quality of final products.
• So-called formal methods do not consider
  practices of OO methodologies seriously.
   – Object-orientation of formal methods
• Formalization of practical OO methodologies is
  needed.
                                                           78
           Current OO Methodology
                             Informal description, probably inconsistent
Usually, requirements are
                             and inconsistent
  inconsistent,
                               (diagrams +natural language)
  incomplete,
  imprecise, …                     Object model

       Req..        Analysis      Dynamic model        Design        Coding


                                       ・          Model unification in design
                                       ・
                                       ・          /coding phase in human brain

                            Long and costly feedback
                                                                           79
         Formal OO Methodology
• Aiming at Formalized OO Methodology
  – Formal analysis models
     • From multiple view points
  – Consistency among analysis models, construction of a
    unified model
  – Machine assistance in Validation and Verification of
    analysis models
     • Prototype execution and verification by theorem
       proving techniques
  – Transformation from the unified models to software
    architecture
  – Software architecture + implementation model => source
    codes
                                                       80
            Formal OO Methodology
                         (what we have done)
                          Formal analysis models in ML

              Modeling support   Object model
                                                   Unification mapping

  Req.           Analysis        Dynamic model       Unification   Unified model




      Verification/      Determination
      prototype          of software             Software
                                                                    Software
      execution                                  generation
                         architecture
(1)ML-based execution
environment
                                                Implementation
(2) Consistency Verification                    condition
using theorem proving system HOL
                                                                               81
 Consistency between Object Model
        and Dynamic Model
• Verify that constraints among attributes in object
  models are maintained for any behavior of objects.

     Attr. a1,a2,…                   Attr. b1,b2,…

      Opr. f1,f2,…                   Opr. g1,g2,…

         e1/act,e2     e1      e1‟      e1‟/act,e2‟




                constraint: a1+a2 = b1+b2             82
       Counter
       number        Class Counter


     Dynamic model for Counter              (statechart after unification)

                                        Counter.number:=0
                                       s1
e / Counter.number:=Counter.number-1
 -
                                            e+/ Counter.number:=Counter.number+1
e+/ Counter.number:=Counter.number+1


                                       s2
     Counter
     number           constraint:”Counter.number≧0”




                                        Counter.number:=0
                                       s1
e / Counter.number:=Counter.number-1
 -
                                            e+/ Counter.number:=Counter.number+1
e+/ Counter.number:=Counter.number+1


                                       s2
     Counter
                      Prove ”Counter.number≧0”
     number




                                        Counter.number:=0
                                       s1     Counter.number≧0

e / Counter.number:=Counter.number-1
 -
                                            e+/ Counter.number:=Counter.number+1
e+/ Counter.number:=Counter.number+1


                                       s2     Counter.number≧1
     Counter
                      Prove ”Counter.number≧0”
     number

                                        Counter.number:=0
                                       s1     Counter.number≧0

e / Counter.number:=Counter.number-1
 -
                                            e+/ Counter.number:=Counter.number+1
e+/ Counter.number:=Counter.number+1


                                       s2     Counter.number≧1

       (1) Counter.number≧0 at S1 ⇒ Counter.number≧1 at S2
             i.e. Counter.number≧0 ⇒ (Counter.number+1)≧1
       (2) Counter.number≧1 at S2 ⇒ Counter.number≧0 at S1
             i.e. Counter.number≧1 ⇒ (Counter.number±1≧0)
      Counter
                      Counter.number≧0 :Global Assertion
      number
                                                         Local Assertion


                                        Counter.number:=0
                                       s1     Counter.number≧0

e / Counter.number:=Counter.number-1
 -
                                            e+/ Counter.number:=Counter.number+1
e+/ Counter.number:=Counter.number+1


                                       s2     Counter.number≧1


     (3) Counter.number≧0∧Counter.number⇒Counter.number≧0
                   Axioms
• Six Axioms:
  –   Local invariant axiom
  –   Global invariant axiom
  –   Event output axiom
  –   Event communication axiom
  –   Inheritance axiom
  –   Aggregation axiom

                                  88
                Inheritance Axiom
Let a class c be a super class of c1,…, cn, and o and oi be
instantiated from c and ci.

    GA1…GAn
      1in   si.GAi([oi][si])  V1in s.GAi([o][s])

                                  C           GA1VGA2




               GA1      C1                 C2           GA2

                                                              89
     F-Developer Environment
• F-Developer
  – Model Editor for constructing analysis models
    graphically
  – F-Verifier: for verifying constructed models using
    HOL
     • HOL: Higher order predicate logic prover developed at
       Cambridge Univ.
     • Proof-checker rather than automatic prover
  – F-Prototyper: for prototype execution of the models


                                                               90
                                        Constructed models

                                           Repository


Model Editor
                            Generation of ML Generation of axioms
                            code for prototyping


Generated ML codes                          Generated axioms




               Prototyper                               Verifier
                         Generation of Axioms
     • Axioms are introduced into HOL as its theory
       modules, which are type/term constants, axioms
       or definitions.
Type constants:                                    send (Prefix):
Counter 0                                          'a ObjectID # EventID # 'a StateID -> bool
EventID 0                                          recieve (Prefix):
StateID 1                                          'a ObjectID # EventID # 'a StateID -> bool
ObjectID 1                                         obj (Prefix): Counter ObjectID
Term constants:                                    ...
s1 (Prefix) :Counter StateID                       Axioms:
s2 (Prefix) :Counter StateID                       AX-LI_Counter|- !o LA_s1 LA_s2.
Counter_number (Prefix):                              valid_Counter (o,LA_s1,LA_s2) ==>
  Counter ObjectID -> Counter StateID -> num          LA_s1(Counter_number o s1)/\LA_s2 (Counter_number o s2)
inc(Prefix) :num -> num                            AX-GI_Counter|- ....
Counter_LA_s1 (Prefix) :num -> bool                ....
Counter_LA_s2 (Prefix) :num -> bool                Definitions:
Counter_GA (Prefix) :num -> bool                   Counter_inc_DEF|- !n.inc n = n+1
valid_Counter (Prefix):                            Counter_LA_s1_DEF|- !x. Counter_LA_s1 x = 0<=x
e_plus (Prefix) :EventID                           Counter_LA_s2_DEF|- !x. Counter_LA_s2 x = 1<=x
e_minus (Prefix) :EventID                          Counter_GA_DEF |- !x. Counter_GA x = 0<=x
link (Prefix): 'a ObjectID # 'b ObjectID -> bool   ...                                              92
                                  Proof in HOL
- ADD_MONO_LESS_EQ;                                 - val r1 =
val it = |- !m n p. m + n <= m + p = n <= p : thm   SYM (SPEC (--`Counter_number obj s1`--)
- ADD_0;                                                   Counter_LA_s1_DEF);
val it = |- !m. m + 0 = m : thm                     val r1 =
- SPEC (--`Counter_number obj s1`--)                |- 0 <= Counter_number obj s1 =
      (SPEC (--`0`--)                               Counter_LA_s1 (Counter_number obj s1): thm
          (SPEC (--`1`--)                           - val r2 =
ADD_MONO_LESS_EQ));                                 SYM (SPEC (--`1 + Counter_number obj s1`--)
val it = |- 1 + 0 <= 1 + Counter_number obj s1 =           Counter_LA_s2_DEF);
       0 <= Counter_number obj s1: thm              val r2 =
- val lemma1 = snd (EQ_IMP_RULE it);                |- 1 <= 1 + Counter_number obj s1 =
val lemma1 =                                        Counter_LA_s2 (1 + Counter_number obj s1): thm
  |- 0 <= Counter_number obj s1 ==>                 - val step1 = REWRITE_RULE [r1, r2] lemma2;
     1 + 0 <= 1 + Counter_number obj s1 : thm       val step1 =
-SPEC (--`1`--) ADD_0;                              |- Counter_LA_s1 (Counter_number obj s1) ==>
val it = |- 1 + 0 = 1 : thm                            Counter_LA_s2 (1 + Counter_number obj s1) :
- val lemma2 = REWRITE_RULE [it] lemma1;            thm
val lemma2 = |- 0 <= Counter_number obj s1 ==>
            1 <= 1 + Counter_number obj s1
                                                                                          93
            Lessons Learned
• Found that formal verification is useful in
  developing correct analysis models
  – Even for the small example we tried, errors
    were found by the proving assertions.
  – In the analysis phase, errors could come in from
    incomplete and inconsistent requirement.
  – HOL style interactive proof making process
    could be considered as a process of gradually
    understanding / constructing analysis models.
                                                  94
               Lessons Learned
• Proof requires long steps, as we need to prove
   – Facts about primitive data such as integer, list, …
   – Also, inference rules are primitive.
• To make it acceptable to “software engineer”, we
  need
   – Abstract domain libraries
      • Theorems about „Banking System‟, „Hotel‟,…
   – Reuse of proof steps
   – Domain specific proof tactics
      • Proof tactics for „Banking System‟,…

                                                           95

				
kala22 kala22
About