OBJECT ORIENTED SYSTEM (CSE 601)

CHAPTER 1
INTRODUCTION
What is object-oriented?
“Object - oriented” means organize software as a collection of discrete objects that
incorporate both data structure and behavior.
The general characteristics are required by an object-oriented approach include four
aspects: identity, classification, polymorphism and inheritance.

Why an object orientation?

• Object-oriented methods enable to create sets of objects that work together
synergistically to produce software that better model their problem domain than
similar system produced by traditional techniques.
• The systems are easier to adapt to changing requirements, easier to maintain,
more robust and promote greater design and code reuse.
• Object-oriented development allows creating modules of functionality.
• Once objects are defined, it can be taken for granted and perform their desired
functions.

Overview of Object Oriented Language

Object – oriented Language is a method of implementation in which programs are
organized as cooperative collections of objects, each of which represents an instance of
some class, and whose classes are all members of a hierarchy of classes united via
inheritance relationships. i.e.

¾ It uses objects, not algorithms

¾ Each object is an instance (example /case) of some class
¾ Classes are related to one another via inheritance relationship.

The physical building block in these languages is called module.

1
The module is a representation of classes and objects instead of subprograms as in earlier
languages.

The fundamental characteristic of object-oriented programming is that it allows the base

concepts of the language to be extended to include ideas and terms closer to those of its
applications.
New data types can be defined in terms of existing data types until it appears that the
language directly supports the primitives of the application.

Foundation of the object-oriented programming

Structured design methods evolved to guide / build complex systems using algorithms as
their fundamental building blocks

But in object-oriented programming languages, using the class and object as basic build
blocks.

Object
• The term object means a combination of data and logic that represents some real
world entity.

• In object-oriented system, everything is an object: A spreadsheet, a cell in a

spreadsheet, a bar chart, a title in a bar chart, a report, a number or telephone
number, a file, a folder, a printer, a word or a sentence or even a single character.

• The objects are an abstraction which represents only those features of a thing that
are deemed relevant to the current purpose and hides those features that are not
relevant.

• The example for abstraction is Map representation.

• The Road maps concentrate on showing roads and place and omit landscape
features

• The Geological maps show rocks and other sub-surface but omit towns and roads.

• The object has ‘state, behavior and identity’

• State represents the particular condition that an object is in at a given moment

2
 • Behavior stands for the things that the object can do that are relevant to model.

• Identity means that every object is unique.

• Example: consider a person is an object,

his name is identity i.e Ahmed and

behavior is reading and

state is studying.

Rounded boxes are used to denote particular instance of classes, class name in brackets

Classes
• In object – oriented systems, a class is a set of objects that share a common
structure and a common behavior; a single object is simply an instance of a class.
• A class is a specification of structure (instance variable), behavior (methods) and
inheritance for objects.
• The classes are important mechanism for classifying objects.
• A method or behavior of an object is defined by its class.
• Each object is an instance of a class.

Meta-Types
In an object-oriented system, everything is an object: numbers, arrays, records, fields,
files, forms and a class is an object. In such case, class belongs to a class called a meta-

3
class or a class of classes. Meta-classes are used by the compiler. For example, the meta-
classes handle messages to classes, such as constructors, “new” and “class variables”

UML META-MODEL
The UML defines notations as well as a meta-model. UML graphic notations can be used
not only to describe the system’s components but also to describe a model itself. This is
known as a meta-model. In other words, a meta-model is a model of modeling elements.
The purpose of the UML meta-model is to provide a single, common and definitive
statement of the syntax and semantics of the elements of the UML. The meta-model
provides us a means to connect different UML diagrams. The connection between the
different diagrams is very important.

Object Oriented Methodologies

The object oriented methodologies is an integrated approach to analysis, design and
implementation of computer system.

The unified Approach Modeling

The unified Approach (UA) is the methodology for software development proposed. The
Unified Approach, based on methodogies by Booch, James rumbaugh and Jacobson.
Unified Approach consists of the following concepts:

™ Use-case driven development

™ Utilizing the unified modeling language for modeling
™ Object-oriented analysis (utilizing use cases and object modeling)
™ Repositories of reusable classes and maximum reuse.
™ The layered approach.
™ Incremental and development and prototyping.
™ Continuous testing

The UML does not specify a methodology of what steps to follow to develop an
application; that would be the task of the unified approach. The heart of the UA is
Jacobson’s use case. The use cases are part of all other activities of the UA.
Advantage of UA: In the object-oriented system is that the class tree is dynamic and can
grow.

Why Modeling
• In any development project that aims at producing useful artifacts, the main focus
of both analysis and design activities.

4
 • System analyst and designers produce models of systems.
• A business analyst will start by producing a model an organization works
• Building a model for a software system prior to its construction is as essential as
having a blueprint for building a large building.
• Good models are essential for communication among project teams.
• As the complexity of systems increases, so does the importance of good modeling
techniques.
• The rigorous modeling language is essential for project success.

The model language must include:

¾ Model elements – fundamental modeling concepts and semantics
¾ Notation - Visual rendering of model elements
¾ Guidelines – expression of usage within the trade.

The use of visual notation to represent or model a problem can provide us several
benefits relating to clarity, familiarity, maintenance and simplification.

UML
The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems. The UML is a standard diagramming notation or
culture of software engineer. Object Modeling is the central technique in UML.

It is a language independent notation:

¾ allowing the specification of classes,

¾ their data or attributes (private) and

¾ methods (public), inheritance, and

¾ other more general relationships between classes.

The Unified Methods are following

¾ Booch method,
¾ OMT method(Rumbaugh),
¾ OOSE method (Jacobson)

5
 UML be applied in three ways

UML as sketch UML as blueprint UML as Programming

