CSUN Information Systems

Systems Analysis & Design

http://www.csun.edu/~dn58412/IS431

Object
Modeling
IS 431: Lecture 6

1
 Object Modeling

Why Object Modeling ?

Object Concepts
Class/Object, Attribute, Behavior, Inheritance,
Encapsulation, Message, Polymorphism
UML Diagrams for Object-Oriented Analysis
Use Case Diagram
Class/Object Diagrams
Sequence Diagram
Statechart Diagram

IS 431 : Lecture 6 2
 Object Modeling
Object-oriented analysis (OOA) techniques are used to (1)
study existing objects to see if they can be reused or adapted
for new uses, and (2) define new or modified objects that
will be combined with existing objects into a useful business
computing application.
Object modeling is a technique for identifying objects
within the systems environment and the relationships
between those objects.
The Unified Modeling Language (UML) is a set of
modeling conventions (notations) to specify or describe
a software system in terms of objects.

IS 431 : Lecture 6 3
 Object Modeling

Benefits:
Break a complex system into manageable components
Create reusable components can be plugged into other
systems or use them as starting points for other projects
Object-think is more realistic !!!

IS 431 : Lecture 6 4
 Object Concepts
An object is something that is or is capable of being
seen, touched, or otherwise sensed, and about which
users store data and associate behavior.
A class is a set of objects that share common
attributes and behavior. A class is also referred to as
an object class.
Attributes are the data that represent characteristics
of interest about an object.
An instance (or object instance) of an object
consists of the values for the attributes that describe
a specific person, place, thing, or event.

IS 431 : Lecture 6 5
 Classes, Objects,
Attributes, & Instances

Customer Doe:Customer Green:Customer

custNo custNo:123 custNo:234
lastName lastName:Doe lastName:Green
firstName firstName:Joe firstName:Mary
phone phone:1234567 phone:3456789
street street:AnyStreet street:OtherStreet
city city:AnyCity city:OtherCity
state state:AnyState state:OtherState

changeAddress() changeAddress() changeAddress()

IS 431 : Lecture 6 6
 Object Concepts

Behavior (method, service) refers to those activities

that the object can do and which correspond to
functions that act on the objects data (or attributes).
Encapsulation is the packaging of data and method
together. It shields the internal working of the object
from the changes in the outside system. It keeps the
system from being affected when changes are made
to objects. It is the key to reusability.
All an object needs to know is the set of methods that
other objects can perform and what message need to be
sent to trigger them.

IS 431 : Lecture 6 7
 Common Methods

Constructor to create a new instance of a class

Query to access and get info about the state of an
object but does not alter the state
Update to alter the state of an object and change the
value of its attribute(s).

IS 431 : Lecture 6 8
 Supertypes & Subtypes
A class supertype is an object class whose
instances store attributes that are common to one or
more class subtypes of the object.
A class subtype is an object class whose instances
inherit some common attributes from a class
supertype, and then add other attributes that are
unique to an instance of the subtype.
Inheritance means that methods and/or attributes
defined in an object class (superclass) can be
inherited or reused by another object classes
(subclasses).

IS 431 : Lecture 6 9
 Generalization
Specialization
Employee
Name
DOB
SSN
DateHire
CalSeniority()

Executive Foreperson Worker

Factory Factory
Position Station Station
Location DateAppoint Machine
DateAppoint Wage Rate
Salary Wage Rate
Update() Update() Insert ()

IS 431 : Lecture 6 10
 Object Concepts
Message is the information passed when one object
invokes one or more of another object's methods
(behaviors) to request information or some action
(It is function calling in programming)

Order
Customer OrderNo
displayStatus(123) OrderDate
OrderStatus

add()
change()
displayStatus()

IS 431 : Lecture 6 11
 Object Concepts
Polymorphism means many forms. In object-
oriented techniques, it means that the same message
can be interpreted (and a behavior may be completed)
differently by different objects/classes.
Methods of the same name in different classes.
Methods of the same name (but different parameters) in
the same class
Insert(customer) is different from insert(inventory-item)
as different info need to be collected and stored.

IS 431 : Lecture 6 12
 Object-Oriented Analysis
