Realizing The AUC


Published on

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

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Realizing The AUC

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