Docstoc

Introduction to Computer Science - PowerPoint

Document Sample
Introduction to Computer Science - PowerPoint Powered By Docstoc
					    Detailed Object-Oriented Requirements Definitions
The Object-Oriented approach has a set of Diagrams that together
document the user’s needs and define the System Requirements.
 It may seem complex at first to have so many different types of Diagrams, but as
    you use them , you will learn to appreciate how they all fit together to produce a
    complete Specification.
 Each Diagram describes a different aspect of the System, so you only focus on one
  aspect at a time.

 Analysts use a collection of Models (Diagrams) based on Use Cases with the
  Object- Oriented approach.
 Four Models are used to describe the System Use Cases from various points of
 view. This Approach is referred to as “Use Case Driven”
           ◘ Use Case Diagrams
           ◘ Use Case Descriptions
           ◘ Activity Diagrams
           ◘ System Sequence Diagrams (SSD)

  Object-Oriented Analysis and Design with the Unified Process                           2
  Detailed Object-Oriented Requirements Definitions
    Each of the Four models are takes each Use Case , one by one,
    and extend the Requirements in more detail.
           Statechart, however is not Use Case Driven but Object Driven.


    The Use Case Diagram shows the Various User roles and the
     way those Users interact with the System.
      - The Use Case Diagram can be derived directly from the Event Table;
            Thus a Use Case Diagram is a convenient way to to document the
            System Events.
     Sometimes a single comprehensive Diagram is used to identify all Use cases
     for an entire System. Sometimes a set of narrower Use Case Diagrams is
      used.
     Each Use Case in the Diagram must be described in detail either by a
     narrative description of the steps that the User and the System do together
       to complete the Use Case. Activity Diagrams can also be used to describe
       any business processes done by people in an organization.
Object-Oriented Analysis and Design with the Unified Process                      3
  Detailed Object-Oriented Requirements Definitions
    Activity Diagram is a type of workflow Diagram that describes
                     the Users activities and their sequential flows.
                                  Can also be used to describe processes that
                                  include both Manual and Automated System
                                  Activities.
    System Sequence Diagram: Is a Diagram showing the Sequence
         (SSD)               of Messages between an Actor and
                             the System during a Use Case
                             Scenario.
                                                    SSDs are used to describe the Input and
                                                    Output s and the sequential order of them.

                                                    SSDs used in conjunction with Detailed Use
                                                    Case Descriptions and/or with Activity
                                                    Diagrams to show processing steps and
                                                    interactions between the Actor and the
                                                    System.
Object-Oriented Analysis and Design with the Unified Process                                 4
  Detailed Object-Oriented Requirements Definitions
    Class Diagrams: Are used to identify the real-world “Things”
                    that determine the structure of the
                    Programming Classes.
                                 Constructing a Class Diagram help Analyst identify
                                 information about the real-world objects that will be part of
                                 the new System.
    Statechart Diagram; Is a Diagram showing the Life of an Object
                        in a set of “States” and “Transitions”.
                                  Since the Real-world objects are mirrored inside the
                                  Computer System, often the Status Conditions of the
                                  real Objects are an important piece of information
                                  that the Analyst can use to define the Business Rules
                                  to be implemented in the Computer System.
                                  Statecharts are also using during the Design to
                                  identify various States of the System itself and the
                                  allowable events that can be processed. Therefore
                                  Statecharts can be considered as an Analysis tool or
                                  as a Designer Tool.


Object-Oriented Analysis and Design with the Unified Process                                 5
                      Requirements Diagrams With UML Models


Object-Oriented Analysis and Design with the Unified Process   6
                A USE CASE / SCENARIO VIEW
   A Use Case can be defined at an Overview Level or at a Detailed
   Level.
    Event table provides an Overview of all Use Cases for a System.
    Detailed information abut each Use Case is described with a Use Case
     Description., an Activity Diagram, and a System Sequence Diagram, or a
     combination of these Models.


   USE CASES AND ACTOR
   The Actor is the person or things that actually touches or
   interacts with the System.
    An Actor is a role played by people or things. - An Actor is always outside
    Automation boundary of the System .
     Eg. A Customer might be a Actor if He/she places the Order directly
         through the Internet.

