Docstoc

Dynamic Model

Document Sample
Dynamic Model Powered By Docstoc
					     Dynamic Model

SSD (System Sequence Diagram)




                                1
Products of requirements elicitation and
               analysis
     Requirements   Requirements
     elicitation    Specification

                    nonfunctional
                    requirements

                      functional
                        model


      Analysis      Analysis Model


                    dynamic model

                    analysis object
                         model


    System design


    Object design

                                           2
  The analysis model is composed of the
functional model, the object model, and the
             dynamic model

  use case         class        statechart      sequence
diagram:View    diagram:View   diagram:View   diagram:View




 functional       object                 dynamic
 model:Model    model:Model            model:Model




                 analysis
                model:Model


                                                        3
       Activities during Object Modeling
• Main goal: Find the important abstractions
• What happens if we find the wrong abstractions?
  – Iterate and correct the model
• Steps during object modeling
  – 1. Class identification
     • Based on the fundamental assumption that we can find
       abstractions
  – 2. Find the attributes
  – 3. Find the methods
  – 4. Find the associations between classes
• Order of steps
  – Goal: get the desired abstractions
  – Order of steps secondary, only a heuristic
  – Iteration is important
                                                              4
                Class Identification

• Identify the boundaries of the system
• Identify the important entities in the system
• Class identification is crucial to object-oriented
  modeling
• Basic assumption:
   – 1. We can find the classes for a new software
     system (Forward Engineering)
   – 2. We can identify the classes in an existing system
     (Reverse Engineering)
• Why can we do this?
   – Philosophy, science, experimental evidence
                                                            5
               Pieces of an Object Model
• Classes
• Associations (Relations)
   – Generic associations
   – Canonical associations
        • Part of- Hierarchy (Aggregation)
        • Kind of-Hierarchy (Generalization)
• Attributes
   –   Detection of attributes
   –   Application specific
   –   Attributes in one system can be classes in another system
   –   Turning attributes to classes
• Operations
   – Detection of operations
   – Generic operations: Get/Set, General world knowledge, design
     patterns
   – Domain operations: Dynamic model, Functional model

                                                                    6
                    Class identification

• Finding objects is the central piece in object modeling
• Approaches
   – Application domain approach (not a special lecture, examples):
      • Ask application domain expert to identify relevant abstractions
   – Syntactic approach (today):
      • Start with use cases. Extract participating objects from flow of
        events
      • Use noun-verb analysis (Abbot‟s technique) to identify components
        of the object model
   – Design patterns approach ( design patterns)
      • Use reusable design patterns
   – Component-based approach (on object design):
      • Identify existing solution classes


                                                                            7
               How do you find classes?
• Finding objects is the central piece in object modeling
   – Learn about problem domain: Observe your client
   – Apply general world knowledge and intuition
   – Take the flow of events and find participating objects in use cases
   – Try to establish a taxonomy
   – Do a syntactic analysis of problem statement, scenario or flow of
     events
   – Abbott Textual Analysis, 1983, also called noun-verb analysis
       • Nouns are good candidates for classes
       • Verbs are good candidates for opeations
   – Apply design knowledge:
       • Distinguish different types of objects
       • Apply design patterns (Lecture on design patterns)


                                                                       8
             How do you find classes?
• Finding objects is the central piece in object
  modeling
   – Learn about problem domain: Observe your client
   – Apply general world knowledge and intuition
   – Take the flow of events and find participating objects in
     use cases
   – Try to establish a taxonomy
   – Apply design knowledge:
      • Distinguish different types of objects
      • Apply design patterns (Lecture on design patterns)
   – Do a syntactic analysis of problem statement, scenario
     or flow of events
   – Abbott Textual Analysis, 1983, also called noun-verb
     analysis
      • Nouns are good candidates for classes
      • Verbs are good candidates for opeations              9
 Finding Participating Objects in Use Cases
• Pick a use case and look at its flow of events
  – Find terms that developers or users need to clarify in
    order to understand the flow of events
  – Look for recurring nouns (e.g., Incident),
  – Identify real world entities that the system needs to
    keep track of (e.g., FieldOfficer, Dispatcher,
    Resource),
  – Identify real world procedures that the system needs
    to keep track of (e.g., EmergencyOperationsPlan),
  – Identify data sources or sinks (e.g., Printer)
  – Identify interface artifacts (e.g., PoliceStation)
• Be prepared that some objects are still missing
  and need to be found:
     • Model the flow of events with a sequence diagram
• Always use the user‟s terms
                                                             10
          Generation of a class diagram from flow of events
                        Flow of events:
