Object Oriented Analysis &

Design
Engr. Abdul-Rahman Mahmood
MS, PMP, MCP, QMR(ISO9001:2000)
armahmood786@yahoo.com
alphapeeler.sf.net/pubkeys/pkey.htm
pk.linkedin.com/in/armahmood
www.twitter.com/alphapeeler
www.facebook.com/alphapeeler
abdulmahmood-sss
alphasecure
armahmood786@hotmail.com

alphasecure@gmail.com
http://alphapeeler.sourceforge.net
http://alphapeeler.tumblr.com
armahmood786@jabber.org
alphapeeler@aim.com
mahmood_cubix
48660186
alphapeeler@icloud.com

http://alphapeeler.sf.net/me

http://alphapeeler.sf.net/acms/

Teaching skills, Project Management

VC++, VB, ASP

Review: Class

Recall, a class is an abstraction

Describes a group of objects with common:

Properties (attributes)
Behavior (operations)
Relationships
Semantics

Class Name
Attributes
Operations

A class is an abstraction in that it

Professor
name
empID
create( )
save( )
delete( )
change( )

Emphasizes relevant characteristics; suppresses others

Consists of the three sections indicated

First section: Class name

Second section: structure (attributes)
Third section: behavior (operations)

For analysis classes, these entries are sufficient!

Review: Use-Case Realization

Use-Case Model

Design Model

Use Case

Use-Case Realization

Sequence Diagrams

Collaboration Diagrams

Use Case

Class Diagrams
Not what we have so far.
These are Design Classes. More later

Review: Use-Case Realization

Remember: a use-case realization describes

how a particular use case is realized within the

Design Model, in terms of collaborating objects.
A use-case realization is one possible realization of

a use case.
A use-case realization in the Design Model can be
traced to a use case in the Use-Case Model.
A realization relationship is drawn from the use-case
realization to the use case it realizes.

A use-case realization can be represented using

set of diagrams (the number and type may vary)

Different organizations may have their own way

of doing these things(and naming them)

Review: Use-Case Realization

The diagrams that may be used to realize a use

case realization may include:

Interaction Diagrams (sequence and/or

collaboration diagrams) can be used to describe

how the use case is realized in terms of collaborating
objects.
These diagrams model the detailed collaborations
of the use-case realization.
Class Diagrams can be used to describe the classes
that participate in the realization of the use case, as
well as their supporting relationships.
These diagrams model the context of the use-case
realization.

Review: Use-Case Realization

In our Use Case Analysis step, the use-case

realizations' diagrams are outlined.

Exactly what this entails will be discussed ahead and

form part of the fourth deliverable.

In subsequent design activities (Use-Case Design)

these class diagrams will be considerably refined

and updated according to more formal class
interface definitions.

 A designer: responsible for the integrity of the

use-case realization.
Must coordinate with the designers responsible
for the classes and relationships employed in the
use-case realization.
The use-case realization can be used by class

designers to understand the classs role in the

use case and how the class interacts with other
classes.
This implies that a team will/may distribute

responsibilities for each class to developers.

This information can be used to determine/refine

the class responsibilities and interfaces.
Lets find the classes from different behaviors the
classes must provide

Identifying Candidate Classes from Behavior

Will use three perspectives of the system to identify
these classes.
The boundary between the system and its actors
The information the system uses
The control logic of the system

Will use stereotypes to represent these perspectives

(boundary, control, entity)

These are conveniences used during analysis that will

disappear or be transitioned into different design elements

during the design process.

Will result in a more robust model because these are the

three things that are most likely to change in system and
so we isolate them so that we can treat them separately.
That is, the interface/boundary, the control, and the key

system entities..

Find Classes From Use-Case Behavior

The complete behavior of a use case has to be
distributed to analysis classes
We must identify these classes identify, name,
and briefly describe in a few sentences.
<<boundary>>

<<control>>

<<boundary>>

