Slide #1.

Moving to Use Cases Chapter 2 – Part 1 1
More slides like this


Slide #2.

Traditional Modes of Expressing Functionality to Users Early in Lifecycle:  Requirements – Specifications Normally in terms of ‘lists’  Data Flow Diagrams (DFDs)  Entity-Relationship Diagrams (ERDs)  Prototypes 2
More slides like this


Slide #3.

Discussing these technologies  Requirements Lists – – –  DFDs – show data flows; interacting processes. – – – – – – – 3 A comprehensive list of functions An itemization Implies functions can be extracted and implemented. Contains Processes, Data flows, data stores. Data flows from process to process stopping at a data store. A dynamic view of the system Shows what happens INSIDE the system. – no algorithms… External entities lie outside the system boundary and trigger the system. Typically contain a lot of detail and many levels… Still useful in design – especially with non-object-oriented systems.
More slides like this


Slide #4.

Data Flow Diagram Conventions Emphasis inDFDsis on Processing Process Process Box Transform Inputs into Outputs Performed by People, Computers... External Entity External / Internal Entity Define Boundary of System Provide Net Inputs and/or Receive Net Outputs from System 1 4
More slides like this


Slide #5.

DataFlowDiagramConventions DataStores-Open-Ended  Cabinets, Logs, Files.  Data“at rest” DataFlows  Depict DataFlowingIntoor Out of a Process  Flowlinestypicallylabeled  Directional  TypicallyRepresent Reports, Forms, Documents, Memos, PhoneCalls, Retrievals, Letters, ... 5 7
More slides like this


Slide #6.

SimplePhysical DataFlowDiagram Mail Payment Check C u ss to m ee rr C u to m L is tin g ss :: L is tin g B aa la n cc ee d B la n d CheckRegister Statement Statement Withdrawal Entry Withdrawal Checkbook LogEntries Entry Customer Mail Bill Deposit Entry Paycheck Employer Anyother Sourceof Income 6 BankStmts Youor Spouse Pay Bill Youor Spouse Deposit moneyin Deposit toBank Slip Other income 8 Youor your Spouse Withdraw Cash Customer Listings: Previous Statements Youor your Spouse Balance Checkbook Account CashReceipt Deposit Bank Mail BankStatement andCanceledChecks
More slides like this


Slide #7.

CommonMechanical Errors NONOS 7 12
More slides like this


Slide #8.

Routingor ForwardingProcesses Customer Sales Department Form: Order Form13: Order tobeFilled Mail Secretary: Route Mail Mail: Payment andPayment Card Accounts Payment Receipt Receivable Letter: Complaint Customer 8 Customer Interofficememorandum: Relations Customer Credit Manager Phoneor letter Responseto Complaint 14
More slides like this


Slide #9.

CommonDFDErrors Employee Mail: Endof MonthBankStatements 3 Form: Credit Union MembershipApplication 1 Existing Accounts Asst Mgr: Create NewMember Account Member Acct (filedrawer) Employee Standing Clerk: Generate Employee Bank Statements Employee(filecabinet) Employee Account ID andAddress 2 Asst. Mgr: Freeze ModifiedAccount Member Status: “frozen” Account 9 Letter: Member Account Frozen Notification 15 Accounts Receivable Department
More slides like this


Slide #10.

TheValueof Physical DFDs DFDsForceAnalyststoCommunciate their Understandingof SystemstoEndUsers DFDsRequireAnalyststoExaminethe InterfacesbetweenSystems, Subsystems, andtheRest of theWorld DFDsmodel aSysteminPhysical Termsthat areFamiliar toEnd-Users 19 10
More slides like this


Slide #11.

Step1: DrawContext DFD DrawContext DFDto describesystem’s relationshiptorest of theworld  Maininputs&outputs  OnlysingleProcess boxandExternal Entities  Boundariesof system  Confirmsproject scopetotoplevel management  All processingdetail collapsedintosingle box Club Member 0 Member Computer Mail: Club Services Report and Promotions Catalog: andCatalogs Record Promotions Form40: Order tobe Warehouse Filled 1 11 Mail: Member Order Coupons Marketing Department
More slides like this


Slide #12.

S s ia Ste tep p2 2:: T Th he eS Sy ys ste tem m sD D iag gra ram m Mail:SubscriptionCard andOrder Form Potential Member Form40: Transcribed Special Order 1 Current Member Status Subscription Dept dbaseIV Member Computer Report & Catalog: Record Promotion 2 12 3 Orders Member Updates Dept Mail: member Order Coupons Promotion Dept Marketing Dept Form40: Order to befilled Member details Member Updates Warehouse Mail: AutoCatalogandAdvertisingFliers Mail: ClubPromotionsandCatalogs 3 Club Member
More slides like this


Slide #13.

Step 3 – Middle Level – Identification- of Transaction Flow Form letter: Membership Welcome or Denial 1.1 Form 40: Transcribed Special Order Mail Subscription Potential Card & Order Form Process Subscription Member Transaction Current Member Status 1.2 FormLtr: Notice of Pending Bonus Club Member Mail: MbrshpRenewal Slip Process Membership Renewal Transaction Mail: Renewal Welcome Ltr FormLtr: Membership Cancellation Confirmation Mail/Phone: Membership Cancellation (letter) dbase IV Member Member Updates 1.3 Process Membership Form 25: Outstanding A/R Cancellation Credit Notice Department Transaction 4 13 Member Updates
More slides like this


Slide #14.

