Sinhgad Institutes

Savitribai Phule Shikshan Prasarak Mandal’s

N B NAVALE SINHGAD COLLEGE OF ENGINEERING, Solapur
(Approved by AICTE & Affiliated to Punyshlok Ahilyadevi Holkar Solapur University)
Opp.Solapur University, Solapur – Pune National Highway, Kegaon, Solapur. Tel: 0217-2500610

Department of Computer Science and Engg.

Name of Teacher : Prof. S. A DHANAWE Paste Your

Photo
Designation : Assistant Prof.

Experience : 6 Years

Qualification : ME (CSE)
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
• Object-oriented modeling 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 structure
and behavior.

• Object-oriented models are useful for understanding problems,

communicating with application experts, modeling enterprises, preparing
documentation, and designing programs and databases.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
What Is Object-Orientation?
• Superficially the term object-oriented (OO) means that we organize software
as a collectionof discrete objects that incorporate both data structure and
behavior.

• This contrasts with previous programming approaches in which data structure

and behavior are only loosely connected.

• There is some dispute about exactly what characteristics are required by an OO

approach, but they generally include four aspects: identity, classification,
inheritance, and polymorphism.

• Identity means that data is quantized into discrete, distinguishable entities

called objects.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
• Objects can be concrete, such as a file in a file system, or conceptual, such as a
scheduling policy in a multiprocessing operating system. Each object has its
own inherent identity.

• In other words, two objects are distinct even if all their attribute values (such
as name and size) are identical.

• In the real world an object simply exists, but within a programming language
each object has a unique handle by which it can be referenced.

• Languages implement the handle in various ways, such as an address, array

index, or artificial number.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
• Classification means that objects with the same data structure (attributes) and
behavior (operations) are grouped into a class.

• A class is an abstraction that describes properties important to an application

and ignores the rest. Any choice of classes is arbitrary and depends on the
application.

• Each class describes a possibly infinite set of individual objects. Each object is
said to be an instance of its class.

• An object has its own value for each attribute but shares the attribute names
and operations with other instances of the class.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
• Inheritance is the sharing of attributes and operations (features) among classes
based on a hierarchical relationship.

• A superclass has general information that subclasses refine and elaborate.

Each subclass incorporates, or inherits, all the features of its superclass and
• adds its own unique features.

• Subclasses need not repeat the features of the superclass. Eg

• The ability to factor out common features of several classes into a superclass
can greatly reduce repetition within designs and programs and is one of the
main advantages of OO technology.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
• Polymorphism means that the same operation may behave differently for
different classes. The move operation, for example, behaves differently for a
pawn than for the queen in a chess game.

• An operation is a procedure or transformation that an object performs or is

subject to An implementation of an operation by a specific class is called a
method.

• Because an OO operator is polymorphic, it may have more than one method

implementing it, each for a different class of object.

• In the real world, an operation is simply an abstraction of analogous behavior

across different kinds of objects.

• Each object “knows how” to perform its own operations.

UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
• Polymorphism means that the same operation may behave differently for
different classes. The move operation, for example, behaves differently for a
pawn than for the queen in a chess game.

• An operation is a procedure or transformation that an object performs or is

subject to An implementation of an operation by a specific class is called a
method.

• Because an OO operator is polymorphic, it may have more than one method

implementing it, each for a different class of object.

• In the real world, an operation is simply an abstraction of analogous behavior

across different kinds of objects.

• Each object “knows how” to perform its own operations.

UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
Modeling Concepts, Not Implementation
• In the past, much of the OO community focused on programming languages,
with the literature emphasizing implementation rather than analysis and
design.

• OO programming languages were first useful in alleviating the inflexibility of

traditional programming languages.

• In a sense, however, this emphasis was a step backward for software

engineering—it focuses excessively on implementation mechanisms, rather
than the underlying thought process that they support.

• The real payoff comes from addressing front-end conceptual issues, rather
than backend implementation details.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
Modeling Concepts, Not Implementation
• Design flaws that surface during implementation are more costly to fix than
those that are found earlier.

• A premature focus on implementation restricts design choices and often leads

to an inferior product.

• An OO development approach encourages software developers to work and

think in terms of the application throughout the software life cycle.

• It is only when the inherent concepts of the application are identified,

