OBJECT-ORIENTED MODELLING

AND DESIGN

CHAPTER- 1
INTRODUCTION & OBJECT MODELING
INTRODUCTION
OBJECT-ORIENTED MODELLING AND DESIGN

 Object-Oriented Modelling and Design is a way of thinking about problems using

models organized around real world concepts.
 The fundamental construct is the object, which combines both data and behaviour.
 Object oriented models are useful for
o Understanding the problems
o Communicating with application experts
o Modelling the enterprises
o Preparing the documentation
o Designing the programs and databases
WHAT IS OBJECT-ORIENTED?

 Software is organized as a collection of discrete objects that incorporate both data

structure and behavior.
 In general it includes four aspects- identity, classification, polymorphism and
inheritance.
OBJECTS

 An object has:
 state - descriptive characteristics

 behaviors - what it can do (or what can be done to it)

 The state of a bank account includes its account number and its
current balance

 The behaviors associated with a bank account include the

ability to make deposits and withdrawals

 Note that the behavior of an object might change its state

OBJECTS

 Objects have three responsibilities:

What they know about themselves – (e.g., Attributes)

What they do – (e.g., Operations)

What they know about other objects – (e.g., Relationships)

CHARACTERISTICS OF OBJECTS

 Software is organized as a collection of discrete objects that

incorporate both State and behavior.
 Four aspects (characteristics) required by an OO
approach are -
Identity
Classification
Polymorphism
Inheritance
IDENTITY

 Identity means that data is organized into discrete,

distinguishable entities called objects.
E.g. for objects: personal computer, bicycle
 Objects can be concrete (such as a file in a file system) or
conceptual (such as scheduling policy in a multiprocessing
OS).
 Each object has its own inherent identity. (i.e. two objects are
distinct even if all their attribute values are identical).
CLASSIFICATION

 It means that objects with same data structure (attribute) and

behavior (operations) are grouped into a class.
 A class is an abstraction that describes important properties and
ignores the rest.
 Each class describes possibly infinite set of individual classes
 Each object is said to be an instance of its class.
 Each instance of the class has its own value for each attribute
but shares the attribute names and operations with other
instances of the class.
Figure: 1.2 :Objects and Classes
POLYMORPHISM

 It means that the same operation (i.e. action or transformation that the object
performs) may behave differently on different classes.

 Ability of different objects to response same message in different ways.

 A Specific Implementation of the Operation by a certain class is called as

Method
 e.g. move operation behave differently on Window and ChessPiece
POLYMORPHISM

Circle

Draw
Rectangle

Triangle
INHERITANCE

 It is the sharing of attributes and operations among classes based on a hierarchical

relationship.
 Subclasses can be formed from broadly defined class.
 Each subclass incorporates or inherits all the properties of its super class and adds
its own unique properties.
INHERITANCE
SOFTWARE LIFE CYCLE

 Software life cycle (or software process) - series of identifiable stages that a
software product undergoes during its life time.

 Feasibility study
 Requirements analysis and specification
 Design
 Coding
 Testing
 Maintenance
OBJECT-ORIENTED DEVELOPMENT

 Object Oriented Development is a way of thinking about

software based on abstraction that exist in real world.
 Development refers to front portion Software Life Cycle i.e. Analysis, Design and
Implementation.

 OOD approach encourages software developers to work

and think in terms of the application domain through most
of the software engineering life cycle.
 OOD IS A CONCEPTUAL PROCESS
INDEPENDENT OF A PROGRAMMING
LANGUAGE UNTIL THE FINAL STAGE.
MODELING CONCEPTS , NOT IMPLENMNTATION

 An object oriented development approach encourages to developers to work in

terms of application in software development cycle
 In this approach , the inherent concepts of the application domains are identified
, organized and understood that the details of data structures and data
structures can be addressed effectively.
 Object oriented development is a conceptual process independent of a
programming language until the final stage
 It an serve as a medium for a specification , analysis , documentation and
interfacing as well as programming
OBJECT-ORIENTED METHODOLOGY
(OMT)

The Object Modelling Technique (OMT) consists of building a

model of an application and then adding details to it during design.
The methodology has the following stages:
1. Analysis
2. System Design
3. Object Design
4. Implementation
OBJECT-ORIENTED METHODOLOGY
(OMT)

 Analysis:

 Starting with the problem statement the ANALYST builds a model of the real
world situation showing its important properties.
 The analyst must work with the requestor to understand the problem, because
problem statements are rarely complete or correct.
 The analysis model is a precise abstraction of what the desired system must do,
not how it will be done.
 The objects in the model should be application domain concepts and not
computer implementation concepts.
 It should not contain implementation decisions.
OBJECT-ORIENTED METHODOLOGY
(OMT)

 System design:

 The System Designer devise a high level decisions about the overall
architecture.
 During system design, the target system is organized into
subsystems based on both the analysis structure and proposed
architecture.
 The system designer must decide what performance characteristics
