Ooad Unit 1

Download as pdf or txt
Download as pdf or txt
You are on page 1of 15

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 Analysis(OOA):-


The main difference between object-oriented analysis and other forms of analysis is that by the object-oriented
approach we organize requirements around objects, which integrate both behaviors (processes) and states (data)
modeled after real world objects that the system interacts with.
The primary tasks in object-oriented analysis are:
➢ Find the objects
➢ Organize the objects
➢ Describe how the objects interact
➢ Define the behaviour of the objects

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.

2. Define Domain Model:-


➢ It is a conceptual model of the domain that incorporates both behaviour and data.
➢ It is used to understand the problem of a given statement.
➢ It is the process of systematically identifying, analyzing, and representing the essential concepts, behaviors,
and relationships within a specific problem domain.
➢ The objects known throughout domain analysis are classified into 3 types:
1. Boundary objects
2. Controller objects
3. Entity objects

3. Define Interaction Diagrams:-


➢ It is used to describe the type of interactions among the different elements in the model.
➢ Interaction behaviour is represented by two diagrams known as sequence and collaboration diagrams.
➢ Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on the
structural organization of the objects that send and receive messages.

4. Define Design Class Diagrams:-


➢ Class diagrams are a type of UML (Unified Modeling Language) diagram used in software engineering to
visually represent the structure and relationships of classes within a system i.e. used to construct and visualize
object-oriented systems.
➢ In these diagrams, classes are depicted as boxes, each containing three compartments for the class name,
attributes, and methods.
Complexity:- OOAD can add complexity to a software system, as objects and their relationships must be
carefully modeled and managed.Here we mentioned the 4 types of complexities examples.
The structure of Complex Systems:
➢ Systems with a set of parts are called as elements and a set of connections between these parts are called
relations. These parts can be ordered or unordered.
Ex:- Parts of a car, Organs in our body.
➢ Software might be referred to as simple or complex depending upon their functionality and behaviour.
Generally industrial-strength software are more complex than those developed individually or by user developers.
➢ Time and space are considered to be general complexities. Additionally maintaining integrity of hundreds
of thousands of records while allowing concurrent updates and queries or managing command and control of real-
world entities like air traffic are also examples of complex systems.
Structure of a personal computer:-
A device of moderate complexity, which has been evolved from small working sub systems like gate architecture
for instance.

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

Structure of Social Institutions:-

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.

The Inherent Complexity of Software:


The complexity of software is an essential property not an accidental one. The inherent complexity derives from
four elements.
a. The complexity of the problem domain
* Complex requirements
* Decay of system

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.

b. 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. Developer must strive to write the less code by using the clever and powerful techniques. Even if we
decompose our implementation in meaningful ways, we still end up with hundreds and sometimes even thousand
modules.
No single person can totally understand the complexity of system. There are always significant challenges
associated with team development more developers' means more complex communication and hence more
difficult coordination.
c. 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. The software development is
different: most of the software companies develop every single component from scratch. Construction industry
has standards for quality of row materials, few such standards exist in the software industry.

d. The problem of characterizing the behavior of discrete 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 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.

Attributes of Complex System:


Considering the nature of the complexity, we conclude that there are 5 Attributes are
common to all complex systems as follows:
1. Hierarchic Structure
2. Relative Primitives
3. Separation of Concerns
4. Common Patterns
5. Stable Intermediate Forms
1. Hierarchic Structure :

• All systems are composed of interrelatedsub-systems


• Sub-systems are composed of sub-sub-systemsand so on
• Lowest level sub-systems are composed ofelementary components
• All sub-systems are parts of larger systems
• Architecture of a complex systemis a function ofits components as well as the hierarchic relationships
among its components
2. Relative Primitives:
• Choice of the components in a system for primitive is relatively arbitrary and is largely depends on the
discretion of the observer/designer of the system.
• Primitive of one observer / designer may beat a much higher level of abstraction of another
3. Separation of Concerns:
It is divided into 2 parts 1. Inter component linkage
2. Intra component linkage
1. Inter component linkage:
1. Involve interactions across components
2. Weaker
3. Low frequency dynamics of the components
2. Intra component linkage:
1. Involve interactions within the structure of the component
2. Stronger
3. High frequency dynamics of the components
4. Common Patterns :
• Common Patterns are a major source of reuse in OOAD
• Complex systems have Common Patterns
• For example, Processors in Personal computer, Processors in Cars, Processors in Mobile Phones etc
• Knowledge of Processor in Personal computer is helpful to study Processors in Cars and Mobile Phones
etc
• Complex Systems are composed of only a few different kinds of subsystems in various combinations and
arrangements (cells found in both plants and animals etc)
5. Stable Intermediate Forms:
• It is extremely difficult to design a complex system correctly inone go or at one instance
• System matures from one intermediate form to the next
• For example, if the representation of floating-point numbers is stable intermediate form and then it is easy
to move to create the next bigger functionality, i.e., next form, like representation of matrix of floating-point
numbers

Organized and Disorganized Complexity: The randomness of unorganized complexity is increases as


the system moves from organized to unorganized. And the complexity of system is also increasing when the
unorganized complexity is increases. So we need to convert the disorganized complexity to organized or
simplified complexity.

Simplifying Complex Systems


• Usefulness of abstractions common to similar activities e.g. driving different kinds of motor vehicle
• Multiple orthogonal hierarchies e.g. structure and control system
• Prominent hierarchies in object-orientation " class structure"" object structure "
e. g. engine types, engine in a specific car.

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

The Limitations of the human capacity for dealing with complexity:


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

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.

c.Algorithmic versus object oriented decomposition:


Object oriented algorithm has a number of advantages over algorithmic decomposition. Object oriented
decomposition yields smaller systems through the reuse of common mechanisms, thus providing an important
economy of expression and are also more resident to change and thus better able to involve over time and it also
reduces risks of building complex software systems.
Although both solutions help dealing with complexity we have reasons to believe that an object-oriented
decomposition is favorable because, the object-oriented approach provides for a semantically richer framework
that leads to decompositions that are more closely related to entities from the real world.

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
vailable for doing 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.
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.
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.

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.
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
➢ Data driven design method emerged for data abstraction.
➢ 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.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy