OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

UNIT-I:
Introduction: The Structure of Complex systems, The Inherent Complexity of Software,
Attributes of Complex System, Organized and Disorganized Complexity, Bringing Order
toChaos, Designing Complex Systems, Evolution of Object Model, Foundation of Object
Model,Elements of Object Model, Applying the Object Model.

Introduction:
Systems: Systems are constructed by interconnecting components (Boundaries, Environments,
Characters, Emergent Properties), which may well be systems in their own right. The larger the
number of these components and relationships between them, higher will be the complexity of
the overall system.
Software Systems: Software systems are not any different from other systems with respect to
these characteristics. Thus, they are also embedded within some operational environment, and
perform operations which are clearly defined and distinguished from the operations of other
systems in this environment. They also have properties which emerge from the interactions of
their components and/or the interactions of themselves with other systems in their environment.
A system that embodies one or more software subsystems which contribute to or control a
significant part of its overall behavior is what we call a software intensive system.
Examples of complex software- intensive systems, we may consider stock and production
control systems, aviation systems, rail systems, banking systems, health care systems and so on.
Complexity: Complexity depends on the number of the components embedded in them as well
as the relationships and the interactions between these components which carry;
• Impossible for humans to comprehend(grasp) fully
• Difficult to document and test
• Potentially inconsistent or incomplete
• Subject to change
• No fundamental laws to explain phenomena and approaches

The structure of Complex Systems

Examples of Complex Systems: The structure of personal computer, plants and animals, matter,
social institutions are some examples of complex system.
The structure of a Personal Computer: A personal computer is a device of moderate
complexity. Major elements are CPU, monitor, keyboard and some secondary storage devices.
CPU encompasses primary memory, an ALU, and a bus to which peripheral devices are
attached. An ALU may be divided into registers which are constructed from NAND gates,
inverters and so on. All are the hierarchical nature of a complex system.
The structure of Plants: Plants are complex multi cellular organism which are composed of
cells which is turn encompasses elements such as chloroplasts, nucleus, and so on. For example,
at the highest level of abstraction, roots are responsible for absorbing water and minerals from
the soil. Roots interact with stems, which transport these raw materials up to the leaves. The
leaves in turn use water and minerals provided by stems to produce food through photosynthesis.
The structure of Animals: Animals exhibit a multicultural hierarchical structure in which
collection of cells form tissues, tissues work together as organs, clusters of organs define systems
(such as the digestive system) and so on.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 1

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

The structure of Matter: Nuclear physicists are concerned with a structural hierarchy of matter.
Atoms are made up of electrons, protons and neutrons. Elements and elementary particles but
protons, neutrons and other particles are formed from more basic components called quarks,
which eventually formed from pro-quarks.
The structure of Social institutions: In social institutions, group of people join together to
accomplish tasks that can be done by made of divisions which in turn contain branches which in
turn encompass local offices and so on.

The Inherent Complexity of Software

The Properties of Complex and Simple Software Systems: Software may involve elements of
great complexity which is of different kind.
Some software systems are simple.
• These are the largely forgettable applications that are specified, constructed, maintained,
and used by the same person, the professional developer working in isolation.
• Such systems tend to have a very limited purpose and a very short life span.
• We can afford to throw them away and replace them with entirely new software rather than
attempt to reuse them, repair them, or extend their functionality, Such applications are
generally more tedious(dull) than difficult to develop; consequently, learning how to
design them does not interest us.

Some software systems are complex.

• The applications that exhibit a very rich set of behaviors
Ex: railway traffic.
• Software systems such as world of industrial strength software tend to have a long life span,
and over time, many users come to depend upon their proper functioning.
• The frameworks that simplify the creation of domain-specific applications, and programs
that mimic(imitate) some aspect of human intelligence.

Why Software is inherently(essentially)Complex

The complexity of software is an essential property not an accidental one. The inherent
complexity derives from four elements; the complexity of the problem domain, the difficultly of
managing the developmental process, the flexibility possible through software and the
problems of characterizing the behavior of discrete systems.