to optimize, choose a strategy of attacking the problem and make
tentative resource allocations.
OBJECT-ORIENTED METHODOLOGY
(OMT)

Object design :

 The object designer builds a design model based on the analysis

model but containing implementation details.
 The focus of object design is the data structures and algorithms
needed to implement each class.
OBJECT-ORIENTED METHODOLOGY (OMT)

Implementation :
 Implementers translate the classes and relationships developed
during class design into particular programming language, database
or hardware.
 Programming should be relatively minor and mechanical part of the
development cycle, because all the hard decisions should be made
during design.
 During implementation, it is important to follow good software
engineering practice so that traceability to the design is apparent and
so that the system remains flexible and extensible.
THREE MODELS OF OBJECT-ORIENTED
METHODOLOGY
1. Object Model:
 Describes basic structure of objects and their relationship
 Contains object diagram
 Object diagram is a graph whose nodes are object classes (Classes) and whose arcs are relationships
among classes.
2. Dynamic Model:
o Describes the aspects of a system that change over time.
o It specifies and implement control aspects of a system.
o Contains state diagram.
o State diagram is a graph whose nodes are states and whose arcs are transitions.
3. Functional Model:
 Describes data value transformation within a system.
 Contains data flow diagram.
 Data Flow Diagram is a graph whose nodes are processes and whose arcs are data flows.
OBJECT ORIENTED THEMES
 Abstraction:
o consist of focusing on the essential, inherent aspect of entity and ignore the
accidental properties
o In system development abstraction means focusing on what an object is and
does, before deciding how it should be implemented.
o During analysis abstraction means dealing only with application domain
concepts, not making design and implementation decisions, before the problem
is understood.

 Encapsulation :
o (Information Hiding) separates the external aspects of an object , that are
accessible to other objects from internal implementation details of objects,
which are hidden from the other object.

 Combining Data & Behaviour: The caller of an operation need not

consider how many implementations of a given operator exist.
OBJECT ORIENTED THEMES

 Combining Data & Behaviour:

o The caller of an operation need not consider how many
implementations of a given operator exist.
o Operator polymorphism shifts the burden of deciding what
implementation to use from calling code to the class hierarchy
o Maintenance is easier, because the calling code need not be modified
when new class is added
o In object oriented system, data structure hierarchy is identical to the
operation inheritance hierachy
 OBJECT ORIENTED THEMES

 Sharing (reuse): Sharing of code using Inheritance is one of the main

advantages of Object Oriented Languages(OOL).
o Reuse does not just happen; it must be planned by thinking beyond the
immediate application and investing extra effort in a more general design.

 Emphasis on object structure, not on procedural structure: OO

technology stresses what an object is, rather than how it is used.

 Synergy: Identity, classification, polymorphism, and inheritance

characterize OO languages. Each of these concepts can be used in
isolation, but together they complement each other synergistically.
EVIDENCE FOR USEFULNESS OF OO
DEVELOPMENT

 Applications at General Electric Research and Development

Center.(1990)
 OO techniques for developing compilers, graphics, user interfaces,
databases ,an OO language, etc.
 OO technology is a part of the computer science and software
engineering mainstream.
 Important forums: (OOPSLA,ECOOP) Object Oriented Programming
systems, Languages and applications. European Conference on OOP.
 OO MODELING HISTORY

 Work at GE R&D led to OMT(Object-Modeling Technique) in 1991.

 Rumbaugh, Grady Booch on unifying the OMT and Booch Notaions in
1994.
 In 1996 the OMG(Object Management Group) issued a request for the
proposals for a standard OO modeling notation.
 1997 UML was accepted by OMG as a standard.
 In 2001 OMG released UML
 Added features and released UML in 2004.
www.omg.org
Year & Version of UML
2011:UML 2.4
2010:UML2.3
2009:UML2.2
2007: UML 2.1.1
2005: UML 2.0
2003: UML 1.5
2001: UML 1.4

2000: UML 1.3

1998: UML 1.2
1997: UML 1.0, 1.1
1996: UML 0.9 & 0.91
1995: Unified Method 0.8
MODELING AS A DESIGN TECHNIQUE
 MODEL

 A model is an abstraction of something for the purpose of

understanding it before building it.
 The main purpose of model is for understanding of the
system.
 Designer build different kinds of models for various purposes
before constructing things.
 For example car , airplane, blueprints of machine parts, Plan
for house construction etc., Models serve many purposes
WHAT IS A MODEL

A model is a simplification of reality.

A model may provide
 Blueprints of a system
 Organization of the system
 Dynamics of the system
WHAT IS MODELING

 Modeling consists of building an abstraction of reality.

 Abstractions are simplifications because:

 They ignore irrelevant details and
 They only represent the relevant details.

 What is relevant or irrelevant depends on the purpose of the

model.
PURPOSE OF MODELING
 Testing a physical entity before building it
 Communication with customers
 Visualization
 Reduction of complexity
