Published on

  • 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


  1. 1. Moving to Use Cases Chapter 2 – Part 1
  2. 2. Traditional Modes of Expressing Functionality to Users Early in Lifecycle: <ul><li>Requirements Specifications </li></ul><ul><ul><li>Normally in terms of ‘lists’ </li></ul></ul><ul><li>Data Flow Diagrams (DFDs) </li></ul><ul><li>Entity-Relationship Diagrams (ERDs) </li></ul><ul><li>Prototypes </li></ul>
  3. 3. Discussing these technologies <ul><li>Requirements Lists </li></ul><ul><ul><li>A comprehensive list of functions </li></ul></ul><ul><ul><li>An itemization </li></ul></ul><ul><ul><li>Implies functions can be extracted and implemented. </li></ul></ul><ul><li>DFDs – show data flows; interacting processes. </li></ul><ul><ul><li>Contains Processes, Data flows, data stores. </li></ul></ul><ul><ul><li>Data flows from process to process stopping at a data store. </li></ul></ul><ul><ul><li>A dynamic view of the system </li></ul></ul><ul><ul><li>Shows what happens INSIDE the system. – no algorithms… </li></ul></ul><ul><ul><li>External entities lie outside the system boundary and trigger the system. </li></ul></ul><ul><ul><li>Typically contain a lot of detail and many levels… </li></ul></ul><ul><ul><li>Still useful in design – especially with non-object-oriented systems. </li></ul></ul>
  4. 4. 1 Data Flow Diagram Conventions Data Flow Diagram Conventions  Emphasis in DFDs is on Processing  Process Box  Transform Inputs into Outputs  Performed by People, Computers...  External / Internal Entity  Define Boundary of System  Provide Net Inputs and/or Receive Net Outputs from System  Emphasis in DFDs is on Processing  Process Box  Transform Inputs into Outputs  Performed by People, Computers...  External / Internal Entity  Define Boundary of System  Provide Net Inputs and/or Receive Net Outputs from System Process External Entity
  5. 13. Step 3 – Middle Level – Identification of Transaction Flow 4 4 - Potential Member Club Member Process Subscription Transaction Process Membership Renewal Transaction Process Membership Cancellation Transaction A/R Department dbase IV Member Form letter: Membership Welcome or Denial Mail Subscription Card & Order Form Form 40: Transcribed Special Order Current Member Status Form Ltr : Notice of Pending Bonus Mail: Mbrshp Renewal Slip Mail: Renewal Welcome Ltr Form Ltr : Membership Cancellation Confirmation Mail/Phone: Membership Cancellation (letter) Member Updates Form 25: Outstanding Credit Notice Member Updates 1.1 1.2 1.3
  6. 14. Step 4 – Detailed Transaction Description
  7. 15. Discussing these technologies <ul><li>Entity-relation diagrams </li></ul><ul><ul><li>A static view of data and data relationships … </li></ul></ul><ul><ul><li>Show details of entities (attributes, relationships) </li></ul></ul><ul><ul><li>Show how data is stored in application </li></ul></ul><ul><ul><li>Used a lot for information engineering approaches. </li></ul></ul><ul><ul><li>Not dynamic and require DFDs for the dynamics. </li></ul></ul><ul><ul><li>Sometimes the differences between static and dynamic views of system are confusing to users. </li></ul></ul><ul><ul><li>Still good for creating logical data models after requirements have been gathered and for creating your database and your fully-attributed list. Used extensively in database modeling and design. </li></ul></ul><ul><ul><li>Provide little meaning / utility to the user. </li></ul></ul>
  8. 17. 9 CSX Entity Relationship Diagrams (continued) Entity Relationship Diagrams (continued)  ERDs REPRESENT ALL DATA THAT ARE INPUT, STORED, TRANSFORMED, AND PRODUCED IN A MANNER THAT IS INDEPENDENT OF THE PROCESSING THAT TRANSFORMS THEM... Manufacturer builds Automobile cardinality / modality
  9. 18. 10 CSX Entity Relationship Diagrams (continued) Entity Relationship Diagrams (continued) Oftentimes specific attribute values may be shown in tables |< ------------------- ATTRIBUTES (FIELDS / MEMBERS) ---------------- > MAKE MODEL ID# BODY TYPE COLOR REFERENC E FORD MUSTANG 1234 2 - DOOR RED RFR PLYM VOYAGER 2345 4 - DOOR WHITE CAR HONDA LX 4455 4 - DOOR GREEN JDR PONT GRAN AM 8899 2 - DOOR RED ETS |< ------------------- ATTRIBUTES (FIELDS / MEMBERS) ---------------- > MAKE MODEL ID# BODY TYPE COLOR REFERENCE E FORD MUSTANG 1234 2 - DOOR RED RFR PLYM VOYAGER 2345 4 - DOOR WHITE CAR HONDA LX 4455 4 - DOOR GREEN JDR PONT GRAN AM 8899 2 - DOOR RED ETS
  10. 19. Discussing these technologies <ul><li>Prototypes </li></ul><ul><ul><li>Concentrate on user interface </li></ul></ul><ul><ul><li>Omit almost all of business rules and background coding. </li></ul></ul><ul><ul><li>Executives have a hard time realizing that what they see is only façade… </li></ul></ul><ul><li>Should not be used as a main requirements tool. </li></ul><ul><li>Good for ascertaining the user interface, though </li></ul>
  11. 20. Discussion: Summary of these Technologies <ul><li>Requirements Specs are rarely used once application is produced. (Discuss…) </li></ul><ul><li>DFDs and ERDs are useful for moving into programming and into database design </li></ul><ul><ul><li>Mean little to users </li></ul></ul><ul><li>Prototypes obscure the real requirements and seem to emphasize the interface at the expense of the real application’s functionality. </li></ul><ul><li>DFDs, ERDs, and prototypes include both ‘whats’ and ‘hows’ in their perspectives – confuses users, and this is not advisable. </li></ul>
  12. 21. Interactions with the User <ul><li>Need to emphasize capturing the requirements of the system from the users’ perspective. </li></ul><ul><li>Users view systems as black boxes (explain) </li></ul><ul><li>Requirements emphasizing black box approach – much more meaningful to users. </li></ul><ul><ul><li>Implies: it’s all about interactions. </li></ul></ul><ul><li>Use Cases are tools that should be used to show the ‘What’ of a system exclusively! </li></ul>
  13. 22. Hello World <ul><li>Basic Hello World Use Case is a ‘system context’ use case. Covered later…(Façade Use Case) </li></ul><ul><li>Use Case – two parts </li></ul><ul><ul><li>Use Case Diagram </li></ul></ul><ul><ul><li>Use Case Description (narrative) </li></ul></ul><ul><li>Diagram presents overview of important interactions </li></ul><ul><ul><li>Can include in Rational Rose </li></ul></ul><ul><li>Narrative presents the details of the interactions </li></ul><ul><ul><li>Can include Word Descriptions in Rational Rose via Requisite Pro </li></ul></ul><ul><li>Use Cases have actors (entities outside the system) interacting with Use Cases. </li></ul><ul><li>A Use Case represents requirements often stated in verb-object format, like Sell Property. Stories of user interactions with system. </li></ul>
  14. 23. Typical Use Case for Selling Property – Main Use Case Diagram
  15. 24. Use Case Diagrams <ul><li>Used to visually show system interactions and to capture the scope . </li></ul><ul><li>Easily drawn – with accompanying documentation (specification) using a software tool, such as Rational Rose. </li></ul><ul><li>The Use Case itself (narrative) needs to be ‘at the same level’ as the diagram and present much more detail than the diagram. (functionality) </li></ul>
  16. 25. Sample Use Case Narrative Discuss numbering, column formats, etc.
  17. 26. Use Cases <ul><li>Textbook uses a different format. </li></ul><ul><li>Can readily created these narratives using ‘Tables’ in Word and linking them into your Use Cases by double clicking on a specific Use Case symbol in a Use Case Diagram, selecting “Files” tab, right clicking (to show short cut menu) and selecting Insert File to link to your Word file via browsing. </li></ul><ul><li>But with Requisite Pro, can link Word documents directly into Rose. </li></ul>
  18. 27. Use Cases (more) <ul><li>Book uses a Filled Use Case (includes the flow of events) – normally done during elaboration </li></ul><ul><ul><li>In Inception, Façade Use Cases are helpful </li></ul></ul><ul><ul><li>(chapter 5 in Use Case textbook) </li></ul></ul><ul><li>Note the elements constituting a Use Case – eventually – name, iteration, actors, description / flow of events, alternative paths, exception points, triggers, assumptions, pre- and post conditions, related business rules (for traceability), an author and a date – for version control. </li></ul><ul><li>Pages 21 – 38 in the Visually Modeling textbook covers how to use rational rose and use case modeling in very explicit detail! </li></ul>
  19. 28. Unified Modeling Language <ul><li>Recall: the UML is a ‘notation’ – a way to document system specifications and interactions. </li></ul><ul><li>UML is not dependent upon any specific methodology (process). You need a process WITH this notation!! </li></ul><ul><li>UML does require that the system has object-oriented components. </li></ul><ul><li>Use cases themselves can be used for systems that are NOT based on object orientation. </li></ul><ul><li>The UML has nine diagrams that provide different necessary views of the system. </li></ul><ul><li>Diagrams are dependent upon each other. </li></ul><ul><ul><li>Changes to one often means changes to another diagram. </li></ul></ul>
  20. 29. Use Case Diagram <ul><li>Use Case diagrams and descriptions are the drivers for the rest of the diagrams. </li></ul><ul><li>Need to be done first; Written in language of the user! </li></ul><ul><li>Use Cases are text descriptions of interactions between some actors and the system. </li></ul><ul><li>Use Case Diagrams are graphical representations between actors and use cases. </li></ul><ul><li>Can have relationships between use cases themselves (includes; extends; others….) </li></ul><ul><li>“ Have the simplicity to represent a computer system’s essence, and yet they have the power to drive the entire methodology…” </li></ul>
  21. 30. Thank you.