1.The complexity of the problem domain

• Complex requirements
• Decay(decompose) of system
The first reason has to do with the relationship between the application domains for which
software systems are being constructed and the people who develop them. Often, although
software developers have the knowledge and skills required to develop software they usually
lack detailed knowledge of the application domain of such systems. This affects their ability to
understand and express accurately the requirements for the system to be built which come from
the particular domain.
Complexity is often increased as a result of trying to preserve(protect) the investments made in
legacy applications. In such cases, the components which address new requirements have to be

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 2

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

integrated with existing legacy applications. This results into interoperability problems caused by
the heterogeneity of the different components which introduce new complexities.

2. The Difficulty of Managing the Development Process

• Management problems
• Need of simplicity
The second reason is the complexity of the software development process. Complex software
intensive systems cannot be developed by single individuals. They require teams of developers.
This adds extra overhead to the process since the developers have to communicate with each
other about the intermediate artifacts they produce and make them interoperable with each other.
This complexity often gets even more difficult to handle if the teams do not work in one location
but are geographically dispersed. In such situations, the management of these processes becomes
an important subtask on its own and they need to be kept as simple as possible.
None person can understand the system whose size is measured in hundreds of thousands, or
even millions of lines of code. Even if we decompose our implementation in meaningful ways,
we still end up with hundreds and sometimes even thousand modules. The amount of work
demands that we use a team of developers and there are always significant challenges associated
with team development more developers means more complex communication and hence more
difficult coordination.
3. The flexibility possible through software
• Software is flexible and expressive and thus encourages highly demanding
requirements, which in turn lead to complex implementations which are difficult
to assess
The third reason is the danger of flexibility. Flexibility leads to an attitude where developers
develop system components themselves rather than purchasing them from somewhere else.
Unlike other industrial sectors, the production depth of the software industry is very large. The
construction or automobile industries largely rely on highly specialized suppliers providing parts.
The developers in these industries just produce the design, the part specifications and assemble
the parts delivered. The software development is different: most of the software companies
develop every single component from scratch. Flexibility also triggers more demanding
requirements which make products even more complicated.
4. The problem of characterizing the behavior of discrete (distinct) systems
Numerous possible states
• Difficult to express all states
The final reason for complexity according to Booch is related to the difficulty in describing the
behavior of software systems. Humans are capable of describing the static structure and
properties of complex systems if they are properly decomposed, but have problems in describing
their behavior. This is because to describe behavior, it is not sufficient to list the properties of the
system. It is also necessary to describe the sequence of the values that these properties take over
time.
Within a large application, there may be hundreds or even thousands of variables aswell as more
than one thread of control. The entire collection of these variables as well as their current values
and the current address within the system constitute the present state of the system with discrete
states. Discrete systems by their very nature have a finite numbers of possible states.
The Consequences of Un controlled Complexity
• Late, over budget and deficient (lacking) in their states requirements

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 3

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

• Run away projects

• Loss of resources
• To master software complexity, We need to study other complex systems

Attributes of a complex system

