1. Object Oriented Methodologies
SYST Object Oriented Methodologies
Object Oriented Methodologies
J.N.Kotuba
Week02

2. Agenda Develop the requirements model & the Unified Process Use cases
Assignment No 1 posted
Review details
SLATE-Weekly Topical Outline and Schedule modified
Recap last lesson
Learning outcomes for today
Develop the requirements model & the Unified Process
Use cases
Use case diagrams
Use case narratives
SYST Object Oriented Methodologies
J.N.Kotuba

3. Last Class Introduced Unified Modeling Language (UML) Discussed Models
Tools
Techniques
SYST Object Oriented Methodologies
J.N.Kotuba

4. Context Diagram –Pharmacy System
SYST Object Oriented Methodologies
J.N.Kotuba

5. Objectives for today
Explain the difference between the Waterfall SDLC and the unified process
Learn how to use the Event Table Technique to identify use cases
Learn how to construct a use case diagram
Learn how to build a use case narrative for each use case and why the narratives are important
Be able to explain the difference between the system boundary and the automation boundary
SYST Object Oriented Methodologies
J.N.Kotuba

6. The Unified Process Four key stages. Inception. Elaboration
Construction
Transition
SYST Object Oriented Methodologies
J.N.Kotuba

7. Unified Process:Inception
Go ahead on project.
Scope determined.
Business case developed for project.
SYST Object Oriented Methodologies
J.N.Kotuba

8. Unified Process: Elaboration
Basic architecture of the system developed.
Construction plan is approved.
Risks are identified.
SYST Object Oriented Methodologies
J.N.Kotuba

9. Unified Process: Construction.
Iterative approach to developing software.
Product will be a beta.
SYST Object Oriented Methodologies
J.N.Kotuba

10. Unified Process:Transition
Beta product is introduced to users and information is collected from users during roll-out.
SYST Object Oriented Methodologies
J.N.Kotuba

11. Iterative Development
Planning
Analysis
Analysis
Analysis
Use Cases
Design
Design
Design
Test
Test
Test
Implement
Implement
Implement
SYST Object Oriented Methodologies
J.N.Kotuba

12. Modeling
Software development is the production of ‘executable models’.
These models often are abstractions of the original problem with classes added to solve the user’s problems.
SYST Object Oriented Methodologies
J.N.Kotuba

13. Different Types of Models
Use Case Model. The system from the users point of view.
Static Model. The elements of the system and how they relate to one another.
Dynamic Model. Outlines the behaviour of the system in the context of Object interactions.
SYST Object Oriented Methodologies
J.N.Kotuba

14. UML
The Unified Modeling language is (UML) a language for development object-oriented models and system designs.
It provides a complete set of graphical diagrams to specify use cases, class diagrams and the dynamic model (object interactions) of a system.
Can be used with different programming languages.
SYST Object Oriented Methodologies
J.N.Kotuba

15. System Boundary vs Automation Boundary
Every System has a boundary between it and it’s environment.
Any inputs or outputs must cross the system boundary. [recall the Context Diagram]
Defining these inputs and outputs is an important part of systems analysis and design.
In every system people are key components and these people do some of the work accomplished by the system.
There is another boundary that is important to the systems analyst- the automation boundary.
On one side of the automation boundary is the automated part of the system where work is done by computers.
On the other side is the manual part of the system where work is done by people.
SYST Object Oriented Methodologies
J.N.Kotuba

16. System Boundary vs Automation Boundary
SYST Object Oriented Methodologies
J.N.Kotuba

17. Use Case Model A use case is a script:
A step-by-step description of how a user might make use of the system to do a task
It is a “case of the usage of the system.”

18. User Goals, Events, and Use Cases
Use Case -- An activity the system performs in response to a user request
Techniques for identifying use cases
User goal technique
Each goal at the elementary business process (EBP) level is a use case
EBP – a task performed by one user, in one place in response to a business event, that adds measurable business value, and leaves system and data in consistent state

19. User Goals, Events, and Use Cases (continued)
CRUD analysis technique (create, read, update, delete)‏
Event decomposition technique

20. Identifying Use Cases Based on User Goals

21. Use Case Based on CRUD Technique

22. CRUD Matrix Example SYST39409-Object Oriented Methodologies
© Jerry Kotuba

23. Discovering Use Cases
Event – in the real world Event occurs when something happens
Events drive or trigger all processing that a system does.
What events occur that will affect the system being studied?
What events occur that will require the system to respond in some way?
Black Box view – focus on “what” not “how”
SYST39409-Object Oriented Methodologies
© Jerry Kotuba