<<entity>>
<<entity>>

Discovering Classes
Analysis classes represent an early conceptual model for

things in the system which have responsibilities and

behaviors.
Analysis classes are used to capture a first-draft, rough-

cut of the object model of the system.

Analysis classes handle primary functional requirements,

interface requirements, and some control - and model

these objects from the problem domain perspective.

Kinds of Analysis Classes

Three things likely to change in a system:

The boundary between the system and its actors

(interfaces)
The information a system uses (data), and
The control logic of the system (who does what)

So, we isolate the different kinds of analysis classes

Each of these has a set of canned duties &

responsibilities
Again, the distinction between these classes is used in
analysis but goes away in design or becomes less of an
issue, as we transition these analysis classes into design
artifacts / design entities to accommodate the problem
domain representations in a solutions space.

What is an Analysis Class?

Can use with the name of the stereotype
In guillemets or as symbols with unique icons.
<<boundary>>

Finding a candidate set of classes is the first

part of transforming a mere statement of
required behavior to a description of how the
System will work.
<<control>>

System
boundary

Use-case
behavior
coordination

System
information

<<entity>>

Analysis Classes - Early Conceptual Model

The analysis classes, taken together, represent an early

conceptual model of the system.

This conceptual model evolves quickly and remains
fluid for some time as different representations and
their implications are explored.
Analysis classes are early conjectures of the composition
of the system; they rarely survive intact into
implementation.
Many of the analysis classes morph into something else
later on (subsystems, components, split classes,
combined classes).
They provide us with a way of capturing the required
behaviors in a form that we can use to explore the
behavior and composition of the system.
Analysis classes allow us to "play" with the distribution
of responsibilities, re-allocating, as necessary.

Analysis Classes: A First Step

Towards Executables

Use Cases Analysis Design

Classes Elements

Source
Code

Use-Case Analysis
(from a structural perspective; static)

Exec

What is a Boundary Class?

Insulates the system from changes in the outside

Several Types of Boundary Classes
User interface classes classes that facilitate

communication with human users of the system

Menus, forms, etc. User interface classes.
System interface classes classes which facilitate
communications with other systems.
These boundary classes are responsible for managing the
dialogue with the external system, like getting data from
an existing database system or flat file
Provides an interface to that system for this system
Device Interface Classes provide an interface to devices
which detect external events like a sensor or
One boundary class per use case/actor pair
Analysis class
stereotype

<<boundary>>

The Role of a Boundary Class

<<boundary>>

Actors can only communicate with boundary classes.

Boundary classes identify the systems boundaries.

<<control>>
<<boundary>>

Customer

External
Database??

<<boundary>>

<<entity>>

<<entity>>

A boundary class is a class used to model interaction between the systems surroundings
and its inner workings; Involves transforming and
Boundary Classes model parts of the system that depend on its surroundings. Entity
and control classes model parts that are independent of the systems surroundings.
Examples of boundary classes: Classes that handle GUI or communications protocols.

Boundary Classes - more

Identify boundary classes for things mentioned in

the flow of events of the use-case realization.
Consider the source for all external events and
make sure there is a way for the system to detect
these
events. (user inputs/responses? Connection to

existing external data)

One recommendation: for the initial identification
of boundary classes is one boundary class per
actor/use-case pair.
This class can be viewed as having responsibility for

coordinating the interaction with the actor.

This may be refined as a more detailed analysis is
performed.
This is particularly true for window-based GUI
applications, where there is typically one boundary
class for each window, or one for each dialog.

Example: Finding Boundary Classes

One boundary class per actor/use case pair:

Student

Register for Courses Course Catalog System

<<boundary>>
RegisterForCoursesForm

<<boundary>>
CourseCatalogSystem

The RegisterForCoursesForm contains a Student's "schedule-in-progress".

It displays a list of Course Offerings for the current semester from which the
Student may select to be added to his/her Schedule.
The CourseCatalogSystem interfaces with the legacy system that provides the