Language
Informal and Relatively detailed
incomplete design diagrams Executed code
diagrams used for better will be
For example: understanding of automatically
Hand sketched existing code in generated
on whiteboards UML diagrams,
code generation.

6
 Figure : UML as blueprint

Figure: UML as a Programming Language

UML defines various types of diagrams, divided into three major categories

Structure Diagrams include the Class Diagram, Object Diagram, Component Diagram,
Composite Structure Diagram, Package Diagram, and Deployment Diagram.

Behavior Diagrams include the Use Case Diagram, Activity Diagram, and State
Machine Diagram.

Interaction Diagrams, all derived from the more general Behavior Diagram, include the
Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction
Overview Diagram.

7
Role of system analyst and designer
- System analyst will produce a more abstract model of the object in the business.
- Designer will produce a model of how a new computerized system will work
within the organization.

Need of model
• A model is quicker and easier to build.
• A model can be used in simulations, to learn more about the thing it represents.
• A model can represent real or imaginary things from any domain.
• Ex: Civil engineers model bridges, economists model the effects of government
policy.

Notations to describe every aspects of software development

Object Modeling Technique (OMT).

The methodology consists of building a model of an application domain and then adding
implementation details to it during the design of a system.

This approach is called Object Modeling Technique (OMT).

Models used in Object Modeling Technique (OMT)

The OMT methodology uses three types of models to describe a system:

The object Model / static Model describes the static structure of the objects in a system
that change over time. This model contains object diagrams. An object diagram is a graph
whose nodes are object classes and whose arcs are relationships among classes.

A static model can be viewed at a specific point in time. Static models are needed to
represent the structural or static aspect of a system. For example, a customer could have
more than one account.

The dynamic model: describes all aspects of a system that change over time. The
dynamic model is used to specify and implement the control aspects of a system. The

8
dynamic model contains state diagrams. The state diagram is a graph whose nodes are
states and whose arcs are transitions between states caused by events.

A dynamic model in contrast to a static model, can be viewed as a collection of

procedures or behaviors that, taken together, reflect the behavior of a system over time.
Dynamic relationships show how the business objects interact to perform tasks. For
example, an order interacts with inventory to determine product availability.

A system can be described by first developing its static model, which is the structure of
its objects and their relationships, a base line. Then, we can examine changes to the
objects and their relationships over time.

Dynamic modeling is most useful during the design and implementation phase of the
system development. The UML interaction diagrams and activity models are examples
of UML dynamic models.

The functional model: describes the data value transformations within the system. The
functional model contains data flow diagrams. A data flow diagram represents a
computation. A data flow diagram is a graph whose nodes are processes and whose arcs
are data flows.

The functional model describes computations within a system. The functional model
shows how output values in a computation are derived from input values, without
specifying how or when they are computed. The function model specifies the meaning of
the operations in the object model and the actions in the dynamic model.

Example : A spreadsheet is a kind of functional model. In most cases, the values in the
spreadsheet are inconsequent and cannot be structured further. The object structure is the
cells in the spreadsheet itself. The purpose of the spreadsheet is to specify values in
terms of other

9
values.

10
 Chapter 2
Object Modeling:
The first step in analyzing the requirements is to construct an object model.

The following steps are performed in constructing an object model:

¾ Identify objects and classes
¾ Prepare a data dictionary
¾ Identify association (including aggregations) between objects.
¾ Identify attributes of objects and links
¾ Organize and simplify object classes using inheritance
¾ Verify that access paths exist for likely queries
¾ Iterate and refine the model
¾ Group classes into modules.

Link Attributes
An attribute is a property of the objects in a class. Similarly, a link attribute is a property
of the links in an association. Each link attribute has a value for each link. The OMT
notation for a link attribute is a box attached to the association by a loop; one or more
link attributes may appear in the second region of the box.

11
Association
An association describes a group of links with common structure and common semantics.
Associations are inherently bidirectional. The binary association can be traversed in
either direction. The direction implied is called forward direction and opposite direction
is called inverse direction

12
Multiplicity

Multiplicity specifies how many instances of one class may relate to a single instance of
an associated class. Multiplicity constrains the number of related objects.
The most important multiplicity distinction between “one’ and “many”.

One-one multiplicity

One-Many multiplicity (optional)

One-to-One Relationships
These are modeled by a labeled straight line between two classes. No direction is
assumed, though there may be an implicit one.

13
One-to-Many Relationship
There are modeled by a labeled straight line, with a dot at the end indicating the “many”
end of relationship. A number label may be used to indicate how many

14
Many-to Many Relationships
These are modeled by a labeled straight line, with a dot at each end. A number label may
be used to indicate how many.

Relationships among Classes

• Class Hierarchy, Inheritance, “is a”
- Generalization / Specialization
- Mammal < Monkey < Human
• Composition, Aggregation, “has a”
- Automobile = Body + Wheels + Steering + Engine
• Association, a general relation between classes
Employ – (works at) - Company

Generalization or inheritance
Generalization refers to refining a super class into subclasses. Each subclass inherits the
attributes of the super class
Classes can be arranged in inheritance hierarchies. A class inherits operations and
attributes from its parent.
Inheritance is indicated with a triangle in the line with the apex pointing to the parent
class
A class inherits all the attributes and operations of its immediate parent and of its parent’s
parent and so on. This is one of the underlying mechanisms to re-use code.

15
Grouping Constructs
Module
A module is a logical construct for grouping classes, associations and generalizations. A
module captures one perspective or view of a situation. For example electrical, plumbing,
and ventilation modules are different views of a building.

An object model consists of one or more modules. Modules enable you to partition an
object model into manageable pieces. Modules provide an intermediate unit of packaging
between an entire object model and the basic building blocks of class and association.
Class names and association names must be unique within a module. There is no other
special notation for modules.