ABSTRACTION

 Abstraction is selective examination of certain aspect of aspects of

problem
 Goal of abstraction: isolate the important aspects for some purpose and
supress the aspects thar are not important
 All abstractions are incomplete and inaccurate
 A good model captures all crucial aspects of problem and omits the
others
 OBJECT MODELING
TECHNIQUE(OMT)
We use three kinds of models to describe a system from different but related
view points.
1. Object Model represents the static, structural , “data” aspects of a system.
2. Dynamic model represents the temporal, behavioural, “Control” aspects of
the system.
3. Functional Model represents the transformational, “Function” aspects of a
systems.

 A typical software procedure incorporates all three aspects: It uses data

structures (object model), it sequences operations in time (dynamic model),
and it transforms values (functional model)
OBJECT MODEL

 The Object model describes the structure of object in system – their

identity. relationships to other objects, attributes and operations
 The object model provides the essential framework into which dynamic
and functional models can be placed
 The object model is represented graphically with object diagrams
containing object classes.
DYNAMIC MODEL

 The Dynamic model describes those aspects of a system concerned

with the time and the sequence of operations – events that marks
changes , sequence of events, states that define the context for events
and the organization of events and states.
 The dynamic model is represented graphically with state diagrams
containing object classes. Each state diagram shows the state and event
sequences permitted in a system for one class of objects.
FUNCTIONAL MODEL

 The functional model describes those aspects of a system concerned

with transformation of values- functions, mappings, constraints and
functional dependencies.
 The functional model is represented graphically with data flow diagrams.
 Data flow diagrams shows the dependency between the values and
computation of output values from input values and function.
RELATIONSHIP AMONG MODELS

 The object model describes the data structure that the dynamic
and functional models operate on.
 The operations in the object model corresponds to the events in the dynamic model and
functions in the functional model.
 The dynamic model shows decisions which depend on the object values and which
cause actions that change object values and invoke functions.
 The functional model describes functions invoked by the operations in the object
model and actions in the dynamic model.
 Functions operate on data values specified by object model
 Also shows constraints on object values.
 Object Modeling

 An object model captures the static structure of a system by

showing the objects in the system, relationships between the objects
and the attributes and operations that characterize each class of the
object.

 THE OBJECT MODEL IS THE MOST

IMPORTANT OF THE THREE MODELS
OBJECT AND CLASSES

Objects

 Object is a concept, abstraction, or thing with crisp boundaries and

meaning for the problem at hand
 A object is simply something that makes sense in an application context.

Object serves two purposes:

1. They promote understanding of the real world
2. Provide a practical basis for computer implementation

 Decomposition of problem into objects depends on judgment and the

nature of the problem.

All the objects have identity and are distinguishable.

OBJECT AND CLASSES

 Classes

An object class describes a group of objects with similar properties

(attributes), common behavior (operations), common relationship to other
objects and common semantics.

Objects and object classes often appear as nouns in problem

descriptions.

Why Classes if Objects are the focus?

Abstraction
Common definitions are stored once per class rather than once per
instance.
OBJECT DIAGRAMS

 Object diagrams provide a formal graphic notation for modeling objects, classes and
their relationships.
 Object diagrams are concise, easy to understand and work well in practice
 Types of Object Diagrams:
1. Class Diagram:
1. Is a schema, pattern or template for describing possible instances of data

2. Instance Diagram:
1. Describes how a particular set of objects relate to each other.
2. Instance diagrams are useful for documenting test cases and discussing examples.

 A GIVEN CLASS DIAGRAM CORRESPONDS TO

INFINITE SET OF INSTANCE DIAGRAMS.
OBJECT DIAGRAMS

Figure : Class and Objects

OBJECT DIAGRAMS

 Attributes:
 Attribute is a data value held by the objects in a class.
 Each attribute has a value for each object instance.
 An attribute should be a pure data value, not a object.
 You need not and should not explicitly list identifiers.
 Attributes are listed in the second part of the class box. Each attribute
name may be followed by operational value such as type and default
value.
OBJECT DIAGRAMS

Figure (a) : Attribute and Values

Figure (b): Do not explicitly list the Object Identifiers

 Operations and Methods:
 An operation is a function or transformation that may be applied to or by objects
in a class.
 Each operation has a target object as an implicit argument.
 The same operation may apply to many different classes. Such operation is
polymorphic.
 A method is implementation of an operation for a class.
 When an operation has methods on several classes, it is important that the methods all
have the same signature- number and types of arguments and the type of result value.
 Operations are listed in the lower third of the class box. Each operation name may be
followed by optional details, such as argument list and result type.
 Query/Update operations and base/derived attribute
Figure: Operations
SUMMARY OF NOTATION FOR OBJECT
CLASSES
MULTIPLICITY

 It specifies how many instances of one class may relate to a single instance of an