organized, and understood that the details of data structures and functions can
be addressed effectively.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
Modeling Concepts, Not Implementation
• OO development is a conceptual process independent of a programming
language until the final stages.

• OO development is fundamentally a way of thinking and not a programming

technique.

• Its greatest benefits come from helping specifiers, developers, and customers
express abstract concepts clearly and communicate them to each other.

• It can serve as a medium for specification, analysis, documentation, and

interfacing, as well as for programming
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
OO Methodology
• We present a process for OO development and a graphical notation for
representing OO concepts.

• The process consists of building a model of an application and then adding

details toit during design.

• The same seamless notation is used from analysis to design to

implementation, so that information added in one stage of development need
not be lost or translated for the next stage.

• The methodology has the following stages.

UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
■ System conception- Software development begins with business analysts or
users conceiving an application and formulating tentative requirements.

■ Analysis-The analyst scrutinizes and rigorously restates the requirements from

system conception by constructing models.

• The analyst must work with the requestor to understand the problem,
because problem statements are rarely complete or correct.

• The analysis model is a concise, precise abstraction of what the desired system
must do, not howit will be done.

• The analysis model should not contain implementation decisions. For

example, a Window class in a workstation windowing system would be
described interms of its visible attributes and operations.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
• The analysis model has two parts: the domain model, a description of the real-
world objects reflected within the system.

• Application model, a description of the parts of the application system itself

that are visible to the user. For example, domain objects for a stockbroker
application might include stock, bond, trade, and commission.

• Application objects might control the execution of trades and present the
results.

• Application experts who are not programmers can understand and criticize a
good model.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
What Is OO Development?
■ System design- The development team devise a high-level strategy—the
system architecture—for solving the application problem.

• They also establish policies that will serve as a default for the subsequent,
more detailed portions of design.

• The system designer must decide what performance characteristics to

optimize, choose a strategy of attacking the problem, and make tentative
resource allocations.

• For example, the system designer might decide that changes to the
workstation screen must be fast and smooth, even when windows are moved
or erased, and choose an appropriate communications protocol and memory
buffering strategy.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
■ Class design.
• The class designer adds details to the analysis model in accordance with the
system design strategy.

• The class designer elaborates both domain and application objects using the
same OO concepts and notation, although they exist on different conceptual
planes.

• The focus of class design is the data structures and algorithms needed to
implement each class.

• For example, the class designer now determines data structures and
algorithms for each of the operations of the Window class.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
■ Implementation.
• Implementers translate the classes and relationships developed during class
design into a particular programming language, database, or hardware.

• Programming should be straightforward, because all of the hard decisions

should have already been made.

• 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.

• For example, implementers would code the Window class in a programming

language, using calls to the underlying graphics system on the workstation.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
Three Models
• We use three kinds of models to describe a system from different viewpoints:
the class model for the objects in the system and their relationships.

• The state model for the life history of objects;

• The interaction model for the interactions among objects.

• Each model applies during all stages of development and acquires detail as
development progresses.

• A complete description of a system requires models from all three viewpoints.

UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
1. Class Model
• The class model describes the static structure of the objects in a system and
their relationships.

• The class model defines the context for software development—the universe
of discourse.

• The class model contains class diagrams. A class diagram is a graph whose
nodesare classes and whose arcs are relationships among classes.

2. State Model
• The state model describes the aspects of an object that change over time.

• The state model specifies and implements control with state diagrams.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
• A state diagram is a graph whose nodes are states and whose arcs are
transitions between states caused by events.

3. Interaction Model
• The interaction model describes how the objects in a system cooperate to
achieve broader results.

• The interaction model starts with use cases that are then elaborated with
sequence and activity diagrams.

• A use case focuses on the functionality of a system that is, what a system does
for users.

• A sequence diagram shows the objects that interact and the time sequence of
their interactions.
UNIT 1: Introduction to Object Oriented approach and
Object Modelling.
• An activity diagram elaborates important processing steps.

• The three models are separate parts of the description of a complete system
but are cross-linked.

• The class model is most fundamental, because it is necessary to describe what

is changing or transforming before describing when or how it changes.
 OO Themes
• Several themes pervade OO technology. Although these themes are not unique to OO
systems, they are particularly well supported.

1. Abstraction
• Abstraction lets you focus on essential aspects of an application while ignoring details.

• This means focusing on what an object is and does, before deciding how to implement it.