Object-Oriented Analysis and Design with the Unified Process                      7
                       THE USE CASE DIAGRAM
 Use Case Diagram Symbols
  Stick figure is given a name that characterizes the role
  the Actor is playing.
        An Actor can be Other Systems that interfaces with the System
         being developed. In that case the Actor illustrated either with an
         appropriately named stick figure or with a Rectangle.
             ◘ E.g. Purchasing Subsystem.
 Oval figure is given a name of the Use Case inside.
 The Connecting Lines between Actor and the Use
  Cases indicate which Actor uses (Utilizes) which Use
  Cases.
  Automation Boundary denotes the boundary between the
   environment , where the Actors resides. And the internal
   components of the Computer System..
Object-Oriented Analysis and Design with the Unified Process                  8
                      A Simple Use Case with an Actor
Object-Oriented Analysis and Design with the Unified Process   9
     A Use Case Diagram of the Order-Entry Subsystem for RMO,
                    Showing a System Boundary
Object-Oriented Analysis and Design with the Unified Process   10
                       THE USE CASE DIAGRAM
 There are two popular ways to Organize Use Case
 Diagrams to depict different point of view:

    Organize Use Cases by Subsystem
    Organize the Use Cases that involve a Specific Actor
       This approach is useful for showing all of the Business Events
        that are accessible through Internet.
   Analyst chooses to draw the Use Case Diagrams based on the needs of
   the Project Team.




Object-Oriented Analysis and Design with the Unified Process             11
 A Use Case Diagram of the Customer Support System (by Subsystem)
Object-Oriented Analysis and Design with the Unified Process    12
                      « Includes » Relationships
   «includes» or «uses» Relationship
   During the Development of a Use Case Diagram it is reasonable
    for more than one Use Case to use the services of a Common
     Subroutine.
       Examples: “Create new Order” and “Update Order” Use Cases may need to
        validate the Customer Account. In that case two Common subroutines may
        be defined to carry the function of Customer Account Validation, “Validate
        Customer Account” and “Look Up Item Availability” .

  The Common Subroutine itself becomes additional Use Case.
   These Relationship is called as <<includes>> or <<uses>>>
      Notation
       The Relationship between these Use cases is denoted by Connecting Line with
        arrow.
       The Direction of the Arrow indicates which Use Case is Included as apart of the
        Major Use Cases.
Object-Oriented Analysis and Design with the Unified Process                              13
   An Example of the Order-entry Subsystem With «Includes» Use Cases
Object-Oriented Analysis and Design with the Unified Process           14
              DEVELOPING A USE CASE DIAGRAM
     Business Modeling helps Analysts understand the Business processes. As a result
      of Business Modeling Business Events are identified and documented in the Event
      Table.

   Event Table is used to identify the Use Cases. However, the Analysts often need
   to make some adjustments when building a Use Case Diagram.
            - One major Adjustment is that frequently Business Events may be combined
              into single Use Case.
           e.g. Adding new Customer and changing Customer information may be done by two
                 different but from the System point of view can be combine into a single Use
                 “Maintain Customer Information”
       -   Analysts also make adjustment by splitting a single Event into multiple Use
            Cases. These additional Use Cases can be identified either <<includes>>
            relationships or when another Use Case is defined from recognizing a common
             subroutine

     Special attention should be paid to Temporal and State Events. Although these
      Events are not requested by any Actors they must be included in the System
       Requirements. Therefore, Analyst often connect these business Events to an
       “Administrator Actor” that might invoke them as a Special Procedure

Object-Oriented Analysis and Design with the Unified Process                                    15
                 DEVELOPING A USE CASE DIAGRAM
  The Process for moving from Business Events to defining Use
  Cases requires two steps done in iteration:
    1. Identify the Actor for each Use Case.
     (Remember other Systems may also be Actors of a System)

    2. Extract the information from the Business Events that
       describe the System responses to the Business Events.
        Remember to adjust the Use Cases so that Goals are System
        tasks such as “Process a Sale”, “Accept Goods Return” etc…

  Also remember that you must assume “Perfect Technology”.
  Be sure that Use Cases are based on Business Events not on
  Technical Activities such as :Logging on to the System”