associated class.
 It constraints the number of related objects
 Often described as “one” or “many”
 Subset of nonnegative integers
 Multiplicity value is single interval or may be set of disconnected intervals
 OMT symbols : solid ball -> zero or more , Hollow ball -> optional (zero or one)
 Intervals: “1”,”1+”,”3-5”, “2,4,18”
 Multiplicity depends upon assumptions and how you define the boundaries of a
problem
MULTIPLICITY

 Determining the multiplicity often exposes the hidden assumtions built into the
model e.g Person WorksFor Company
 Underestimating the multiplicity can restrict the flexibility of an application e.g
person with multiple mobile numbers
 Overestimating multiplicity imposes extra overhead and requires the application
to supply the additional information to distinguish among the members of
“many” side e.g boss with multiplicity of “zero or one”, Leader and Project group
LINK AND ASSOCIATION
CONCEPTS
LINKS AND ASSOCIATION

Links and associations are the means for establishing

relationships among objects and classes.

 A link is a physical or conceptual connection among objects.

E.g. JoeSmith WorksFor Simplex Company.

 An association is a describes oa group of links with common

structure and common semantics.
E.g. a person WorksFor a company.
 A link is an instance of an association.
 An association describes a group of links with common structure and semantics.
 All the links in an association connect objects from the same classes.
 Association and links often appear as verbs in a problem statement.
 An association describes a set of potential links in the same way that a class describes
a set of potential objects.
 Associations are bidirectional.
 In real, both directions of traversal are equally meaningful and refer to same
association.
 Associations are often implemented in programming languages as pointers from
one object to another.
 A pointer is an attribute in one object that contains an explicit reference to
another object.
 A link shows a relationship between two or more objects.
 All connections among classes should be modeled as association.
 Types of Association
o One-to-one association
o One-to-many association
o Many-to-many association
 Association may be binary, ternary, or high order.
MULTIPLICITY

 It specifies how many instances of one class may relate to a single instance of an
associated class.
 In OMT solid ball -> zero or more
 Hollow ball -> optional (zero or one)
 Multiplicity depends upon assumptions and how you define the boundaries of a
problem.
Figure: One-to-one association and links
Figure: Many-to-many association and links
TERNARY ASSOCIATION

 The ternary association describe the relation among the three classes
 The ternary association is an atomic unit and can not be subdivided into binary
associations without losing information.
 The OMT symbol for general ternary and n-ary associations is a diamond with
lines connecting to related classes. The name of association is written next to the
diamond.
 Example: Person who are programmers use computer languages on projects.
Figure: Ternary association and links
ADVANCED LINK AND ASSOCIATION
CONCEPTS

1. Link Attributes
2. Modeling an Association as Class
3. Role Names
4. Ordering
5. Qualification
6. Aggregartion
LINK ATTRIBUTE

 An attribute is property of the objects in a class

 A link attribute is a property of the links in an association
 The OMT notation for a link attribute is a box attached to association by a loop
 One or more link attributes may appear in the second region of the box
LINK ATTRIBUTE
LINK ATTRIBUTE
LINK ATTRIBUTE
 Baseball is a bat-and-ball game played between two opposing teams who take
turns batting and fielding. The game proceeds when a player on the fielding team,
called the pitcher, throws a ball which a player on the batting team tries to hit
with a bat. The objective of the offensive team (batting team) is to hit the ball
into the field of play, allowing its players to run the bases, having them advance
counter-clockwise around four bases to score what are called "runs". The
objective of the defensive team (fielding team) is to prevent batters from
becoming runners, and to prevent runners' advance around the bases.
LINK ATTRIBUTE
MODELING AN ASSOCIATION AS A CLASS

 Each link becomes one instance of the class

 The association is medeled as class and may have name and operations in
addition to attributes
ROLE NAMES

 A role is an end of an association.

 Role name is a name that uniquely identifies one end of an association.
 Each role on a binary association identifies an object or set of objects associated
with an object at other hand.
 Use of role names provides a way of traversing associations from an object at one
end , without explicitly mentioning the association.
 Use of Role names are optional , but it is often easier and less confusing to assign
role names instead of or in addition to the association names
ROLE NAMES
ROLE NAMES

 Use of Role names are necessary in case of

1. associations between two objects of the same class
2. distinguish between two associations between the same pair of clasess
ROLE NAMES

 An n-ary association has a role for each end. The role names distinguish the ends
of the association and are necessary if a class participates in an n-ary association
more than once
ORDERING

 Objects on “many” side of association may or may not have explicit order
 The ordering is an inherent part of the association
 An order set of objects on the “many” end of association is indicated by writing
“{ordered}” next to the multiplicity dot for the role.
 This is a special kind of constraint
QUALIFICATION

 The qualifier is a special attribute that reduces the effective multiplicity of an association.
 A qualified association relates two object classes and a qualifier
 One to many and many to many associations may be qualified
 A qualifier is drawn as a small box on the end of the association line near the class it qualifies
 Qualification improves semantic accuracy and increases the visibility of navigation paths

 Example: One to many is reduced to One to one

