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

Realizing The AUC

on

  • 1,559 views

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.

Statistics

Views

Total Views
1,559
Views on SlideShare
1,553
Embed Views
6

Actions

Likes
0
Downloads
13
Comments
0

2 Embeds 6

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

Accessibility

Categories

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
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?
      06/08/09
    • 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.
      06/08/09
    • 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.
      06/08/09
    • 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.
      06/08/09
    • 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.
      06/08/09
    • 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.
      06/08/09
    • 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.
      06/08/09
    • 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.
      06/08/09
    • 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.
      06/08/09
    • 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.
      06/08/09
    • Updated Class Diagram
      • The cargo class has been updated to reflect the operations discovered on the sequence diagram.
      06/08/09
    • Alternative and Extending Flows
      • Repeat drawing a sequence diagram for each alternative and extending flow.
      06/08/09
    • 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.
      06/08/09
    • 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’.
      06/08/09
    • Update The Class Diagram
      • We have added a ‘failureState’ attribute to the valve class.
      06/08/09
    • 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.
      06/08/09
      • 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.
      06/08/09
    • 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.
      06/08/09