24. Event Decomposition Technique
Event – an occurrence at a specific time and place and which needs to be remembered
Business events trigger elementary business processes (EBPs)‏
EBPs are at correct level of analysis for use cases
Identify business events to decompose system into activities/use cases

25. Types of Events External Temporal State Outside system
Initiated by external agent or actor
Temporal
Occur as result of reaching a point in time
Based on system deadlines
State
Something inside system triggers processing need

26. Events – (affecting a system)

27. External event checklist
SYST39409-Object Oriented Methodologies
© Jerry Kotuba

28. Temporal Event Checklist
SYST39409-Object Oriented Methodologies
© Jerry Kotuba

29. Listing events When analyzing a system we must list all events
Identify other information about each of them
SYST39409-Object Oriented Methodologies
© Jerry Kotuba

30. Identifying Events Can be difficult to determine
Often confused with conditions and responses
May be useful to trace a transaction’s life cycle
Certain events left to design phase
System controls to protect system integrity
Perfect technology assumption defers events

31. Sequence of Actions that Lead Up to Only One Event Affecting the System

32. Sequence of “Transactions” for One Specific Customer Resulting in Many Events

33. Events Deferred Until the Design Phase

34. Event table “Process”  Use Case
SYST39409-Object Oriented Methodologies
© Jerry Kotuba

35. Event Table Exercise- Pharmacy System
SYST Object Oriented Methodologies
J.N.Kotuba

36. Identifying the Actors
Where do you look?
Context Diagram
Existing system documentation (our case)
Ask the following questions
Who or what provides inputs,such as forms, voice commands, fields on input screens, etc to the system?
Who or what receives outputs, such as notifications, reports, voice messages , etc from the system?
Are interfaces required to other systems?
Are there any events that are automatically triggered at a predetermined time?
Who (User) will maintain the information system?
SYST Object Oriented Methodologies
J.N.Kotuba

37. Use Case - Actors
An actor is always outside the automation boundary of the system but may be part of the manual portion of the system
an actor is not always the same as the source of the event in the event table.
A source of an event is the initiating person, such as a customer, and is always external to the system, including the manual system.
an actor in use case analysis is the person who is actually interacting (hands-on) with the computer system itself.
SYST Object Oriented Methodologies
J.N.Kotuba

38. Use Case Identifies What Users Want
Use cases focus on usage of the system
Services
Behaviors
Responses
No internal structural details of the system
Can be considered as the “responsibilities” of the system
SYST Object Oriented Methodologies
J.N.Kotuba

39. Use Case Identifies What Users Want
Next
Validate use case names
Write narrative descriptions for each use case
Refining the name
May “discover” more than one use case
E.g register member
Register new member
Renew existing member
Purchase
Retail
Trade
Dealer
staff
SYST Object Oriented Methodologies
J.N.Kotuba

40. Use Case Identifies What Users Want
Refining the name
Does it tell the whole story?
Any exceptions?
Special cases?
Possible errors?
Occasional variations?
Does the name cover several related or similar processes?
Is there a more informative or enlightening name?
SYST Object Oriented Methodologies
J.N.Kotuba

41. Use Case Identifies What Users Want
Write a narrative description
Sequence of events or steps user goes through.
Focus on mainline
Straight-line sequence
Then consider exceptions, options errors
SYST Object Oriented Methodologies
J.N.Kotuba

42. Use Cases Analysts define use cases at three levels Brief Intermediate
Fully developed
SYST Object Oriented Methodologies
J.N.Kotuba

43. Use Case Narrative: Fill Prescription
Step 1.Pharmacist inputs Patient ID Step 2.System displays patient medical record Step 3.Pharmacist verifies dosage, potential allergic reactions and/or interaction with other medications. Step 4.The Pharmacist fills the prescription and updates the patient’s medical record on the system with details of the new prescription. Step 5. The system prints a label which is sent to the nurses station and the Billing Dept. is given Patient and Prescription details. Alt Step 3. If the pharmacist determines a possible negative condition exists, then the Doctor is contacted Alt Step 4. The prescription is held for disposition and the process terminates with the pharmacist proceeding to the next prescription in the queue.
SYST Object Oriented Methodologies
J.N.Kotuba

44. Brief Description of Create New Order Use Case
SYST Object Oriented Methodologies
J.N.Kotuba

45. Intermediate Description of Telephone Order Scenario for Create New Order Use Case
SYST Object Oriented Methodologies
J.N.Kotuba

46. Fully Developed Description of Telephone Order Scenario for Create New Order Use Case
SYST Object Oriented Methodologies
J.N.Kotuba