Object-Oriented Analysis and Design with the Unified Process    16
                      USE CASE DESCRIPTIONS
  The Use Case Diagram helps identify the various processes that Users perform
   and that the new System must support.
  However, careful System Development requires much more detailed level of
   description or Diagrams.
     To create a comprehensive, robust System that needs Users’ needs, Analyst
     must understand all of the derailed internal steps within a single Use Case.

       Internally a Use Case includes a whole sequence of steps to complete a
       Business process and frequently several variations of the Business steps
        (flows of Activities) exist within a Single Use Case. These different flow of
       Activities are called “Scenarios” or “Use Case Instances”.


  SCENARIO is a unique set of internal activities within a Use
              Case and represents a unique path through the
              Use Case.
   A Use Case may have many different Scenarios.
Object-Oriented Analysis and Design with the Unified Process                            17
             USE CASE DESCRIPTIONS (continued)
   Use Case Descriptions are written at three levels of detail
       Brief Description
       Intermediate Description
       Fully Developed Description

      Written Descriptions and Activity Diagrams can be used in any combination
      depending on Analyst’s need.

   Brief Description
      Can be used for very simple Use Cases especially when the System
      to be developed is also small and well understood application.
       Simple Use case would normally have a single Scenario and very few (if any)
       exception Conditions. It is used in conjunction with an Activity Diagram
       adequately describes a simple Use Case.
Object-Oriented Analysis and Design with the Unified Process                      18
         Brief Description of Create New Order Use Case
Object-Oriented Analysis and Design with the Unified Process   19
             USE CASE DESCRIPTIONS (continued)
   INTERMEDIATE DESCRIPTION
     It extends the Brief Description to include the “Internal Flow of
     Activities” for the Use Case.
      If there are multiple Scenarios for a Use Case , then each internal
      flow of Activities is described individually.
      e.g. Create Order Use case has two Scenarios ( Order ClerkCcreatesTelephone
      Order , and Customer creates Web Orders)
    This description resembles a type of writing “Structured English”
    which can include Sequence , Select (Davison) and Reputation
    blocks.
     - Notice that Intimidate Description describes what the User and
       the System need to carry out the processing for the Scenario.
    - Each Step is identified with a number to make it easy to read.
    - Exception Conditions are also documented if they are needed.
Object-Oriented Analysis and Design with the Unified Process                    20
  Intermediate Description of Telephone Order Scenario for
                             Design with New Order
Object-Oriented Analysis and Create the Unified Process Use Case   21
             USE CASE DESCRIPTIONS (continued)
   FULLY DEDVELOPED DECRIPTION

    It is the Most formal Method and preferred method for documenting
    a Use Case despite the fact that it takes a little more time to define
    the Internal Flow Of Activities for a Use case.

   Creating a Fully Developed Use Case description helps Analyst to
    get a deep understanding of the Users’ needs.
   It will also increase the probability of thoroughly understand the
    Business Processes and the ways the System must support them.
   Fully developed Use Case Description
       Superset of Intermediate and Brief Descriptions
       Consists of eleven compartments
       User, Actor, Stakeholder, EBP, and Conditions identified