QUALIFICATION

 Example: Many to many is reduced to One to many

 Qualification is not always reducing the multiplicity

AGGREGATION

 Aggregation is the “part-whole” or “a-part-of” relationship in which objects

representing the components of something are associated with an object representing
the entire assembly.
 Aggregation is tightly coupled form of association with some extra semantics
 Properties of aggregation
1. Transitivity
2. Antisymmetric
3. Propagation of properties
 Aggregation is drawn like association , except a small diamond indicates the assembly
end of the relationship
 The existence of component object may depend on the existence of the aggregate
object of which it is part.
 The aggregation may have an arbitrary number of levels
AGGREGATION
GENERALIZATION AND INHERITANCE

 Generalization and inheritance are powerful abstractions for sharing similarities among the
classes while preserving their differences
 Generalization is the relationship between a class and one or more refined versions of it.
 The class being refined is called the “superclass” and each refined version are called a “subclass”.
 Generalization is sometimes called a “is-a” relationship. Each instance of a subclass is an instance
of the superclass.
 Generalization and inheritance are transitive across an arbitrary number of levels.
 The term ancestor and descendent refer to generalization of classes across multiple levels. An
instance of a subclass is simultaneously an instance of all its ancestor classes.
 Each subclass not only inherits all the features of its ancestors but adds its own specific attributes
and operations as well.
 The notation for generalization is a triangle connecting a superclass to its subclasses.The
superclass is connected by a line to the apex of the triangle. The subclasses are connected by
lines to a horizontal bar attached to the base of triangle.
 Figure 3.23 shows an equipment generalization
GENERALIZATION AND INHERITANCE
GENERALIZATION AND INHERITANCE

 The dangling ellipsis in the above figure indicates that there are additional
subclasses that are not shown in the diagram.
 A discriminator is an attribute of enumeration type that indicates which
property of an object is being abstracted by a particular generalization
relationship
 Only one property should be discriminated at once.
 The discriminator is optional part of a generalization relationship
 Do not nest subclasses too deeply because they are difficult to understand.
GENERALIZATION AND INHERITANCE
USE OF GENERALIZATION

 Useful for both conceptual modeling and implementation

 Used for three purposes:
 Support for polymorphism:
polymorphism increases the flexibility of software.
Adding a new subclass and automatically inheriting superclass behavior.

 Structuring for Inheriatance:

Forming a classification, organizing objects according to their similarities. It is much more profound
than modeling each class individually and in isolation of other similar classes.

 Enabling code reuse:

Reuse is more productive than repeatedly writing code from scratch.
GENERALIZATION, SPECIALIZATION, AND
INHERITANCE

 The terms generalization, specialization, and inheritance all refer to aspects

of the same idea.
 Generalization and specialization concern a relationship among classes and
take opposite perspectives, viewed from the superclass or from the
subclasses.
 Generalization derives from the fact that the superclass generalizes the
subclasses
 Specialization refers to the fact that the subclasses refine or specialize the
superclass.
 Inheritance is the mechanism for sharing attributes, operations, and
associations via the generalization/specialization relationship.
 Generalization represents a relationship at the conceptual level
 Inheritance is an implementation technique
OVERLOADING VS. OVERRIDING

 Overriding deals with two

 Overloading deals with
methods, one in a parent class
multiple methods in the same
and one in a child class, that
class with the same name but
have the same signature
different signatures

 Overriding lets you define a

 Overloading lets you define a
similar operation in different
similar operation in different
ways for different object
ways for different data
types
OVERRIDING FEATURES

 A subclass may override a superclass feature by defining a feature with the same
name
 Reasons for overriding the features
1. Specify the behaviour that depends on the subclass
e.g. display operation for figure. Figure superclass and triangle, rectangle, circle
1. Tighten the specification of a feature e.g ellipse superclass and circle subclass
2. For better performance e.g rotate operation on circle
GROUPING CONSTRUCTS

Module
 A module is a logical construct for grouping classes, associations, and
generalizations. It captures one view of a situation.
 For example: Let us say, electrical, plumbing, etc. are different views of a building.
 An object model consists of one or more modules.
 Class names and association names must be unique within a module.
 Module names are usually listed at the top of each sheet. The same class may be
referenced in many modules.
GROUPING CONSTRUCTS

Sheet
 A sheet is a mechanism for breaking a large object model down into a series of
pages.
 A sheet is a single printed page. Each module consists of one or more sheets.
 Each sheet has a title and a name or number.
 Each association/generalization appears on a single sheet. Classes may appear on
multiple sheets.
ADVANCED OBJECT MODELING
AGGREGATION

 Aggregation is a strong form of association in which an aggregate is made

of components. Components are part of the aggregate.
 The aggregate is semantically an extended object that is treated as a unit
in many
 operations, although physically it is made of several lesser objects.