with UML Diagrams
Modeling the functions of the system (with a use
case diagram).
Modeling the objects within the scope of the
system and their relationships (with class and
object diagrams for each use case, and then for
the integrated system).
Modeling the interactions between objects to
complete a function/use case (with a sequence
diagram for each use case).
Modeling the behavior / logic of the objects (with
a statechart diagram for each complex class).

IS 431 : Lecture 6 13
 UML Diagrams
USE CASE DIAGRAM CLASS DIAGRAM FOR USE CASE
Create New Order
Enter New Customer CUSTOMER

ORDER

Create New Order

Order Clerk
SHIPMENT

:customer :order :shipment

SEQUENCE DIAGRAM
Create Order
Order Clerk Create Shipment FOR USE CASE Create
New Order

CREATE ORDER CREATE SIPMENT STATECHART DIAGRAM

FOR OBJECT Order

IS 431 : Lecture 6 14
 Use Case Modeling
Use case modeling is the process of modeling a systems
functions in terms of business events, who initiated the
events, and how the system responds to the events.
A use case is a complete sequence of related actions (a
scenario), both automated and manual, for the purpose of
completing a business function: What the system must do.
An actor represents an external entity that needs to interact
with the system to exchange information. An actor is a user,
a role, which could be an external system as well as a
person.
A temporal event is a system event that is triggered
by time. (The actor of a temporal event use case is
time.)
IS 431 : Lecture 6 15
 USE CASE DIAGRAM
Use Case Diagram is a functional description (use cases,
actors) of the entire system: functions being supported by the
system
Use Case Diagram is similar to Context Diagram + Level-O
DFD in traditional structured technique:
An individual Use Case appears more like a DFD fragment as it
identifies an individual function (major process)

In Use Case Diagram, an actor is the one who actually interacts with
the system, whether that actor is the original source of information or not
(in DFD, an external agent is always the source or destination of info
and may not necessarily be the one interacting with the system.)
Use Case Diagram does NOT indicate data flows or flows of
information in and out the system (they are identified later in interaction
diagrams)
IS 431 : Lecture 6 16
 A Use Case Diagram
Order Subsystem Subscription Subsystem

Maintain Member Submit Change of Submit New Potential Member

Order Address Subscription initiates
initiates
Club Member
initiates
Place New initiates Submit
Member Order Resubscription

initiates initiates
Make Purchase Submit Past Submit New Past Member
Inquiry Member Member
Resubscription Subscription
Program Program

initiates
Operations Subsystem Promotion Subsystem
initiates initiates

Make Account Generate Quarterly

Inquiry Membership
Analysis initiates Time Marketing

Generate Annual Generate Quarterly Submit New

Sales Analysis initiates initiates Promotion Analysis Promotion initiates

initiates initiates
Generate Quarterly Generate Annual
Sales Analysis Membership
Analysis

IS 431 : Lecture 6 17
 Extension and Abstract
Use Cases
An extension use case extends the functionality of
an original use case to add new behaviors or actions
to the basic course. An extension use case can only
be invoked by the use case it is extending.
An abstract use case contains typical course steps
that were common to two or more original use
cases. An abstract use case reduces redundancy and
promotes reuse.

IS 431 : Lecture 6 18
 Extension Use Cases
(extend relationship)

Class registration

<<extend>> <<extend>>

Registration for Insufficient

special classes prerequisites

Class registration is the basic course of actions.

On special occasions, Registration for special classes
and/or Insufficient prerequisites will be invoked.
Special cases add new data/behaviors to the normal case.
IS 431 : Lecture 6 19
 Abstract Use Cases
(use or include relationship)

Reorder supplies

<<include>>

Track sales & inventory

<<include>>

Generate reports

Reorder Supplies uses Track sales & inventory

Generate reports uses Track sales & inventory.
In programming, it is a common subroutine.
IS 431 : Lecture 6 20
 Building a Use Case
Diagram
Identify use cases (major system functions)
Identify the system boundary
Identify associations between use cases
(extends, includes) for special cases or common
subroutines
Identify actors (look at the sources and
destinations of major inputs and outputs)

IS 431 : Lecture 6 21
 CLASS / OBJECT DIAGRAMS

Class: a set of objects sharing a common structure