The same class may be referenced in different modules. Referencing the same class in
multiple modules is the mechanism for binding modules together. There should be fewer
links between modules (external binding) than within modules (internal binding).

Sheet
The complex model will not fit on a single piece of paper. A sheet is the mechanism for
breaking a large object model down into a series of pages. A sheet is a single printed
page. Each module consist one or more sheets. Each sheet has a title and a name or
number. Each association and generalization appears on a single sheet. Classes may
appear on multiple sheets. Use of sheet cross-reference circles is optional. Sheet numbers
or sheet names inside circle continuous to a class box indicate other sheets that refer to a
class.

Problems on object modeling

In the static structure of object modeling, i.e. the structure of its objects and their
relationships to each other at a single moment in time.

We can’t examine changes to the objects and their relationships over time.

16
Advantages of Object Modeling
The object model precedes the dynamic model and functional model because static
structure is usually better defined, less dependent on application details, more stable as
the solution evolves and easier for humans to understand.
• The object model describes the structure of objects in a system: their identity,
their relationship to other objects, their attributes and their operations.
• The goal in constructing an object model is to capture those concepts from the
real world that are important to an application.
• In modeling an engineering problem, the object model should contain terms
familiar to engineers.
• In modeling a business problem, terms from the business.
• The object model is represented graphically with object diagrams containing
object classes.
• Classes are arranged into hierarchies sharing common structure and behavior and
are associated with other classes.
• Object model diagrams promote communication between computer professionals
and application-domain experts.

17
 Chapter 3
Analysis

Stages of applying OMT Model

The approach for object oriented methodology is called object Modeling Technique
(OMT). The object oriented methodology consists of building a model of an application
domain and then adding implementation details to it during the design of the system.
There are four different stages for applying OMT model, namely
• Analysis,

• System design,

• Object Design,

• Implementation

1. Analysis
The analyst first reads the statement of the problem and then builds a model of the real
world situation showing its important properties.

Problem statements are generally not complete or correct.

Hence the analyst must sit with the user and try to understand the problem.

The analysis model describes

¾ What the desired system must do

¾ How it will be done

It is important to note the following points about the analysis model

It should not contain any implementation decisions such as data structures.

A good model should be simple and be understood by everybody including non-

programmers.

2. System design
The system designer makes high-level decisions about the overall architecture.

During the system design, the target system is divided into a number of subsystems.

The following are the decisions that have to be made by the system designer

18
 ¾ Organize the system into sub systems

¾ Allocate subsystems to processes and tasks

¾ Choose an approach for the management of data stores

¾ Handle access to global resources

¾ Choose the implementation of control in software

¾ Handle boundary conditions.

3. Object Design
The object designer builds a design model based on the analysis model but containing the
implementation details.

The designer adds details to the design model in accordance with the analysis model.

The focus in the design model is the data structures and algorithms designed to
implement each class.

4. Implementation
During the implementation stage, the object classes and relationships are finally
translated into a particular programming language, database or hardware implementation.

The target language to be used determines the design decisions to some extent, but the
design should not depend on the fine details of the programming language.

During implementation, it is necessary to follow good software engineering procedures

so that the system remains flexible and extensible.

Problem Analysis
Problem statement
The first step in developing anything is to state the requirements. The problem statement
should state what is to be done and not how it is to be done. It should be a statement of
needs, not a proposal for a solution. A user manual for the desired system is a good
problem statement. The requestor should indicate which features are mandatory and
which are optional, to avoid overly constraining design decision. The requestor should
avoid describing system internals, as this restricts implementation flexibility.

19
Many problem statements, from individuals, companies and government agencies,
mixture requirements with design decisions. There may sometimes be a compelling
reason to require a particular computer or language. There is rarely justification to specify
the use of a particular algorithm.

A problem statement may have more or less detail. A requirement for a conventional
product, such as a payroll program or billing system, may have considerable detail.

Most problem statements are ambiguous, incomplete or even inconsistent. Therefore, the
problem statement is just a starting point for understanding the problem, not an
immutable document.

Overview of Analysis Process

Requirement Statement
• Problem Scope
• What is needed
• Application Context
• Assumptions
• Performance needs

Problem Domain
The first step in analyzing the requirement is to construct an object Model. The object
model describes real-world object classes and their relationship to each other.

Information for the object model comes from the problem statement, expert knowledge of
the application domain, and general knowledge of the real world.

Identify classes and associations first, as they affect the overall structure and approach to
the problem. Next add attributes to further describe the basic network of classes and
associations. Then combine and organize classes using inheritance.

Add operations to classes later as a by-product of constructing the dynamic and

functional models. Operations modify objects and therefore cannot be fully specified
until the dynamics and functionality are understood.

20
Iterations: The entire model need not be constructed uniformly. Some aspects of the
problem can be analyzed in depth through several iterations while other aspects are still
sketchy.

Identifying object classes

The first step in constructing an object model is to identify relevant object classes from
the application domain. Objects include physical entities, such as houses, employees and
machines as well as concepts seating assignments and payment schedules. All classes
must make sense in the application domain

Discard unnecessary and incorrect classes according to the following:

Redundant classes: If two classes express the same information. Ex: user and customer
are redundant.

Irrelevant classes: If a class has little or nothing to do with the problem, it should be
eliminated. For example, but the theater ticket reservation system, the occupations of the
ticket holders are irrelevant, but the occupations of the theater personnel may be relevant.

Vague Classes: A class should be specific. Some tentative classes may have ill-defined
boundaries or be too broad in scope. Example Stocksales, Telephone calls or Machine
failure

Attributes : names that primarily describe individual objects should be restated as

attributes. For example, name, age, weight and address are usually attributes.

Operations :if a name describes an operation that is applied to objects. For example, in a
billing system for telephone calls a call would be an important class with attributes such
as date, time and destination.