47. Use Case Narratives- Preconditions & Post Conditions
Hospital Pharmacy Case Study
Preconditions & post conditions
Preconditions state what conditions must be true before a use case begins.
In other words, a precondition identifies what the state of the system must be for the use case begin, including what objects must already exist, what information must be available, even the condition of the actor (e.g. user logged on; connection to an external system is active etc.)
For example; for some companies, an order cannot be created unless the customer exists and has a good credit rating.
Another example; what about the library? What must exist for someone to borrow a book?
Hospital Pharmacy System:
What preconditions must exist for “Fill Prescription” ?
Post conditions
A post condition identifies what must be true upon completion of the use case.
The same items that are used to describe the precondition should be included in the statement of the post condition. Use the same guidelines for preconditions to define post conditions; concentrate on what objects must exist; what relationships must exist; and what values are important.
SYST39409-Object Oriented Methodologies
© Jerry Kotuba

48. SYST39409 - Object Oriented Methodologies J.N.Kotuba
Package:
Pharmacy System
Use Case Name:
Review Prescription
Primary Actor:
Pharmacy Technician
Other Participating Actors:
Summary Description:
When prescriptions are received at the Mercy Hospital Pharmacy, they are directed to the Pharmacy Technician. He reviews the prescription and then decides, based on the type of medication, which of three stations to direct it to for filling.
Preconditions:
The prescription must be for a current patient of Mercy Hospital and issued by a licensed Medical Doctor.
Trigger:
Prescription is received by the pharmacy.
Typical Course of events:
Pharmacy Technician (PT) verifies that the patient is an admitted patient.
PT verifies that a licensed Medical Doctor issued the prescription.
PT logs the prescription into the system and it is assigned a serialized ID number by the system.
PT checks the type of medication; if it must be formulated (made-on-site), sends it to the lab station; if it is an off-the-shelf medication, sends it to the shelving station; narcotics are sent to the secure station.
PT enters the shelving station ID to which it was sent into the system.
Alternative Paths:
If the patient is not currently admitted to the Hospital, the prescription is returned to the Doctor.
If the Doctor is not listed in the Pharmacy database, the prescription is referred to the Pharmacist for disposition.
Post conditions:
The prescription is assigned to a filling station and logged into the system for tracking.
Assumptions:
Related Business Rules:
Prescriptions can only be accepted from licensed Physicians for patients admitted to Mercy Hospital.
Author:
J.N.Kotuba
Date:
May 2012
Example
“Review
Prescription”
Use Case
Fully Developed
SYST Object Oriented Methodologies
J.N.Kotuba

49. Use Case Narrative: Do’s Don’ts Use complete sentences
How is the use case initiated and how does it end
What the initial and final actions and state of the system look like
Don’ts
Use abbreviations or sentence fragments
SYST Object Oriented Methodologies
J.N.Kotuba

50. SYST39409 - Object Oriented Methodologies
J.N.Kotuba

51. Components of the Use Case Diagram
Actor
System Boundary
SYST Object Oriented Methodologies
J.N.Kotuba

52. Draw the Use Case with SA
SYST Object Oriented Methodologies
J.N.Kotuba

53. Your Turn… See SLATE – I-C-E-01
Use Case For the Dental Office Appointment System, develop;
Context Diagram
Event table
Use Case Diagram
Create a narrative for each use case (Intermediate Level)
SYST Object Oriented Methodologies
J.N.Kotuba

54. Use Case Guidelines Names Noun + Verb
J.N.Kotuba
SYST Object Oriented Methodologies

55. Use Case Guidelines Nouns SYST39409 - Object Oriented Methodologies
J.N.Kotuba
SYST Object Oriented Methodologies

56. Use Case Guidelines
Avoid using implementation system specific language when writing use case narratives
J.N.Kotuba
SYST Object Oriented Methodologies

57. .Summary Developing the Requirements Model: The Use Case Model
Use Cases are an informal description of the system;
They do not give information about how the system does things
Or any other details internal to the system.
They just tell us what the system will do for the users.
Concentrating on what rather than how makes them more a tool for analysis than design, but. . .
They do give us a good starting point for both
Testing the system, and
Prototyping the user interface.
SYST Object Oriented Methodologies
J.N.Kotuba

58. Recap Lesson Learning outcomes for today
Develop the requirements model
Use cases
Use case diagrams
Use case narratives
SYST Object Oriented Methodologies
J.N.Kotuba

59. What Comes Next?
SYST Object Oriented Methodologies
J.N.Kotuba