complete catalog of all courses offered by the university.

Guidelines: Boundary Class

User
Interface
classes
User Interface Classes
Concentrate on what information is presented to the user
Do NOT concentrate on the UI details
Analysis Classes are meant to be a first cut at the abstraction

of the system.
The boundary classes may be used as holding places for GUI
classes. (Addressed in much more detail later)
Do not do a GUI design in analysis, but isolate all
environment-dependent behavior. (Likely you may be able
to reverse engineer a GUI component and tailor it.)
The expansion, refinement and replacement of these
boundary classes with actual user interface classes is a
very important activity of Class Design later
If prototyping the interface has been done, these screen
dumps or sketches may be associated with a boundary
class.
Only model the key abstractions of the system not every
button, list, etc. in the GUI.

Guidelines: Boundary Classes

System and Device
System and Device Interface Classes

Concentrate on what protocols must be defined

Note that your application must interface with an

existing information source.
Do NOT concentrate on how the protocols will be
implemented

If the interface to an existing system or device is

already well-defined, the boundary class
responsibilities should be derived directly from
the interface definition.
If there is a working communication with the
external system or device, make note of it for
later reference during design.

What is an Entity Class? (recall: boundary, entity,

control)
Key abstractions of the system
Analysis class
stereotype
Glossary
Sources for entity
Classes:
Glossary
Use-Case Flow of Use Case
Events
Business domain
model
Business-Domain Model
Architectural Analysis
Abstractions

<<entity>>

Entity classes show the

logical data structure,
which will help us
understand what the
system is supposed to
offer to its users.

Environment Independent

Entity Classes
Entity classes represent stores of information in the

system
They are typically used to represent the key concepts the
system manages.
Entity objects (instances of entity classes) are used to
hold and update information about some phenomenon,
such as an event, a person, or some real-life object.
(Chapter advisor, memorabilia, university, student,

correspondence_item, International_Secretary, )

They are usually persistent, having attributes and

relationships needed for a long period, sometimes for the

life of the system.
The main responsibilities of entity classes are to
store and manage information in the system.

The Role of an Entity Class

<<boundary>>

Entity objects can have complicated behavior;

however, unlike other objects, this behavior
is strongly related to the phenomenon the entity
object represents.
<<control>>
<<boundary>>

Customer
<<boundary>>

<<entity>>

<<entity>>

Store and manage information in the system

The values of its attributes and relationships are often given by an actor.
Entity objects are independent of the environment (actors)

Example: Finding Entity Classes

Use use-case flow of events as input
Key abstractions of the use case
Traditional, filtering nouns approach
Underline noun clauses in the use-case flow of events
Remove redundant candidates
Remove vague candidates
Remove actors (out of scope)
Remove implementation constructs
Remove attributes (save for later)
Remove operations

Example: Candidate Entity

Classes
Register for Courses (Create Schedule)
Student
CourseOffering
A person enrolled in classes at the university
A specific offering for a course
including days of week and times
Schedule

The courses a student has selected for current semester

Candidate Entity Classes

Sometimes there is a need to model information

about an actor within the system. This is not the

same as modeling the actor (actors are external.
by definition). These classes are sometimes
called surrogates.
For example, a course registration system
maintains information about the student which is
independent of the fact that the student also
plays a role as an actor of the system.
This information about the student that is stored in a

Student class is completely independent of the actor

role the student plays; the Student class (entity) will
exist whether or not the student is an actor to the

Analysis Classes
Entity class :

Persistent data
(used multiple times and in many UCs)
Still exists after the UC terminates (e.g. DB storage)

Boundary class:
(User) interface between actors and the system
E.g. a Form, a Window (Pane)

Control class:
Encapsulates business functionality
Proposed in RUP (Rational Unified Process)

9-29

Prentice Hall, 2007

9-30

Prentice Hall, 2007

What Is an Analysis Class?

