State, behavior, identity:

Objects
Much of the power and flexibility of modern software analysis and design derives from its use of objects.

The use of objects allows designers to create programs that are more easily maintained and extended. And it makes it
easier to design very complex or large-scale programs.

The advantage of using objects in programming is that they allow us to model the real world more accurately.

Procedural programming represents the world as a series of processes acting on data.

However, object-oriented programming represents it the way we really see it – as a set of objects interacting with
each other.
Use cases and problem statements allow you to define the problem domain you're analyzing.

After use cases and problem statements have been created, you need to model how the problem domain actually
behaves.
By using objects, you can translate features of the problem domain into conceptual models that can be used to create
software.

So creating objects is usually the next stage in a design project after use cases or problem statements have been
drawn up.
An object is a distinct entity that represents something significant in the problem domain.

It has clear boundaries. And it has a well-defined behavior and a definite purpose.

Classes
Classes are the moulds or templates for the creation of objects. They set out rules for how the objects that they
contain may behave.
Classes are part of the abstract structure of a program, and are created when the program is created.

But objects are created only when a program runs. In contrast to classes, they exist at a definite point in time.
Grouping objects into a class allows you to simplify the problem you're modeling.

Classes create an abstract representation of the world, letting you discard unnecessary details.
A class includes objects with similar

 properties
 behavior
 relationships to other objects

The way you group objects into classes depends on the problem you're modeling.

Different problem domains have different requirements, even when they contain the same objects. You will need to
create specific classes that suit the needs of each problem domain.
For example, the following are objects relevant to a bank application domain:

 bank teller
 manager
 customer
 ATM
 Computer
 mainframe
To model different aspects of the bank, you need to create classes that will capture the essential features of the
problem domain.

So a class named ComputerSystem will capture the essential features of ATMs, computers, and the bank mainframe.
Alternatively, you could create separate classes for each of these objects if you wanted to analyze the problem
domain in more detail.
Let's say you want to model the way users interact with the bank computer system.

You can create a class to model the behavior of bank tellers, customers, and managers. And all of these things will be
instances of the ComputerSystemUser class.
You may need to rearrange the classes you've chosen if you want to model other aspects of the bank. For example,
you might create a class named Employee to model the roles of staff in the bank.
But you would need to split this into an Employee class and a class named Manager if you also wanted to model the
bank's chain of command.

State
All objects have three essential features:

 state
 behavior
 identity

An object's state is defined by the attributes of the object and by the values these have.
An attribute is a feature of an object, which distinguishes it from other kinds of objects. For example, one of the
attributes of any car object is that it is capable of movement – it has a speed.
An attribute is usually something static. This means that it cannot be removed or altered without changing the
essential nature of the object to which it belongs.

For example, a car that could never be moved would not be a typical car.
Though attributes themselves are usually static, the value an attribute can have is usually dynamic.

So you can alter the state of an object by changing the value of its attributes.

Behavior and identity

You can model the states of a system by defining the states of the objects that represent it. But to capture the
complexity of real world problems, you also need to consider how these objects behave.
Objects always exist in some kind of relation to other objects.

Sometimes they act on other objects, or even on themselves. And sometimes they are acted on by other objects.
The ways in which an object behaves are determined by its operations. So when an object needs to act on another
object – to retrieve data, for instance – it uses an operation.
An operation occurs when a message is passed between two objects, allowing some function to be performed.
For structural and security reasons, some operations and attributes in a class or object are not visible to other
classes.

This protects a program against malicious damage. And it prevents data being accidentally deleted or overwritten by
other parts of the computer program.
The hidden parts of a class can be accessed only indirectly, through the visible parts of the class.

Together, the visible operations and attributes of a class make up its interface. This is the part of a class that is acted
on by operations from other classes or system users.

The three most common types of operations that a class can have are

 modifiers
  selectors
 iterators

modifiers
A modifier operation alters the state of an object.
selectors
A selector operation lets you access the state of an object without changing it.
iterators
An iterator operation allows all the parts of an object to be accessed in a definite order. Object-oriented
programmers often create a separate class that is responsible for using the iterator function on an object.
Modifiers, selectors, and iterators are not part of any programming language, but are used to characterize the effects
operations have.
Two types of operation are needed to create and destroy instances of a class. These are:

 Constructor
 Destructor

Constructor
The constructor operation creates an object and fixes its initial state.
Destructor
The destructor operation destroys an object.
Together, state and behavior define the roles that an object may play. And an object may play many roles during its
lifetime.

For example, an object in the bank's Employee class could be involved with the payroll system, with the customer
database, or with the command hierarchy.
The functions you require an object to perform are its responsibilities. And an object's responsibilities are fulfilled by
its roles – by its state and behavior combined.

So you can capture all the meaningful functionality of an object by specifying its state and behavior.
Objects are characterized by a third feature in addition to state and behavior – identity.

