OBJECT ORIENTED

ANALYSIS AND DESIGN

(OOAD)
 UNIT-3

Class & Object Diagrams

 six types of relationships in UML class diagrams

1.Inheritance
Inheritance is also called generalization and is used to describe the relationship
between parent and child classes.

2.Realization / Implementation
Implementation (Implementation) is mainly used to specify the relationship
between interfaces and implementation classes .

An interface (including an abstract class ) is a collection of methods. In an

implementation relationship, a class implements an interface, and methods in the
class implement all methods of the interface declaration.

In a realization relationship of UML, one entity denotes some responsibility which is

not implemented by itself and the other entity that implements them. This
relationship is mostly found in the case of interfaces.
.
3.Composition relationship

The combination relationship represents the relationship between the whole and part
of the class, and the overall and part have a dependable lifetime. Once the overall
object does not exist, some of the objects will not exist, and they will all die in the
same life. For example, a person is composed of a head and a body. The two are
inseparable and coexist.
4.Aggregation Relationship

An object of one class can own or access the objects of another class.

Aggregation implies a relationship where the child can exist

independently of the parent. Example: Class (parent) and Student (child).

For example, bus drivers and work clothes and hats are part of the overall
relationship, but they can be separated. Work clothes and hats can be damaged
on other drivers. Bus drivers can also wear other work clothes and hats.

Example of a car and a wheel. A car needs a wheel to function correctly, but a
wheel doesn’t always need a car. It can also be used with the bike, bicycle, or any
other vehicles but not a particular car. Here, the wheel object is meaningful even
without the car object. Such type of relationship is called an aggregation relation.
5.Association Relationships

objects can be connected or associated with another object inside the system..
There are four kinds of associations : two-way associations , one-way
associations , self-association , and multiple-number associations .
For example: cars and drivers, one car corresponds to a particular driver, and one driver
can drive multiple cars.

In UML diagrams, bidirectional associations can have two arrows or no arrows , and one-way
associations or self-associations have an arrow.

In a multiplicity relationship, you can add a number directly to the associated line to indicate the
number of objects in the corresponding class.

•1..1: Only one

•0..*: Zero or more
•1..*:one or more
•0..1: No or only one
•m..n: at least m, at most n (m<=n)
6.Dependencies
Dependence: Assume that a change in class A causes a change in class B, then
say that class B depends on class A.

In most cases, dependencies are reflected in methods of a class that use

another class’s object as a parameter .

For example: The car relies on gasoline. If there is no gasoline, the car will not be
able to drive.
 Class Diagrams
TERMS AND CONCEPTS

A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and
their relationships. Graphically, a class diagram is a collection of vertices and arcs.

Common Properties: A class diagram is just a special kind of diagram and shares
the same common properties as do all other diagrams name and graphical content
that are a projection into a model. What differentiates a class diagram from other
kinds of diagrams is its particular content.

Contents: Class diagrams commonly contain the following things:

• Classes • Interfaces • Collaborations • Dependency, generalization, and association
relationships. Like all other diagrams, class diagrams may contain notes and
constraints.

Class diagrams may also contain packages or subsystems, both of which are used to
group elements of your model into larger amounts. Sometimes you'll want to place
instances in your class diagrams as well, especially when you want to visualize the
(possibly dynamic) type of an instance.
Common Uses :
You use class diagrams to model the static design view of a system. This view
primarily supports the functional requirements of a system the services the system
should provide to its end users.

When you model the static design view of a system, you'll typically use class
diagrams in one of three ways.
1. To model the vocabulary of a system

Modeling the vocabulary of a system involves making a decision about which

abstractions are a part of the system under consideration and which fall outside
its boundaries. You use class diagrams to specify these abstractions and their
responsibilities.

2. To model simple collaborations

A collaboration is a society of classes, interfaces, and other elements that work

together to provide some cooperative behavior that's bigger than the sum of all the
elements.
For example, when you re modeling the semantics of a transaction in a distributed
system, you can't just watch at a single class to understand what's going on. Rather,
these semantics are carried out by a set of classes that work together. You use
class diagrams to visualize and specify this set of classes and their relationships.
3. To model a logical database schema

Think of a schema as the blueprint for the conceptual design of a database. In many
domains, you'll want to store constant information in a relational database or in an
object-oriented database. You can model schemas for these databases using class
diagrams.
COMMON MODELING TECHNIQUES

1.Modeling Simple Collaborations To model a collaboration,

• Identify the mechanism you'd like to model. A mechanism represents some

function or behavior of the part of the system you are modeling that results from the
interaction of a society of classes, interfaces, and other things.

• For each mechanism, identify the classes, interfaces, and other collaborations that
participate in this collaboration. Identify the relationships among these things as well.

• Use scenarios to walk through these things. Along the way, you'll discover parts of
your model that were missing and parts that were just plain semantically wrong.

• Be sure to populate these elements with their contents. For classes, start with
getting a good balance of responsibilities. Then, over time, turn these in to concrete
attributes and operations.
2. Modeling a Logical Database Schema

To model a schema,
• Identify those classes in your model whose state must transcend the lifetime of
their applications.

• Create a class diagram that contains these classes. You can define your own set
of stereotypes and tagged values to address database-specific details.

• Expand the structural details of these classes. In general, this means specifying
the details of their attributes and focusing on the associations and their multiplicities
that relate these classes.

• Watch for common patterns that complicate physical database design, such as
cyclic associations and one-to-one associations. Where necessary, create
intermediate abstractions to simplify your logical structure.

