Transcript Engineering Quality Software

Object Oriented Methodologies
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
1
Agenda
• Assignment No 1 posted
– Review details
• SLATE-Weekly Topical Outline and Schedule modified
– Quiz No 1 Next week
• Recap last lesson
• Learning outcomes for today
– Further develop the requirements model
• √ Use cases
• √ Use case diagrams
• √ Use case narratives
– Activity Diagrams
– Class Diagrams
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
2
Review Last Class
• Introduced Unified Process (UP) and Unified Modeling
Language (UML)
• Discussed
– Models
– Tools
– Techniques
• Introduced Techniques for identifying Use Cases
– User Goal Technique
• Including user stories
– Event Table Technique
– CRUD Technique
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
3
System Boundary vs Automation Boundary
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
4
Context Diagram –Pharmacy System
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
5
The Pharmacy System
• Finalize the Event Table
• Identify the Actors
• Build the Use Case Diagram
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
6
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
7
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
8
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
9
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 email 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?
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
10
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.
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
11
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
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
12
Use Cases
• Analysts define use cases at three levels
– Brief
– Intermediate
– Fully developed
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
13
Brief Description of Create New Order Use Case
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
14
Intermediate Description of Telephone Order Scenario for Create New
Order Use Case
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
15
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
16
Fully Developed Description of Telephone Order Scenario for Create New Order
Use Case
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
17
Use Case Narratives- Preconditions & Post
Conditions
• Hospital Pharmacy Case Study
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
18
Example
“Review
Prescription”
Use Case
Fully Developed
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:
1.
2.
3.
4.
5.
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:
J.N.Kotuba
Author:
Date:
Prescriptions can only be accepted from licensed Physicians for patients admitted to Mercy
Hospital.
SYST39409 - Object Oriented
J.N.Kotuba
Methodologies
May 2013
19
More about Use Cases…
• What are “use case scenarios” ?
• How to identify and show relationships between Use
Cases. [Includes & Extends] ?
• What are use case Pre-conditions/Post-conditions
and why they are important?
• How to describe a use case with an activity or
workflow diagram?
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
20
ATM Example
• Use Case: Withdraw
Money
• Use Case: Deposit
Money
– Flow of events
– Flow of events
• The user inserts an ATM
card
• The system prompts the
user to enter a password
• The user enters the
password.
• The system validates the
password
• The user inserts an ATM
card
• The system prompts the
user to enter a password
• The user enters the
password.
• The system validates the
password
Common Behaviours
21
ATM Example
• Use Case: Withdraw
Money
– Flow of Events
• Include [login]
• Use Case: Deposit
Money
– Flow of Events
• Include [login]
Use Case: Login
Flow of events
The user inserts an ATM card
The system prompts the user to enter a password
The user enters the password.
The system validates the password
22
Withdraw
Money
Deposit
Money
Login
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
23
Use case scenarios…
• Case In Point
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
24
Use Case Relationships
• Also referred to as dependencies
– Includes
• E.g. “Stop Payment”
– Extends (Option to extend the base Use Case)
• E.g “Register Student”
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
25
Comments on Include & Extend
• Tend to see more includes.
• Extends are fewer.
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
26
More About Actors
• People
• External Systems
• Time
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
27
Use Case Narratives- Preconditions & Post
Conditions
• Hospital Pharmacy Case Study
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
28
Use Cases
• Use cases tell;
– the customer what to expect
– the developer what to code
– the technical writer what to document
– and the tester what to test.
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
29
Example
Student Registration Sy stem
Register f or
Courses
Course Catalogue Sy stem
Student
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
30
Activity Diagram
• A type of workflow diagram that describes the
user activities and their sequential flow.
• Illustration:
–The following slide summarizes the workflow of
how a customer request for a quotation to modify
a computer system is handled.
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
32
Generate a quotation
The customer initiates the process by requesting a quote. A
salesperson receives the request and writes down the details
of the request and then decides whether she can do it herself
or whether she needs help. If she does not need help, then
the salesperson enters the information into the computer
system. If the salesperson needs help, then the technical
expert performs the next step. The expert reviews the quote
request to make sure that the requested components can be
integrated into a functioning computer system. The expert
then enters the information into the computer system. At
this point, the computer system generates the detailed quote.
The customer reviews the quote and decides whether it needs
changes or is acceptable. If acceptable, places the order.
Jerry Kotuba
Object Oriented Methodologies
33
Notation
Your Turn… Activity Diagrams –ICE-02
© Jerry Kotuba
SYST39409-Object Oriented
Methodologies
35
Example without
Package Notation
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
36
Example using
Package Notation
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
37
What Comes Next?
J.N.Kotuba
SYST39409 - Object Oriented
Methodologies
38
Class Diagrams- Objectives
• Identify and analyze the objects and object-classes needed in a
system
• Learn how to identify and represent relationships between object
classes.
• Learn how to identify and create super/subclass relationships
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
39
Problem Domain Classes
• Problem domain
– Abstraction”Real World” to “Data world”
– Set of work-related “things” in system component
• Things have data representation within system
– Examples: products, orders, invoices, customers
• OO approach to things in problem domain
– Objects that interact in the system
• Identify and understand things in problem domain
– Key initial steps in defining requirements
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
40
Types of Things
• Things can be identified with methodology
• Separate the tangible from the intangible
• Include information from all types of users
• Ask important questions about nature of
event
– “What actions upon things should be
acknowledged and recorded by the system?”
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
41
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
42
Procedure for Developing an Initial List
of Things
• Perform Textual Analysis
– List nouns users mention when discussing system
• Event table as source of potential things
– Use cases, external agents, triggers, response
• Select nouns with questions concerning relevance
– Further research may be needed
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
43
Pharmacy System Example
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
44
Associations among Things
• Analyst document entity associations ( relationships)
– Example: “Is placed by” and “works in”
• Associations apply in two directions
– Customer places an order
– An order is placed by a customer
• Multiplicity: the number of associations
– One to one or one to many
• The associations between types of things
– Unary (recursive), binary, n-ary
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
45
Attributes of Things
• Specific details of things are called attributes
• Analyst should identify attributes of things
• Identifier (key): attribute uniquely identifying thing
– Examples: Social Security number, vehicle ID number, or
product ID number
• Compound attribute is a set of related attributes
– Example: multiple names for the same customer
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
46
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
47
Classes and Objects
• Domain model class diagram as UML class
– OOA applies domain model class diagram to things
• Problem domain objects have attributes
• Software objects encapsulate attributes and behaviors
– Behavior: action that the object processes itself
• Software objects communicate with messages
• Information system is a set of interacting objects
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
48
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
49
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
50
Exercises No 1 to No 3
• To be done in class for illustration and practice
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
51
Your Turn…ICE-03
• See SLATE
Jerry Kotuba
SYST39409-Object Oriented
Methodologies
52