Object Oriented in Design

I
 Introduction
• Definition of Object
• An object is a self-contained entity/package with well-defined
characteristics (properties or attributes) and behaviors (operations).
• Example of real-life objects include: School, Teacher, Client, Course,
Account,
etc.
Object
classification
Domain Models/Conceptual model
OOD is concerned with creating a description of the domain
(concepts) from the perspective of classification by objects.

A decomposition of the domain involves an identification of the

concepts, attributes, and associations that are considered
noteworthy.

 The result can be expressed in a domain model (previously called

Conceptual Model).
 Definition of Domain
Model
• Captures the most important types of objects in a system.
• Describing “things” in a system and how these things are related to
each other.
• A “thing” can be an object, a class, an interface, a package or a
subsystem, which is
•part of the system being developed.
•Very important process because it is employed throughout
the entire system development life cycle.
Definition of Domain
Model Things / object -> interact
object, a class,
an interface,
package or
subsystem,

Syste
m
Characteristic of the Domain Modeling

• Association and relationship between concepts (e.g Payment PAYS- FOR Sales).
• Attributes for information content (e.g. Sale records DATE and TIME).
• Does not include operations / functions.
• Does not describe Software Classes
• Does not describe Software Responsibilities.
What are Concepts and Conceptual Classes?

Concept: is an idea, thing, or object has S a le

c o n c ep t's s y m b o l

symbol, intension, and extensions. date

time

 Symbol --words or images representing a concept

"A sale rep resents the event of a c o n c ep t's in te n s io
purchase tr ansactio n. It n

 Intention --the definition of a concept h a s a d a te a n d time ."

 Extension --the set of examples to which the

concept applies. sa le -
1
sa le -
c o n c ep t's e x ten s io
sa le - 2 n
3

sa le -
4

7
Class
diagram
• A diagram that describe the structure of a system by showing
the system’s:
• classes
• its attributes and operations
• relationships between the classes.
• their name will never be “imperative procedural name”
HOW TO CREATE A
DOMAIN
MODEL?
Expanded
Steps:
A recommended flow for domain modeling is shown below in sequential
order:
1. Prepare problem statement for the system being developed.
2. Identify objects.
3. Develop data dictionary.
4. Identify association between classes.
5.Identify attributes of classes and association classes.
6.Verify access paths for likely queries.
7. Iterate and refine the model.
 Brief Guideline: How to Create
a Domain Model?
• Find the conceptual classes (see a following guideline).
Step 1:

• Draw them as classes in a UML class diagram.

Step 2:

• Add associations
Step 3:

• Add attributes.
Step 4
 Guideline: How to Create
a Domain Model?
• Find the conceptual classes
• using the concept category list and noun phrase identification
Step 1: • related to the current requirements under consideration.

• Draw them as classes in a UML class diagram.

Step 2:

• Add associations to record relationships (for which there is a need to preserve some memory)
Step 3:

• Add attributes (to fulfill the information requirements)

• UML static structure is being used as “concept” to refer to real-world things, and
“class” will be used to refer to software specifications and Implementations
(design class).
1: Finding Conceptual Classes with Noun
Phrase Identification
 Expanded use cases are good candidates for nouns based concept or attribute

Typical Course of Events System Response Actor

Action

Register Attribute
1.This use case begins when
Attribute Customer arrives at the
POST checkout with items
tto purchase.
2. The Cashier records the 3. Determines the item price and
universal adds the item information to the
product code (UPC) from each item. running sales transaction. →
If there is more than one of an event
item, the Cashier can enter thee
The description and price of the
quantity as well.
current item are presented.
Step 2: Find and Draw Conceptual Classes

The Point-of-Sale Domain Model (concepts only: in UML static

structure) Customer
Sal Cashier
e CashPayment

SalesLineItem Store
Item
Sale Cashier CashPayment Customer

SalesLineIte Store ProductDescriptio

m n

Register ProductCatalog Item

Step 3:Identify Associations between
Classes
Association is a relation b/w concepts that indicates some meaningful and interesting
connection
 UML Association -"direction reading arrow"
-has n meaning except to indicate direction
reading
of o the association label
-often excluded

Inherently bi-directional

POST Records-current Sale

1 1

association name
multiplicity

•Not a statement about connection b/w s/w entities (not implementation guide).

19
 Naming Associations
1. based on a TypeName-VerbPhrase-TypeName format

2. Verb phrase creates a sequence that is readable and

meaningful

3. verb phrase should have –default direction left-right or top-

bottom
Types (if against the default direction, readability arrow must be there)

20
Class
diagram
How to make a Design Class Diagram (DCD)?

Identify Classes
• Identify all the classes participating in the SW solution by
analyzing the interaction diagrams.
• Draw them in a class diagram.

Add Attributes (From Domain Model)

• Duplicate the attributes from the associated concepts in the
domain model.

Add Methods/Operations
• Add method names by analyzing the interaction diagrams.

Elaborate Attributes
• Add type information to the attributes and methods,
constrains.
Attribut
e
Attributes as Attribute Text vs. Association Line

• The full format of the Attribute Text Notation is:

• Visibility name : type multiplicity = default {property-string}
• Attribute-as-Association Line has the following style:
• a navigability arrow pointing from the source (Register) to
target (Sale) object, indicating a Register object has an
attribute of one Sale
• a multiplicity at the target end, but not the source end
• a role name (currentSale) only at the target end to show the
attribute name
• no association name
Attribute text versus association line notation for
a UML attribute
32 Applying the guidelines to show attributes in two notations