The five Attributes of a complex system: There are five attributes common to all complex
systems. They are as follows:
1.Hierarchical and interacting subsystems
Frequently,complexity takes the form of a hierarchy, whereby a complex system is composed of
interrelated subsystems that have in turn their own subsystems and so on, until some lowest
level of elementary components is reached.
2. Arbitrary determination of primitive components
• The choice of what components in a system are primitive is relatively arbitrary
(subjective) and is largely up to the discretion of the observer of the system
• primitive for one observer may be at a much higher level of abstraction for another
3. Separation concerns(Stronger intra-component than inter-component link)
Intra-component linkages are generally stronger than inter-component linkages. This fact has the
involving the high frequency dynamics of the components-involving the internal structure
of the components – from the low frequency dynamic involving interaction among
components.
4.Common patterns(Combine and arrange common rearranging subsystems)
Hierarchic systems are usually composed of only a few different kinds of subsystems in various
combinations and arrangements. In other words, complex systems have common patterns.
These patterns may involve the reuse of small components such as the cells found in both
plants or animals, or of larger structures, such as vascular systems, also found in both
plants and animals.
5. Evolution from simple to complex systems
A complex system that works is invariably bound to have evolved from a simple system that
worked ……….. A complex system designed from scratch never works and can't be
patched up to make it work. You have to start over, beginning with a working simple
system.
Organized and Disorganized Complexity
One mechanism to simplify concerns in order to make them more manageable is to
identify and understand abstractions common to similar objects or activities. We can use a car
as an example (which are considerable complex systems). Understanding common abstractions
in this particular example would, for instance, involve the insight that clutch, accelerator and
brakes facilitate the use of a wide range of devices, namely transport vehicles depending on
transmission of power from engine to wheels).
Another principle to understand complex systems is the separation of concerns leading to
multiple hierarchies that are orthogonal to each other. In the car example, this could be, for
instance, the distinction between physical structure of the car (chassis, body, engine), functions
the car performs (forward, back, turn) and control systems the car has (manual, mechanical, and
electrical). In object-orientation, the class structure and the object structure relationship is the
simplest form of related hierarchy. It forms a canonical representation for object oriented
analysis.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 4

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

The canonical form of a complex system – the discovery of common abstractions and
mechanisms greatly facilitates are standing of complex system. For example, if a pilot already
knows how to fly a given aircraft, it is easier to know how to fly a similar one. May different
hierarchies are present within the complex system. For example an aircraft may be studied by
decomposing it into its propulsion system. Flight control system and so on the decomposition
represent a structural or "part of" hierarchy. The complex system also includes an "Is A"
hierarchy. These hierodules for class structure and object structure combining the concept of the
class and object structure together with the five attributes of complex system, we find that
virtually all complex system take on the same (canonical) form as shown in figure. There are two
orthogonal hierarchies of system, its class structure and the object structure.

The figure 1.1 represents the relationship between two different hierarchies: a hierarchy of
objects and a hierarchy of classes. The class structure defines the 'is-a' hierarchy, identifying the
commonalities between different classes at different levels of abstractions. Hence class C4 is also
a class C1 and therefore has every single property that C1 has. C4, however, may have more
specific properties that C1 does not have; hence the distinction between C1 and C4. The object
structure defines the 'part-of' representation. This identifies the composition of an object from
component objects, like a car is composed from wheels, a steering wheel, a chassis and an
engine. The two hierarchies are not entirely orthogonal as objects are instances of certain classes.
The relationship between these two hierarchies is shown by identifying the instance-of
relationship as well. The objects in component D8 are instances of C6 and C7 As suggested by
the diagram, there are many more objects then there are classes. The point in identifying classes
is therefore to have a vehicle to describe only once all properties that all instances of the class
have.

Example:
• More than one type of hierarchies may be present in complex system
• Computer (Part of)
• CPU, Input Devices, Output Devices

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 5

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

• ALU, CU, Registers

• Gates
• VS
• Computer (is a)
• Desktop, Laptop, Super Computer
• Intel, Mac
i7, i5, Pentium, 486
Approaching a Solution
Hampered by human limitations
• dealing with complexities
• memory
• communications
When we devise a methodology for the analysis and design of complex systems, we need to bear
in mind the limitations of human beings, who will be the main acting agents, especially during
early phases. Unlike computers, human beings are rather limited in dealing with complex
problems and any method need to bear that in mind and give as much support as possible.
Human beings are able to understand and remember fairly complex diagrams, though linear
notations expressing the same concepts are not dealt with so easily. This is why many methods
rely on diagramming techniques as a basis. The human mind is also rather limited. Miller
revealed in 1956 that humans can only remember 7 plus or minus one item at once. Methods
should therefore encourage its users to bear these limitations in mind and not deploy overly
complex diagrams.
The analysis process is a communication intensive process where the analyst has to have
intensive communications with the stakeholders who hold the domain knowledge. Also the
design process is a communication intensive process, since the different agents involved in the
design need to agree on decompositions of the system into different hierarchies that are
consistent with each other.
The Limitations of the human capacity for dealing with complexity: Object model is the
organized complexity of software. As we begin to analyze a complex software system, we find
many parts that must interact in a multitude of intricate ways with little commonality among
either the parts or their interactions. This is an example of disorganized complexity. In complex
system, we find many parts that must interact in a multitude of intricate ways with little
commonality among either the parts or their intricate. This is an example in an air traffic control
system, we must deal with states of different aircraft at once, and involving such it is absolutely
impossible for a single person to keep track of all these details at once.