and a common behavior (Student).
Class Diagram: showing the static structure of OO
model: classes, their internal structure, and the
relationships.
Object Diagram: showing the graphs of object
instances (class members) of a given class diagram:
Marie:student (identified object) or :student
(unidentified object).

IS 431 : Lecture 6 22
 A Class Diagram
Member
Member-Number
Member-Name
Member-Status
Member-Street-Address
Member-PO-Box
Member-City
Member-State
Member-Zip-Code

persistent

Product
Product-Number
UPC-
Quantity-In-Stock
Product-Type
Suggested-Retail-Price 1
Default-Unit-Price
Current-Special-Unit-Price
Current-Month-Units-Sold
Current-Year-Units-Sold
Total-Lifetime-Units-Sold
persistent
<<actor>> <<actor>>
Potential Member Club Member <<actor>>
Past Member
Member-Date-Of-Last-Order Expiration-Date
Member-Daytime-Phone-Number Agreement
persistent Member-Credit-Card-Expire-Date
Member-Credit-Card-Number Agreement-Number
Member-Credit-Card-Type persistent Agreement-Expire-Date
Member-Balance-Due Agreement-Active-Date
Member-Bonus-Balance-Available
1..* Fulfillment-Period
Audio-Category-Preference Required-Number-Of-Credits
Audio-Media-Preference
Has 1 Date-Enrolled binds
purchased Email-Address 1 persistent
Game-Category-Preference
0..* Game-Media-Preference
Member Ordered Product Number-Of-Credits-Earned
Privacy-Code
Quantity-Ordered Video-Category-Preference
Video-Media-Preference Transaction
Quantity-Shipped 1
Quantity-Backordered Conduct Transaction-Reference-Number
Sold as Purchase-Unit-Price
Credits-Earned persistent
s Transaction-Date
Transaction-Type
0..* Transaction-Description
0..* Transation-Amount
persistent 1
1..* persistent
Places

0..*
Member Order Return
Sells
Merchandise 1 Order-Number
Title Order-Creation-Date
Promotion Order-Fill-Date persistent
Merchandise-Name Title-Of-Work Shipping-Address-Name
Merchandise-Description Title-Cover 1..* Promotion-Number Shipping-Street-Address
Merchandise-Type Catalog-Description Promotion-Release-Date Generate Shipping-City
Unit-of-Measure Copyright-Date Feature Promotion-Status 0..1 s Shipping-State
Entertainment-Company 0..* Promotion-Type Shipping-Zip-Code
Credit-Value s 0..* Shipping-Instructions
persistent Order-Sub-Total
Order-Sales-Tax
persistent Order-Shipping-Method
persistent Order-Shipping-&-Handling-Cost
Order-Status
Order-Prepaid-Amount
Order-Prepayment-Method

persistent
Audio Tilte Video Title Game Title
Artist Producer Manufacturer
Audio-Category Director Game-Category
Audio-Sub-Category Video-Category Game-Sub-Category
Number-Of-Units-In-Package Video-Sub-Category Game-Platform
Audio-Media-Code Closed-Captioned Game-Media-Type
Content-Advisory-Code Language Number-Of-Players
Running-Time Parent-Advisory-Code
Video-Media-Type
persistent Video-Encoding
Screen-Aspect
MPA-Rating-Code persistent

persistent

IS 431 : Lecture 6 23
 Object/Class Relationships

An object/class relationship is an association that

exists between one or more objects/classes. It is
defined by business rules and/or common practices.
Multiplicity defines how many instances of one
object/class can be associated with one instance of
another object/class. (It is Cardinality in ERD !!!)

places
0..*
Customer Order

IS 431 : Lecture 6 24
 UML Multiplicity Notations
UML Association
Multiplicity Multiplicity Association with Multiplicity Meaning
Notation
Works for 1
1 Employee Department
An employee
Exactly 1 or works for one
Works for
and only one
leave blank Employee Department
department.

Has 0..1 An employee has

Zero or one 0..1 Employee Spouse either one or no
spouse.

Makes 0..*
0..* Customer Payment
A customer can
Zero or or make no payment
more Makes * up to many
payments.
* Customer Payment

Offers 1..* A university

