Ooad Unit 1
Ooad Unit 1
Ooad Unit 1
INTRODUCTION: The structure of complex systems, The Inherent Complexity of Software, Attributes of
Complex System, Organized and Disorganized Complexity, Bringing Order to Chaos, Designing Complex
Systems.
Case Study: System Architecture: Satelite-Based Navigation
Introduction:
Object:-
An object is a real-world element in an object–oriented environment that may have a physical or a conceptual
existence. An object may have a physical existence, like a customer, a car, etc.; or an intangible conceptual
existence, like a project, a process, etc.
➢ Object is a combination of data and logic that represents some real world entity.
* Data are called as attributes
* Logic is called as functions
Ex:- Object : Car
Attributes : car name, colour, no.of doors
Functions : stop, milage, start
Ex:- Representation of an object
Window
Size
colour
Open()
Close()
1. Class:
A class is a user-defined data type. It consists of data members and member functions, which can be accessed
and used by creating an instance of that class. It represents the set of properties or methods that are common to
all objects of one type. A class is like a blueprint for an object.
For Example: Consider the Class of Cars. There may be many cars with different names and brands but all of
them will share some common properties like all of them will have 4 wheels, Speed Limit, Mileage range, etc.
So here, Car is the class, and wheels, speed limits, mileage are their properties.
Object-Oriented Design:-
➢ Object -oriented design involves implementation of the conceptual model produced during object-oriented
Analysis.
➢ OOD concepts in the analysis model which are technology independent are mapped on to implementing
classes, constraints are identified and interfaces are designed resulting in a model for the solution domain.
Object-Oriented Paradigm:-
Object-Oriented Paradigm based upon objects(Having the data in the form of fields often known as attributes and
code in the form of procedures often known as methods) that aims to incorporate the advantages of modularity
and reusability.
Object Oriented Analysis and Design:-
Object-Oriented Analysis and Design is a structural methodology for analyzing , designing and developing
software systems. OOAD is based on the principles of object-oriented programming.
OOAD Steps:-
1. Define Use cases
2. Define Domain Model
3. Define Interaction Diagrams
4. Define Design Class Diagrams
1. Define Use cases:-
➢ Use case is a list of actions or event steps defining the interactions between a actor and a system to achieve a
goal.
➢ Actor can be a human or other external system.
➢ Use case is a popular tool in requirement analysis.
➢ Composed of the same major elements - CPU, monitor, keyboard, secondary storage
➢ An element can be taken and decomposed further and can be studied separately.
➢ The collaborative activity of each major part causes a computer system to function.
➢ The hierarchy of computer system also represents different levels of abstraction - each built upon another and
in each level of abstraction, a collection of devices are found to be collaborating one another to provide functions
to higher layers.
Structure of a Plants and Animals:-
Plants are complex multicellular organism which are composed of cells which is turn encompasses elements
such as chloroplasts, nucleus, and so on. For example, the highest level of abstraction, roots are responsible for
absorbing water and minerals from the soil.
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.
In the social sciences, social structure is the aggregate of patterned social arrangements in society that are
both emergent from and determinant of the actions of individuals. Likewise, society is believed to be grouped
into structurally related groups or sets of roles, with different functions, meanings, or purposes.
Examples of social structure include family, religion, law, economy, and class. It contrasts with "social
system", which refers to the parent structure in which these various structures are embedded. Thus, social
structures significantly influence larger systems, such as economic systems, legal systems, political
systems, cultural systems, etc. Social structure can also be said to be the framework upon which a society is
established. It determines the norms and patterns of relations between the various institutions of the society.
Often, although software developers have the knowledge and skills required to develop software they usually lack
detailed knowledge of the application domain of systems. This affects their ability to understand and express
accurately the requirements for the system to be built which come from the particular domain. Note, that these
requirements are usually themselves subject to change.
External complexity usually springs from the difference of thoughts that exists between the users of a system and
its developers. Users may have only vague ideas of what they want in a software system.
Users and developers have different perspectives on the nature of the problem and make different assumptions
regarding the nature of the system. A further complication is that the requirement of a software system is often
change during its development.
It is software maintenance when we correct errors, evolution when we respond to changing environments and
preservations, when we continue to use extraordinary means to keep an ancient and decaying piece of software
in operation.
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 well 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.
e. The Consequences of Unrestrained Complexity
The more complex the system, the more open it is to total breakdown. Rarely would a builder think about adding
a new sub-basement to an existing 100-story building; to do so would be very costly and would undoubtedly
invite failure. Amazingly, users of software systems rarely think twice about asking for equivalent changes.
Besides, they argue, it is only a simple matter of programming.
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.
In order to do so we need to follow 2 methods they are:
1. The canonical form of a complex system:
The discovery of common abstractions and mechanisms greatly facilitates understanding of complex systems.
For example, if a pilot already knows how to fly a jet aircraft safely fly the vehicle, it is easier to know how to fly
a similar one. May different hierarchies are present in 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 takes on the same (canonical) form as shown in figure. There are two orthogonal
hierarchies of system, its class structure and the object structure.
The above diagram 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 Cl 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. Approaching a Solution
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.
Bringing Order to Chaos: Principles that will provide basis for development
1. The Role of Abstraction: Abstraction is an exceptionally powerful technique for dealing with complexity.
Unable to master the entirely of a complex object, we chose 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
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.
2. 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 nonhierarchical: interactions, 'relationships'.
3. 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.
a. Algorithmic (Process Oriented) Decomposition: In Algorithmic decomposition, each module in the system
denotes a major step in some overall process.
b. 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 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.
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.
Booch presents a model of object-oriented development that identifies several relevant perspectives. The
classes and objects that form the system are identified in a logical model.
For this logical model, again two different perspectives have to be considered. A static perspective identifies
the structure of classes and objects, their properties and the relationships classes and objects participate in. A
dynamic model identifies the dynamic behavior of classes and objects, the different valid states they can be in
and the transitions between these states.
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)
✓ 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.