Step 4 – Detailed Transaction Description A Form letter: Membership welcome or denial Potential Member Mail: Subscription card and order form A 1.1.1 Subscription card and order via advertisement B Mail Clerk: Distribute Mail Subscription card and order via referral 1.1.6 dbase IV program: C Chk Refrl Screen: Validity Current Member Current Status member status A 1.1.5 Clerk: Notify Applicant of Status Form ltr: Notice of Pending Bonus A Club Member 14 D E D 1.1.7 1.1.4 Clerk: Notify Applicant of Status Subscript ion clerk: Approve Applicant F Application Notebook Processed Application 1.1.2 dbase IV program Add new member A New member details Processed Application F Past Member File Cabinet Standing at time acoount was closed Special Order Form dbase IV Member Prospective Member application and order Existing Member’s bonus order (bottom) 1.1.3 Clerk: Transcribe Order Form 40: Transcribed Special Order A G
More slides like this


Slide #15.

Discussing these technologies  Entity-relation diagrams – – – – – – – 15 – A static view of data and data relationships… Show details of entities (attributes, relationships) Show how data is stored in application Used a lot for information engineering approaches. Not dynamic and require DFDs for the dynamics. Sometimes the differences between static and dynamic views of system are confusing to users. 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. Provide little meaning / utility to the user.
More slides like this


Slide #16.

Data Modeling with Entity Relationship Diagrams  ERDs define relations between data objects  Considered the cornerstone in Data Modeling  Shows attributes/properties for each data object  Producer/consumer of information  Shows relationships connecting objects  Number of objects in the relationship (cardinality) {1-1; 1-n; m-n}  Indicates if relationship is required or not (modality) {0 or 1} CSX 8 16
More slides like this


Slide #17.

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... cardinality / modality Manufacturer builds Automobile CSX 9 17
More slides like this


Slide #18.

Entity Relationship Diagrams (continued) Oftentimes specific attribute values may be shown in tables |<------------------- ATTRIBUTES (FIELDS / MEMBERS) ---------------- > MAKE MODEL ID# BODY TYPE COLOR REFERENCE REFERENC E FORD MUSTANG 1234 2-DOOR RED RFR PLYM VOYAGER 2345 4-DOOR WHITE CAR LX 4455 4-DOOR GREEN JDR GRAN AM 8899 2-DOOR RED HONDA PONT ETS CSX 10 18
More slides like this


Slide #19.

Discussing these technologies  Prototypes – – –   19 Concentrate on user interface Omit almost all of business rules and background coding. Executives have a hard time realizing that what they see is only façade… Should not be used as a main requirements tool. Good for ascertaining the user interface, though
More slides like this


Slide #20.

Discussion: Summary of these Technologies   Requirements Specs are rarely used once application is produced. (Discuss…) DFDs and ERDs are useful for moving into programming and into database design –   20 Mean little to users Prototypes obscure the real requirements and seem to emphasize the interface at the expense of the real application’s functionality. DFDs, ERDs, and prototypes include both ‘whats’ and ‘hows’ in their perspectives – confuses users, and this is not advisable.
More slides like this


Slide #21.

Interactions with the User  Need to emphasize capturing the requirements of the system from the users’ perspective.  Users view systems as black boxes (explain)  Requirements emphasizing black box approach – much more meaningful to users. – Implies: it’s all about interactions.  Use Cases are tools that should be used to show the ‘What’ of a system exclusively! 21
More slides like this


Slide #22.

Hello World   Basic Hello World Use Case is a ‘system context’ use case. Covered later…(Façade Use Case) Use Case – two parts – –  Diagram presents overview of important interactions –   22 Can include in Rational Rose Narrative presents the details of the interactions –  Use Case Diagram Use Case Description (narrative) Can include Word Descriptions in Rational Rose via Requisite Pro Use Cases have actors (entities outside the system) interacting with Use Cases. A Use Case represents requirements often stated in verb-object format, like Sell Property. Stories of user interactions with system.
More slides like this


Slide #23.

Typical Use Case for Selling Property – Main Use Case Diagram <> Buyer <> <> Sel l Property Sel ler Advisor 23
More slides like this


Slide #24.

Use Case Diagrams  Used to visually show system interactions and to capture the scope.  Easily drawn – with accompanying documentation (specification) using a software tool, such as Rational Rose.  The Use Case itself (narrative) needs to be ‘at the same level’ as the diagram and present much more detail than the diagram. (functionality) 24
More slides like this


Slide #25.

Sample Use Case Narrative 25 Discuss numbering, column formats, etc.
More slides like this


Slide #26.

Use Cases  Textbook 26 uses a different format.  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.  But with Requisite Pro, can link Word documents directly into Rose.
More slides like this


Slide #27.

Use Cases (more)  Book uses a Filled Use Case (includes the flow of events) – normally done during elaboration – –   27 In Inception, Façade Use Cases are helpful (chapter 5 in Use Case textbook) 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. Pages 21 – 38 in the Visually Modeling textbook covers how to use rational rose and use case modeling in very explicit detail!
More slides like this


Slide #28.

Unified Modeling Language       28 Recall: the UML is a ‘notation’ – a way to document system specifications and interactions. UML is not dependent upon any specific methodology (process). You need a process WITH this notation!! UML does require that the system has object-oriented components. Use cases themselves can be used for systems that are NOT based on object orientation. The UML has nine diagrams that provide different necessary views of the system. Diagrams are dependent upon each other. – Changes to one often means changes to another diagram.
More slides like this


Slide #29.

Use Case Diagram       29 Use Case diagrams and descriptions are the drivers for the rest of the diagrams. Need to be done first; Written in language of the user! Use Cases are text descriptions of interactions between some actors and the system. Use Case Diagrams are graphical representations between actors and use cases. Can have relationships between use cases themselves (includes; extends; others….) “Have the simplicity to represent a computer system’s essence, and yet they have the power to drive the entire methodology…”
More slides like this


Slide #30.

Thank you. 30
More slides like this