Agenda
Announcements
Review Introduction ot Objects
Chapter 11 material – Object Modeling
15 Minute Break
Announcements
The IT Club has arranged for a guest speaker
Informal presentation regarding Software
Industry in BiH
http://www.infostudio.ba
Saturday November 29th at 12:00 RSVP to [email protected] Question and Answer Session
PMI Meeting was small but productive
Review: Introduction to Objects
An object is a collection of attributes (state) and methods
that operate on those attributes (behavior).
Inheritance: objects can inherit attributes and methods
from other objects
Polymorphism: Selecting the method appropriate for the
class of object called. One construct can take many forms.
Encapsulation: the inclusion of many features in one object.
This provides data protection and abstraction. The data and methods are stored together.
Method: a feature that describes programs within an object.
Review: Introduction to Objects
Instantiation: creating an object
Class: a blueprint for an object; a generic
definition of an object
Abstract Class: a class that cannot be
instantiated
Extends: classes and objects extend other
classes and objects. This is the mechanism of inheritance.
If a class extends another class, it is a
Chapter 11
Object modeling combines processes, data, and
flows into one modeling paradigm.
This allows objects to be modeled as independent
entities and flexibly combined into systems.
The encapsulation of data and processes means that
objects can be designed independently of each other
We can specify interfaces only in order to build the
Chapter 11: UML
UML – Unified Modeling Language
UML combines aspects of ERD and DFD into
one unified model
UML provides the following types of diagrams:
Use case diagrams
Object class diagrams
Sequence diagrams
Transition diagrams
Chapter 11: Objects
Associations
How are two objects related?
Example: people manage projects
Composition
Objects are made of many other kinds of objects
Example: a project is made of many project
tasks
Inheritance
Objects can be defined in terms of other objects
Chapter 11: Object Class Diagrams
Object Class Diagram is a diagram that
shows object classes and relationships
between them. You will also see this referred
to simply as a class diagram.
Class Name Properties Methods
UML notation is commonly used for object
Chapter 11: UML Notation
PROJECTS
PROJECT-ID: string; MANAGER: string; START-DATE: date; BUDGET: real; PEOPLE-ASSIGNED(N):PERSONS; TASKS(N): PROJECT-TASKS; Add-project(project-no); Delete-project(project-no); Create-task(task-name,task-details); Change-budget(new-budget); a87: PROJECT
PROJECT-ID: a87; MANAGER: Melissa; START-DATE: 10-7-98; BUDGET: 45000.00;
PEOPLE-ASSIGNED(N):{Mary, Lin};
TASKS(N): {task20, task31}; Add-project(project-no);
Delete-project(project-no); Create-task(task-name,task-details);
Change-budget(new-budget);
Chapter 11: Object Class Diagram
PROJECT S
WORK
PERSON S
PROJECT -TASKS
MANAGER
1
1..*
0 .. * manage 1
work-in
1..* 1..*
Compositio n
Association Association
Chapter 11: Object Class Diagram
PROJECTS
PROJECT-NO: integer; MANAGER: PERSONS; START-DATE: date; BUDGET: 120000-00;
PEOPLE-ASSIGNED(N):PERSONS; TASKS(N): PROJECT-TASKS; Add-project(); Delete-project(); Create-task(); Change-budget(); PERSONS
SURNAME: string; DATE-OF-BIRTH: date; DATE-JOINED: date; POSITION: integer; PAY-RATE: number;
ASSIGNED-TO(N): PROJECTS; Add-person();
Delete-person(); Create-task(); Change-budget();
TASKS
TASK-NO: 4;
DATE-SET-UP: 20-6-97; DESCRIPTION: write-program;
PROGRESS: ref DOCUMENT; Update-progress();
manage
work-in
Chapter 11: Object Class Diagram
TASKS LOCAL-TASKS OUTSOURCE D-TASKS TASKSTASK-NO: integer; DATE-SET-UP: date; DESCRIPTION: string; STATUS: string;
COST-TO-DATE: real; Update-progress();
LOCAL-TASKS
TASK-MANAGER: string; PERSONS(N): string; record-time-spent(); update-cost();
OUTSOURCED-TASKS
ORGANIZATION: string; CONTRACT-NO: integer; CONTRACT-RATE: integer; get-report();
update-cost();
Chapter 11: Object Modeling
Object Modeling and Analysis follows many of the
following steps prior to creating object class diagrams:
Use cases and use case models Sequence Diagrams
Transition Diagrams Event Flow Diagrams Collaboration Diagrams Object Class Diagrams
Important: different books use different names and
Chapter 11: Use Cases
Use cases revisited A use case describes the steps that people
follow in carrying out a system activity.
We can build a use case model from these
cases.
A use case model shows all the use cases and
the actors in each use case.
Each use case has two major components:
Script
Chapter 11: Use Cases
The use case script is an informal description
of the steps followed in an activity.
In some development practices, use case
scripts are written on index cards.
Use case – Using the ATM
A greeting message is waiting on the ATM
The customer inserts their card into the machine The ATM asks the customer for their PIN
Chapter 11: Use Cases
Each alternative set of events is a new use
case
What if the card is not accepted?
What if the customer enters the incorrect PIN? What if the withdrawal is too large?
What if the customer stops the process and
withdraws the card?
Each of these situations would require a new
Chapter 11: Use Case Model
Customer
Operator
Withdraw Cash
Transfer funds
Deposit funds
Get Report
Bank System
Chapter 11: Use Cases
Develop project
plan Produce
budget report
Produce budget
<<uses>>
<<uses>>
Classify expenditure
by task
<<extends>>
Chapter 11: Object Analysis
After we build our use case model, what next?
It is often too difficult to jump directly to
object class diagrams
If you feel that the use cases do not provide
enough information to construct quality object class diagrams then consider using:
Chapter 11: Sequence Diagram
Sequence diagram shows dynamic
relationships between objects.
They model messages exchanged between
objects in a use case.
Each object is drawn as a vertical line
Messages between objects are shown in their
time sequence from top to bottom
Chapter 11: Sequence Diagram
Customer ATM Bank System
Customer Card
Request for PIN
PIN
PIN and Card info
PIN OK w/ Accounts
Account Numbers
Selected account
Chapter 11: Transition Diagram
Another way to model use case dynamics
Each circle or ellipse represents the state of the
object
States change as the result of a message
State changes are shown with arrows labeled by
the message that caused the change of state
Chapter 11: Transition Diagram
Idle Readin g Card Waitin g for PIN Ask bank to check PIN Waiting for authorit y from bank Display accoun ts Waiting for selectio n Displa y limits Waiting for selectio n Print Receipt and give cash ReceiptCard RequestPIN PIN entered
Request security check
PIN OK w/ Accounts
Accounts Account selected
Limits
Chapter 11: Event Flow Diagram
Event Flow Diagrams bring all sequence
diagrams together into one diagram
All objects in the sequence diagrams appear
only once in the event flow diagram
All messages are shown in the event flow
diagram
The messages are grouped by direction of flow We now have all of the information needed to
design the object class
Collaboration diagrams are similar to Event
Chapter 11: Event Flow Diagram
CUSTOMER get-PINrequest; get-accounts; get-limits; get-receipt; ATM get-card; get-PIN; get-account; get-amount; get-PINOK; get-limits; get-approval; BANK SYSTEM get-PINandCard; get-selection; get-amount; Customer inserts card Customer inserts PIN Selected account amount Request PIN Display accounts Display limits ReceiptPIN and Card information Selected account amount
Chapter 11: OOSE
These methods are part of Object-Oriented
Software Engineering
OOSE emphasize use cases
All other OOSE models depend on Use Case Model
Domain Object Model - defines standard terms
Analysis Model
Design Model
Implementation Model
Testing Model
OOSE is well-suited to rapid application
development
Chapter 12: Object Analysis
How do we proceed with Object-oriented
analysis?
Use a model as the foundation for defining objects
Rich picture – pictorial representation of a system
Start with use cases and define objects with
techniques in Chapter 11
Use case model
Sequence Diagrams Transition Diagrams Event Flow Diagrams
Chapter 12: Object Analysis
Validation and Verification
Good Naming Conventions – Consistent across
diagrams
Each use case and exception must have a unique
name
Each alternative and exception must have its own
sequence diagram
An event flow diagram must have all objects and
messages from all sequence diagrams
An object class must have
A method for each incoming message
Chapter 12: Object Analysis
Defining object classes
Each object in event flow diagram becomes object
class
Each exchange of messages becomes and association Each parameter in a method becomes a property
Each incoming message becomes a method
Refining object classes
Remove redundant properties
Identify additional relationships between object classes
Group properties
Discover new object classes through inheritance and
Chapter 12: Object Analysis
Refining methods
Can methods be broken down?
Add methods to create and delete objects Create internal methods where needed
Refactoring
Refactoring is changing code in a way that
improves software design without changing functionality
Refactoring is a very big part of OOSE Refactoring is a critical part of software
Bibliography
http://atlas.kennesaw.edu/~dbraun/csis4650/
A&D/UML_tutorial/index.htm
Excellent UML Tutorial with additional
references
http://atlas.kennesaw.edu/~dbraun/csis4650/
A&D/UML_tutorial/resources.htm
Martin Fowler, Kendall Scott: UML