• Consider also the behavior of these classes by expanding operations that are
important for data access and data integrity. In general, to provide a better
separation of concerns, business rules concerned with the manipulation of sets of
these objects should be encapsulated in a layer above these constant classes.

• Where possible, use tools to help you transform your logical design into a
physical design.
3. Forward and Reverse Engineering: https://slideplayer.com/slide/8049773/

Forward engineering is the process of transforming a model into code through a

mapping to an implementation language. Forward engineering results in a loss of
information, because models written in the UML are semantically richer than any
current object-oriented programming language.

To forward engineer a class diagram,

·Identify the rules for mapping to your implementation language or languages of

choice.

·Depending on the semantics of the languages you choose, you may want to
constrain your use of certain UML features.

·Use tagged values to guide implementation choices in your target language.

·Use tools to generate code.

All of these classes specify a mapping to Java, as noted in their stereotype. Forward
engineering the classes in this diagram to Java is straightforward, using a tool.
Forward engineering the class EventHandler yields the following code.
Reverse engineering is the process of transforming code into a model through a
mapping from a specific implementation language. Reverse engineering results in a
overflow of information, some of which is at a lower level of detail than you'll need
to build useful models. At the same time, reverse engineering is incomplete.

There is a loss of information when forward engineering models into code, and so
you can't completely recreate a model from code unless your tools encode
information in the source comments that goes beyond the semantics of the
implementation language.

To reverse engineer a class diagram,

·Identify the rules for mapping from your implementation language or languages of
choice.

·Using a tool, point to the code you'd like to reverse engineer. Use your tool to
generate a new model or modify an existing one that was previously forward
engineered.

·Using your tool, create a class diagram by querying the model.

·Manually add design information to the model to express the intent of the design that
is missing or hidden in the code.
 Object Diagrams:

Object diagrams are derived from class diagrams so object diagrams are dependent
upon class diagrams.

Object diagrams represent an instance of a class diagram. The basic concepts are
similar for class diagrams and object diagrams. Object diagrams also represent the
static view of a system but this static view is a snapshot of the system at a particular
moment.

Object diagrams are used to provide a set of objects and their relationships as an
instance.

Object diagrams model the instances of things contained in class diagrams. An

object diagram shows a set of objects and their relationships at a point in time.

Basic Object Diagram Symbols and Notations

Object Names:
Every object is actually symbolized like a rectangle, that offers the name from the
object and its class underlined as well as divided with a colon.
Object Attributes:

Similar to classes, you are able to list object attributes inside a separate compartment.
However, unlike classes, object attributes should have values assigned for them.

Links:
Links tend to be instances associated with associations. You can draw a link while
using the lines utilized in class diagrams.

Class Diagram vs. Object Diagram

An object diagram is a UML structural diagram that shows the instances of the
classifiers in models.
Object diagrams use notation that is similar to that used in class diagrams.
Class diagrams show the actual classifiers and their relationships in a system
Object diagrams show specific instances of those classifiers and the links between
those instances at a point in time.
You can create object diagrams by instantiating the classifiers in class, deployment
component, and use-case diagrams.
TERMS AND CONCEPTS

An object diagram is a diagram that shows a set of objects and their relationships
at a point in time. Graphically, an object diagram is a collection of vertices and arcs.

Common Properties

An object diagram is a special kind of diagram and shares the same common
properties as all other diagrams that is, a name and graphical contents that are a
projection into a model. What differentiates an object diagram from all other kinds
of diagrams is its particular content.

Contents

Object diagrams commonly contain

•Objects
•Links

Like all other diagrams, object diagrams may contain notes and constraints.
Sometimes you'll want to place classes in your object diagrams as well, especially
when you want to visualize the classes behind each instance.
Common Uses

You use object diagrams to model the static design view or static process view of a
system just as you do with class diagrams, but from the perspective of real or
prototypical instances.

This view primarily supports the functional requirements of a system that is, the
services the system should provide to its end users. Object diagrams let you model
static data structures.

When you model the static design view or static process view of a system, you
typically use object diagrams in one way:

To model object structures

Modeling object structures involves taking a snapshot of the objects in a system at

a given moment in time. An object diagram represents one static frame in the
dynamic storyboard represented by an interaction diagram. You use object
diagrams to visualize, specify, construct, and document the existence of certain
instances in your system, together with their relationships to one another.
COMMON MODELING TECHNIQUES

Modeling Object Structures

To model an object structure,

•Identify the mechanism you'd like to model. A mechanism represents some

function or behavior of the part of the system you are modeling that results from
the interaction of a society of classes, interfaces, and other things.

• Create a collaboration to describe a mechanism.

• For each mechanism, identify the classes, interfaces, and other elements that
participate in this collaboration; identify the relationships among these things as
well.

•Consider one scenario that walks through this mechanism. Freeze that scenario
at a moment in time, and provide each object that participates in the mechanism.

•Expose the state and attribute values of each such object, as necessary, to
understand the scenario.

•Similarly, expose the links among these objects, representing instances of

associations among them.
FORWARD AND REVERSE ENGINEERING

Forward engineering a object diagram is theoretically possible but practically of

limited value as the objects are created and destroyed dynamically at runtime, we
cannot represent them statically.

Reverse engineering

To reverse engineer a object diagram,

Choose the target (context) you want to reverse engineer.

Use a tool to stop execution at a certain moment in time.

Identify the objects that collaborate with each other and represent them in an
object diagram.

To understand their semantics, expose these object’s states.

Also identify the links between the objects to understand their semantics.