A class that represents initial data and behavior

requirements, and whose software and hardwareoriented details have not been specified
Analysis class diagram a UML diagram showing

analysis classes and their relationships

9-31

Prentice Hall, 2007

Stereotypes of Analysis Classes

Mostly
corresponds to
conceptual data
model classes

9-32

Encapsulates
connections
between actors
and use cases

Prentice Hall, 2007

Mostly performs
behaviors
associated with
inner workings of
use cases

9-33

Prentice Hall, 2007

What Is a Sequence Diagram?

A UML diagram that shows the interaction

between objects to perform critical pieces of use

case behavior in a time-ordered manner
Interactions are in the form of messages
Behavioral responsibilities are assigned to

message recipients

9-34

Prentice Hall, 2007

Messages are passed between objects, and may contain parameters

9-35

Prentice Hall, 2007

Symbols in a Sequence Diagram

Box or class stereotype symbol represents
objects.
Dotted vertical line represents objects lifetime.
Thin bars represent focus of control, periods of
time when object is behaving (fulfilling

responsibilities).

Labeled horizontal lines represent messages

passing between objects.
9-36

Prentice Hall, 2007

9-37

Prentice Hall, 2007

Typically, actors interact with

boundary classes, which in
turn interact with control
classes, which in turn interact
with entity classes.

9-38

Prentice Hall, 2007

What Is Robustness Analysis?

Involves analyzing the narrative text of each of the use
cases and identifying a first-guess set of the objects
into entity, boundary, and control classes
Requires completeness checks and adherence to
diagramming rules

9-39

Prentice Hall, 2007

9-40

Prentice Hall, 2007

What Is a Communication Diagram?

A UML diagram that shows the interactions between

objects to perform critical pieces of the use case

behavior
Unlike sequence diagrams, communication diagrams

have no spatial representation of time; sequences of

messages are shown by numbering.

9-41

Prentice Hall, 2007

9-42

Prentice Hall, 2007

Drawing Analysis Class Diagrams

Analysis classes are completed by including
operations, which fulfill the responsibilities taken by
the analysis class.
In addition, attributes and relationships from the
conceptual data model are retained and refined.

9-43

Prentice Hall, 2007

Operations (behaviors)
are depicted in the
lower third of a class
box.
Operations fulfill the
classs responsibilities.

9-44

Prentice Hall, 2007

EXAMPLE
The UNIVERSITY OF BUTERE (UBT) registration system is

briefly described thus:

You have been asked to streamline, improve, and automate
the process of assigning professors to courses and the
registration of students such that it takes advantage of
prevailing web technologies for on-line real time, location
independent access.
The process begins by professors deciding on which courses
they will teach for the semester. The Registrars office then
enters the information into the computer system, allocating
times, room, and student population restrictions to each
course. A batch report is then printed for the professors to
indicate which courses they will teach. A course catalogue is
also printed for distribution to students.

EXAMPLE
Students then select what courses they desire to take and
indicate these by completing paper-based course advising
forms. They then meet with an academic advisor who
verifies their eligibility to take the selected courses, that the
sections of the courses selected are still open, and that the
schedule of selected courses does not clash. The typical
student load is four courses. The advisor then approves the
courses and completed the course registration forms for
the student. These are then sent to the registrar who keys
them into the registration system thereby formally
registering a student. If courses selected are not approved,
the student has to select other courses and complete the
course advising forms afresh.

EXAMPLE
Most times students get their first choice, however,
in those cases where there is a conflict, the
advising office talks with the students to get
additional choices. Once all students have been
successfully registered, a hard copy of the students
schedule is sent to the students for verification.
Most student registrations are processed within a
week, but some exceptional cases take up to two
weeks to resolve.
Once the initial registration period is over,
professors receive a student roster for each class
they are scheduled to teach.

Analysis Phase Class Diagram

DESIGN PHASE CLASS DIAGRAM