Object-Oriented Analysis and Design with the Unified Process           22
             USE CASE DESCRIPTIONS (continued)
   FULLY DEDVELOPED DECRIPTION

    Precondition states what conditions must be true before a Use Case
                  begins. (What the state of the System must be for the
                  Use Case to begin
    Postcondition Identifies what must be true upon completion of the
                   Use Case.

    Tips for writing Use Case Descriptions:
       - Keep Pre- and Post conditions fairly basic.
        - The Scope of a Use Case begins when the System is at a stable point and
          ends when it is again stable.
          This consideration will help you identify the Pre and Postconditions
       - Assume Perfect Technology such as the System is up and
          running, User is logged on , the Database connection is active and so forth…

Object-Oriented Analysis and Design with the Unified Process                        23
Fully Developed Description of Telephone Order Scenario for Create
                                       New Order
 Object-Oriented Analysis and Design with the Unified ProcessUse Case 24
              USE CASE DESCRIPTIONS (continued)
   Activity Diagram is another way to Document a Use Case
    Scenario.

        - Since an Activity Diagram is an easily understood Diagram,
          Analysts use it to document the workflows of Business Processes as
           well as Documenting the flow of Activities for Use Case Scenarios.

   An Activity Diagram can be used to support any three levels of Use
    Case Descriptions. It is similar to Two-column Description - (Actor and
    System) in the fully Developed Use Case Description.
  .
   The Benefits of creating an Activity diagram is that it is more visual
    and so can help both the User and System Developer as they work
    together to fully document the Use Case.

   Activity Diagrams are also helpful in developing System Sequence
    Diagrams (SSD).

Object-Oriented Analysis and Design with the Unified Process                    25
Object-Oriented Analysis and Design with the Unified Process   26
                   SYSTEM SEQUENCE DIAGRAM (SSD)
   System Sequence Diagram is a type of “Interaction Diagram”. It is used to describe
    the flow of information into and out of the Automated System.
   SSD documents the Inputs and the Outputs and identifies the interaction between
    Actors and the System.

   SSD NOTATIONS
      The “Stick” figure represents an Actor
      The Box labeled as :system is an Object that represents the entire Automated
       System ( As opposed to the Class Diagram notation in SSD Object notation is used.
       Object notation indicates that the box refers to an individual Object and not to the
       Class of all similar Objects.)
      A Rectangle with the name of the Object identified - the colon ( : ) is optional
      Underneath the Actor and the :system are vertical dashed lines called “LIFELINES”
      A Lifeline is simply the extension of that Object, throughout the duration of the SSD.
      The Arrows between the Lifelines represent the Messages that are sent or received.
      Lifelines indicate the Sequence of the Messages sent and received by the Actor and
       Object
      A Message is Labeled to describe both the message’s purpose and any input data
       being sent
      A Message is a command that has a syntax (Input parameters)
      Output Message has shown as dashed arrow a slightly format and meaning. An
       Optional note can be added to explain output Messages
Object-Oriented Analysis and Design with the Unified Process                             27
                     Sample System Sequence Diagram
Object-Oriented Analysis and Design with the Unified Process   28
                   SYSTEM SEQUENCE DIAGRAM (SSD)
     The same Message may be sent multiple times (i.e Repeated)
      (e.g. The message “Add An Item to an Order” may be sent multiple tines )


     The Repetition of a Message in a Condition Loop can be represented in
       two ways:

          a) The Message and its return are located inside a larger Rectangle to indicate
              the Repeating Loop.

          b) * [True/False Condition] - Asterisk (*) indicates that Message repeats as
              long as the True/ False condition evaluates true.

          The True / False Condition is used for Control of the Loop as well as to
           determine as to whether a Message is sent or not.


Object-Oriented Analysis and Design with the Unified Process                          29
                   SYSTEM SEQUENCE DIAGRAM (SSD)
     THE COMPLETE NOTATION FOR A MESSAGE

      * [true/false Condition] return-value := message-name (parameter – list)

          Note: Any part of the message may be omitted

      • Indicates repeat or Looping of the Message

      • Brackets [ ] indicates true / false Condition.

      • Message-name is the description of the requested service. It is omitted on the
        dashed-line return messages. Which only show the Return Data Parameter.

      • Parameter-list (with parentheses on input Messages and without
                       parenthesis on Return Messages) shows what data are passed
                       with the Message

      • Return-value on the same line as the Message requires Assignment Operator
        (: =) which is used to describe Data being returned from the destination
        Object to the source Object in response to the message.
Object-Oriented Analysis and Design with the Unified Process                        30
       Repeating Message (A) Detailed Notation (B) Alternate Notation
Object-Oriented Analysis and Design with the Unified Process            31
DEVELOPING A SYSTEM SEQUENCE DIAGRAM
  Begin with Detailed Description of the Use Case either Fully
   Developed form or as with Activity Diagrams
        One Advantage of using Activity Diagrams is that it is easy to identify
         when an Input or Output occurs. Input an Output occurs whenever an
         arrow in an Activity Diagram goes from an External Actor to the
         Computer System.

  FOUR Step Process for turning Activity Diagram into SSD
       [1] Identify the Input Messages
       [2] Describe messages from External Actor to System
       [3] Identify / apply special Conditions to Input Messages
       [4] Identify and add the Output Return Messages


