OOAD

Unit-2

Objects and Classes

The concepts of objects and classes are intrinsically linked with each other and form the
foundation of object–oriented paradigm.

Object

An object is a real-world element in an object–oriented environment that may have a physical

or a conceptual existence. Each object has −

• Identity that distinguishes it from other objects in the system.

• State that determines the characteristic properties of an object as well as the values of
the properties that the object holds.
• Behavior that represents externally visible activities performed by an object in terms
of changes in its state.

Objects can be modelled according to the needs of the application. An object may have a
physical existence, like a customer, a car, etc.; or an intangible conceptual existence, like a
project, a process, etc.

Class

A class represents a collection of objects having same characteristic properties that exhibit
common behavior. It gives the blueprint or description of the objects that can be created from
it. Creation of an object as a member of a class is called instantiation. Thus, object is an
instance of a class.

The constituents of a class are −

• A set of attributes for the objects that are to be instantiated from the class. Generally,
different objects of a class have some difference in the values of the attributes.
Attributes are often referred as class data.
• A set of operations that portray the behavior of the objects of the class. Operations are
also referred as functions or methods.

N-ary association:

An N-ary association is a relationship that exists between three or more classes. The association
cannot be broken down into a regular, binary association without some information being lost.
The great majority of associations are binary; very few are ternary (N = 3). Rarer still are
associations of order four or more (N = 4 or more). A common example of a ternary association
is the one that exists between a taxpayer, an accountant, and the IRS.

To draw an N-ary association

• Connect two classes with an association line
• Draw an association line from a third class to the association line between the first two
classes. The association line connects to the line, and a diamond-shaped symbol
appears at the junction. The entire multi-part association becomes one structure, with
one underlying definition.
• To open the definition of the ternary association, double-clicking the line. The
definition dialog of the line contains an association end for each class involved in the
association (so for a ternary association, there will be three association ends, and so on).

Abstract classes:

It is a class with an operation prototype, but not the implementation. It is also possible to have
an abstract class with no operations declared inside of it. An abstract is useful for identifying
the functionalities across the classes. Let us consider an example of an abstract class. Suppose
we have an abstract class called as a motion with a method or an operation declared inside of
it. The method declared inside the abstract class is called a move ().

This abstract class method can be used by any object such as a car, an animal, robot, etc. for
changing the current position. It is efficient to use this abstract class method with an object
because no implementation is provided for the given function. We can use it in any way for
multiple objects.

In UML, the abstract class has the same notation as that of the class. The only difference
between a class and an abstract class is that the class name is strictly written in an italic font.

An abstract class cannot be initialized or instantiated.

Abstract Class Notation

In the above abstract class notation, there is the only a single abstract method which can be
used by multiple objects of classes.

Metadata:

Metadata is data about the data or documentation about the information which is required by
the users. In data warehousing, metadata is one of the essential aspects.

Metadata includes the following:

1. The location and descriptions of warehouse systems and components.

2. Names, definitions, structures, and content of data-warehouse and end-users views.
3. Identification of authoritative data sources.
4. Integration and transformation rules used to populate data.
5. Integration and transformation rules used to deliver information to end-user analytical
tools.
6. Subscription information for information delivery to analysis subscribers.
7. Metrics used to analyze warehouses usage and performance.
8. Security authorizations, access control list, etc.

Metadata is used for building, maintaining, managing, and using the data warehouses.
Metadata allow users access to help understand the content and find data.

Reification:
Reification is the process through which an abstract idea regarding a computer application is
converted into an object or explicit data model or another object created in a programming
language. A computable or addressable object (a resource) gets created in a system as a proxy
for a non-computable or non-addressable object. Reification makes it possible for something
that was implicit, unexpressed, and maybe even inexpressible to be formulated explicitly and
made available for conceptual (logical or computational) manipulation.
Constraints:
Constraints specify the conditions or restrictions that need to be satisfied over time. They
allow adding new rules or modifying existing ones. Constraints can appear in all the three
models of object-oriented analysis.

• In Object Modelling, the constraints define the relationship between objects. They
may also define the relationship between the different values that an object may take
at different times.
• In Dynamic Modelling, the constraints define the relationship between the states and
events of different objects.
• In Functional Modelling, the constraints define the restrictions on the transformations
and computations.

Representation − A constraint is rendered as a string within braces.

Example − The following figure shows a portion of DFD for computing the salary of
employees of a company that has decided to give incentives to all employees of the sales
department and increment the salary of all employees of the HR department. It can be seen that
the constraint {Dept:Sales} causes incentive to be calculated only if the department is sales and
the constraint {Dept:HR} causes increment to be computed only if the department is HR.

Package:

A package is an organized group of elements. A package may contain structural things like
classes, components, and other packages in it.

Notation − Graphically, a package is represented by a tabbed folder. A package is generally

drawn with only its name. However it may have additional details about the contents of the
package. See the following figures.

