CMIS 470
Structured Systems Design
Object-Oriented Analysis
and Design – Terms,
UML, Class Diagrams,
Use Cases
Week 4
Plan for the week




Object terms
Unified Modeling Language history
Use Case Diagrams
Class Diagrams
Object-Oriented Analysis & Design

Object-oriented analysis



Defines all of the types of objects that do the work
of the system
Shows how objects interact
Object-oriented design


Defines all additional object types needed to
communicate with people and devices in the
system
Refines each type of object for implementation
Object-Oriented Approach

Views information systems as collections of
interacting objects that work together to
accomplish tasks


Objects - things in the computer system that can
respond to messages
No processes, programs, data entities, or files
Classes and Objects



A class is a category of similar objects.
Each object is an instance of a class – that is,
one specific member of the class.
Class is the template – it contains all the
shared attributes and behaviors found in each
object of the class.
Objects


An object is a person, place, event, or
thing about which we want to capture
data and define processes.
Where have you heard this definition
before?
Objects versus Entity

Objects can have behaviors.


Object instance is assigned a unique
identifier.


Behaviors are methods or operations that serve to
specify what actions the object can perform.
Entities have primary and foreign keys.
However, objects have attributes like entities.
Example!
Appointment scheduling example
Characteristics of OO
Approach




Methods and Messages
Encapsulation (Information Hiding)
Hierarchical Inheritance
Polymorphism
Behaviors / Methods /
Messages



Behaviors specify what the object can do.
A method is nothing more than an action or
process that an object can perform. Methods
are very much like a function or procedure in
a traditional programming language.
A message is the information sent to objects
to trigger methods. Essentially a function or
procedure call from one object to another
object.
Encapsulation /
Information Hiding



Combining of processes and data into a
single object.
All attributes and methods are all
together/incorporated in definition of
object.
Makes it easier to create new object
classes – knows what to do when you
want to create a new patient.
Hierarchical Inheritance




Classes can have “children”
Parent is “base” or “super” class
Child is “derived” or “sub” class
Similar to subtypes and supertypes of
entities.
Polymorphism

The same message can be interpreted
differently by different classes of
objects.
Unified Modeling Language
(UML)


The Three Amigos – Booch, Jacobson,
and Rumbaugh
Objective was to provide a common
vocabulary of object-based terms and
diagramming techniques for any
systems development project from
analysis through implementation.
UML diagrams




9 diagrams
Used throughout SDLC
Use consistent syntax and notation.
Key building block is the use-case.
O-O Diagrams
Use-Case
Captures business requirements for system
Class
Illustrates relationships between classes modeled in system
Object
Illustrates relationships between objects; used when actual
instances of the classes will better communicate the model
Sequence
Models the behavior of classes within a use-case (temporal
sequence)
Collaboration
Models the behavior of classes within a use-case (nontemporal sequence)
Statechart
Examines the behavior of one class within a use-case
Activity
Illustrates the flow of activities in a use-case
Component
Illustrates the physical structure of the software
Deployment
Shows the mapping of software to hardware components
Use-Case


Requires you to break system into use
cases, small logical pieces of the system
and deal with each separately.
In contrast, DFDs and ERDs encompass
the entire system in one diagram.
Use-Case Diagrams



Graphical specification of the system’s
behavior from the perspective of the user(s).
Describes what the system does without
describing how the system does it.
They are used to identify and communicate
the high-level business requirements for the
system.
Patient Admission System



A patient will call in to schedule an appointment or cancel an
appointment. The office employee should be able to look up the
patient’s name to determine if this is an existing patient. The office
employee should also be able to lookup any existing unpaid bills the
patient may have with the doctor’s office. The system will look up
available times and dates for an appointment. When a day/time works
for the patient, the system will add a new appointment.
Before available days and times can be recorded, an employee of the
doctor’s office will need to create a master schedule. This master
schedule will list all the doctor’s schedules and the days and times the
office will be open for appointments.
A doctor can alter his or her schedule. When this occurs, the doctor
will inform the employee of any days/times when he/she is not
available. In addition, the doctor can add days/times when he/she is
available to see patients.
Use-Case contains:




Actor
Event/Use Case
Association
System boundary
Example!

Patient Admission system
Example – Student fitness class



When a student wants to add a new class, the manager will
check the fitness class schedule for availability. The manager
will notify the student of an opening, and the student will pay
the fee if there is an opening. The student is then registered for
the class.
As new instructors are hired, their availability to teach a class
will be recorded. Information on the type of class the instructor
is certified to teach as well as the times he/she is available is
recorded.
At times, the fitness class schedule must be changed. When
this occurs, the manager will change the fitness schedule, and
will then notify the instructors and students who are affected by
the change.
Another example –
Placing an order over the internet

Using the web, customers should be able to search
for products and identify if the item is available.
They should be able to order the item. The
functionality that the system should have is listed
below:





Search through the inventory of products
Place an order
Receive marketing material on all products
User should be able to place item into shopping cart
User should be able to provide customer information
including billing information.
Steps in creating a Use-Case





1. Identify use-cases (find major
functions)
2. Draw the system boundary
3. Place use-cases on the diagram (6-8
use-cases per diagram)
4. Identify the actors
5. Add associations
In addition…


Text documents to document use-cases since
use-case diagram does not describe how
those use cases are carried out by the actors.
When describing the use-case, you should
focus on its external behavior – how it
interacts with the actors, rather than how the
use case is performed inside the system.
Steps in Documentation




1. Create a use case template that has
areas labeled Basic Course and
Alternative Courses.
2. Ask “What happens?”
3. Ask “And then what happens?”
4. Ask “What else can happen?
Documentation examples



Patient Admission
Student fitness registration
Placing a special order
Documentation

1.
Documentation

1.
TIPS





Think usage scenario rather than
functional requirements.
Describe usage rather than attributes
and methods.
Don’t write use-case too tersely.
Don’t ignore system responses.
Don’t forget alternative courses of
action.
Includes statement


When one use-case needs to use
another use-case
Two types


Internal – only other use-cases reference
Both external actors and internal use-cases
reference
Examples


Order Entry
Appointment scheduling
Class Diagrams



Static Model
During analysis, classes refer to the
people, places, events, and things
about which the system will capture
information.
What is this similar to?
Class Diagram vs ERD

What would the class diagram contain
that the ERD does not?
How to Draw the Class


Each class is drawn using three partrectangles.
Let’s draw a class diagram for the
Patient Admission System.
Three kinds of Methods



Constructor
Query
Update
Relationships in Class Diagram


Again, similar to relationship in ERD.
However, maintained internally by
system rather than by primary keys or
foreign keys.
Multiplicity

Just another name for cardinality

… and a different way to show it
Multiplicity
Instance
Exactly one
Represen- Description
tation
1
A department has one and only one boss.
Zero or more
0..*
An employee has zero to many children.
One or more
1..*
A boss is responsible for one or more
employees.
Zero or one
0..1
An employee can be married to zero or one
spouse.
Specified
range
2..4
An employee can take between two to four
vacations each year.
1..3, 5
An employee is a member of one to three or
five committees.
Multiple,
disjoint range
Creating a Class Diagram



1. Identify classes
2. Identify attributes and methods
3. Draw relationships between the
classes.
For Next Class Meeting…


Read pages 250-263 in book
OO homework 1 DUE