Customer
                              customer     enters
                     • The customer enters the storestore to buy
                        a toy. It has to be a toy that his
                             buy
        ?
      store             toy                daughter
                        daughter likes and it must cost less
     enter()                                 less a videogame,
                        than 50 Euro. He tries than 50 Euro
                                        videogame
                        which uses a data glove and a head-
  daughter              mounted display. He likes it.
    age

      suitable               An assistant helps him. The suitability
        *toy                 of the game depends on the age of the
                                                          depends
         toy
       price                          age
                             child. His daughter is only 3 years
       buy()
       buy()
       like()
                             old. The assistant recommends another
                             type of toy, namely a boardgame. The
videogame        boardgame   type of buy               boardgame
                             customer toy the game and leaves the
                             store                              11
  Steps to Generate Class Diagrams

1. Class identification (textual analysis, domain
   experts).
2. Identification of attributes and operations
   (sometimes before the classes are found!)
3. Identification of associations between
   classes
4. Identification of multiplicities
5. Identification of roles
6. Identification of constraints
                                                12
                        Object Types

• Entity Objects
   – Represent the persistent information tracked by the system
     (Application domain objects, “Business objects”)
• Boundary Objects
   – Represent the interaction between the user and the system
• Control Objects:
   – Represent the control tasks performed by the system
• Having three types of objects leads to models that are
  more resilient to change.
   – The interface of a system changes more likely than the control
   – The control of the system change more likely than the application
     domain
• Object types originated in Smalltalk:
   – Model, View, Controller (MVC)

                                                                     13
                                    MVC
• Model
   – The model represents enterprise data and the business rules that
     govern access to and updates of this data. Often the model serves as a
     software approximation to a real-world process, so simple real-world
     modeling techniques apply when defining the model.
• View
   – The view renders the contents of a model. It accesses enterprise data
     through the model and specifies how that data should be presented. It is
     the view's responsibility to maintain consistency in its presentation when
     the model changes. This can be achieved by using a push model,
     where the view registers itself with the model for change notifications, or
     a pull model, where the view is responsible for calling the model when it
     needs to retrieve the most current data.
• Controller
   – The controller translates interactions with the view into actions to be
     performed by the model. In a stand-alone GUI client, user interactions
     could be button clicks or menu selections, whereas in a Web
     application, they appear as GET and POST HTTP requests. The actions
     performed by the model include activating business processes or
     changing the state of the model. Based on the user interactions and the
     outcome of the model actions, the controller responds by selecting an
     appropriate view.
                                                                              14
15
          Example: 2BWatch Objects



      Year                           Button
                  ChangeDate

     Month
                                   LCDDisplay


       Day




Entity Objects   Control Objects   Interface Objects


                                                       16
      Naming of Object Types in UML

• UML provides several mechanisms to extend the
  language
• UML provides the stereotype mechanism to present new
  modeling elements

      <<Entity>>                       <<Boundary>>
         Year         <<Control>>         Button
                      ChangeDate
      <<Entitity>>
        Month                          <<Boundary>>
                                        LCDDisplay
      <<Entity>>
         Day


   Entity Objects    Control Objects   Boundary Objects

                                                          17
    Recommended Naming Convention for
             Object Types
• To distinguish the different object tpyes on a syntactical basis,
  recommend suffixes:
• Objects ending with the “_Boundary” suffix are boundary objects
• Objects ending with the “_Control” suffix are control objects
• Entity objects do not have any suffix appended to their name.

          Year                                 Button_Boundary
                            ChangeDate_
                              Control
         Month

                                              LCDDisplay_Boundary
           Day



                                                                      18
           Dynamic Modeling with UML
• Diagrams for dynamic modeling
   – Interaction diagrams describe the dynamic behavior between
     objects
   – Statecharts describe the dynamic behavior of a single object
• Interaction diagrams
   – Sequence Diagram:
       • Dynamic behavior of a set of objects arranged in time sequence.
       • Good for real-time specifications and complex scenarios
   – Collaboration Diagram :
       • Shows the relationship among objects. Does not show time
• State Chart Diagram:
   – A state machine that describes the response of an object of a
     given class to the receipt of outside stimuli (Events).
   – Activity Diagram: A special type of statechart diagram, where all
     states are action states (Moore Automaton)


                                                                           19
                Dynamic Modeling

• Definition of dynamic model:
  – A collection of multiple state chart diagrams, one
    state chart diagram for each class with important
    dynamic behavior.
• Purpose:
  – Detect and supply methods for the object model