Object-Oriented Analysis and Design with the Unified Process                       32
           DEVELOPING A SYSTEM SEQUENCE DIAGRAM
   1. Identify the Input Messages
        At each location where the workflow crosses the Automation boundary,
        Input data are required therefore a Message is needed.
   2. Describ Messages from External Actor to System
       Name the Messages to reflect the services that the Actor is requesting of the
       System. (eg. startOrder, addItem etc
       The other information required is the Parameter List for each Message. The
       important principle for identifying Data parameters is to base the List on the
       attributes on the Class Diagram.
        Looking at the Attributes with an understanding of what the System needs
        to do will help you find the right Attributes.
   3. Identify / Apply special Conditions to Input Messages
       Including Iterations and True / False conditions
   4. Identify and Add the Output Return Messages

Object-Oriented Analysis and Design with the Unified Process                            33
                  A Simplified Diagram of the Telephone Order Scenario
Object-Oriented Analysis and Design with the Unified Process             34
An SSD of Simplified Telephone Order Scenario for the Create New Order Use Case

 Object-Oriented Analysis and Design with the Unified Process                 35
                             THE STATECHART DIAGRAM
Statechart Diagram describes the collection of States of each Objects.
Statechart shows the ‘Behavior’ or ‘Life of an Object’ in “States” and
  “Transitions”.
      Status Condition is a Condition during and Object Life when it satisfy some
      criterion, performs some Action, or waits for an Event.
      Transition is the movement of an object from one State to another State.
      State of each Object are an important piece of information that an Analyst can
       use to help define the ‘Business Rules’ to be implemented in a Computer
       System.
      Statechart Can be developed for any Problem Domain Classes that have
       Complex “Behaviors” or “Status Condition” that need to be tracked by the
       System.
      Not all Problem Domain Classes require Statechart.
           ◘ A Statechart is not necessary for a Class that does not have Status
             Condition to Control Processing .
  Object-Oriented Analysis and Design with the Unified Process                     36
                           THE STATECHART DIAGRAM

 Statechart Diagram Symbols
      Ovals represent “Status of Object”
      Arrows represent “Transitions”
       Pseudostate (Black dot) denotes start of Statechart flow




Object-Oriented Analysis and Design with the Unified Process       37
                                   Simple Statechart for a Printer

Object-Oriented Analysis and Design with the Unified Process         38
              STATECHART DIAGRAM
  State of an object is a Condition that occurs during its
      Life when it satisfies some criterion, performs some Action
      or waits for an Event.
         States are Semi-permanent conditions. Transitions interrupt
          them and cause them to end.

  Transition is the movement of an Object from one State to
      another State. Transition is like a trigger that fires or an event
      that occurs.
   Origin State is the original State of an Object from which a
    Transition occurs.
   Destination State is the State to which an Object moves
    during a Transition.
   Message Event is the Trigger for a Transition which causes
    an Object to leave its original State.
Object-Oriented Analysis and Design with the Unified Process               39
                                  STATECHART DIAGRAM
Transition Label consists of three components:-
      transition-name (parameters) [guard-condition] / action-expression
Transition-name is the name of a “Message Event” that triggers the Transition and causes the
                 Object to leave the Origin state.
                         »    Message Names and Transition Names almost use the same Syntax
                         »    Transitions are caused by Messages coming to the Object


   Parameters comes directly from the Message Parameters.
 Guard-condition is the qualifier or test on the Transition and it is simply a “True / False”
                             condition that must be satisfied before Transition can fire.
                         » Sometimes a Transaction has only Guard-Condition and no Triggering Event; in that
                           case the Trigger is constantly firing and whenever the Guard-Condition becomesTrue
                           the Transition occurs.
Action-expression is a Procedural Expression that executes when the Transition fires.
                   It describes the Action to be performed.
Any of the three components (i.e transaction-name, guard-condition, or action-expression)
    may be empty.
        If either the Transition-name or Guard-condition is empty then it automatically evaluates
         to ‘True” . Either of them may be complex with AND an OR connectives.


    Object-Oriented Analysis and Design with the Unified Process                                           40
                     Statechart Diagram
Guidelines to help identify Object States
 There are two ways to identify the Valid States

     Check Naming convention for Status Conditions.

        A State may have a name of a simple Condition such as such as
         “On” or “In repair”
        A Complex States labeled with Gerunds or Verb phrases
                ◘     Example: “Being shipped”
                ◘     Active States usually not labeled with Nouns. (If you use a noun to
                      name a State‘ you have an incorrect idea about the States of Object
                      Classes.)
                         –    Rethink your Analysis and describe only States of being of the
                              Object itself
Think about Status Conditions that may need to be reported to Management or
   Customers (e.g. “Shipped”)


 Object-Oriented Analysis and Design with the Unified Process                                  41
                        Nested States And Concurrency
 The BVehavior of Objects in the real world is more complex than simply being
     in one State at a time.
  The condition of an Object being in more than one State at a time is called
     ‘Concurrency’[ or ‘oncurrent States’

             The Two ways to represent Concurrent States
        1. Show Concurrency with a Synchronization Bar and Concurrent
           Paths. (Path is a sequential set connected States and Transitions)
       2. Show Concurrency with States Nested inside other, higher-level States.
          (Nest low-level States inside Higher-level States)
           Higher-level states also called “Composite States”


  A Composite State represents a Higher Level of abstraction and
   can contain multiple Levels and Transitions (Nested States and
   Transitions.)
            To show Composite States we draw Lower- Level Statecharts within the Higher-
             Level State.

Object-Oriented Analysis and Design with the Unified Process                            42
                    Sample Composite States for the Printer Object
 When the Printer enters the “ON” State , it automatically begins at the nested black dot
 and moves to the “IDLE” State. So the Printer is both in the “On” State and the “Idle”
 State When Print Message is received the Printer makes the transition to the “Working”
 State but also remains in “On State.”. The Lower compartment contains
  “action-expression” - (Load: and Unified Process
Object-Oriented Analysis and Design with thePrint Sheets) while printer is in Working State.   43
                        Nested States And Concurrency
 Object Behavior is frequently more complex than simpleNested States.

 An Object may have entire set of States and Transitions (Multiple Paths – that are
  actively concurrent)
 To document Concurrent Behavior of a single Object we draw Composite State
  with the Lower portion divided into multiple compartments , one for each
  concurrent Path of Behavior.

 Example: A Printer that has an Input Bin to hold paper also cycles between two
           States in its work cycle of “Idle” and “Working” States.

                  – If we describe one Path as the States of Input Paper Try and the other
                    path as the States of the Printing mechanism (Idle and Working )

                  – In first Path (Input Paper try ) will have States of :
                              “Empty”, “Full” and “ Low”.
                  -In the Second Path will have States of “Idle” and “Working”.

                    These two paths are independent. The movement between States in
                    one compartment is completely independent of movement between
                    States in the other compartment.
Object-Oriented Analysis and Design with the Unified Process                           44
                   Nested States And Concurrency
       Object Behavior is frequently more complex than simple Nested States.
       An Object may have entire set of States and Transitions
        (Multiple Paths – that are active concurrently)
       To document Concurrent Behavior of a single Object we draw Composite
        State with the lower portion divided into multiple compartments , one for
        each concurrent Path of Behavior.




          Concurrent Paths for the Printer in the On State
Object-Oriented Analysis and Design with the Unified Process                        45
                       Rules for Developing Statecharts
  The primary challenge in building a Statechart is to identify the
   right “States” for the Object.

  The other major problem is to identify and handle “Composite
   States” with Nested Threads. (Due to Lack of experience!)
        Remember to consider “Exception Conditions” especially when you
         see the word “Verify” and “Check” .

          Normally there will be Transitions out of States that Verify something
          (one for Accept and one for Reject}

  The best solution is to remember that developing Statechart is an
   iterative behavior, more so than developing any other type of UML
   Diagram. (Analysts seldom get a Statechart right the first time!
   Thus, you should draw it and refine it again and again.


Object-Oriented Analysis and Design with the Unified Process                  46
                         Rules for Developing Statecharts
The following Rules can help to develop Statecharts for Classes in
the Problem Domain
[1] Review Class Diagram and Select the Classes that will require Statecharts
    (Include those Classes that have various Status Conditions important to track in the
     System

[2] Make a List all the Status Conditions for each Object group
    Think the Life Cycle of an Object! How does it come into existence in the
    System, when and how it is modified or deleted from the System. Does it have
    Active / Inactive States ., Waiting States etc.
[3] Begin building Statechart fragments by identifying the “Transitions” that
   cause an object to leave the identified State.
   (e.g. If an Order is in the State of “Ready to be Shipped”, a Transition such as
         ‘beginShipping’ will cause the Order to leave the State.
[4] Sequence State-transition” combinations in correct Order and Aggregate
    these combinations into large fragments.
    As fragments aggregated into Larger Paths begin to look for a natural Life Cycle
    for the Object.
    Continue to build longer Paths in the Statechart by combining the Fragments.
  Object-Oriented Analysis and Design with the Unified Process                             47
            Rules for Developing Statecharts (continued)
 [5] Review    the Paths and look for independent, Concurrent Paths.

     The two States may be on independent Path; one can change without affecting the other. Alternatively, one State may be a Composite
     state, so that the two States should be Nested, one inside the other.
     - One way to identify a candidate for a Composite State is to determine if it is concurrent with several other States,
       and the other States depend on the Origin State.


 [6] Look   for additional Transitions
     One method to identify the additional Transitions is to take every paired combination
     of States and ask whether there is a valid Transition between the States. Test them in
     both directions.


               Expand each Transition with Message Event, Guard Condition and
 [7] appropriate
     Action-expression.
     Include with each State appropriate “Action-expression” Much of it have been done as the Statechart fragments were being built
     Statechart.


 [8] Review and test each Statechart.
     Test Statechart by “Desk-checking” and review them by doing the followings:

     a) Make sure your States are really States of the Object in the Class. Ensure that the name truly
        describes States of being of the Object
      b) Follow the Object Life Cycle from its coming to existence to its being deleted from the system..
         Be sure that possible combinations are covered and that the paths are accurate.
     c) Be sure to cover all Exception Conditions as well as the normally expected flow of Behaviors.
     d) Check again for Concurrent Behavior (Multiple Paths) and the possibility of Nested Paths.
Object-Oriented Analysis and Design with the Unified Process                                                                          48
                DEVELOPING RMO STATECHARTS
 Review the Domain Class Diagram
 Select Classes with Status Conditions that need to be tracked
 Candidate Classes : Order, OrderItem, InventoryItem,
                       Shipment, Customer
 Choose Order and OrderItem as an example
     Continue Developing Statechart according to Eight rules

 Identify possible Status Conditions of interest
       “Ready to be shipped”

       “On back order”

       “Shipped”


Object-Oriented Analysis and Design with the Unified Process      49
Object-Oriented Analysis and Design with the Unified Process   50
                        Final Statechart for Orderitem
Action-expressions are added to the transitions to indicate any special action. It
is indicated by the Object or on the Object. (Place Purchase Order)
  Object-Oriented Analysis and Design with the Unified Process                 51
                            States and Exit Transitions for Order

Object-Oriented Analysis and Design with the Unified Process        52
                               Second-cut Statechart for Order
Object-Oriented Analysis and Design with the Unified Process     53
                      Developing the Order State Chart
      Benefits of developing a Statechart for an Object:

            It helps to capture and clarifies Business Rules

            It also help Analysts gain a true understanding of
             System Requirements




Object-Oriented Analysis and Design with the Unified Process      54
                    Integrating Object-Oriented Models
Developing and integrating Models are critical to ensure that Analyst understands the Business Requirements.

You should note that the development of detailed Diagram s is critical to gaining a through understanding of the
    User Requirements.

The Primary (or source) Models are:

       Use Case Diagram
          ◘ Use Case Descriptions
          ◘ Activity Diagrams
          ◘ System Sequence |Diagram

       Problem Domain Class Diagram
          ◘ System Sequence Diagram
          ◘ Statechart Diagrams

            You must make sure that the Use Case Diagram and the Domain Class Diagram is designed as completely as possible..

   CRUD Analysis validates Model is performed between the Class Diagram and Use Case Diagrams to ensure that
    the Use Case Diagram and the Problem Domain Class Diagram are as complete as possible.

       The detailed Use Case Descriptions or Activity Diagrams are internal documentation of the Use Case and must
        completely support the Use Case Diagrams. Internal descriptions such as Pre-and post- conditions are also
        important for development of System Sequence Diagrams.

       So the Detailed Use Case Descriptions, Activity Diagrams and System Sequence Diagrams must be all
        consistent with regards to the steps of a particular Use Case.


Object-Oriented Analysis and Design with the Unified Process                                                                    55
                           Relationships among OO Requirements Models
Object-Oriented Analysis and Design with the Unified Process            56

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:35
posted:7/12/2012
language:English
pages:56