State Modeling:
The state model describes the sequences of operations that occur in response to external stimuli,
as opposed to what the operations do, what they operate on, or how they are implemented. The
state model consists of multiple state diagrams, one for each class with temporal behavior that
is important to an application. The state diagram is a standard computer science concept (a
graphical representation of finite state machines) that relates events and states. Events represent
external stimuli and states represent values of objects. You should master the material in this
chapter before proceeding in the book.
Events
An eyent is an occurrence at a point in time, such as user depresses lefi button or flight 123
departs from Chicago. Events often correspond to verbs in the past tense Qtower turned on,
alarm set) or to the onset of some condition (paper tray becomes empty, temperature be- comes
lower than freezing). By definition, an event happens instantaneously with regard to the time
scale of an application. Of course, nothing is really instantaneous; an event is simply an
occurrence that an application considers atomic and fleeting. The time at which an event occurs
is an implicit attribute of the event. Temporal phenomena that occur over an interval of time
are properly modeled with a state. One event may logically precede or follow another, or the
two events may be unrelated. Flight 123 must depart Chicago before it can arrive in San
Francisco; the two events are caus- ally related. Flight 123 may depart before or after flight
456 departs Rome; the two events are causally unrelated. Two events that are causally unrelated
are said to be concurrent; they have no effect on each other. If the communications delay
between two locations exceeds the difference in event times, then the events must be concurrent
because they cannot influence each other. Even if the physical locations of two events are not
distant, we consider the events concurrent if they do not affect each other. In modeling a system
we do not try to establish an ordering between concurrent events because they can occur in any
order. Events include error conditions as well as normal occurrences. For example, motor
jammed, transaction aborted, and timeout are typical effor events. There is nothing different
about an error event; only our interpretation makes it an "error." The term event is often used
ambiguously. Sometimes it refers to an instance, at other times to a class. In practice, this
ambiguity is usually not a problem and the precise meaning is apparent from the context.
necessary, you can say event occurrence or event type to be precise.
States
A state is an abstraction of the values and links of an object. Sets of values and links are grouped
together into a state according to the gross behavior of objects. For example, the state of a bank
is either solvent or insolvent, depending on whether its assets exceed its liabilities. States often
correspond to verbs with a suffix of "ing" (Waiting, Dialing) or the duration of some condition
(Powe red, Below Freezing).
In defining states, we ignore attributes that do not affect the behavior of the object, and lump
together in a single state all combinations of values and links with the same response to events.
Of course, every attribute has some effect on behavior or it would be meaningless, but often
some attributes do not affect the sequence of control and you can regard them as simple
parameter values within a state. Recall that the purpose of modeling is to focus on qualities that
are relevant to the solution of an application problem and abstract away those that are irrelevant.
The three UML models (class, state, and interaction) present different views of a system for
which the particular choice of attributes and values are not equally important. For example,
except for leading 0s and 1s, the exact digits dialed do not affect the control of the phone line,
so we can summarize them all with state Dialing and track the phone number as a parameter
Sometimes, all possible values of an attribute are important, but usually only when the number
of possible values is small. The objects in a class have a finite number of possible states one or
possibly some larger number. Each object can only be in one state at a time. Objects may parade
through one or more states during their lifetime. At a given moment of time, the various objects
for a class can exist in a multitude of states. A state specifies the response of an object to input
events. All events are ignored in a state, except those for which behavior is explicitly
prescribed. The response may include the invocation of behavior or a change of state. For
example, if a digit is dialed in state Dial tone, the phone line drops the dial tone and enters state
Dialing; if the receiver is replaced in stateDial tone, the phone line goes dead and enters state
ldle.
Transitions and Conditions
A transition is an instantaneous change from one state to another. For example, when a called
phone is answered, the phone line transitions from the Riruging state to the Connected state.
The transition is said toft.re upon the change from the source state to the target state. The origin
and target of a transition usually are different states, but may be the same. A transition fires
when its event occurs (unless an optional guard condition causes the event to be ignored). The
choice of next state depends on both the original state and the event received.
An event may cause multiple objects to transition; from a conceptual point of view such tran-
sitions occur concurrently. A guard condition is a boolean expression that must be true in order
for a transition to occur. For example, ataffic light at an intersection may change only if a road
has cars waiting. A guarded transition fires when its event occurs, but only if the guard
condition is true. For example, "when you go out in the morning (event), if the temperature is
below freezing (condition), then put on your gloves (next state)." A guard condition is checked
only once-, at the time the event occurs, and the fransition fires if the condition is true. If the
condition becomes true later, the transition does not then flre. Note that a guard condition is
different from a change event-a guard condition is checked only once while a change event is,
in effect, checked continuously.
State diagrams - State diagram behaviour:

ram show, why is it important, and what are the benefits of state diagrams?
A state diagram is the graphical representation of a state machine and one of the 14 diagram
types of the Unified Modeling Language (UML) for software and other systems. Statecharts
show a behavioral model of states, state transitions, and actions. UML state diagrams are
based on the concept of David Harel’s state diagrams (also known as Harel state diagram or
Harel state machine).

State diagrams show the allowed states and state transitions of a state machine, as well as the
events that trigger these transitions. In other words, a state diagram describes the allowed
states of a (model) element, the state transitions that trigger events, and the states.

Statecharts are often used in the field of embedded systems. However, they can also be found
in other areas. State diagrams are modeled to represent the entire life cycle of objects and
thus contribute to a better understanding of state-based systems.

An example of such a state-based system is an ATM: After being switched on, for example,
either the ready state or the faulty state could be reached. When the card is inserted,
depending on the card verification, the transition to the pin query or abort state occurs. Other
possible states would be account query, availability check, etc.

State diagrams are irreplaceable when it comes to describing systems and their possible
behavior. One example of this is electronic components in vehicles, such as control units for
driver assistance systems. For these systems from the field of embedded systems, possible
(permitted) states are defined in state diagrams, as are activities that are executed in certain
states or in the course of transitions.
State diagrams are the ideal way to model object life cycles. State diagrams enable you to
describe the behaviour of objects during their entire life span. In addition, the different states
and state changes as well as events causing transitions can be described. On other words: State
diagrams make the system behaviour visible.