Even objects with the same properties and behavior have their own individual identity. For instance, two blue station
wagons that were built in the same year by the same manufacturer are still separate and unique cars.
The identity of an object is independent of its attributes or operations. So an object will retain its identity no matter
what values its properties have.

Class Diagram Relationships
Classes are interrelated to each other in specific ways. In particular, relationships in
class diagrams include different types of logical connections. The following are such
types of logical connections that are possible in UML:

 Association
 Directed Association
 Reflexive Association
 Multiplicity
 Aggregation
  Composition
 Inheritance/Generalization
 Realization

Relationships in UML
class diagrams

Association

Association
is a broad term that encompasses just about any logical connection or relationship
between classes. For example, passenger and airline may be linked as above.
Directed Association

Directed Association
refers to a directional relationship represented by a line with an arrowhead. The
arrowhead depicts a container-contained directional flow.

Reflexive Association

Reflexive Association
This occurs when a class may have multiple functions or responsibilities. For example,
a staff member working in an airport may be a pilot, aviation engineer, a ticket
dispatcher, a guard, or a maintenance crew member. If the maintenance crew member
is managed by the aviation engineer there could be a managed by relationship in two
instances of the same class.

Multiplicity

Multiplicity
is the active logical association when the cardinality of a class in relation to another is
being depicted. For example, one fleet may include multiple airplanes, while one
commercial airplane may contain zero to many passengers. The notation 0..* in the
diagram means “zero to many”.
Aggregation

Aggregation
refers to the formation of a particular class as a result of one class being aggregated or
built as a collection. For example, the class “library” is made up of one or more books,
among other materials. In aggregation, the contained classes are not strongly
dependent on the lifecycle of the container. In the same example, books will remain so
even when the library is dissolved. To show aggregation in a diagram, draw a line from
the parent class to the child class with a diamond shape near the parent class.

To show aggregation in a diagram, draw a line from the parent class to the child class
with a diamond shape near the parent class.

Composition

Composition
The composition relationship is very similar to the aggregation relationship. with the
only difference being its key purpose of emphasizing the dependence of the contained
class to the life cycle of the container class. That is, the contained class will be
obliterated when the container class is destroyed. For example, a shoulder bag’s side
pocket will also cease to exist once the shoulder bag is destroyed.

To show a composition relationship in a UML diagram, use a directional line connecting

the two classes, with a filled diamond shape adjacent to the container class and the
directional arrow to the contained class.
Inheritance / Generalization

Inheritance
refers to a type of relationship wherein one associated class is a child of another by
virtue of assuming the same functionalities of the parent class. In other words, the child
class is a specific type of the parent class. To show inheritance in a UML diagram, a
solid line from the child class to the parent class is drawn using an unfilled arrowhead.

Realization

Realization
denotes the implementation of the functionality defined in one class by another class.
To show the relationship in UML, a broken line with an unfilled solid arrowhead is
drawn from the class that defines the functionality of the class that implements the
function. In the example, the printing preferences that are set using the printer setup
interface are being implemented by the printer.

Drawing class diagrams using Creately

We’ve given a lot of thought to relationships when we built our class diagramming
tools. Our connectors adjust to the context and show only the most logical relationships
when connecting classes. This significantly reduced your chances of making a mistake.

Create a class diagram >>

Drawing from scratch can be cumbersome. You can get started immediately using our
professionally designed class diagrams. Browse our class diagram examples and pick
the one that’s closely related to your system.

What are the Class Diagrams?

Class diagrams are the main building block in object-oriented modeling. They are used
to show the different objects in a system, their attributes, their operations and
the relationships among them.

The following figure is an example of a simple class:

Simple class diagram with attributes and operations

In the example, a class called “loan account” is depicted. Classes in class diagrams are
represented by boxes that are partitioned into three:

1. The top partition contains the name of the class.

2. The middle part contains the class’s attributes.
3. The bottom partition shows the possible operations that are associated with the
class.

The example shows how a class can encapsulate all the relevant data of a particular
object in a very systematic and clear way. A class diagram is a collection of classes
similar to the one above.

Types of relations:
Some objects have functional relationships rather than a hierarchical relationship. A functional
relationship is one where two or more objects interact with each other but are not directly
related to each other. A hierarchical relationship is one where objects are directly related
through inheritance.

For example, a student fills out a registration form in order to register for a course. The student and the
registration form are both objects that have a functional relationship, and neither is directly related
through inheritance. The functional relationship is that a student uses a registration form to register for
class.

Object-oriented programmers determine the functional relationship among objects in order to help
them understand how objects work together to achieve the goal of the application.

An object is sometimes referred to as an entity . For example, a student is an entity, the registration
form is an entity, and a course is an entity. A functional relationship is also known as an entity
relationship .