Bringing Order to chaos

Principles that will provide basis for development
• Abstraction
• Hierarchy
• Decomposition
The Role of Abstraction: Abstraction is an exceptionally powerful technique for dealing with
complexity. Unable to master the entirely of a complex object, we choose to ignore its inessential
details, dealing instead with the generalized, idealized model of the object. For example, when
studying about how photosynthesis works in a plant, we can focus upon the chemical reactions in

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 6

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

certain cells in a leaf and ignore all other parts such as roots and stems. Objects are abstractions
of entities in the real world.
In general abstraction assists people's understanding by grouping, generalizing and chunking
information.
Object-orientation attempts to deploy abstraction. The common properties of similar objects are
defined in an abstract way in terms of a class. Properties that different classes have in common
are identified in more abstract classes and then an ‘is-a’ relationship defines the inheritance
between these classes.
The role of Hierarchy: Identifying the hierarchies within a complex software system makes
understanding of the system very simple. The object structure is important because it illustrates
how different objects collaborate with one another through pattern of interaction (called
mechanisms). By classifying objects into groups of related abstractions (for example, kinds of
plant cells versus animal cells, we come to explicitly distinguish the common and distinct
properties of different objects, which helps to master their inherent complexity.
Different hierarchies support the recognition of higher and lower orders. A class high in the ‘is-
a’ hierarchy is a rather abstract concept and a class that is a leaf represents a fairly concrete
concept. The ‘is-a’ hierarchy also identifies concepts, such as attributes or operations, that are
common to a number of classes and instances thereof. Similarly, an object that is up in the part-
of hierarchy represents a rather coarse-grained and complex objects, assembled from a number of
objects, while objects that are leafs are rather fine grained. But note that there are many other
forms of patterns which are non hierarchical: interactions, ‘relationships’.
The role of Decomposition: Decomposition is important techniques for copying with
complexity based on the idea of divide and conquer. In dividing a problem into a sub problem
the problem becomes less complex and easier to overlook and to deal with. Repeatedly dividing
a problem will eventually lead to sub problems that are small enough so that they can be
conquered. After all the sub problems have been conquered and solutions to them have been
found, the solutions need to be composed in order to obtain the solution of the whole problem.
The history of computing has seen two forms of decomposition, process-oriented (Algorithmic)
and object-oriented decomposition.
1.Algorithmic (Process Oriented) Decomposition: In Algorithmic decomposition, each module
in the system denotes a major step in some overall process.

2.Object oriented decomposition: Objects are identified as Master file and check sum which derive
directly from the vocabulary of the problem as shown in figure. We know the world as a set of
autonomous agents that collaborate to perform some higher level behavior. Get formatted update thus
does not exist as an independent algorithm; rather it is an operation associated with the object file of

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 7

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

updates. Calling this operation creates another object, update to card. In this manner, each object in
our solution embodies its own unique behavior .Each hierarchy in layered with the more abstract
classes and objects built upon more primitive ones especially among the parts of the object structure,
object in the real world. Here decomposition is based on objects and not algorithms.

Designing Complex Systems

Engineering as a Science and an Art: Every engineering discipline involves elements of both
science and art. The programming challenge is a large scale exercise in applied abstraction and thus
requires the abilities of the formal mathematician blended with the attribute of the competent
engineer. The role of the engineer as artist is particularly challenging when the task is to design an
entirely new system.
The meaning of Design: In every engineering discipline, design encompasses the discipline
approach we use to invent a solution for some problem, thus providing a path from requirements to
implementation. The purpose of design is to construct a system that.
1. Satisfies a given (perhaps) informal functional specification
2.Conforms to limitations of the target medium
3.Meets implicit or explicit requirements on performance and resource usage
4. Satisfies implicit or explicit design criteria on the form of the artifact
5. Satisfies restrictions on the design process itself, such as its length or cost, or the available
fordoing the design. According to Stroustrup, the purpose of design is to create a clean and
relatively simple internal structure, sometimes also called as architecture. A design is the end
product of the design process.
The Importance of Model Building: The buildings of models have a broad acceptance among all
engineering disciplines largely because model building appeals to the principles of decomposition,
abstraction and hierarchy. Each model within a design describes a specific aspect of the system under
consideration. Models give us the opportunity to fail under controlled conditions. We evaluate each
model under both expected and unusual situations and then after them when they fail to behave as we
expect or desire. More than one kind of model is used on order to express all the subtleties of a
complex system.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 8

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

The Elements of Software design Methods: Design of complex software system involves an
incremental and iterative process. Each method includes the following:
1. Notation: The language for expressing each model.
2. Process: The activities leading to the orderly construction of the system's mode.
3. Tools: The artifacts that eliminate the medium of model building and enforce rules about the
models themselves, so that errors and inconsistencies can be exposed.

The models of Object Oriented Development: The models of object oriented analysis and
design reflect the importance of explicitly capturing both the class and object hierarchies of
the system under design. These models also over the spectrum of the important design
decisions that we must consider in developing a complex system and so encourage us to craft
implementations that embody the five attributes of well formed complex systems.

The Object Model

The elements of the object oriented technology collectively known as the object model. The object
model encompasses the principles of abstraction, encapsulation, modularity, hierarchy, typing,
concurrency and persistency. The object model brought together these elements in a synergistic way.
The Evolution of the object Model
- The shift in focus from programming-in-the-small to programming-in-the-large.
- The evolution of high-order programming languages.
- New industrial strength software systems are larger and more complex than their predecessors.
- Development of more expressive programming languages advances the decomposition, abstraction
and hierarchy.
- Wegner has classified some of more popular programming languages in generations according to
the language features.
The generation of programming languages
1. First generation languages (1954 – 1958)
- Used for specific & engineering application.
- Generally consists of mathematical expressions.
- For example: FORTRAN I, ALGOL 58, Flowmatic, IPLV etc.
2. Second generation languages (1959 – 1961)
- Emphasized on algorithmic abstraction.
- FORTRAN II - having features of subroutines, separate compilation
- ALGOL 60 - having features of block structure, data type
- COBOL - having features of data, descriptions, file handing
- LISP - List processing, pointers, garbage collection
3. Third generation languages (1962 – 1970)

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 9

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

- Supports data abstraction.

- PL/1 – FORTRAN + ALGOL + COBOL
- ALGOL 68 – Rigorous successor to ALGOL 60
- Pascal – Simple successor to ALGOL 60
- Simula - Classes, data abstraction
4. The generation gap (1970 – 1980)
- C – Efficient, small executables
- FORTRAN 77 – ANSI standardization
5. Object Oriented Boom (1980 – 1990)
- Smalltalk 80 – Pure object oriented language
- C++ - Derived from C and Simula
- Ada83 – Strong typing; heavy Pascal influence
- Eiffel - Derived from Ada and Simula
6. Emergence of Frameworks (1990 – today)
- Visual Basic – Eased development of the graphical user interface (GUI) for windows
applications
- Java – Successor to Oak; designed for portability
- Python – Object oriented scripting language
- J2EE – Java based framework for enterprise computing
- .NET – Microsoft’s object based framework
- Visual C# - Java competitor for the Microsoft .NET framework
- Visual Basic .NET – VB for Microsoft .NET framework
Topology of first and early second generation programming languages
- Topology means basic physical building blocks of the language & how those parts can be
connected.
- Arrows indicate dependency of subprograms on various data.
- Error in one part of program effect across the rest of system.

Topology of late second and early third generation programming languages

Software abstraction becomes procedural abstraction; subprograms as an obstruction mechanism and
three important consequences:
- Languages invented that supported parameter passing mechanism
- Foundations of structured programming were laid.
- Structured design method emerged using subprograms as basic physical blocks.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 10

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

The topology of late third generation programming languages

- Larger project means larger team, so need to develop different parts of same program
independently, i.e. complied module.
- Support modular structure.

Topology of object and object oriented programming language

Two methods for complexity of problems
(i) Data driven design method emerged for data abstraction.
(ii) Theories regarding the concept of a type appeared
- Many languages such as Smalltalk, C++, Ada, Java were developed.
- Physical building block in these languages is module which represents logical collection of classes
and objects instead of subprograms.
- Suppose procedures and functions are verbs and pieces of data are nouns, then
- Procedure oriented program is organized around verbs and object oriented program is organized
around nouns.
- Data and operations are united in such a way that the fundamental logical building blocks of our
systems are no longer algorithms, but are classes and objects.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 11

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

- In large application system, classes, objects and modules essential yet insufficient means of
abstraction.

Foundations of the object model

In structured design method, build complex system using algorithm as their fundamental building
block. An object oriented programming language, class and object as basic building block.
Following events have contributed to the evolution of object-oriented concepts:
• Advances in computer architecture, including capability systems and hardware support for
operating systems concepts
• Advances in programming languages, as demonstrated in Simula, Smalltalk, CLU, and Ada.
• Advances in programming methodology, including modularization and information hiding.
We would add to this list three more contributions to the foundation of the object model:
• Advances in database models
• Research in artificial intelligence

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 12

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

• Advances in philosophy and cognitive science

OOA(Object Oriented analysis)

During software requirement phase, requirement analysis and object analysis, it is a method of
analysis that examines requirements from the perspective of classes and objects as related to problem
domain. Object oriented analysis emphasizes the building of real-world model using the object
oriented view of the world.
OOD (Object oriented design)
During user requirement phase, OOD involves understanding of the application domain and build an
object model. Identify objects; it is methods of design showing process of object oriented
decomposition. Object oriented design is a method of design encompassing the process of object
oriented decomposition and a notation for depicting both logical and physical as well as static and
dynamic models of the system under design.
OOP (Object oriented programming)
During system implementation phase, It is a method of implementation in which programs are
organized as cooperative collection of objects, each of which represents an instance of some class
and whose classes are all members of a hierarchy of classes united in inheritance relationships.
Object oriented programming satisfies the following requirements:
- It supports objects that are data abstractions with an interface of named operations and a hidden
local state.
- Objects have associated type (class).
- Classes may inherit attributes from super type to subtype.
Elements of Object Model
Kinds of Programming Paradigms: According to Jenkins and Glasgow,most programmers work in
one language and use only one programming style. They have not been exposed to alternate ways of
thinking about a problem. Programming style is a way of organizing programs on the basis of some
conceptual model of programming and an appropriate language to make programs written in the style
clear.
There are five main kinds of programming styles:
1. Procedure oriented – Algorithms for design of computation
2.Object oriented – classes and objects
3. Logic oriented – Goals, often expressed in a predicate calculus
4. Rules oriented – If then rules for design of knowledge base
5. Constraint orient – Invariant relationships.

Each requires a different mindset, a different way of thinking about the problem. Object model is the
conceptual frame work for all things of object oriented.
There are four major elements of object model. They are:
1. Abstraction
2. Encapsulation
3. Modularity
4. Hierarchy

There are three minor elements which are useful but not essential part of object model. Minor
elements of object model are:
1. Typing
2. Concurrency
3. Persistence

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 13

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

Abstraction
Abstraction is defined as a simplified description or specification of a system that emphasizes some
of the system details or properties while suppressing others. A good abstraction is one that
emphasizes details that are significant to the reader or user and suppresses details that are, not so
significant, immaterial.
An abstraction denotes the essential characteristics of an object that distinguishes it from all other
kinds of objects and thus provides crisply defined conceptual boundaries on the perspective of the
viewer. An abstraction focuses on the outside view of an object, Abstraction focuses up on the
essential characteristics of some object, relative to the perspective of the viewer. From the most to
the least useful, these kinds of abstraction include following.
- Entity abstraction: An object that represents a useful model of a problem domain or solution
domain entity.
- Action abstraction: An object that provides a generalized set of operations all of which program
the same kind of function.
- Virtual machine abstractions: An object that groups together operations that are used by some
superior level of control, or operations that all use some junior set of operations.
- Coincidental abstraction: An object that packages a set of operations that have no relation to
each other.

Encapsulation
The act of grouping data and operations into a single object
Modularity
The act of partitioning a program into individual components is called modularity. It is reusable
component which reduces complexity to some degree. Although partitioning a program is helpful for
this reason, a more powerful justification for partitioning a program is that it creates a number of
well-defined, documented boundaries within the program. These boundaries, or interfaces, are
invaluable in the comprehension of the program. In some languages, such as Smalltalk, there is no
concept of a module, so the class forms the only physical unit of decomposition. Java has packages
that contain classes. In many other languages, including Object Pascal, C++, and Ada, the module is
a separate language construct and therefore warrants a separate set of design decisions. In these

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 14

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

languages, classes and objects form the logical structure of a system; we place these abstractions in
modules to produce the system’s physical architecture. Modularization consists of dividing a
program into modules which can be compiled separately, but which have connections with other
modules. Modularity is the property of a system that has been decomposed into a set of cohesive and
loosely coupled modules.
- modules can be compiled separately. modules in C++ are nothing more than separately compiled
files, generally called header files.
- Interface of module are files with .h extensions & implementations are placed in files with .c or .cpp
suffix.
- Modules are units in pascal and package body specification in ada.
- modules Serve as physical containers in which classes and objects are declared like gates in IC of
computer.
- Group logically related classes and objects in the same module.
- E.g. consider an application that runs on a distributed set of processors and uses a message passing
mechanism to coordinate their activities.
- A poor design is to define each message class in its own module; so difficult for users to find the
classes they need. Sometimes modularization is worse than no modulation at all.
- Developer must balance: desire to encapsulate abstractions and need to make certain abstractions
visible to other modules.
- Principles of abstraction, encapsulation and modularity are synergistic (having common effect)

Applying the Object Model

Benefits of the Object Model: Object model introduces several new elements which are
advantageous over traditional method of structured programming. The significant benefits are:
• Use of object model helps us to exploit the expressive power of object based and object
oriented programming languages. Without the application of elements of object model, more
powerful feature of languages such as C++, object pascal, ada are either ignored or greatly
mis used.
• Use of object model encourages the reuse of software and entire designs, which results in the
creation of reusable application framework.
• Use of object model produces systems that are built upon stable intermediate forms, which are
more resilent to change.
• Object model appears to the working of human cognition, many people who have no idea how a
computer works find the idea of object oriented systems quite natural.

Application of Object Model

OOA & Design may be in only method which can be employed to attack the complexity inherent in
large systems. Some of the applications of the object model are as follows:
- Air traffic control
- Animation
- Business or insurance software
- Business Data Processing
- CAD
- Databases
- Expert Systems
- Office Automation
- Robotics
- Telecommunication

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 15

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

- Telemetry System etc.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 16