AGGREGATION VS. ASSOCIATION

 Aggregation is a special form of association not an independent concept.

 If two objects are bound by a part-whole relationship, it is an aggregation .
 If two objects are usually considered independent, even though they may be linked, it
is an association.
 Some possible tests are:
i) Would you use the phrase part of?
ii) Are some operations on the whole automatically applied to its parts?
iii) Are some attribute values propagated from the whole to all or some parts
iv) Is there an intrinsic asymmetry to the association, where one object class is
subordinate to the other?
 Aggregation includes part explosions and expansions of an object into constituents
parts
 The decision to use aggregation is a matter of judgment and is often arbitrary.
AGGREGATION VS. ASSOCIATION
AGGREGATION VS. GENERALIZATION

 Aggregation is not the same as generalization.

 Aggregation relates instances .Two distinct objects are involved; one of them part of
other.
 While generalization relates classes and is a way of structuring the description of a
single object.
 With generalization, an object is simultaneously an instance of the superclass and an
instance of the subclass.
 An aggregation tree is composed of object instances that are all part of a composite
objects. A generalization tree is composed of classes that describes an object.
 Aggregation is called “a part of” relationship; generalization is often called “a kind of”
or “is-a “relationship.
 Aggregation is sometimes called an “and-relationship” and generalization an “or-
relationship”.
AGGREGATION VS. GENERALIZATION
RECURSIVE AGGREGATES

 Aggregation can be fixed, variable or recursive.

 A fixed aggregate has a fixed structure; the number and types of subparts are
predefined. The desk lamp in figure 4.2 is a fixed aggregate.
 A variable aggregate has a finite number of levels, but the number of parts may
vary. The Company in Fig.4.1 is a variable aggregate.
 A recursive aggregate contains, directly or indirectly, an instance of the same kind
of aggregate; the number of potential levels is unlimited.Fig4.3 shows a recursive
aggregate.
PROPAGATION OF OPERATIONS

 Propagation (also called triggering) is the automatic application of an operation

to a network of objects when the operation is applied to some starting object.
 For example, moving an aggregate moves its parts; the move operation
propagates to the parts.
 Provides concise and powerful way of specifying a continuum behavior.
 Propagation is possible for other operations including save/restore, destroy, print,
lock, display.
 Notation (not an UML notation): a small arrow indicating the direction and
operation name next to the affected association.
PROPAGATION OF OPERATIONS
ABSTRACT CLASSES

 Abstract class is a class that has no direct instances but whose descendant
classes have direct instances.
 A concert class is a class that is insatiable; that is, it can have direct instances.
 A concrete class may have abstract class.
 Only concrete classes may be leaf classes in an inheritance tree.
ABSTRACT CLASSES
ABSTRACT CLASSES
ABSTRACT CLASSES
ABSTRACT CLASSES

 We can use abstract classes to define the methods that can be inherited
by subclasses.
 Alternatively, an abstract class can define the signature for an operation
with out supplying a corresponding method. We call this an abstract
operation.
 Abstract operation defines the signature of an operation for which each
concrete subclass must provide its own implementation.
 A concrete class may not contain abstract operations, because objects of
the concrete class would have undefined operations.
GENERALIZATION AS EXTENSION AND
RESTRICTION

 In generalization, an instance of a class is an instance of a class is an instance of all

ancestors of the class. Therefore you can say that all ancestor class features must
apply to the subclass instances. This includes not only the attributes on the
ancestor classes but also the operations on the ancestor class.
 A subclass may include many features, which is called as an extension. For
example, fig.4.7 extends class Employee with three subclasses that inherit all
Employee features and add new features of their own.
 A subclass may also constrain ancestor attributes. This is called restriction
because it restricts the values that instances can assume. For example, a circle is
an ellipse whose major and minor axes are equal.
 Arbitrary changes to the attribute values of a restricted subclass may cause it to
violate the constraints, such that the result no longer belongs to the original
subclass. This is not a problem from the perspective of the superclass because
the result is still a valid superclass instance. For example, a circle that is scaled
unequally in the x and y dimensions remains an ellipse but is no longer a circle.
GENERALIZATION AS EXTENSION AND
RESTRICTION

 The inherited features can be renamed in a restriction For example, the inherited
features can be renamed the diameter.
 Class membership can be defined in two ways:
o Implicitly by rule
1. A rule defines a condition for membership in class; all object whose values
satisfies the rule belongs to the class
2. Suitable for immutable objects
3. E.g. Polygon, Triangles , ellipses, circles etc.
o Explicitly by enumeration
1. Suitable for objects that can undergo changes and yet remains the same
objects
2. Operations that invalidate class membership constraints must be disallowed
on semantic grounds
OVERRIDING OPERATIONS

 Use of inheritance for abstract data types and for sharing the implementations
 Overriding is done for the following reasons :