Roles : the name of a class should reflect its intrinsic nature and not a role that it pays in
an association. For example owner would be a poor name for a class in a car
manufacturer’s database.

The proper class is Person (or possibly customer) which assumes various different roles,
such as owner, driver and lessee.

Using USE CASE Analysis

The Use case diagram is used to identify the primary elements and processes that form
the system. The primary elements are termed as "actors" and the processes are called
"use cases." The Use case diagram shows which actors interact with each use case. A
use case diagram captures the functional aspects of a system.

21
The notion of use-cases, introduced by Iver Jacobson.

One of the most fundamental problems in software engineering is determining the

requirements of a system.

The use-case approach requires the analyst to determine all the potential actors involved
in a system.

Use-cases allow us to describe at a high level the basic functionality of a system in terms
of the various actors who need to interact with the system.

From the use-cases, which describe broad functionality, we begin to analyze the details of
the functionality of the systems we want to construct.

Use-cases are broken down into sequences of actions and events. These actions and
events are mapped onto objects through object interaction diagrams.

When to Use: Use Cases Diagrams

Use cases are used in almost every project.

The are helpful in exposing requirements and planning the project.

During the initial stage of a project most use cases should be defined, but as the project
continues more might become visible.

How to Draw: Use Cases Diagrams

Start by listing a sequence of steps a user might take in order to complete an action.

For example a user placing an order with a sales company might follow these steps.
1. Browse catalog and select items.
2. Call sales representative.
3. Supply shipping information.
4. Supply payment information.
5. Receive conformation number from salesperson.

22
These steps would generate this simple use case diagram:

Elements of a Use Case Diagram

A use case diagram generally have two types of elements: one representing the business
roles and the other representing the business processes
- Actor - Role
- Use Case - Processes
* System Boundary (optional)
* Package (optional)
- Association
• A use case in a use case diagram is a visual representation of a distinct business
functionality in a system.
• The key term here is "distinct business functionality.“
• To choose a business process, as the first step in identifying use cases, you should
list the discrete business functions in your problem statement.
• Each of these business functions can be classified as a potential use case.
• Remember that identifying use cases is a discovery rather than a creation.
• A use case is shown as an ellipse in a use case diagram

23
The name of the use case can be placed below or inside the ellipse

Use Case Associations

Associations between actors and use cases are indicated in use case diagrams by solid
lines.
An association exists whenever an actor is involved with an interaction described by a
use case.
Associations are modeled as lines connecting use cases and actors to one another, with an
optional arrowhead on one end of the line
The arrowhead is often used to indicating the direction of the initial invocation of the
relationship or to indicate the primary actor within the use case.

Actor
Actors are external to the system and make use of it. An actor is typically a person, but
may be a third-party organization or another computer system.
One person may in fact be multiple actors, say a shop assistant may be a customer of the
same shop at another time.
Model actors, not individuals – For example many people can be members of a library,
which can be represented by one actor called member.
An actor makes use of a system in different ways.

24
Representation of Actor
Three representation of an actor are equivalent.

<<actor>> <<actor>>
Customer Customer

A use-case may involve a number of actors, just as an

Individual actor may make use of several use-cases.

Now it might be that the system which is being implemented in the bank needs to involve
a cashier for depositing,

But that to withdraw money the customer has to use the cash machine. The cashier is then
an actor

25
System Boundary
• A system boundary defines the scope of what a system will be.
• A system cannot have infinite functionality.
• So, it follows that use cases also need to have definitive limits defined.
• A system boundary of a use case diagram defines the limits of the system.
• The system boundary is shown as a rectangle spanning all the use cases in the
system.
• The actors in the system are outside the system boundary.

The system boundary is potentially the entire system as defined in the problem
statement. But this is not always the case.

For large and complex systems, each of the modules may be the system boundary.

For example, for an ERP system for an organization, each of the modules such as
personnel, payroll, accounting, and so forth, can form the system boundary for use cases
specific to each of these business functions.

26
The entire system can span all of these modules depicting the overall system boundary.

Packages (optional)
Packages are UML constructs that enable you to organize model elements (such as use
cases) into groups.

Packages are depicted as file folders and can be used on any of the UML diagrams,
including both use case diagrams and class diagrams.

Use packages only when diagrams become unwieldy, which generally implies they
cannot be printed on a single page, to organize a large diagram into smaller ones.

27
Relationships between use cases
The three types of relationships between use cases
-- extends,
--includes,
-- and inheritance -- as well as inheritance between actors.

Extend relationships as the equivalent of a "hardware interrupt" because you don't know
when or if the extending use case will be invoked (perhaps a better way to look at this is
extending use cases are conditional).
The Extend relationship is used when you have one use case that is similar to another use
case but does a bit more. In essence it is like a subclass.
Include relationships as the equivalent of a procedure call.
Inheritance is applied in the same way as UML class diagrams -- to model specialization
of use cases or actors in this case. The essay Reuse in Use Case Models describes these
relationships. (or) Uses : A uses relationship between use cases is shown by a
generalization arrow from the use case.

The diagram shows the use of the includes link. Both invoice purchase and online
purchase include the scenarios defined by purchase valuation. In general, the includes
link is to avoid repetition of scenarios in multiple use cases.

Includes

28
Generalization

Extends
Search by name is said to extend search at the name extension point. The extends link is
more controlled than the generalization link in that functionality can only be added at the
extension points.

29
 Chapter 4
Aggregation is a strong form of association in which aggregate object is made of
components. Components are part of the aggregate. Aggregation relationships are
modeled by a line with a diamond at the aggregate end. The dot notation, denoting many,
may also be used if there are many similar parts.

Implementing Aggregation in Programming Language

Multilevel Aggregation