• Use ofabstraction preserves the freedom to make decisions as long as possible by

avoiding premature commitments to details.

• Most modern languages provide data abstraction, but inheritance and polymorphism add
power.

• The ability to abstract is probably the most important skill required for OO development.
2. Encapsulation
• Encapsulation (also information hiding) separates the external aspects of an object, that
are accessible to other objects, from the internal implementation details, that are hidden
from other objects.

• Encapsulation prevents portions of a program from becoming so interdependent that a

small change has massive ripple effects.

• You can change an object’s implementa-tion without affecting the applications that use it.

• You may want to change the implementation of an object to improve performance, fix a
bug, consolidate code, or support porting.

• Encapsulation is not unique to OO languages, but the ability to combine data structure
and behavior in a single entity makes encapsulation cleaner and more powerful than in
prior languages, such as Fortran, Cobol, and C.
3. Combining Data and Behavior
• The caller of an operation need not consider how many implementations exist.
Operator polymorphism shifts the burden of deciding what implementation to use
from the calling code to the class hierarchy.

• For example, non-OO code to display the contents of a window must distinguish the
type of each figure, such as polygon, circle, or text, and call the appropriate procedure
to display it.

• An OO program would simply invoke the draw operation on each figure; each object
implicitly decides which procedure to use, based on its class.

• Maintenance is easier, because the calling code need not be modified when a new
class is added.

• In an OO system, the data structure hierarchy matches the operation inheritance

hierarchy
4. Sharing
• OO techniques promote sharing at different levels. Inheritance of both data structure
and behavior lets subclasses share common code. This sharing via inheritance is one of
the main advantages of OO languages.

• More important than the savings in code is the conceptual clarity from recognizing that
different operations are all really the same thing.

• This reduces the number of distinct cases that you must understand and analyze.
• OO development not only lets you share information within an application, but also
offers the prospect of reusing designs and code on future projects.

• OO development provides the tools, such as abstraction, encapsulation, and

inheritance, to build libraries of reusable components.

• Reuse does not just happen; developers must plan by thinking beyond the immediate
application and investing extra effort in a more general design.
5 Emphasis on the Essence of an Object
• OO technology stresses what an object is, rather than how it is used.

• The uses of an object depend on the details of the application and often change during
development.

• As requirements evolve, the features supplied by an object are much more stable than
the ways it is used, hence software systems built on object structure are more stable in
the long run.

• OO development places a greater emphasis on data structure and a lesser emphasis on

procedure structure than functional-decomposition methodologies.

• In this respect, OO development is similar to information modeling techniques used in

database design, although OO development adds the concept of class-dependent
behavior.
6. Synergy
• Identity, classification, polymorphism, and inheritance characterize OO languages.
•
• Each ofthese concepts can be used in isolation, but together they complement each
other synergistically.

• The benefits of an OO approach are greater than they might seem at first.

• The emphasis on the essential properties of an object forces the developer to think
more carefully and deeply about what an object is and does.

• The resulting system tends to be cleaner, more general,and more robust than it would
be if the emphasis were only on the use of data and operations.
 Class Modeling

• A class model captures the static structure of a system by characterizing the

objects in the system, the relationships between the objects, and the
attributes and operations for each class of objects.

• The class model is the most important of the three models.

• We emphasize building a system around objects rather than around

functionality, because an object-oriented system more closely corresponds to
the real world and is consequently more resilient with respect to change.

• Class models provide an intuitive graphic representation of a system and are

valu_x0002_able for communicating with customers.
 Object and Class Concepts
• The purpose of class modeling is to describe objects.

• An object is a concept, abstraction, or thing with identity that has meaning for
an application.

• Objects often appear as proper nouns or specific references in problem

descriptions and discussions with users.

• Objects can be a real world entity or conceptual entity.

• The choice of objects depends on judgment and the nature of a problem;there

can be many correct representations.

• All objects have identity and are distinguishable. The term identity means that
objects are distinguished by their inherent existence and not by descriptive
properties that they may have.
 Object and Class Concepts
• An object is an instance—or occurrence—of a class. A class describes a
group of objects with the same properties (attributes), behavior (operations),
kinds of relationships, and semantics.

• Each process has an owner, priority, and list of required resources. Classes
often appear as common nouns and noun phrases in problem descriptions
and discussions with users.

