• Like
  • Save
Realizing The AUC
Upcoming SlideShare
Loading in...5

Realizing The AUC



This presentation describes a method for analyzing the requirements in a use case model in order to determine if they are complete.

This presentation describes a method for analyzing the requirements in a use case model in order to determine if they are complete.



Total Views
Views on SlideShare
Embed Views



2 Embeds 6

http://www.linkedin.com 5
https://www.linkedin.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Realizing The AUC Realizing The AUC Presentation Transcript

    • Realizing The Application Use Case Analysis And Design Discipline
    • Precursor
      • In order to understand the material in this course, you should have a knowledge of UML, a UML modeling tool and equivalent knowledge of the following presentations:
        • Working With AUC Documents.
        • Use Case Modeling Notation.
        • Working With Class Diagrams.
        • What Is A State Transition Diagram?
    • Overview
      • In this lesson you will learn :
        • how to add analysis information to a use case diagram.
        • how to identify classes, their attributes and relationships from the use case model.
        • how to discover class operations.
        • how to map the use case to an analysis class diagram.
        • how to map an activity diagram to an analysis sequence diagram.
        • how to map state transition diagrams to classes.
    • Use Case Recap
      • A use case comprises the following components as a minimum:
        • Description – High level view of the contents of the use case.
        • Maximum Usage – How often that this use case could potentially be executed.
        • Primary Actor – The actor that initiates the use case.
        • Secondary Actors – Non-initiating actors that interface with the use case.
        • Preconditions – The state of the system prior to the use case executing.
        • Basic Flow – The main or expected path the use case executes.
        • Alternate Flows – Alternate paths the use case may execute in order to achieve its goal.
        • Extension Flows – Alternate paths that cause the use case to fail to achieve its goal.
        • Postconditions – The possible states of the system after the use case has completed.
    • Modeling Recap
      • The initial node takes the name of the preconditions.
      • A control flow takes the name of an externally visible event.
      • A decision describes an alternate of extension point.
      • A merge describes an alternate path returning to the basic flow.
      • A final node describes a postcondition of the system.
    • Adding Objects
      • For every activity in the activity diagram discover what information is input to the activity and what information is output from the activity.
      • Identify the appropriate object for this data and indicate whether the activity is writing to the object or reading from the object using directed object flows.
      • Label the object flow with the name of the data.
    • Dematerializer Objects 1 06/08/09
    • Dematerializer Objects 2 06/08/09
    • The Objects
      • Notice that the objects take the name of the ‘real-life’ object that they interface with.
        • door – operates the door to the dematerializer.
        • transmitter – interfaces to the Transmitter actor.
        • cargoHandler – controls securing the cargo.
        • vacuumPump – controls removing air.
        • deconstructor – controls the heart of the dematrializer.
        • blueprintManager – is an interface to the BlueprintManger actor.
        • airSensor – monitors the air pressure.
        • airValve – controls the air pressure.
        • powerManager – controls the power to the dematerializer.
    • Class Diagram
      • Create a class diagram and copy the object classes onto the diagram.
      • Add the operations and data from the activity diagram to the classes.
      • Connect the classes with relationships and add new classes as required.
    • Dematerializer Class Diagram
      • The Cargo class has been added to identify the attributes of the cargo. These will be input to the system as parameters of the ‘deconstruct’ command.
    • Draw A Sequence Diagram
      • Create a sequence diagram.
      • Add an instance of the primary actor of the use case on the left side of the sequence diagram.
      • Add instances of secondary actors on the right side of the sequence diagram.
      • Place instances of the classes on the diagram, roughly in the sequence in which they are accessed by the use case.
      • For every control flow in the basic flow of the use case activity diagram, draw equivalent message flows on the sequence diagram.
      • Add operations, as necessary, to the classes that represent the messages on the sequence diagram.
    • Corresponding Sequence Diagram 06/08/09
    • Sequence Diagram Explained
      • The sequence diagram is only complete up to step 5 of the use case.
      • Notice that the Cargo object is used to control the internal messages between the other objects.
      • Because the sequence diagram implies a time scale running vertically down the page, it is very difficult to show parallel flows on a sequence diagram.
    • Updated Class Diagram
      • The cargo class has been updated to reflect the operations discovered on the sequence diagram.
    • Alternative and Extending Flows
      • Repeat drawing a sequence diagram for each alternative and extending flow.
    • State Transition Diagrams
      • Another tool that helps us to determine if there is any missing data or operations from our model, is the STD.
      • For each class in the class diagram, where its states are non-trivial, i.e. there is more than one state, create a STD.
      • Identify all of the possible states that the class may take and all potential transitions between those states.
      • Ensure that all data and operations used by the STD are captured within the class that the STD is modeling.
    • AirValve STD
      • Notice that from the class diagram we see 2 states, ‘Open’ and ‘Closed’.
      • Once we start modeling, we discovered another 2 states and a potential data element, ‘failed’.
    • Update The Class Diagram
      • We have added a ‘failureState’ attribute to the valve class.
    • Revisit the Use Case Activity
      • The use case did not consider what to do if the air valve failed.
      • We need to add an alternate path to the use case describes the action to be taken in the event of a valve failure, extension point A3.
      • Notice the new extension does not mention the valve, it abstracts the functionality to the vacuum equipment without stating what that comprises.
      • Extension Points
      • A3 Vacuum equipment broke:
      • 12 At step 6 the system cannot create a vacuum, the system unsecures the cargo.
      • 13. When the cago is released the system opens the door.
      • The use case ends.
    • Summary
      • In this presentation you learned:
        • how to add objects to a use case activity diagram.
        • how to convert those objects into classes on a class diagram, and add preliminary data and operations.
        • how to model the use case and its associated classes using sequence diagrams.
        • how the sequence diagrams are used to capture more detailed operations of the classes.
        • how to model a class with a STD.
        • how to identify more information for the class diagram from the events in the STD.
        • how to add identify functionality from a use case by analyzing the classes that implement the use case.
    • Test Your Knowledge
      • Add objects to the ATM example use case.
      • Create a class diagram for the ATM application.
      • Create a sequence diagram for each path through the ATM application use case.
      • Model the ATM classes with STDs.
      • Update the use case from operations that are discovered during the modeling process.