1. Overriding for Extension: new operation adds some behaviour to inherited
operation e.g. draw operation in Window and LabeledWindow
2. Overriding for Restriction: new operation restricts the protocol such as
tightening the type of arguments e.g superclass Set may have the operation
add(object) and subclass IntegerSet have more restrictive operation add(Integer)
3. Overriding for Optimization: implementation can take the advantage of the
constraints imposed by restriction to improve the code for an operation e.g. getMax
operation in IntegerSet and SortedIntegerSet
4. Overriding for Convenience: The new class is made a subclass of existing class
and overrides the method that are inconvenient. This adhoc use of inheritance is
semantically wrong and leads to maintenance problems because there is no inherent
relation between the parent and child classes
RULES FOR INHERITANCE

Adherence to following rules of inheritance will make a software easier to

understand, easier to extend and less prone to error:
1. All query operations are inherited by all subclasses
2. All update operations are inherited across all extensions
3. Update operations that change the constrained attributes or associations are
blocked across the restriction e.g scale-x of ellipse is blocked on circle
4. Operation may not be overridden to make them behave differently from
inherited operations. All the methods that implement an operation must have
the same protocol
5. Inherited operations can be refined by adding additional behaviour
MULTIPLE INHERITANCE

 Multiple inheritance permits a class to have more than one superclass and to
inherit features from all parents.
 We can mix information from 2 or more sources.
 This is a more complicated from of generalization than single inheritance, which
restricts the class hierarchy to a tree.
 The advantage of multiple inheritance is greater power in specifying classes and
an increased opportunity for reuse.
 The disadvantage is a loss of conceptual and implementation simplicity.
 In principal all kinds of different mixing rules can be defined to resolve the
conflicts among features defined on different paths.
MULTIPLE INHERITANCE- DEFINITION
 A class may inherit features from more than one class.
 A class with more than one superclass is called a join class.
 A feature from the same ancestor class found along more than one path is
inherited only once; it is the same feature.
 Conflicts among parallel definitions create ambiguities that must be resolved in
implementation.
 Kinds of Multiple Inheritance
1. Multiple Inheritance from overlapping classes
2. Multiple Inheritance from disjoint classes
MULTIPLE INHERITANCE FROM
OVERLAPPING CLASSES
 Each generalization should cover single property , e.g, where vehicle can travel
 A solid triangle indicated overlapping classes
MULTIPLE INHERITANCE FROM DISJOINT
CLASSES

 If a class can be refined on several distinct and independent dimension, then use
multiple generalization
 A hollow triangle indicated disjoint classes
ACCIDENTAL MULTIPLE INHERITANCE

 An instance of a join class is inherently an instance of all the ancestors of the join
class. For example, an instructor is inherently both faculty and student.
 Now consider example a Harvard Professor taking classes at MIT.
 This is example of “accidental” multiple inheritance, in which one instance
happens to participate in two overlapping classes.
 Best approach is a treat Person as object composed of multiple
UniversityMember objects.This workaround replaces inheritance with delegation
 But drawback of this approach is there is loss of identity between the separate
roles
ACCIDENTAL MULTIPLE INHERITANCE
WORKAROUNDS

 Dealing with lack of multiple inheritance is really an implementation issue, but

early restructuring of a model is often the easiest way to work around its
absence.
 Here we list 2 approaches for restructuring techniques (it uses delegation)
 Delegation is an implementation mechanism by which an object forwards an
operation to another object for execution.
 There are three approaches to deal with lack of multiple inheritance
1. Delegation using aggregation of roles
2. Inherit the most important class and delegate the rest
3. Nested generalization
DELEGATION USING AGGREGATION OF
ROLES
 A superclass with multiple independent generalizations can be recast as an
aggregate in which each component replaces the generalization
 In this approach, the various join classes need not be actually be created as
explicit classes.
 All combination of subclasses from different generalizations are possible
DELEGATION USING AGGREGATION OF
ROLES
INHERIT THE MOST IMPORTANT CLASS
AND DELEGATE THE REST
 It makes a join class a subclass of its most important superclass
 The join class is treated as aggregation of the remaining superclasses and their
operations are delegated
 Preserves identity and inheritance across one generalization
NESTED GENERALIZATION

 Factor on one generalization and then the other

 This approach multiplies out all possible combinations
 This approach preserves inheritance but duplicates declarations and code and
violates the spirit of object oriented programming
NESTED GENERALIZATION
ISSUES IN SELECTION OF THE BEST
WORKAROUNDS
 All workarounds compromise logical structure and maintainability
 Some issues should be considered when selecting the best workaround
are:
1. If a subclass has several superclasses, all of equal importance, it may the best to use
delegation and preserve the symmetry in the model
2. If one superclass clearly dominates and others are less important , implementing
multiple inheritance via single inheritance and delegation may be the best
3. If the number of combinations is small, consider nested generalization. If the number
of combinations is large, avoid nested generalization.
4. If one superclass has significantly more features than the other superclasses or one
superclass is clearly the performance bottleneck, preserve the inheritance through
this path
5. If you choose to use the nested generalization, factor on most important criterion
first, the nest most important second and so forth
6. Try to avoid nested generalization, if large quantity of code must be duplicated.
7. Consider the importance of strict identity. Only the nested generalization preserve
this.
METADATA

 Metadata is data that describes other data

 E.g definition of class, models
 Many real world applications have metadata such as part catalogue,