• The notion of abstraction is at the heart of the matter. By grouping objects into
classes, we abstract a problem. Abstraction gives modeling its power and
ability to generalize from a few specific cases to a host of similar cases.

• Common definitions (such as class name and attribute names) are stored
once per class rather than once per instance. You can write operations once
for each class, so that all the objects in the class benefit from code reuse.
 Class Diagrams
• Class diagrams provide a graphic notation for modeling classes and their
relationships, thereby describing possible objects.

• Class diagrams are useful both for abstract modeling and for designing actual
programs. They are concise, easy to understand, and work well in practice.

• We will also occasionally use object diagrams. An object diagram shows

individual objects and their relationships.

• Object diagrams are helpful for documenting test cases and discussing
examples. A class diagram corresponds to an infinite set of object diagrams.

• The UML symbol for a class also is a box. Our convention is to list the class
name in boldface, center the name in the box, and capitalize the first letter. We
use singular nouns for the names of classes.

• Class Representation:
 Values and Attributes
• A value is a piece of data. You can find values by examining problem
documentation for examples.

• An attribute is a named property of a class that describes a value held by each

object of the class.

• You can find attributes by looking for adjectives or by abstracting typical

values.

• Each attribute has a value for each object.

• Different objects may have the same or different values for a given attribute.
Each attribute name is unique within a class
 Values and Attributes
• The UML notation lists attributes in the second compartment of the class box.
Optional details, such as type and default value, may follow each attribute. A
colon precedes the type.

• An equal sign precedes the default value. Our convention is to show the
attribute name in regular face, left align the name in the box, and use a
lowercase letter for the first letter.

• You may also include attribute values in the second compartment of object
boxes. The notation is to list each attribute name followed by an equal sign
and the value.

• We also left align attribute values and use regular type face.
 Values and Attributes

• Some implementation media require that an object have a unique identifier.

These identifiers are implicit in a class model—you need not and should not
list them explicitly

Fig: Object identifiers. Do not list object identifiers; they are implicit in models.
 Operations and Methods
• An operation is a function or procedure that may be applied to or by objects in
a class.

E.X: Hire,fire, and payDividend are operations on class Company. Open, close,
hide, and redisplay are operations on class Window. All objects in a class share
the same operations.

• Each operation has a target object as an implicit argument. The behavior of

the operation depends on the class of its target. An object “knows” its class,
and hence the right implementation of the operation.

• The same operation may apply to many different classes. Such an operation is
polymorphic; that is, the same operation takes on different forms in different
classes. A method is the implementation of an operation for a class.
 Operations and Methods
• For example, the class File may have an operation print. You could implement
different methods to print ASCII files, print binary files, and print digitized
picture files. All these methods logically perform the same task—printing a
file; thus you may refer to them by the generic operation print. However, a
different piece of code may implement each method.

Fig:Operations. An operation is a function or procedure that may be applied to or

by objects in a class.
Links and Associations
• A link is a physical or conceptual connection among objects. For example, Joe Smith
Works For Simplex company. Most links relate two objects, but some links relate three or
more objects.

• Mathematically, we define a link as a tuple—that is, a list of objects. A link is an instance

of an association.

• An association is a description of a group of links with common structure and common

semantics. For example, a person WorksFor a company.

• The links of an association connect objects from the same classes.

• An association describes a set of potential links in the same way that a class describes a
set of potential objects.

• Links and associations often appear as verbs in problem statements.

Links and Associations
• A link is a physical or conceptual connection among objects. For example, Joe Smith
Works For Simplex company. Most links relate two objects, but some links relate three or
more objects.

• Mathematically, we define a link as a tuple—that is, a list of objects. A link is an instance

of an association.

• An association is a description of a group of links with common structure and common

semantics. For example, a person WorksFor a company.

• The links of an association connect objects from the same classes.

• An association describes a set of potential links in the same way that a class describes a
set of potential objects.

• Links and associations often appear as verbs in problem statements.

Many-to-many association. An association describes a set of potential links in the same
way that a class describes a set of potential objects
Multiplicity
• Multiplicity specifies the number of instances of one class that may relate to a single
instance of an associated class. Multiplicity constrains the number of related objects.

• The literature often describes multiplicity as being “one” or “many,” but more
generally it is a (possibly infinite) subset of the nonnegative integers.