Programmers categorize entity relationships in four ways:

One to One
A one-to-one entity relationship is where one entity is related to only one instance of another entity,
such as one student has one dorm room.

One to Many
A one-to-many entity relationship is where one entity is related to many instances of another entity,
such as one student takes multiple courses.

Many to One
A many-to-one entity relationship is where many instances of an entity are related to one instance of
another entity, such as many students are assigned to one course.

Many to Many
A many-to-many entity relationship is where many instances of an entity are related to many instances
of another entity, such as many students assigned to many classrooms.

UML-Relationship
Relationships depict a connection between several things, such as structural, behavioral, or
grouping things in the unified modeling language. Since it is termed as a link, it demonstrates how
things are interrelated to each other at the time of system execution. It constitutes four types of
relationships, i.e., dependency, association, generalization, and realization.

Dependency
Whenever there is a change in either the structure or the behavior of the class that affects the
other class, such a relationship is termed as a dependency. Or, simply, we can say a class contained
in other class is known as dependency. It is a unidirectional relationship.
Association
Association is a structural relationship that represents how two entities are linked or connected to
each other within a system. It can form several types of associations, such as one-to-one, one-to-
many, many-to-one, and many-to-many. A ternary association is one that constitutes three
links. It portrays the static relationship between the entities of two classes.

An association can be categorized into four types of associations, i.e., bi-directional, unidirectional,
aggregation (composition aggregation), and reflexive, such that an aggregation is a special form
of association and composition is a special form of aggregation. The mostly used associations are
unidirectional and bi-directional.

Aggregation
An aggregation is a special form of association. It portrays a part-of relationship. It forms a binary
relationship, which means it cannot include more than two classes. It is also known as Has-a
relationship. It specifies the direction of an object contained in another object. In aggregation, a
child can exist independent of the parent.

Composition
In a composition relationship, the child depends on the parent. It forms a two-way relationship. It
is a special case of aggregation. It is known as Part-of relationship.

Aggregation VS Composition relationship

Features Aggregation relationship Composition relationship

Dependency In an aggregation relationship, a child can exist In a composition relationship, the child
independent of a parent. cannot exist independent of the parent.

Type of It constitutes a Has-a relationship. It constitutes Part-of relationship.

Relationship

Type of It forms a weak association. It forms a strong association.

Association

Examples A doctor has patients when the doctor gets A hospital and its wards. If the hospital
transfer to another hospital, the patients do not is destroyed, the wards also get
accompany to a new workplace. destroyed.
Generalization
The generalization relationship implements the object-oriented concept called inheritance or is-
a relationship. It exists between two objects (things or entities), such that one entity is a parent
(superclass or base class), and the other one is a child (subclass or derived class). These are
represented in terms of inheritance. Any child can access, update, or inherit the functionality,
structure, and behavior of the parent.

Realization
It is a kind of relationship in which one thing specifies the behavior or a responsibility to be carried
out, and the other thing carries out that behavior. It can be represented on a class diagram or
component diagrams. The realization relationship is constituted between interfaces, classes,
packages, and components to link a client element to the supplier element.

Object Oriented Process

The Object Oriented Methodology of Building Systems takes the objects as the basis. For this, first the system to be
developed is observed and analyzed and the requirements are defined as in any other method of system
development. Once this is done, the objects in the required system are identified. For example in case of a Banking
System, a customer is an object, a chequebook is an object, and even an account is an object.

In simple terms, Object Modeling is based on identifying the objects in a system and their interrelationships. Once this
is done, the coding of the system is done. Object Modeling is somewhat similar to the traditional approach of
system designing, in that it also follows a sequential process of system designing but with a different approach. The
basic steps of system designing using Object Modeling may be listed as:

 System Analysis

 System Design

 Object Design

 Implementation

System Analysis
As in any other system development model, system analysis is the first phase of development in case of Object
Modeling too. In this phase, the developer interacts with the user of the system to find out the user requirements and
analyses the system to understand the functioning.

Based on this system study, the analyst prepares a model of the desired system. This model is purely based on what
the system is required to do. At this stage the implementation details are not taken care of. Only the model of the
system is prepared based on the idea that the system is made up of a set of interacting objects. The important
elements of the system are emphasized.
System Design
System Design is the next development stage where the overall architecture of the desired system is decided. The
system is organized as a set of sub systems interacting with each other. While designing the system as a set of
interacting subsystems, the analyst takes care of specifications as observed in system analysis as well as what is
required out of the new system by the end user.

As the basic philosophy of Object-Oriented method of system analysis is to perceive the system as a set of interacting
objects, a bigger system may also be seen as a set of interacting smaller subsystems that in turn are composed of a
set of interacting objects. While designing the system, the stress lies on the objects comprising the system and not on
the processes being carried out in the system as in the case of traditional Waterfall Model where the processes form
the important part of the system.