30
 Chapter 5
Interaction diagrams
• Interaction diagrams are diagrams that describe how groups of objects collaborate
to get the job done.
• Interaction diagrams capture the behavior of a single use case showing the pattern
of interaction among objects.
• There are two kinds of interaction models:
• Sequence diagrams
• Collaboration diagrams

Sequence Diagram
• Sequence diagram are an easy way of describing the behavior of a system by
viewing the interaction between the system and its environment.
• A sequence diagram shows an interaction arranged the time sequence.
• It shows the objects participating in the interaction by their lifeline and the
message they exchange, arranged in a time sequence.
• A sequence diagram is made up of objects and messages.
• Objects are represented exactly how they have been represented in all UML
diagrams—as rectangles (optional: with the underlined class name within the
rectangle)
Dimensions of Sequence diagram
A sequence diagram has two dimensions:
• The vertical dimension represents time,
• The horizontal dimension represents different objects.
The vertical line is called the object’s lifeline.
The lifeline represents the object’s existence during the interaction.
An object role is shown as a vertical dashed line, the lifeline.
This form was first popularized by Jacobson.
An object is shown as a box at the top of a dashed vertical line.
However, sequence diagram does not show the relationship among the role or the
association among the objects.

31
What is role?
A role is a slot for an object within a collaboration that describes the type of object that
may play the role.

Elements of a Sequence diagram

Object: The primary element involved in a sequence diagram is an Object—an
instance of a class.
• A Sequence diagram consists of sequences of interaction among different objects
over a period of time.
• An object is represented by a named rectangle.
• The name to the left of the ":" is the object name and to its right is the class name.

Message: The interaction between different objects in a sequence diagram is represented

as messages.
• A message is denoted by a directed arrow.
• Depending on the type of message, the notation differs.
• In a Sequence diagram, you can represent simple messages, special messages to
create or destroy objects, and message responses.

32
 Each message is represented by an
arrow between the lifeline of two
objects.
Each message is labeled with the
message name.
The label also can include the
argument, control information, a
message that an object sends to itself
by sending the message arrow back to
the same lifeline.

Figure: Transferring funds between accounts.

Advantage of using sequence diagram

• The sequence diagram is very simple and has immediate visual appeal.
• It is an alternative way to understand the over all flow of the control of a program.
• Instead of looking at the code and trying to find out the overall sequence of
behavior, use the sequence diagram to quickly understand all sequence.

33
Collaboration Diagram
• A collaboration diagram, also called a communication diagram or interaction diagram
• It is an illustration of the relationships and interactions among software objects in the
Unified Modeling Language (UML).
• A collaboration diagram resembles a flowchart that portrays the roles, functionality
and behavior of individual objects as well as the overall operation of the system in
real time.
• Objects are shown as rectangles with naming labels inside.
• These labels are preceded by colons and may be underlined.
• The relationships between the objects are shown as lines connecting the rectangles.
• The messages between objects are shown as arrows connecting the relevant
rectangles along with labels that define the message sequencing.

• The route and seat objects are multi objects which means they are a collection of
objects.
• The message, "purchaseTicket(route, preference)” is the initializing message
which is generated by the initializing actor.
• All other messages are generated by the system between objects.
• The initializing message is not numbered.

34
 • The first message after the initializing message is numbered.
• Messages that are dependent on previous messages are numbered based on the
number of the message they are dependent on.

• Therefore the message, "r=findRoute(route)" is numbered "1.1" since it is

dependent on the message "s=findSeat(route, preference)".

Purpose
A collaboration diagram shows the objects and relationships involved in an interaction,
and the sequence of messages exchanged among the objects during the interaction.
Compared with a sequence diagram
A sequence diagram shows the objects and messages involved in an interaction. It shows
the timing of the messages, but not the relationships among the objects.

As a decomposition diagram
The collaboration diagram can be a decomposition of a class, class diagram, or part of a
class diagram;
It can be the decomposition of a use case, use case diagram, or part of a use case diagram.
Instance
An instance in a collaboration diagram represents an instantiation of a class in a class
diagram or a use case in a use case diagram.

Label
[instance-name][:instance-type]
instance-name is the name of the instance
instance-type is a class or a use case

Note: While both elements of the label are optional, you must provide one of them to
avoid check errors.

35
Multi object
Multi object represents a set of instances at the many end of an association.

LABLE - [name][:type]
• name is the name of the multi object
• type is a class or a use case

Active object
An active object is an instance that owns a thread of control and can initiate control
activity. For example, processes and tasks are active objects.

Collaboration diagrams are best suited to the portrayal of simple interactions among
relatively small numbers of objects. As the number of objects and messages grows, a
collaboration diagram can become difficult to read. The Interaction diagram loses its
clarity with more complex conditional behavior. Any message path that is mutually
exclusive is numbered with an "a" or "b". In finding position, if position is left then it is
1.1.1a or position is right then 1.1.1b.

36
Activity diagram
State diagram vs. Activity diagram

State diagram Activity diagram

A State diagram shows the different states An Activity diagram talks more about these
an object is in during the lifecycle of its transitions and activities causing the
existence in the system, and the transitions changes in the object states.
in the states of the objects. These
transitions depict the activities causing Special case of state diagram, in which
these transitions, shown by arrows. sates are activities representing the
performance of operations and transisitions
It shows, state is the set of values that are triggered by the completion of the
describes an object at a specific point in operations.
time.
It can be used to model an entire business
It focus on the event occurring to a single process.
object as it responds to message
It provides a view of flows and what is
going on onside a use case or among
several classes.

It focus on the event occurring to a single

object as it responds to message

Purpose of Activity Diagram

• Activity diagrams can be used to model different aspects of a system
• Used to model business activities in an existing or potential system
• It May be used early in the system development lifecycle.