• UML diagrams explicitly list multiplicity at the ends of association lines. The UML
specifies multiplicity with an interval, such as “1” (ex_x0002_actly one), “1..*” (one or
more), or “3..5” (three to five, inclusive).

• The special symbol “*” is a shorthand notation that denotes “many” (zero or more).
 Multiplicity
• Multiplicity depends on assumptions and how you define the boundaries of a problem.

• Vague requirements often make multiplicity uncertain. Do not worry excessively about
multiplicity early in software development.

• First determine classes and associations, then decide on multiplicity.

• If you omit multiplicity notation from a diagram, multiplicity is considered to be unspecified.

 Association End Names
• multiplicity implicitly referred to the ends of associations. For example, a one-to-many
association has two ends—an end with a multiplicity of “one” and an end with a multiplicity of
“many.”

• The notion of an association end is an important concept in the UML. You can not only assign
a multiplicity to an association end, but you can give it a name as well.

• Association end names often appear as nouns in problem descriptions.

• Use of association end names is optional, but it is often easier and less confusing to assign
association end names instead of, or in addition to, association names.
 Association End Names
• Association end names are especially convenient for traversing associations, because you
can treat each one as a pseudo attribute.
• Each end of a binary association refers to an object or set of objects associated with a source
object.
• From the point of view of the source object, traversal of the association is an operation that
yields related objects.
• Association end names provide a means of traversing an association, without explicitly
mentioning the association.
• Association end names are necessary for associations between two objects of the same
class.
 Ordering
• Often the objects on a “many” association end have no explicit order, and you
can regard them as a set.

• Sometimes, however, the objects have an explicit order.

• The ordering is an inherent part of the association.

• You can indicate an ordered set of objects by writing “{ordered}” next to the
appropriate association end.
 Ordering
• Ordinarily a binary association has at most one link for a pair of objects. However, you
canpermit multiple links for a pair of objects by annotating an association end with {bag} or
{sequence}

• A bag is a collection of elements with duplicates allowed.

• A sequence is an ordered collection of elements with duplicates allowed.

• In Figure an itinerary is a sequence of airports and the same airport can be visited more than
once.
• Like the {ordered} indication,{bag} and {sequence} are permitted only for binary associations.

• Note: that the {ordered} and the {sequence} annotations are the same, except that the first
disallows duplicates and the other allows them. A sequence association is an ordered
bag,while an ordered association is an ordered set.
 Qualified Associations
• A qualified association is an association in which an attribute called the qualifier
disambiguates the objects for a “many” association end.

• It is possible to define qualifiers for one-to-many and many-to-many associations.

• A qualifier selects among the target objects, reducing the effective multiplicity, from
“many” to “one.”

• Qualified associations with a target multiplicity of “one” or “zero-or-one” specify a precise

path for finding the target object from the source object.

• Figure illustrates the most common use of a qualifier— for associations with one-to-many
multiplicity.
 Qualified Associations

• A bank services multiple accounts. An account belongs to a single bank.

• Within the context of a bank, the account number specifies a unique account.
• Bank and Account are classes and accountNumber is the qualifier.
• Qualification reduces the effective multiplicity of this association from one-to-many to
one-to-one.
 Generalization & Inheritance
• Generalization is the relationship between a class (the superclass) and one or more
variations of the class (the subclasses). Generalization organizes classes by their
similarities and differences, structuring the description of objects.

• The superclass holds common attributes, operations, and associations; the subclasses add
specific attributes, operations, and associations. Each subclass is said to inherit the
features of its superclass.

• Generalization is sometimes called the “is-a” relationship, because each instance of a

subclass is an instance of the superclass as well.

• Simple generalization organizes classes into a hierarchy; each subclass has a single
immediate superclass. There can be multiple levels of generalizations.
• Generalization is transitive across an arbitrary number of levels. The terms ancestor and
descendant refer to generalization of classes across multiple levels.
 Generalization & Inheritance
• An instance of a subclass is simultaneously an instance of all its ancestor
classes.

• An instance includes a value for every attribute of every ancestor class.

• An instance can invoke any operation on any ancestor class.

• Each subclass not only inherits all the features of its ancestors but adds its
own specific features as well.
 Abstract Class
• An abstract class is a class that has no direct instances but whose
descendant classes have direct instances.
• A concrete class is a class that is instantiable; that is, it can have direct
instances.