Object Design
In this phase, the details of the system analysis and system design are implemented. The Objects identified in the
system design phase are designed. Here the implementation of these objects is decided as the data structures get
defined and also the interrelationships between the objects are defined.

Let us here deviate slightly from the design process and understand first a few important terms used in the Object-
Oriented Modeling.

As already discussed, Object Oriented Philosophy is very much similar to real world and hence is gaining popularity
as the systems here are seen as a set of interacting objects as in the real world. To implement this concept, the
process-based structural programming is not used; instead objects are created using data structures. Just as every
programming language provides various data types and various variables of that type can be created, similarly, in
case of objects certain data types are predefined.

For example, we can define a data type called pen and then create and use several objects of this data type. This
concept is known as creating a class.

Class: A class is a collection of similar objects. It is a template where certain basic characteristics of a set of objects
are defined. The class defines the basic attributes and the operations of the objects of that type. Defining a class does
not define any object, but it only creates a template. For objects to be actually created instances of the class are
created as per the requirement of the case.

Abstraction: Classes are built on the basis of abstraction, where a set of similar objects are observed and their
common characteristics are listed. Of all these, the characteristics of concern to the system under observation are
picked up and the class definition is made. The attributes of no concern to the system are left out. This is known as
abstraction.

The abstraction of an object varies according to its application. For instance, while defining a pen class for a
stationery shop, the attributes of concern might be the pen color, ink color, pen type etc., whereas a pen class for a
manufacturing firm would be containing the other dimensions of the pen like its diameter, its shape and size etc.

Inheritance: Inheritance is another important concept in this regard. This concept is used to apply the idea of
reusability of the objects. A new type of class can be defined using a similar existing class with a few new features.
For instance, a class vehicle can be defined with the basic functionality of any vehicle and a new class called car can
be derived out of it with a few modifications. This would save the developers time and effort as the classes already
existing are reused without much change.

Coming back to our development process, in the Object Designing phase of the Development process, the designer
decides onto the classes in the system based on these concepts. The designer also decides on whether the classes
need to be created from scratch or any existing classes can be used as it is or new classes can be inherited from
them.
Implementation
During this phase, the class objects and the interrelationships of these classes are translated and actually coded
using the programming language decided upon. The databases are made and the complete system is given a
functional shape.

The complete OO methodology revolves around the objects identified in the system. When observed closely, every
object exhibits some characteristics and behavior. The objects recognize and respond to certain events. For example,
considering a Window on the screen as an object, the size of the window gets changed when resize button of the
window is clicked.

Here the clicking of the button is an event to which the window responds by changing its state from the old size to the
new size. While developing systems based on this approach, the analyst makes use of certain models to analyze and
depict these objects. The methodology supports and uses three basic Models:

 Object Model - This model describes the objects in a system and their interrelationships. This model
observes all the objects as static and does not pay any attention to their dynamic nature.

 Dynamic Model - This model depicts the dynamic aspects of the system. It portrays the changes occurring in
the states of various objects with the events that might occur in the system.

 Functional Model - This model basically describes the data transformations of the system. This describes
the flow of data and the changes that occur to the data throughout the system.

While the Object Model is most important of all as it describes the basic element of the system, the objects, all the
three models together describe the complete functional system.

As compared to the conventional system development techniques, OO modeling provides many benefits. Among
other benefits, there are all the benefits of using the Object Orientation. Some of these are:

 Reusability - The classes once defined can easily be used by other applications. This is achieved by defining
classes and putting them into a library of classes where all the classes are maintained for future use. Whenever a new
class is needed the programmer looks into the library of classes and if it is available, it can be picked up directly from
there.

 Inheritance - The concept of inheritance helps the programmer use the existing code in another way, where
making small additions to the existing classes can quickly create new classes.

 Programmer has to spend less time and effort and can concentrate on other aspects of the system due to the
reusability feature of the methodology.

 Data Hiding - Encapsulation is a technique that allows the programmer to hide the internal functioning of the
objects from the users of the objects. Encapsulation separates the internal functioning of the object from the external
functioning thus providing the user flexibility to change the external behaviour of the object making the programmer
code safe against the changes made by the user.

 The systems designed using this approach are closer to the real world as the real world functioning of the
system is directly mapped into the system designed using this approach.

Advantages of Object Oriented Methodology

 Object Oriented Methodology closely represents the problem domain. Because of this, it is easier to produce
and understand designs.
 The objects in the system are immune to requirement changes. Therefore, allows changes more easily.

 Object Oriented Methodology designs encourage more re-use. New applications can use the existing
modules, thereby reduces the development cost and cycle time.

 Object Oriented Methodology approach is more natural. It provides nice structures for thinking and abstracting
and leads to modular design.