Activity diagrams are used for the following purpose:

¾ To model a task (in business modelling for instance);

¾ To describe a system function that is represented by a use case

¾ In operation specifications, to describe the logic of an operation

Notation used in activity diagram

UML diagrams are made up of four elements in activity diagram
*icons
• Two dimensional symbols
• Paths
• Strings
UML diagrams are graphs – composed of various kinds of shapes, known as nodes,
Joined together by lines, known as paths.

37
Both are made up of two-dimensional symbols that represent activities, linked by
arrows that represent the transitions from one activity to another and the flow of control
through the process that is being modeled.
The start and finish of each activity graph is marked by special symbols – icons- the dot
for the initial state and dot in a circle for the final state.
Activity diagrams at their simplest consist of a set of activities linked together by
transitions from one activity to the next.
Each activity is shown as a rectangle with rounded ends.
The name of the activity is written inside this two-dimensional symbol.

Symbols used in Activity diagram Symbol Description

Initial Activity: This shows the starting point or
first activity of the flow. Denoted by a solid circle.
This is similar to the notation used for Initial State.

Activity: Represented by a rectangle with rounded

(almost oval) edges.

Signal: When an activity sends or receives a

message, that activity is called a signal. Signals are
of two types: Input signal (Message receiving
activity) shown by a concave polygon and Output
signal (Message sending activity) shown by a
convex polygon.

Concurrent Activities: Some activities occur

simultaneously or in parallel. Such activities are
called concurrent activities. For example, listening
to the lecturer and looking at the blackboard is a
parallel activity. This is represented by a horizontal
split (thick dark line) and the two concurrent
activities next to each other, and the horizontal line
again to show the end of the parallel activity

Final Activity: The end of the Activity diagram is

shown by a bull's eye symbol, also called as a final

38
 activity.

Logical database Schema

In object-oriented paradigm basis for designing systems and programming code but can
also be used to design databases.
The OO design can design hierarchical, network, relational and object-oriented databases.
The OO design are efficient, coherent, the use of a uniform design technique improves
integration of database and programming language code.
The most important and difficult task for many database applications is the database
design.
The design of the accompanying programming code is usually easier.
A database design is often referred to as a data model or schema.
There are two approaches to database design: attribute driven and entity driven.
The attribute driven – it compiles a list of attributes relevant to the application and
synthesizes groups of attributes that preserve functional dependencies.
The entity driven – It discover entities that are meaningful to the application and describe
them.
RDBMS Logical Data Structure
A relational database logically appears as simply a collection of tables.
Tables have a specific number of columns and an arbitrary number of rows.
The columns of tables are called attributes and directly correspond to attributes in object
model.
The rows are called tuples and correspond to object instances and links.
A simple value is stored at each table row and column intersection.
The description of a database is called the database schema, which is specified during
database design and is not expected to change frequently.

Most data model has certain conventions for displaying schemas as diagrams. A
displayed schema is called a schema diagram.

The diagram displays the structure of each record type but not the actual instances of
records. Each object in the schema such as STUDENT or COURSE – a schema
construct.

39
 Extended three schema architecture for object models
The internal level has an internal schema, which describes the physical storage
structure of the database. The internal schema uses a physical data model and describes
the complete details of data storage and access paths for the database.

40
The conceptual level has a conceptual schema, which describes the structure of the
whole database for a community of user. The conceptual schema hides the details of
physical storage structures and concentrates on describing entities, data types,
relationships, user operations and constraints.

The external or view level includes a number of external schema or user view. Each
external schema describes the part of the database that a particular user group is
interested in and hides the rest of the database from that user group.

UML CLASS DIAGRAM

Representing specialization/Generalization and Inheritance in UML class diagrams

A blank triangle indicates a specialization / generalization with the disjoint constraint

and a filled triangle indicates an overlapping constraint.

41
Object Model in Logical Structure of DBMS
The object models focus on logical data structure.
Each object model consists of many classes, associations, generalizations and attributes.
Object modeling promotes deep, abstract thinking about a problem by implementation
details.
Object models are effective for communicating with application expert and help
developers achieve a coherent, understandable, efficient and correct database design.
Each table model consists of many ideal tables.
These ideal tables are generic and DBMS-independent.

42
The table model decouples DBMS from object model to table model mapping rules.
This improves documentation and eases porting.

Translate form object model to table

To translate from an object model to ideal table, several mapping alternatives methods
are used
You must also supply details that are missing from object model, such as the primary key
and candidate keys for each table and whether each attribute can be null.
The internal schema of the three architecture consists of SQL commands that create the
tables, attributes and performance tuning structures.
Indexes are the most popular performance tuning device.

Mapping object classes to Tables

Each class maps to one or more tables
The objects in a class may be partitioned horizontally and / or vertically.

Object Person
Model Person name
address

Attribute name Nulls? Domain

Table person-ID N ID
Model person-name N name
address Y address

CREATE TABLE Person

( person-ID ID not null
person-name char(30) not null
SQL Address char(30)
Code PRIMARY KEY (person-ID) );

CREATE SECONDARY INDEX Person-index-name

ON Person (person-name);
Mapping class to Table

43
 Object Orientation v s. OORDBASE
Object Orienta tion Object-oriented relational Dbase
Set of conceptual, design and
developm ent principles, Based on Object Query Language OQL
autonomous structures known as objects Characteristics Object Oriented
OO Contribution areas Data Model:
Programming Languages, Graphical User Supports complex objects
Interfaces, Databases, Software analysis, Must be extensible
design, and implementation, Operating Supports encapsulation
Systems Exhibits inheritanc e
OID Object ID Supports object identity
Unique to object, assigned by system
object-oriente d programming languages OODM object has behavior,
Smalltalk, then C++, then Java inheritance, and encapsulation
Methods
Code that performs operation on object’s Handles a mix of data types
data and it has name and body
Messages Follows OO rules
Invokes method and Sent to object
Follow s DBMS rules
Classes
Collection of similar objects, Shares Support for complex objects
attributes and structure
Protocol Extensibility of data types
Represents object’s public aspect