One or more 1..* University Course offers at least 1
course up to
many courses.
Has
Specific scheduled 7..9 A team has either
range 7..9 Team Game 7, 8, or 9 games
scheduled

IS 431 : Lecture 6 25
 Aggregation
Relationship

Operation Team

Doctor Nurse Admin staff

is a part of, is made of relationships

IS 431 : Lecture 6 26
 Generalization
Relationship

Employee

Doctor Nurse Admin staff

-is a kind of relationships

- Showing inheritance (type/subtypes)

IS 431 : Lecture 6 27
 Building a Class Diagram
Identify related classes. A class diagram show the
classes that are needed for one particular use case,
(not for the whole system as in integrated class
diagram).
Identify attributes and operations. List only
peculiar, special methods (calculateTax) of the
class, not the implicit methods (insert).
Identify relationships and multiplicity between
classes. Make use of generalization and aggregation
relationships if possible.

IS 431 : Lecture 6 28
 SEQUENCE DIAGRAM
A Sequence Diagram depicts the interactions among
objects of a use case during a certain period of time. It gives
an external view of object behaviors.
A sequence diagram represents a specific set of messages
(function calls) and interchanges between objects. Thus,
objects are indicated on the diagram instead of classes.
Each actor and object has a lifeline (from top to bottom)
that shows the sequence of message.
The activation lifeline shows time period during which
the object perform an operation. The X mark at the end of
the activation line indicate the point at which the object
ceases to exist in the system.
IS 431 : Lecture 6 29
 SEQUENCE DIAGRAM
A message symbol in a sequence diagram has 2 parts:
A directional arrow
A message descriptor in the form of:
[true/false condition] return-value:= message-name (arguments)
Sometimes, one can use a return arrow if the return value is not
very important

IS 431 : Lecture 6 30
 A Sequence Diagram
Template for a Use Case

Actor :object 1 :object 2

message 1
message 2
message 3

IS 431 : Lecture 6 31
 A Sequence Diagram

:order- :member :order :orderedProduct

:product
Clerk

verify member
(member number)
display member information

update address (address)

select new order

enter item (product number)

create item
validate item

IS 431 : Lecture 6 32
 Building a Sequence
Diagram
Identify objects and the sequence that these objects
interact with each other in each use case.
Identify message (function call) and the sequence
Draw lifeline and activation boxes (how long we
want to keep the class/program active in the system)

IS 431 : Lecture 6 33
 STATECHART DIAGRAM

A Statechart Diagram describes the internal

working of an object when it receives a message.
Each class in the class diagram for a system has its
own unique state diagram.
An object comes into existence within the system in
some manner. During its existence, it is in certain
states, and makes transitions from states to states. An
object remains in a state until some event causes it to
move to another state.

IS 431 : Lecture 6 34
 STATECHART DIAGRAM

A state for an object is a situation during its life

when it satisfies some condition, performs some
activity, or waits for some event. (A set of values that
describe an object at a specific point in time)
An event is something that takes place at a certain
point in time and changes value(s) of an object, (which
in turn changes the objects state).
Transition is the mechanism that causes an object to
leave a state and change to a new state.

IS 431 : Lecture 6 35
 A Statechart Diagram
Template for an Object

Event 1 State 1 Trans 1 State 2

Internal Trans Internal Trans
Init state
Trans 2
Final state

Trans 3

State 3 Event 2
Internal Trans Final state

IS 431 : Lecture 6 36
 A Statechart Diagram
Order Backordered

Not all product Product received

available
Order pending awaiting payment or additional member information
Member Order Order submitted In Process Pending
initial state
Response received from member
Order released
to the warehouse

Order Released Order filled by the warehouse Order Filled

Order shipped to club member

Order rejected based on Member's past history
Order Invoiced Order Shipped
Invoice sent to member for payment

Final payment received

Order Closed
Member Order final
state

Member order archived after 90 days

Member Order final

state

IS 431 : Lecture 6 37
 Building a Statechart
Diagram
Examine the class diagram and identify which
classes must undergo a complex series of state
changes and build a statechart diagram for each of
them (classes).
Identify the various states that an object will have
over its life time
Determine what causes each state to occur (change)

IS 431 : Lecture 6 38