blueprints and dictionaries
 RDBMS also use metadata.
 A person an define the database tables for storing information
 Similarly RDBMS has several metatables that store the table definitions
 Metadata is frequently confusing because it blurs the normal separation
between the model and real world
PATTERNS AND METADATA

 A class describes a set of object instances of a given form.

 Instantiation relates a class to its instances.
 Any pattern describes the example of patterns
 The relationship between pattern and example can be regarded as an extension
of instantiation.
PATTERNS AND METADATA

 Real world things may be metadata. There are real world things that describe other real world things.
 Examples:
1. A part description in catalogue describes manufactured parts
2. A blueprint describes a house
3. An engineering drawing describe a system

 Consider models of cars made by manufacturers

CLASS DESCRIPTORS

 Classes can be considered as objects, but they are metaobjects and not real world objects
 Class descriptor objects have features, and they in turn have their own classes which are called
metaclasses
 A class attribute describes value common to an entire class of objects rather than data
peculiar to the each instance
 A class operation is operation on the class itself e.g create new instance of class, query for
summary information for instances in class
CANDIDATE KEYS

 It is a minimal set of attributes that uniquely identifies an object or link.

 It means you can't discard an attribute from the candidate key and still
distinguish all objects and links
 A class or association may have one or more candidate keys, each of which may
have different combinations and numbers of attributes.
 The object id is always a candidate key for a class. One or more combinations of
related objects are candidate keys for associations.
 A candidate key is delimited with braces in an object model.
 Figure 4.17 compares multiplicity and candidate keys for binary association
 multiplicity and candidate keys have nearly same expressive power for binary
association
CANDIDATE KEYS
CANDIDATE KEYS

 Figure 4.18 shows a ternary association that has one candidate key consisting of
all three objects
 Persons who are programmers use computer languages on Projects
CANDIDATE KEYS

 Figure 4.19 is another example of ternary association

 A student has one advisor at a university. A student may attend more than one
university.A professor may be an advisor at more than one university.
CONSTRAINTS

 Constraints are functional relationships between entities of an object model

 The term entity includes objects, classes, attributes, links and associations
 A constraints restricts the values that entity can assume.
 Simple constraints may be placed in object model. Complex constraints should be
placed in functional model
 Object modelling syntax for constraints is as follows: Constraints are delimitated by
braces and positioned near the constrained entity. A dotted line connects multiple
constrained entities. An arrow may be used to connect a constrained entity to the
entity it depends on. Instantiation is a kind of constraint and therefore uses the same
notation.
 Constraints provide one criterion for measuring the quality of an object model. A
“good” object model captures many constraints through its structure.
CONSTRAINTS ON OBJECTS
CONSTRAINTS ON LINKS

 Multiplicity constrains an association

 It restricts the number of objects related to the given object
 The notation {ordered} indicated that elements of the “many” end of an
association have an explicit order that must be preserved.
GENERAL CONSTRAINTS

 General constraints must be expressed with natural language or equations

 We should draw a dotted line between classes involved in constraints and specify
the details with comments in braces
 Figure 4.22 shows one association may be subset of another
DERIVED OBJECTS, LINKS AND
ATTRIBUTES

 A derived object is defined as a function of one or more objects, which in turn

may be derived. The derivation tree terminates with base objects.
 The derived object is redundant but may be included in object model to ease the
comprehension
 Similarly there are also derived links and derived association
 The notation for derived entity is slash or diagonal line on the corner of a class
box, on an association line or in front of attribute
 The derived value notation is optional and you should show the constraint hat
determines the derived value
 Derived entities are constrained by their base entities and derivation rule
HOMOMORPHISM

 A homomorphism maps between the two associations

 Example :
In a part catalogue for an automobile, catalogue item may contain other catalogue
items. The individual items are also composed of subitems. The contains aggregation on
catalogue items is homomorphism of the contains aggregation on physical items.
HOMOMORPHISM

 In general, homomorphism involves four relationships among four classes

 The homomorphism maps links of one general association (u) into links of another general
association (t) as a many-to-one mapping
 Two instantiation relationships map elements of one class into another:
1. r is many-to-one mapping from class B to class A
2. s is many-to-one mapping from class D to class C
 In the common case , where t is on single class and u is on single class , then A=C, B=D and r=s.
HOMOMORPHISM

 Homomorphism most likely to occur for complex applications that deal with
metadata
 The homomorphism is essentially just an analogy - special type of relationship
between relationships
 Proper use of homomorphism constrain the structure of an object model and
improve the correspondence between the model and the real world.