The use of Object IDs

Each class derived table has an ID for the primary key; one or more object OIDs form the
primary key for association-derived tables.
Object –oriented languages implement identity with pointers or look-up tables into
pointers.
IDs provide a uniform mechanism for referencing objects.
The stability of ID is particularly important for associations since they refer to objects.
The main property required of an OID is that it be immutable; i.e. the OID value of a
particular object should not change.
Object structure: In OO databases, the state (current value) of a complex object may be
constructed from other objects (or other values) by using certain type constructors.
The three most basic constructors are atom, tuple (also called structured type) and set.
The type constructors set, list, array and bag are called collection types or bulk types.

44
 Type constructor
OID Example : A complex object State

O1 = (i1, atom, ‘Hyderabad’)

O2 = (i2, atom, ‘5’)
O3 = (i3, set, {i1,i2,i3})
O4 = (i4,tuple, <DNAME:i5,DNUMBER:i2,MGR:i1>)

An OO dbase system provides a unique identity to each independent object stored in the
dbase.
This unique identity is typically implemented via a unique, system-generated object
identifier or OID.
The value of an OID is not visible to the external user, but it is used internally by the
system to identify each object uniquely and to create and manage inter-object references.
The OID can be assigned to program variables of the appropriate type when needed.

Difference between traditional dbase and oo dbase

Traditional DBASE OO DBASE

Relation models or ERR A class declaration of EMPLOYEE
models (entity-relation model) specifies only the type and operations
All objects are assumed to be for a class of objects.
persistent. The user must separately define a
EMPLOYEE, represented both persistent object of type set
the type declaration for (EMPLOYEE) or list (EMPLOYEE)
EMPLOYEE and a persistent whose value is the collection of
set of all EMPLOYEE objects. references to all persistent
EMPLOYEE OBJECTS.

45
Type constructors
ODL – object definition Language incorporates the preceding type constructors
can be used to define the object types for a particular data bases application.
The type constructor can be used to define the data structures for an OO
database schema.
The type constructor uses the data type as tuple, set and list.
The standard data types called integer, string, float called atomic types.

define type date tuple ( define type Department

year : integer;
tuple ( dname: string;
month : integer;
dnumber: integer;
day: integer; );
mgr: tuple ( manager: Employee;
startdate: Date; );
Specifying the object
types employee, date locations: set(string);
and department using employees: set(Employee);
type constructors.
projects: set(Project); );

define type Employee: The dept of

employee or
tuple ( fname: string;
projects of
initial: char; department – are
basically references
Iname: string;
to other objects.
eno: string;
The dept of
date of birth: Date; Employee is type
Department, it is
address: string;
used to refer to a
sex: char; specific department
object (where the
salary: float;
employee works).
supervisor: Employee;
The value of such
dept: Department; ); an attribute would
be an OID for a
The attribute employees of department has its value specific department
a set of references (i.e a set of OID) to objects of object.
type Employee these are the employees who work
for the department. The inverse is the reference
attribute dept of Employee.

46
 Relational Dbase Object Dbase

Relationship among tuples are It is having relationship properties or

specified by attributes with matching
values.
These can be considered as value
reference and are specified via
foreign keys.
reference attributes include OID of
the related object.
Both single references and collections
of references are allowed.

Multivalued attributes are not Depending on type of access, references

permitted.
M:N relationships must be represented
not directly but as a separate relation.
No built-in construct exists for
inheritance.
for an binary relationship can be
declared in a single direction or both
direction
Inheritance are built into the model, so
mapping is achieved by using the
inheritance constructs such as derived
(:) and EXTENDS.

Specifying operation is not strictly

It is important to specify operations
required until the implementation
during the design phase.
phase.
24

Modeling workflow
A development process should specify what has to be done, when it has to be done, how
it should be done and by whom in order to achieve the required goal.
Project management techniques are used to manage and control the process for individual
projects.
The Unified Software Development Process (USDP) has been developed by the team
that created UML. USDP is often referred to as the Unified process.
USDP does not follow the Traditional Life Cycle. But it adopts an iterative approach
within four main phases namely Inception, Elaboration, Construction and Transition.
USDP include:
• Iterative and incremental development
• Component –based development
• Requirement driven development
• Configurability
• Architecture centrism
• Visual modeling techniques.

These phases reflect the different emphasis on tasks that are necessary as systems
development proceeds.
These differences are captured in a series of workflow that run through the development
process.

47
Each workflow defines a series of activities that are to be carried out as part of workflow
and specifies the roles of the people who will carry out those activities.
While activity is something that has particular meaning for the developers who carry it
out, a phase is considered primarily from the perspective of the project manager.
The project manager thinks in terms of milestones that mark the progress of the project
along its way to completion.
Phases are sequential. A project passes through each phases in turn and then moves on to
the next.
The end of a phase is a decision point for the project management.

Iteration
Project within a phase
Phases

Inception Elaboration Construction Transition

1 2 3 4 5 6 7 8

Requirements

Analysis

Design

Implementation

Test

Workflows Size of the square relative to

time spent on workflows

Phases and workflows in the Unified Software Development Process

48
When each phase is completed, those in charge must decide whether to begin the next
phase or to halt development at that point.
Within each phase, the workflows are essentially the same. All four phases include the
full range of workflows from requirements to testing.
Workflow can be seen as a flow of activities. Since each activity can be related to worker
who will carry it out, it is useful for identify which workers will need to participate in the
project.