•Use the attribute text notation for data type objects and
the association line notation for others.
• Both are semantically equal
• Showing an association line to another class box in the
diagram gives visual emphasis
• it catches the eye
• Emphasis on the connection between the class of objects on
the diagram.
constrains
Constraints
• Constraints may be used on most UML diagrams, but are especially common
on class diagrams.
• A UML constraint is a restriction or condition on a UML element.
• It is visualized in text between braces;
• for example: { size >= 0 }.
• The text may be natural language or anything else,
•such as UML's formal specification language, the Object Constraint
Language (OCL).
 OPERATIONS AND
METHODS

36
Operations
• One of the compartments of the UML class box shows the
signatures of operations
• Official format of the operation
• visibility name (parameter-list) : return-type {property- string}
• The property string contains arbitrary additional information
•e.g. exceptions that may be raised, if the operation is abstract,
and so forth
• UML allows the operation signature to be written in any programming
language
• such as Java, both expressions are possible:
• + getPlayer( name : String ) : Player {exception
IOException}
• public Player getPlayer( String name )
throws IOException
Operation vs. Method

• An operation is not a method

• A UML operation is a declaration,
• with a name, parameters, return type, exceptions list, and
possibly a set of constraints of pre-and post-conditions.
• it isn't an implementation
• Methods are implementations
• Operation contracts in UML terms
• the definition of constraints for UML operations
Showing Methods in Class Diagrams
• Method Illustrations
• in class diagrams, with a UML note symbol stereotyped with
«method»
• Using UML note to show a method
• mixing static and dynamic views in the same diagram
• The method body (which defines dynamic behavior) adds a dynamic element
to the static class diagram.
Interfaces
Different notations to show interfaces in UML
(2)

• Interface Realization
• Lollipop Notation
ASSOCIATIONS,
DEPENDENCIES,
GENERALIZATIO
NS AND
AGGREGATIONS
 Association

• An association is a structural relationship that

specifies that objects of one thing are connected to
objects of another.
 Navigation

• Navigability is a property of the role which indicates

that it is possible to navigate uni-directionally across
the association from objects of the source to target
class.

• Navigability implies visibility.

 Dependency
• A dependency is a using relationship, specifying that a change in the specification of one
thing may affect another thing that uses it.

• Example relation of meeting and schedule

• If time and date of meeting is change the schedule will be updated

• Dependency can be viewed as another version of coupling, a traditional

term in software development when an element is coupled to or
depends on another.
46 Showing
Dependencies

• There are many kinds of dependency

• having an attribute of the product description type
• an attribute, a parameter variable, a local variable, a
global variable, or class visibility (invoking static or class
methods)
• receiving a parameter of the productdescriton
type
 Generalization

• A generalization is a relationship between a

general thing (called the super class or parent) and
a more specific kind of that thing (called the
subclass or child).

• is-a-kind-of relationship.
Aggregatio
n
• Whole/part relationship
• Has-a relationship
Composition Over Aggregation

• Aggregation is a vague kind of association

• suggests whole-part relationships (as do many ordinary associations)
• It has no meaningful distinct semantics in the UML versus a plain association

• Composition, also known as composite aggregation

• strong kind of whole-part aggregation
• useful to show in some models

• A composition relationship implies that

• an instance of the part (such as a Square) belongs to only one composite instance (such as one Board) at a
time,
• the part must always belong to a composite and
•the composite is responsible for the creation and deletion of its parts either by itself
creating/deleting the parts, or by collaborating with other objects.
• if the composite is destroyed, its parts must either be destroyed, or attached to another
composite (no free-
floating Fingers allowed!)
Compositions in UML
51 Aggregation vs.
Composition
• What relationship if any exists between
the following entities? And why? Justify! Strictly
Meaningless,
since the same
can be said using
an assocition

•An instance of Point may be part of a polygon or may be the center of a

circle, but it cannot be both
•The general rule is that, although a class may be a component of many
other classes, any instance must be a component of only one owner at a
time
•The class diagram may show multiple classes of potential owners, but
any instance has only a single object as its owner
 Realization
• A realization is a semantic relationship between classifiers in which one classifier specifies
a contract that another classifier guarantees to carry out.

• We use realization in two circumstances:

• In the context of interfaces.
• In the context of collaborations.
Qualified Association
• A qualified association has a qualifier that is used to select an object (or objects) from a larger set of
related objects, based upon the qualifier key.
• Informally, in a software perspective, it suggests looking things up by a key, such as objects in a
HashMap.
•For example, if a Product Catalog contains many Product Descriptions, and each one can be
selected by an itemID, then the UML notation to depict this is as follows:

The change in multiplicity. Contrast (a) vs. (b), qualification reduces the multiplicity at the target end of
the association,
usually down from many to one,
It implies the selection of usually one instance from a larger set
Association Class
• An association class allows you treat an
association itself as a class,
• and model it with attributes, operations, and other
features.

 In the UML, it is illustrated with a dashed line from

the association to the association class.
Example of a
DCD.  A design class diagram
illustrates the
specifications for SW
classes and interfaces
Typical information

included:
 Classes,
associations, and
attributes
 Interfaces, with
their
operations and
constants
 Methods
Attribute type
information