• In the UML notation an abstract class name is listed in an italic font. Or you
may place the keyword {abstract} below or after the name.
• An abstract operation is designated by italics or the keyword {abstract}
 Multiple Inheritance
• Multiple inheritance permits a class to have more than one superclass and to
inherit features from all parents. Then you can mix information from two or
more sources.

• 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.

• The term multiple inheritance is used somewhat imprecisely to mean either

the conceptual relationship between classes or the language mechanism that
implements that relationship.
 Kinds of Multiple Inheritance
• The most common form of multiple inheritance is from sets of disjoint
classes.
• Each subclass inherits from one class in each set.
 Kinds of Multiple Inheritance
• Multiple inheritance can also occur with overlapping classes.

• The UML uses a constraint to indicate an overlapping generalization set; the

notation is a dotted line cutting across the affected generalizations with
keywords in braces.
 Constraints
• A constraint is a boolean condition involving model elements, such as
objects, classes, attributes, links, associations, and generalization sets.
• A constraint restricts the values that elements can assume.
• You can express constraints with natural language or a formal language such
as the Object Constraint Language.

1. Constraints on Objects:
 Constraints
2. Constraints on Generalization Sets
UML defines the following keywords for generalization sets.
■ Disjoint: The subclasses are mutually exclusive. Each object belongs to
exactly one of the subclasses.

■ Overlapping: The subclasses can share some objects. An object may belong to
more than one subclass.

■ Complete: The generalization lists all the possible subclasses.

■ Incomplete: The generalization may be missing some subclasses.

 Constraints
3. Constraints on Links

■ Multiplicity: It is a constraint on the cardinality of a set. Multiplicity for an

association restricts the number of objects related to a given object. Multiplicity
for an attribute specifies the number of values that are possible for each
instantiation of an attribute.

■ Qualification: It is also constrains an association. A qualifier attribute does not

merely describe the links of an association but is also significant in resolving the
“many” objects at an association end.

■ Association class: An association class implies a constraint.

■ ordinary association: An ordinary association presumes no particular order

on the objects of a “many” end. The constraint {ordered} indicates that the
elements of a “many” association end have an explicit order that must be
preserved.
2. Generalization as Extension
Here, the subclass extends the functionality of the superclass.

•Meaning:
The subclass inherits all attributes and operations of the superclass and adds new
features.

•Focus: Adding extra capabilities beyond what the parent provides.

•Real-world analogy:
A Smartphone is a Phone but with added capabilities (Internet, Apps, Camera).

•Effect:
The subclass is a superset of the superclass in terms of behavior.
Example:
Superclass:Vehicle
Attributes:make,model,year
Methods:start(),stop()

Subclass:ElectricCar(extendsVehicle)
Additional Attributes:batteryCapacity
Additional Methods:chargeBattery()
UML:
Vehicle
↑
ElectricCar

Here, ElectricCar inherits everything from Vehicle and extends with batteryCapacity &
chargeBattery().
Key points for Extension:

•Increases specialization.

•Preserves the "is-a" relationship.

•Common in frameworks when we "extend" base classes to add new features.

Generalization as Restriction
Here, the subclass restricts the scope of the superclass.

•Meaning:
The subclass inherits from the superclass but removes, limits, or specializes certain
behavior.

•Focus: Narrowing the set of valid instances or operations.

•Real-world analogy:
A TwoWheeler is a Vehicle but restricted to exactly 2 wheels (where Vehicle can have any
number of wheels).

•Effect:
The subclass represents a more constrained form of the superclass.
Superclass: Account
Attributes: accountNumber, balance
Methods: deposit(), withdraw()

Subclass: FixedDepositAccount (restriction)

Restriction: withdraw() allowed only after maturity date
UML:
Account
↑
FixedDepositAccount
Here, FixedDepositAccount restricts the withdraw() behavior.

Key points for Restriction:

1. Tightens rules or constraints.
2. Still "is-a" relationship, but with narrower applicability.
3. Common in domain modeling when defining specialized variants of a general entity.
Aspect Extension Restriction

Narrow existing
Purpose Add new functionality functionality

Superset of superclass Subset of superclass

Effect on Subclass features features

ElectricCar extends Vehicle FixedDepositAccount limits

Example with battery features withdrawal options

Need to enhance base class Need to enforce stricter

When to use behavior rules or constraints