Architect Analyse Architecture

Use Case Analyse a Use case

Engineer

Analyse a class
Component
Engineer

Analyse a package

The analysis workflow in USDP

49
The object –oriented design process and design axioms
Databases, object-oriented paradigm and logic programming are three independently
developed areas in computer science. Both the logical and the object-oriented approaches
to database design attracted considerable interest in the previous decades. Logic forms
the basis for efficient knowledge-based systems, while object-orientated database
languages are popular for their straightforward interface to applications.

Axiom n [from Greek axioma, literally something worthy]. An axiom is a universally

held principle generally accepted as true without proof. An example is: The shortest
distance between two points is a straight line.

The basic goal of the axiomatic approach is to formalize the design process and assist in
establishing a scientific foundation for the object-oriented design process, to provide a
fundamental basis for the creation of systems. Without scientific principles, the design
field never will be systematized.

• Main focus of the analysis phase of SW development Î “what needs to be done”

• Objects discovered during analysis serve as the framework for design
• Class’s attributes, methods, and associations identified during analysis must be
designed for implementation as a data type expressed in the implementation
language
• During the design phase, we elevate the model into logical entities, some of which
might relate more to the computer domain (such as user interface, or the access
layer) than the real world or the physical domain (such as people or employees).
Start thinking how to actually implement the problem in a program.
• The goal Î to design the classes that we need to implement the system.
• Design is about producing a solution that meets the requirements that have been
specified during analysis.
Analysis Vs. Design:
• Analysis : • Design:
o Focus on understanding the o Focus on understanding the solution
problem o Operations & attributes
o Idealized design o performance
o Behavior o close to real code
o Functional o object lifecycles 50
o System structure requirements o non-functional requirements
o A small model o a large model
OO design processes in the unified approach are as below,

Design Apply design

Design view
classes, axioms
/access layers
methods,
attributes, & & prototype
Refine UML class
associations
diagrams

User
Continue testing satisfaction &
usability tests
based on use-
cases

51
 ¾ Facts and rules are axioms
¾ Ground axioms contain no variables
¾ Rules are deductive axioms
¾ Deductive axioms can be used to construct new facts from existing facts
¾ This process is known as theorem proving

• An axiom = is a fundamental truth that always is observed to be valid and for

which there is no counterexample or exception.

52
• A theorem = is a proposition that may not be self-evident but can be proven from
accepted axioms. Therefore, is equivalent to a law or principle. Theorem is valid
if its referent axioms and deductive steps are valid.
• A corollary = is a proposition that follows from an axiom or another proposition
that has been proven
• Suh’s design axioms to OOD :
ƒ Axiom 1 : The independence axiom. Maintain the independence of
components
ƒ Axiom 2 : The information axiom. Minimize the information content of
the design.
From the two design axioms, many corollaries may be derived as a direct consequence of
the axioms. They even may be called design rules, and all are derived from the two basic
axioms.
• Axiom 1Î states that, during the design process, as we go from requirement and
use-case to a system component, each component must satisfy that requirement,
without affecting other requirements

• Axiom 2 Î concerned with simplicity. Rely on a general rule known as Occam’s

razor.
ƒ Occam’s razor rule of simplicity in OO terms :

The best designs usually involve the least complex code but not
necessarily the fewest number of classes or methods. Minimizing
complexity should be the goal, because that produces the most easily
maintained and enhanced application. In an object-oriented system, the
best way to minimize complexity is to use inheritance and the system’s
built-in classes and to add as little as possible to what already is there.

53
 Corollary 4

Corollary 1
Axiom 1
Corollary 2
Axiom 2
Corollary 3

Corollary 6 Corollary 5

Corollaries 1,2 and 3 are from both axioms, whereas corollary 4 is from axiom 1 and
corollaries 5 & 6 are from axiom 2.

54
Question bank
1. What is an object?
2. What is the main advantage of object-oriented development?
3. If you are in market to buy a washing machine, which attributes or services are
relevant to you?
4. What is use-case modeling?
5. What is object modeling?
6. What is multiplicity?
7. What is UML? What is the importance of UML?
8. Name and describe the relationships in a use case diagram.
9. What is the purpose of an activity model
10. Describe the class diagram
11. What are the phases of OMT? Briefly describe each phase
12. How would you identify actors?
13. Why is use-case modeling useful in analysis
14. What is the purpose of analysis? why do we need analysis

55
Syllabus

Chapter 1 : Introduction
Overview of OOL; Object classes; Meta types, object oriented Methodologies, The
unified Approach Modelling; Why Modelling; static and Dynamic Models; Functional
Models.

Chapter 2
Object modeling: object, Links, Association. Inheritance, Grouping constructs, problems
on Object modeling. Advantages of Object Modeling

Chapter 3
Analysis :
Problem analysis, problem domain classes, identify classes and objects of real world
problems. Using USE case analysis, recording analysis.
Chapter 4
Basic object modeling, Multiplicity, constraints, aggregation, component.
Chapter 5
Sequence diagram: modeling scenarios, mapping events to objects, interfaces,
discovering attributes. Modeling simple collaboration modeling, logical database schema.
Activity diagram, modeling workflow
Chapter 6
Class diagram
Test scenarios, interfaces. Classes, methods . stree testing. System testing. Scalability
testing. Regression testing. Behavioral modeling. State chart diagram.
Chapter 7
Design
Architectural Design. Refining the Model. Refactoring. Coupling and Cohesion. Who
should own the Attribute? Who should own the operations? Process and Threads.
Chapter 8
Design classes
Classes visibility; user interface. Subsystem interface.
Chapter 9
Deponent Diagram
Modelling Source codes. Physical Databases
Chapter 10
Deployment Diagram:
Modeling in a Distributed system and Embedded Systems.

56