• How do we do this?
  – Start with use case or scenario
  – Model interaction between objects => sequence
    diagram
  – Model dynamic behavior of a single object =>
    statechart diagram                                   20
  Start with Flow of Events from Use Case

• Flow of events from “Dial a Number” Use
  case:
  – Caller lifts receiver
  – Dial tone begins
  – Caller dials
  – Phone rings
  – Callee answers phone
  – Ringing stops
  – ....
                                            21
                     What is an Event?
• Something that happens at a point in time
• Relation of events to each other:
   – Causally related: Before, after,
   – Causally unrelated: concurrent
• An event sends information from one object to another
• Events can be grouped in event classes with a
  hierarchical structure. „Event‟ is often used in two ways:
   – Instance of an event class: “New AA issued on Thursday
     September 14 at 9:30 AM”.
       • Event class “New AA”, Subclass “Figure Change”
   – Attribute of an event class
       • ATM Update (9:30 AM, 9/14/2006)
       • Car starts at ( 4:45pm, University Center, Parking Lot 23B)
       • Mouse button down(button#, tablet-location)



                                                                       22
                   Sequence Diagram
• From the flow of events in the use case or scenario
  proceed to the sequence diagram
• A sequence diagram is a graphical description of objects
  participating in a use case or scenario using a DAG
  (direct acyclic graph) notation
• Relation to object identification:
   – Objects/classes have already been identified during object
     modeling
   – Objects are identified as a result of dynamic modeling
• Heuristic:
   – A event always has a sender and a receiver.
   – The representation of the event is sometimes called a message
   – Find them for each event => These are the objects participating
     in the use case
                                                                       23
System Sequence Diagram (SSD)
       Notation (Figure 7-14)




                                24
                 SSD Notation
• Actor represented by a stick figure – a person (or
  role) that interacts with system by entering input
  data and receiving output data
• Object is a rectangle with name of object
  underlined – shows individual object and not
  class of all similar objects ( :System for SSD )
• Lifeline or object lifeline is a vertical line under
  object or actor to show passage of time for object
• Message is labeled on arrows to show messages
  sent to or received by actor or system

                                                    25
                SSD Lifelines

• Vertical line under object or actor
  – Shows passage of time
• If vertical line dashed
  – Creation and destruction of thing is not
    important for scenario
• Long narrow rectangles
  – Activation lifelines emphasize that object is
    active only during part of scenario


                                                    26
  Example: Use Case Model for Incident
             Management



                                 Dispatcher
FieldOfficer                                        OpenIncident




               ReportEmergency




                                              AllocateResources




                                                              27
        Sequence diagram for the ReportEmergency
                       use case
                    Report                                                                       Manage
               EmergencyButton                                                              EmergencyControl
FieldOfficer

       press()        «create»
                                 ReportEmergency
                                     Control

                                         «create»        ReportEmergency
                                                              Form

                                                   fillContents()

                                                       submit()
                                           submitReport()
                                                                    «create»
                                                                                Emergency
                                                                                  Report

                                                                        submitReportToDispatcher()
                                           «destroy»




                                                                                                      28
            Sequence diagram for the
      ReportEmergency use case (continued)

                       Manage
                  EmergencyControl                                                   Dispatcher
submitReportToDispatcher() «create»
                                       IncidentForm


                                               createIncident()

                                             «create»
                                                          Incident

                                              submit()

                                                         «create»
                                                                    Acknowledgment
                           «destroy»




                                                                                           29
      Sequence diagram for the
ReportEmergency use case (continued)


                    Manage            ReportEmergency
FieldOfficer   EmergencyControl           Control



                        acknowledgeReport()
                                               «create»       Acknowledgment
                                                                  Notice
       dismiss()

                                              endReportTransaction()
                                               «destroy»
                        «destroy»




                                                                               30
                     An Example

• Flow of events in a “Get SeatPosition” use case :

   1. Establish connection between smart card and
     onboard computer

   2. Establish connection between onboard computer and
     sensor for seat

   3. Get current seat position and store on smart card

• Which are the objects?

                                                          31
       Sequence Diagram for “Get SeatPosition”
                      Smart Card         Onboard Computer              Seat
       1. Establish
       connection
       between              Establish Connection
       smart card                                  Establish Connection
       and onboard
       computer

       2. Establish
       connection
       between                                     Accept Connection
       onboard
       computer
       and sensor             Accept Connection
       for seat

       3. Get
       current seat            Get SeatPosition
       position and
       store on               “500,575,300”
       smart card
                                                                          32
time
       Heuristics for Sequence Diagrams
• Layout:
   – 1st column: Should correspond to the actor who initiated the use
     case
   – 2nd column: Should be a boundary object
   – 3rd column: Should be the control object that manages the rest
     of the use case
• Creation:
   – Control objects are created at the initiation of a use case
   – Boundary objects are created by control objects
• Access:
   – Entity objects are accessed by control and boundary objects,
   – Entity objects should never call boundary or control objects: This
     makes it easier to share entity objects across use cases and
     makes entity objects resilient against technology-induced
     changes in boundary objects.
                                                                      33
          Is this a good Sequence Diagram?
                    Smart Card         Onboard Computer              Seat
•First column is
not the actor             Establish Connection
                                                 Establish Connection
•It is not clear
where the
boundary object
is
                                                 Accept Connection
•It is not clear
where the
control object is           Accept Connection


                             Get SeatPosition
                            “500,575,300”
                                                                        34
 Transfer Funds UI

From Account


To Account

Amount Transfer



        Cancle    Ok




                       35
                    Transfer Funds Use Case
1.  The system displays the prompt for the selection of the FromAccount from the
    list of available accounts; a Cancel button is visible (screen SC-Transfer-1)
2. The BankCustomer selects a FromAccount
3. The system locates and displays the selected FromAccount Account object and
    prompts for the selection of the ToAccount from the list of available accounts
    (the selected FromAccount is not included); a Cancel button is visible
4. The BankCustomer selects a ToAccount
5. The system locates the selected ToAccount Account object; the system displays
    the selected FromAccount and ToAccount and prompts for the Amount of the
    transfer; a Cancel button is visible
6. The system displays a prompt for the confirmation of the transfer; the selected
    FromAccount and ToAccount and the transfer Amount are displayed; OK and
    Cancel buttons are visible;
7. The BankCustomer presses the OK button;
8. The system checks if the FromAccount.balance is greater or equal to the
    transfer Amount
9. The system updates the balances in the FromAccount and ToAccount and
    creates a Transaction object detailing the transfer of funds, including the
    FromAccount, ToAccount, transfer Amount, as well as the Date and Time of
    the transfer;
10. The system displays the transfer confirmation, including the FromAccount,
    ToAccount, transfer Amount, as well as the Date and Time of the transfer and
    the Transaction.id; the account balances reflect the transfer

                                                                                     36
Transfer Funds




                 37
   What else can we get out of sequence
                diagrams?
• Sequence diagrams are derived from the
  use cases. We therefore see the structure
  of the use cases.
• The structure of the sequence diagram
  helps us to determine how decentralized
  the system is.
• We distinguish two structures for sequence
  diagrams: Fork and Stair Diagrams (Ivar
  Jacobsen)
                                           38
                         Fork Diagram
• Much of the dynamic behavior is placed in a single object, ususally
  the control object. It knows all the other objects and often uses them
  for direct questions and commands.




                                                                       39
                         Stair Diagram
• The dynamic behavior is distributed. Each object delegates some
  responsibility to other objects. Each object knows only a few of the
  other objects and knows which objects can hel with a specific
  behavior.




                                                                         40
                        Fork or Stair?

• Which of these diagram types should be chosen?
• Object-oriented fans claim that the stair structure is
  better
   – The more the responsibility is spread out, the better
• However, this is not always true. Better heuristics:
• Decentralized control structure
   – The operations have a strong connection
   – The operations will always be performed in the same order
• Centralized control structure (better support of change)
   – The operations can change order
   – New operations can be inserted as a result of new requirements


                                                                      41
          Summary: Requirements Analysis
 1. What are the transformations?                       Functional Modeling
     – Create scenarios and use case diagrams
         • Talk to client, observe, get historical records, do thought
           experiments
2. What is the structure of the system?                   Object Modeling
    Create class diagrams
         Identify objects.
         What are the associations between them? What is their multiplicity?
         What are the attributes of the objects?
         What operations are defined on the objects?

3. What is its behavior?                                Dynamic Modeling
    Create sequence diagrams
         Identify senders and receivers
         Show sequence of events exchanged between objects. Identify event
         dependencies and event concurrency.
    Create state diagrams
         Only for the dynamically interesting objects.
                                                                               42
                   Let‟s Do Analysis

1. Analyze the problem statement
   – Identify functional requirements
   – Identify nonfunctional requirements
   – Identify constraints (pseudo requirements)
2. Build the functional model:
   – Develop use cases to illustrate functionality requirements
3. Build the dynamic model:
   – Develop sequence diagrams to illustrate the interaction
     between objects
   – Develop state diagrams for objects with interesting behavior
4. Build the object model:
   – Develop class diagrams showing the structure of the system

                                                                  43
               Problem Statement:
          Direction Control for a Toy Car

• Power is turned on                • Power is turned off
                                       – Car stops and headlight goes
   – Car moves forward and car
                                         out.
     headlight shines
                                    • Power is turned on
• Power is turned off
                                       – Headlight shines
   – Car stops and headlight goes
                                    • Power is turned off
     out.
                                       – Headlight goes out.
• Power is turned on                • Power is turned on
   – Headlight shines
                                       – Car runs forward with its
• Power is turned off                    headlight shining.
   – Headlight goes out.
• Power is turned on
   – Car runs backward with its
     headlight shining.

                                                                     44
  Find the Functional Model: Do Use Case
                  Modeling
• Use case 1: System Initialization
   – Entry condition: Power is off, car is not moving
   – Flow of events:
       • Driver turns power on
   – Exit condition: Car moves forward, headlight is on
• Use case 2: Turn headlight off
   – Entry condition: Car moves forward with headlights on
   – Flow of events:
       • Driver turns power off, car stops and headlight goes out.
       • Driver turns power on, headlight shines and car does not move.
       • Driver turns power off, headlight goes out
   – Exit condition: Car does not move, headlight is out



                                                                          45
                    Use Cases continued
•   Use case 3: Move car backward
     – Entry condition: Car is stationary, headlights off
     – Flow of events:
         • Driver turns power on
     – Exit condition: Car moves backward, headlight on
•   Use case 4: Stop backward moving car
     – Entry condition: Car moves backward, headlights on
     – Flow of events:
         • Driver turns power off, car stops, headlight goes out.
         • Power is turned on, headlight shines and car does not move.
         • Power is turned off, headlight goes out.
     – Exit condition: Car does not move, headlight is out.
•   Use case 5: Move car forward
     – Entry condition: Car does not move, headlight is out
     – Flow of events
         • Driver turns power on
     – Exit condition:
         • Car runs forward with its headlight shining.

                                                                         46
                      Use Case Pruning

• Do we need use case 5?

• Use case 1: System Initialization
   – Entry condition: Power is off, car is not moving
   – Flow of events:
       • Driver turns power on
   – Exit condition: Car moves forward, headlight is on

• Use case 5: Move car forward
   – Entry condition: Car does not move, headlight is out
   – Flow of events
       • Driver turns power on
   – Exit condition:
       • Car runs forward with its headlight shining.


                                                            47
  Find the Dynamic Model: Create sequence
                  diagram
• Name: Drive Car
• Sequence of events:
   –   Billy turns power on
   –   Headlight goes on
   –   Wheels starts moving forward
   –   Wheels keeps moving forward
   –   Billy turns power off
   –   Headlight goes off
   –   Wheels stops moving
   –   ...




                                        48
Sequence Diagram for Drive Car Scenario

  :Headlight                Billy:Driver                :Wheel


               Power(on)                   Power(on)


               Power(off)                  Power(off)



               Power(on)                   Power(on)




                                                                 49
                 Toy Car: Dynamic Model
                                    Wheel
  Headlight
                                    Forward
        Off                                     power
                          power                  off
                           on
power         power
 off           on


                      Stationary                Stationary
        On


                                               power
                            power               on
                             off

                                    Backward


                                                             50
              Toy Car: Object Model

                           Car




     Power             Headlight              Wheel

Status: (On, Off)   Status: (On, Off)               w
                                        Motion: (For ard,
                                                 Backward,
TurnOn()            Switch_On()                  Stationary)
TurnOff()           Switch_Off()
                                        Start_Moving()
                                        Stop_Moving()




                                                               51
Analysis: UML Activity Diagram
                             D e f i n e
                           u s e c a s e s




                             D e f i n e
                         p a r t i c i p a t i n g
                            o b j e c t s




     D e f i n e            D e f i n e              D e f i n e
     e n t i t y           b o u n d a r y           c o n t r o l
    o b j e c t s          o b j e c t s             o b j e c t s




                            D e f i n e
                         i n t e r a c t i o n s




     D e f i n e
                            D e f i n e             D e f i n e
   n o n t r i v i a l    a t t r i b u t e s    a s s o c i a t i o n s
    b e h a v i o r




                         C o n s o l i d a t e
                            m o d e l




                            R e v i e w
                            m o d e l                                      52

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:9
posted:8/6/2011
language:English
pages:52