Object-Oriented Analysis

Object–Oriented Analysis (OOA) is the procedure of identifying software engineering

requirements and developing software specifications in terms of a software system’s object
model, which comprises of interacting objects.
The main difference between object-oriented analysis and other forms of analysis is that in
object-oriented approach, requirements are organized around objects, which integrate both data
and functions. They are modelled after real-world objects that the system interacts with. In
traditional analysis methodologies, the two aspects - functions and data - are considered
separately.
Grady Booch has defined OOA as, “Object-oriented analysis is a method of analysis that
examines requirements from the perspective of the classes and objects found in the vocabulary
of the problem domain”.
The primary tasks in object-oriented analysis (OOA) are −

 Identifying objects
 Organizing the objects by creating object model diagram
 Defining the internals of the objects, or object attributes
 Defining the behavior of the objects, i.e., object actions
 Describing how the objects interact
The common models used in OOA are use cases and object models.

Object-Oriented Design
Object–Oriented Design (OOD) involves implementation of the conceptual model
produced during object-oriented analysis. In OOD, concepts in the analysis model,
which are technology−independent, are mapped onto implementing classes,
constraints are identified and interfaces are designed, resulting in a model for the
solution domain, i.e., a detailed description of how the system is to be built on concrete
technologies.
The implementation details generally include −

 Restructuring the class data (if necessary),

 Implementation of methods, i.e., internal data structures and algorithms,
 Implementation of control, and
 Implementation of associations.
Grady Booch has defined object-oriented design as “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”.
An analysis model created using object oriented analysis is transformed by
object oriented design into a design model that works as a plan for software
creation. OOD results in a design having several different levels of modularity
i.e., The major system components are partitioned into subsystems (a system
level “modular”), and data their manipulation operations are encapsulated into
objects (a modular form that is the building block of an OO system.).
In addition, OOD must specify some data organization of attributes and a
procedural description of each operation.
Shows a design pyramid for object oriented systems. It is having the following
four layers.

1. The Subsystem Layer :

It represents the subsystem that enables software to achieve user
requirements and implement technical frameworks that meet user needs.

2. The Class and Object Layer :

It represents the class hierarchies that enable the system to develop using
generalization and specialization. This layer also represents each object.
3. The Message Layer :
It represents the design details that enable each object to communicate with
its partners. It establishes internal and external interfaces for the system.

4. The Responsibilities Layer :

It represents the data structure and algorithmic design for all the attributes
and operations for each object.

Object-Oriented Design
The analysis phase identifies the objects, their relationship, and behavior using the

conceptual model.

While in design phase, we describe these objects (by creating class diagram from

conceptual diagram — usually mapping conceptual model to class diagram), their

attributes, behavior, and interactions.

The input for object-oriented design is provided by the output of object-oriented

analysis. But, analysis and design may occur in parallel, and the results of one activity

can be used by the other.

In the object-oriented design, we …

1. Describe the classes and their relationships using class diagram.

2. Describe the interaction between the objects using sequence diagram.

3. Apply software design principles and design patterns.

After the analysis phase, the conceptual model is developed further into an object-
oriented model using object-oriented design (OOD). In OOD, the technology-
independent concepts in the analysis model are mapped onto implementing classes,
constraints are identified, and interfaces are designed, resulting in a model for the
solution domain.
In a nutshell, a detailed description is constructed specifying how the system is to be
built on concrete technologies.
The stages for object–oriented design can be identified as −
  Definition of the context of the system
 Designing system architecture
 Identification of the objects in the system
 Construction of design models
 Specification of object interfaces

System Design
Object-oriented system design involves defining the context of a system followed by
designing the architecture of the system.
 Context − The context of a system has a static and a dynamic part. The static
context of the system is designed using a simple block diagram of the whole
system which is expanded into a hierarchy of subsystems. The subsystem
model is represented by UML packages. The dynamic context describes how
the system interacts with its environment. It is modelled using use case
diagrams.
 System Architecture − The system architecture is designed on the basis of the
context of the system in accordance with the principles of architectural design as
well as domain knowledge. Typically, a system is partitioned into layers and
each layer is decomposed to form the subsystems.

Object-Oriented Decomposition
Decomposition means dividing a large complex system into a hierarchy of smaller
components with lesser complexities, on the principles of divide–and–conquer. Each
major component of the system is called a subsystem. Object-oriented decomposition
identifies individual autonomous objects in a system and the communication among
these objects.
The advantages of decomposition are −
 The individual components are of lesser complexity, and so more
understandable and manageable.
 It enables division of workforce having specialized skills.
 It allows subsystems to be replaced or modified without affecting other
subsystems.

Identifying Concurrency
Concurrency allows more than one objects to receive events at the same time and
more than one activity to be executed simultaneously. Concurrency is identified and
represented in the dynamic model.
Object Design
After the hierarchy of subsystems has been developed, the objects in the system are
identified and their details are designed. Here, the designer details out the strategy
chosen during the system design. The emphasis shifts from application domain
concepts toward computer concepts. The objects identified during analysis are etched
out for implementation with an aim to minimize execution time, memory consumption,
and overall cost.
Object design includes the following phases −

 Object identification
 Object representation, i.e., construction of design models
 Classification of operations
 Algorithm design
 Design of relationships
 Implementation of control for external interactions
 Package classes and associations into modules

Object Identification
The first step of object design is object identification. The objects identified in the
object–oriented analysis phases are grouped into classes and refined so that they are
suitable for actual implementation.
The functions of this stage are −
 Identifying and refining the classes in each subsystem or package
 Defining the links and associations between the classes
 Designing the hierarchical associations among the classes, i.e., the
generalization/specialization and inheritances
 Designing aggregations
Object Representation
Once the classes are identified, they need to be represented using object modelling
techniques. This stage essentially involves constructing UML diagrams.
There are two types of design models that need to be produced −
 Static Models − To describe the static structure of a system using class
diagrams and object diagrams.
  Dynamic Models − To describe the dynamic structure of a system and show the
interaction between classes using interaction diagrams and state–chart
diagrams.
Classification of Operations
In this step, the operation to be performed on objects are defined by combining the
three models developed in the OOA phase, namely, object model, dynamic model, and
functional model. An operation specifies what is to be done and not how it should be
done.
The following tasks are performed regarding operations −
 The state transition diagram of each object in the system is developed.
 Operations are defined for the events received by the objects.
 Cases in which one event triggers other events in same or different objects are
identified.
 The sub–operations within the actions are identified.
 The main actions are expanded to data flow diagrams.
Algorithm Design
The operations in the objects are defined using algorithms. An algorithm is a stepwise
procedure that solves the problem laid down in an operation. Algorithms focus on how
it is to be done.
There may be more than one algorithm corresponding to a given operation. Once the
alternative algorithms are identified, the optimal algorithm is selected for the given
problem domain. The metrics for choosing the optimal algorithm are −
 Computational Complexity − Complexity determines the efficiency of an
algorithm in terms of computation time and memory requirements.
 Flexibility − Flexibility determines whether the chosen algorithm can be
implemented suitably, without loss of appropriateness in various environments.
 Understandability − This determines whether the chosen algorithm is easy to
understand and implement.
Design of Relationships
The strategy to implement the relationships needs to be chalked out during the object
design phase. The main relationships that are addressed comprise of associations,
aggregations, and inheritances.
The designer should do the following regarding associations −
 Identify whether an association is unidirectional or bidirectional.
 Analyze the path of associations and update them if necessary.
  Implement the associations as a distinct object, in case of many–to-many
relationships; or as a link to other object in case of one–to-one or one–to-many
relationships.
Regarding inheritances, the designer should do the following −
 Adjust the classes and their associations.
 Identify abstract classes.
 Make provisions so that behaviors are shared when needed.
Implementation of Control
The object designer may incorporate refinements in the strategy of the state–chart
model. In system design, a basic strategy for realizing the dynamic model is made.
During object design, this strategy is aptly embellished for appropriate implementation.
The approaches for implementation of the dynamic model are −
 Represent State as a Location within a Program − This is the traditional
procedure-driven approach whereby the location of control defines the program
state. A finite state machine can be implemented as a program. A transition
forms an input statement, the main control path forms the sequence of
instructions, the branches form the conditions, and the backward paths form the
loops or iterations.
 State Machine Engine − This approach directly represents a state machine
through a state machine engine class. This class executes the state machine
through a set of transitions and actions provided by the application.
 Control as Concurrent Tasks − In this approach, an object is implemented as a
task in the programming language or the operating system. Here, an event is
implemented as an inter-task call. It preserves inherent concurrency of real
objects.

Packaging Classes
In any large project, meticulous partitioning of an implementation into modules or
packages is important. During object design, classes and objects are grouped into
packages to enable multiple groups to work cooperatively on a project.
The different aspects of packaging are −
 Hiding Internal Information from Outside View − It allows a class to be
viewed as a “black box” and permits class implementation to be changed
without requiring any clients of the class to modify code.
 Coherence of Elements − An element, such as a class, an operation, or a
module, is coherent if it is organized on a consistent plan and all its parts are
intrinsically related so that they serve a common goal.
  Construction of Physical Modules − The following guidelines help while
constructing physical modules −
o Classes in a module should represent similar things or components in the
same composite object.
o Closely connected classes should be in the same module.
o Unconnected or weakly connected classes should be placed in separate
modules.
o Modules should have good cohesion, i.e., high cooperation among its
components.
o A module should have low coupling with other modules, i.e., interaction or
interdependence between modules should be minimum.

Design Optimization
The analysis model captures the logical information about the system, while the design
model adds details to support efficient information access. Before a design is
implemented, it should be optimized so as to make the implementation more efficient.
The aim of optimization is to minimize the cost in terms of time, space, and other
metrics.
However, design optimization should not be excess, as ease of implementation,
maintainability, and extensibility are also important concerns. It is often seen that a
perfectly optimized design is more efficient but less readable and reusable. So the
designer must strike a balance between the two.
The various things that may be done for design optimization are −

 Add redundant associations

 Omit non-usable associations
 Optimization of algorithms
 Save derived attributes to avoid re-computation of complex expressions

Addition of Redundant Associations

During design optimization, it is checked if deriving new associations can reduce
access costs. Though these redundant associations may not add any information, they
may increase the efficiency of the overall model.
Omission of Non-Usable Associations
Presence of too many associations may render a system indecipherable and hence
reduce the overall efficiency of the system. So, during optimization, all non-usable
associations are removed.
Optimization of Algorithms
In object-oriented systems, optimization of data structure and algorithms are done in a
collaborative manner. Once the class design is in place, the operations and the
algorithms need to be optimized.
Optimization of algorithms is obtained by −

 Rearrangement of the order of computational tasks

 Reversal of execution order of loops from that laid down in the functional model
 Removal of dead paths within the algorithm

Saving and Storing of Derived Attributes

Derived attributes are those attributes whose values are computed as a function of
other attributes (base attributes). Re-computation of the values of derived attributes
every time they are needed is a time–consuming procedure. To avoid this, the values
can be computed and stored in their computed forms.
However, this may pose update anomalies, i.e., a change in the values of base
attributes with no corresponding change in the values of the derived attributes. To
avoid this, the following steps are taken −
 With each update of the base attribute value, the derived attribute is also re-
computed.
 All the derived attributes are re-computed and updated periodically in a group
rather than after each update.

Design Documentation
Documentation is an essential part of any software development process that records
the procedure of making the software. The design decisions need to be documented
for any non–trivial software system for transmitting the design to others.
Usage Areas
Though a secondary product, a good documentation is indispensable, particularly in
the following areas −

 In designing software that is being developed by a number of developers

 In iterative software development strategies
 In developing subsequent versions of a software project
 For evaluating a software
 For finding conditions and areas of testing
 For maintenance of the software.

Contents
A beneficial documentation should essentially include the following contents −
  High–level system architecture − Process diagrams and module diagrams
 Key abstractions and mechanisms − Class diagrams and object diagrams.
 Scenarios that illustrate the behavior of the main aspects − Behavioural
diagrams
Features
The features of a good documentation are −
 Concise and at the same time, unambiguous, consistent, and complete
 Traceable to the system’s requirement specifications
 Well-structured
 Diagrammatic instead of descriptive

Object Modeling Technique (OMT) is real world based modeling approach for
software modeling and designing. It was developed basically as a method to
develop object-oriented systems and to support object-oriented programming. It
describes the static structure of the system.
Object Modeling Technique is easy to draw and use. It is used in many
applications like telecommunication, transportation, compilers etc. It is also
used in many real world problems. OMT is one of the most popular object
oriented development techniques used now-a-days. OMT was developed
by James Rambaugh.
Purpose of Object Modeling Technique:
 To test physical entity before construction of them.
 To make communication easier with the customers.
 To present information in an alternative way i.e. visualization.
 To reduce the complexity of software.
 To solve the real world problems.
Object Modeling Technique’s Models:
There are three main types of models that has been proposed by OMT:
1. Object Model:
Object Model encompasses the principles of abstraction, encapsulation,
modularity, hierarchy, typing, concurrency and persistence. Object Model
basically emphasizes on the object and class. Main concepts related with
Object Model are classes and their association with attributes. Predefined
relationships in object model are aggregation and generalization (multiple
inheritance).

The process of object modelling can be visualized in the following steps −

  Identify objects and group into classes
 Identify the relationships among classes
 Create user object model diagram
 Define user object attributes
 Define the operations that should be performed on the classes
 Review glossary

2. Dynamic Model:
Dynamic Model involves states, events and state diagram (transition
diagram) on the model. Main concepts related with Dynamic Model are
states, transition between states and events to trigger the transitions.
Predefined relationships in object model are aggregation (concurrency) and
generalization.

The process of dynamic modelling can be visualized in the following steps −

 Identify states of each object

 Identify events and analyze the applicability of actions
 Construct dynamic model diagram, comprising of state transition diagrams
 Express each state in terms of object attributes
 Validate the state–transition diagrams drawn

3. Functional Model:
Functional Model focuses on the how data is flowing, where data is stored
and different processes. Main concepts involved in Functional Model are
data, data flow, data store, process and actors. Functional Model in OMT
describes the whole processes and actions with the help of data flow
diagram (DFD).

The process of functional modelling can be visualized in the following steps −

 Identify all the inputs and outputs

 Construct data flow diagrams showing functional dependencies
 State the purpose of each function
 Identify constraints
 Specify optimization criteria

Phases of Object Modeling Technique:

OMT has the following phases:
1. Analysis:
This the first phase of the object modeling technique. This phase involves
the preparation of precise and correct modelling of the real world problems.
Analysis phase starts with setting a goal i.e. finding the problem statement.
Problem statement is further divided into above discussed three models i.e.
object, dynamic and functional model.
2. System Design:
This is the second phase of the object modeling technique and it comes after
the analysis phase. It determines all system architecture, concurrent tasks
and data storage. High level architecture of the system is designed during
this phase.
3. Object Design:
Object design is the third phase of the object modelling technique and after
system design is over, this phase comes. Object design phase is concerned
with classification of objects into different classes and about attributes and
necessary operations needed. Different issues related with generalization
and aggregation are checked.
4. Implementation:
This is the last phase of the object modeling technique. It is all about
converting prepared design into the software. Design phase is translated into
the Implementation phase.

SA/SD VS OMT
Principles of Object-Oriented Systems
The conceptual framework of object–oriented systems is based upon the object model.
There are two categories of elements in an object-oriented system −
Major Elements − By major, it is meant that if a model does not have any one of these
elements, it ceases to be object oriented. The four major elements are −

 Abstraction
 Encapsulation
 Modularity
 Hierarchy
Minor Elements − By minor, it is meant that these elements are useful, but not
indispensable part of the object model. The three minor elements are −

 Typing
 Concurrency
 Persistence

Abstraction
Abstraction means to focus on the essential features of an element or object in OOP,
ignoring its extraneous or accidental properties. The essential features are relative to
the context in which the object is being used.
Grady Booch has defined abstraction as follows −
“An abstraction denotes the essential characteristics of an object that distinguish it from
all other kinds of objects and thus provide crisply defined conceptual boundaries,
relative to the perspective of the viewer.”
Example − When a class Student is designed, the attributes enrolment_number,
name, course, and address are included while characteristics like pulse_rate and
size_of_shoe are eliminated, since they are irrelevant in the perspective of the
educational institution.

Encapsulation
Encapsulation is the process of binding both attributes and methods together within a
class. Through encapsulation, the internal details of a class can be hidden from
outside. The class has methods that provide user interfaces by which the services
provided by the class may be used.

Modularity
Modularity is the process of decomposing a problem (program) into a set of modules
so as to reduce the overall complexity of the problem. Booch has defined modularity as
−
“Modularity is the property of a system that has been decomposed into a set of
cohesive and loosely coupled modules.”
Modularity is intrinsically linked with encapsulation. Modularity can be visualized as a
way of mapping encapsulated abstractions into real, physical modules having high
cohesion within the modules and their inter–module interaction or coupling is low.

Hierarchy
In Grady Booch’s words, “Hierarchy is the ranking or ordering of abstraction”. Through
hierarchy, a system can be made up of interrelated subsystems, which can have their
own subsystems and so on until the smallest level components are reached. It uses
the principle of “divide and conquer”. Hierarchy allows code reusability.
The two types of hierarchies in OOA are −
 “IS–A” hierarchy − It defines the hierarchical relationship in inheritance,
whereby from a super-class, a number of subclasses may be derived which may
again have subclasses and so on. For example, if we derive a class Rose from
a class Flower, we can say that a rose “is–a” flower.
 “PART–OF” hierarchy − It defines the hierarchical relationship in aggregation
by which a class may be composed of other classes. For example, a flower is
composed of sepals, petals, stamens, and carpel. It can be said that a petal is a
“part–of” flower.

Typing
According to the theories of abstract data type, a type is a characterization of a set of
elements. In OOP, a class is visualized as a type having properties distinct from any
other types. Typing is the enforcement of the notion that an object is an instance of a
single class or type. It also enforces that objects of different types may not be generally
interchanged; and can be interchanged only in a very restricted manner if absolutely
required to do so.
The two types of typing are −
 Strong Typing − Here, the operation on an object is checked at the time of
compilation, as in the programming language Eiffel.
 Weak Typing − Here, messages may be sent to any class. The operation is
checked only at the time of execution, as in the programming language
Smalltalk.

Concurrency
Concurrency in operating systems allows performing multiple tasks or processes
simultaneously. When a single process exists in a system, it is said that there is a
single thread of control. However, most systems have multiple threads, some active,
some waiting for CPU, some suspended, and some terminated. Systems with multiple
CPUs inherently permit concurrent threads of control; but systems running on a single
CPU use appropriate algorithms to give equitable CPU time to the threads so as to
enable concurrency.
In an object-oriented environment, there are active and inactive objects. The active
objects have independent threads of control that can execute concurrently with threads
of other objects. The active objects synchronize with one another as well as with purely
sequential objects.

Persistence
An object occupies a memory space and exists for a particular period of time. In
traditional programming, the lifespan of an object was typically the lifespan of the
execution of the program that created it. In files or databases, the object lifespan is
longer than the duration of the process creating the object. This property by which an
object continues to exist even after its creator ceases to exist is known as persistence.

Structured Analysis vs. Object Oriented Analysis

The Structured Analysis/Structured Design (SASD) approach is the traditional
approach of software development based upon the waterfall model. The phases of
development of a system using SASD are −

 Feasibility Study
 Requirement Analysis and Specification
 System Design
 Implementation
 Post-implementation Review
Now, we will look at the relative advantages and disadvantages of structured analysis
approach and object-oriented analysis approach.
Advantages/Disadvantages of Object Oriented Analysis
Advantages Disadvantages

Focuses on data rather than the procedures as Functionality is restricted within objects. This
in Structured Analysis. may pose a problem for systems which are
intrinsically procedural or computational in
nature.

The principles of encapsulation and data hiding It cannot identify which objects would generate
help the developer to develop systems that an optimal system design.
cannot be tampered by other parts of the
system.

The principles of encapsulation and data hiding The object-oriented models do not easily show
help the developer to develop systems that the communications between the objects in the
cannot be tampered by other parts of the system.
system.

It allows effective management of software All the interfaces between the objects cannot be
complexity by the virtue of modularity. represented in a single diagram.

It can be upgraded from small to large systems

at a greater ease than in systems following
structured analysis.

Advantages/Disadvantages of Structured Analysis

Advantages Disadvantages

As it follows a top-down approach in contrast to In traditional structured analysis models,

bottom-up approach of object-oriented analysis, it one phase should be completed before the
can be more easily comprehended than OOA. next phase. This poses a problem in
design, particularly if errors crop up or
requirements change.

It is based upon functionality. The overall purpose is The initial cost of constructing the system is
identified and then functional decomposition is done high, since the whole system needs to be
for developing the software. The emphasis not only designed at once leaving very little option
gives a better understanding of the system but also to add functionality later.
generates more complete systems.

The specifications in it are written in simple English It does not support reusability of code. So,
language, and hence can be more easily analyzed the time and cost of development is
by non-technical personnel. inherently high.
Jackson Structure Design

JSD, Jackson Structure Design is a methodology to specify and design systems in

which time factor is significant and system may be described using sequence of
events. Developed by Michael A. Jackson , this design method considers the fact that
the design of the system is an extension of the programme design. The purpose of this
design method is to create a maintainable software. The method addresses all stages
of the software development life cycle. It has three phases:
1. Modeling phase - A JSD model starts with real world consideration. This phase
is a part of analysis process. The aspects of the real world relevant to the
system being developed are modeled in this phase.
2. Specification phase - This phase focuses on the specification. In this phase
JSD determines what is to be done? The previous phase i.e. the modeling
phase provides the basic for the system specifications to achieve the required
functionality.
3. implementation phase - In this phase , JSD determines how to achieve
required functionality. Operational specifications are executed so that it
expresses desired system behavior in terms of some abstract machine.

Ways of working
 The basic principle of operation of JSD is that development must start with
describing and modeling the real world rather than specifying the function
performed by the system.
 The second principle states that an adequate model of a time ordered world
must itself be time ordered. The aim is to map progress in the real world on
progress in the system that models it.
 The third principle stetes way of implementing the system based on
transformation of specification in to efficient set of processes. These processes
should be designed in a manner to make them run on available software and
hardware.

Steps for JSD software development

Originally presented by Jackson in 1983 the method consisted of six steps which are
following.
1. Entity /action step
2. Entity structure step
3. Initial model step
 4. function step
5. system timing step
6. system implementing step
Later , some steps were combined to create a method with only three steps
1. Modeling stage (Analysis)
o Action step
o Structure step
2. Network stage (design)
o Initial model step
o Function step
o System timing step
3. Implementation stage (Realisation)
o System implementation step

Advantages of JSD
1. specially designed to handle real time problem.
2. JSD considers concurrent processing and timing.
3. JSD modeling focuses on time.
4. It provide functionality in the real world.
5. Excellent methodology for micro code application.

Disadvantages of JSD
1. JSD is a poor approach for high level analysis and data base design.
2. More complex due to pseudo code representation.
3. complex and difficult to understand.
4. less graphically oriented than SA/ SD and OMT.

Jackson Structured Development (JSD)

It is another approach for object oriented design in which the time factor is the vital factor and is
described by using sequence of events. JSD is applicable to the application where efficiency
plays a vital role. JSD was introduced by Michael Jackson in 1983. The fundamental principle of
 JSD[6] is that it focuses on describing the real world by the system i.e. its main focus is to map
the progress in the real world rather than specifying the functions performed by the system i.e its
main focus is to map the progress in the real world. JSD consist of three stages:

1. Modeling Stage – This Stage comprises of Entity Action and Entity Structure.
2. Network Stage – Initial model step, Function Step, and System Timing Step.
3. Implementation Stage – Implementation Step.

 In modeling stage the entity structure diagram has been created and identifies the entities and
their actions. In a network phase a set of sequential is expanded into a process network by
addition of process for handling messages for external environment and generating system
output. In Entity Action the entities perform actions in time. The action is atomic and cannot
be decomposed further.
 Entity Structure Step partially sequences the order of action with respect to time. In initial
model step we concentrate on state vector and data stream communication. A data stream is
an unbounded queue where read operator extracts the next record from the queue, if there are
no records when the process executing the read operation waits until the record is available
whereas in write operation data stream places the next record in the queue. In state vector we
are present all the possible states of an entity. Function step consist of pseudo code to the
output of action generated from states. In this step the developer requires a complete
specification of the system.
 System Timing Step relates with the performance constraints of the system. The
implementation step focuses on process scheduling and allocates the number of processors
required. The process may be different form the processors. So it is the job of the developer
who decides how to get several processes to share the same processors.
 Since JSD is useful for concurrent software, real time software and parallel programming
computers but when we talk about high level analysis JSD is ill suited. JSD approach is
difficult to understand because it is less graphical oriented as compared with SA/SD.
 Since SA/SD and JSD both suffers from some limitations we will try to formulate a new
approach using cross over operation of genetic algorithm which can minimize the limitation
to a certain extent.

Overcome the limitations of SA/SD and JSD

Problem Statement: In order to overcome the limitations of SA/SD and JSD by using
cross over operation (GA) we will consider a case study on library management system.
The system should be stand alone and it should be designed to provide the following
functionality. The processes that can be used are

1. Issue of Books
2. Return of books
3. Join the membership.
4. Leave the membership.
5. Acquire the books.
6. Sell the books.
JSD approach for designing Library Management System : To design library
management system by JSD following stages should be taken

Modeling Stage – Entity Action and Entity Structure.

Entity Structure Step

The * indicates the multiplicity in an operation and circle „0‟ indicates that they are
the part of selection. Each Member action can borrow, return and other.
Network phase: In this phase, we connect model processes and functions.

Initial Model Steps:

Data Stream: The data stream diagram is shown below

The library may require daily list of return of books. For each return event, each book
process writes a record on output stream R. These streams are merged with the
message D to generate another daily list. Then the function process F reads this
merged stream and whenever it encounters a D message daily list is produced.

How do you map the object-oriented concepts using non object-

oriented languages? Explain with an example.
Implementing an object-oriented concept in a non-object oriented language
requires the following steps:
1. Translate classes into data structures:
i. Each class is implemented as a single contiguous block of attributes. Each
attribute contains a variable. Now an object has state and identity and is subject
to side effects.
ii. A variable that identifies an object must therefore be implemented as a
sharable reference.
2. Pass arguments to methods:
i. Every method has at least one argument. In a non-object-oriented language,
the argument must be made explicit.
ii. Methods can contain additional objects as arguments. In passing an object as
an argument to a method, a reference to the object must be passed if the value
of the object can be updated within the method.
3. Allocate storage for objects:
i. Objects can be allocated statically, dynamically or on a stack.
ii. Most temporary and intermediate objects are implemented as stack-based
variables.
iii. Dynamically allocated objects are used when there number is not known at
compile time.
iv. A general object can be implemented as a data structure allocated on request
at run time from a heap.
4 Implement inheritances in data structures: Following ways are used to
implement data structure for inheritance in non-object oriented programming
language

 Avoid it.
 Flatten the class hierarchy.
 Break out separate objects.
5 Implement method resolutions: Method resolution is one. Main features of
an object-oriented language that is lacking in a non-object-oriented language.
Method resolution can be implemented in a following ways

 Avoid it.
 Resolve methods at compile time.
 Resolve methods at run time.
6. Implement associations: Implementing associations in a non-oriented
language can be done by:

 Mapping them into pointers.

 Implementing them directly as association container objects.
7. Deal with concurrency:

 Most languages do not explicitly support concurrency.

 Concurrency is usually needed only when more than one external event
occurs, and the behavior of the program depends on their timing.
8. Encapsulate internal details of classes:

 Object-oriented languages provide constructs to encapsulate

implementation.
 Some of this encapsulation is lost when object-oriented concepts
translated into a non-object-oriented language, but we can still take
advantage of the encapsulation facilities provided by language
Procedural Programming:
Procedural Programming can be defined as a programming model which is
derived from structured programming, based upon the concept of calling
procedure. Procedures, also known as routines, subroutines or functions,
simply consist of a series of computational steps to be carried out. During a
program’s execution, any given procedure might be called at any point,
including by other procedures or itself.
Languages used in Procedural Programming:
FORTRAN, ALGOL, COBOL,BASIC, Pascal and C.
Object Oriented Programming:
Object oriented programming can be defined as a programming model which is
based upon the concept of objects. Objects contain data in the form of
attributes and code in the form of methods. In object oriented programming,
computer programs are designed using the concept of objects that interact with
real world. Object oriented programming languages are various but the most
popular ones are class-based, meaning that objects are instances of classes,
which also determine their types.
Languages used in Object Oriented Programming:
Java, C++, C#, Python, PHP, JavaScript, Ruby, Perl, Objective-C,
Dart, Swift, Scala.

Procedural Oriented Object Oriented

Programming Programming

In procedural programming, In object oriented

 Procedural Oriented Object Oriented
Programming Programming

program is divided into small parts programming, program is

called functions. divided into small parts
called objects.

Procedural programming Object oriented programming

follows top down approach. follows bottom up approach.

Object oriented programming

There is no access specifier in have access specifiers like
procedural programming. private, public, protected etc.

Adding new data and function is Adding new data and function
not easy. is easy.

Procedural programming does not Object oriented programming

have any proper way for hiding provides data hiding so it
data so it is less secure. is more secure.

In procedural programming, Overloading is possible in

overloading is not possible. object oriented programming.

In procedural programming, In object oriented

function is more important than programming, data is more
data. important than function.

Procedural programming is based Object oriented programming is

on unreal world. based on real world.

Examples: C, FORTRAN, Pascal, Examples: C++, Java, Python,

Basic etc. C# etc.
Both Procedural Oriented Programming (POP) and Object Oriented Programming
(OOP) are the high level languages in programming world and are widely used in
development of applications. On the basis of nature of developing the code both
languages have different approaches on basis of which both are differentiate from each
other.
Following are the important differences between Procedural Oriented Programming
(POP) and Object Oriented Programming (OOP)

Sr. Key Object Oriented Programming Procedural Oriented

No. (OOP) Programming (POP)

1 Definition Object-oriented Programming is a On other hand Procedural

programming language that uses Oriented Programming is a
classes and objects to create programming language that
models based on the real world follows a step-by-step approach
environment. In OOPs it makes it to break down a task into a
easy to maintain and modify collection of variables and
existing code as new objects are routines (or subroutines) through
created inheriting characteristics a sequence of instructions. Each
from existing ones. step is carried out in order in a
systematic manner so that a
computer can understand what to
do.

2 Approach In OOPs concept of objects and On other hand in case of POP the
classes is introduced and hence the main program is divided into
the program is divided into small small parts based on the
chunks called objects which are functions and is treated as
instances of classes. separate program for individual
smaller program.

3 Access In OOPs access modifiers are On other hand no such modifiers

modifiers introduced namely as â~PrivateâTM, are introduced in POP.
â~publicâTM, and âTM~ProtectedâTM.

4 Security Due to abstraction in OOPs data On other hand POP is less secure
hiding is possible and hence it is as compare to OOPs.
more secure than POP.
Sr. Key Object Oriented Programming Procedural Oriented
No. (OOP) Programming (POP)

5 Complexity OOPs due to modularity in its On other hand thereâTMs no

programs is less complex and simple process to add data in
hence new data objects can be POP at least not without revising
created easily from existing the whole program.
objects making object-oriented
programs easy to modify

Describe implementation of inheritance with example.

Inheritance is an important pillar of OOP(Object Oriented Programming). It is the

mechanism in java by which one class is allow to inherit the features(fields and
methods) of another class.
Important terminology:

 Super Class: The class whose features are inherited is known as super
class(or a base class or a parent class).
 Sub Class: The class that inherits the other class is known as sub class(or
a derived class, extended class, or child class). The subclass can add its
own fields and methods in addition to the superclass fields and methods.
 Reusability: Inheritance supports the concept of “reusability”, i.e. when we
want to create a new class and there is already a class that includes some
of the code that we want, we can derive our new class from the existing
class. By doing this, we are reusing the fields and methods of the existing
class.
Types of Inheritance
There are Various types of inheritance in Java:
Single Inheritance:
In Single Inheritance one class extends another class (one class only).

In above diagram, Class B extends only Class A. Class A is a super class and
Class B is a Sub-class.
Multiple Inheritance:
In Multiple Inheritance, one class extending more than one class. Java does not
support multiple inheritance.

As per above diagram, Class C extends Class A and Class B both.

Multilevel Inheritance:
In Multilevel Inheritance, one class can inherit from a derived class. Hence, the
derived class becomes the base class for the new class.
As per shown in diagram Class C is subclass of B and B is a of subclass Class
A.
Hierarchical Inheritance:
In Hierarchical Inheritance, one class is inherited by many sub classes.

As per above example, Class B, C, and D inherit the same class A.

Hybrid Inheritance:
Hybrid inheritance is a combination of Single and Multiple inheritance.
As per above example, all the public and protected members of Class A are
inherited into Class D, first via Class B and secondly via Class C.
Note: Java doesn't support hybrid/Multiple inheritence

Features of object-oriented languages:

1. Classes
2. Objects
3. Data Abstraction
4. Encapsulation
5. Inheritance
6. Polymorphism

A programming language structure wherein the data and their associated

processing ("methods") are defined as self-contained entities called "objects."
The norm today, object-oriented programming (OOP) languages, such as C++
and Java, provide a formal set of rules for creating and managing objects.
There are three major features in object-oriented programming that makes
them different than non-OOP languages: encapsulation, inheritance and
polymorphism.

Encapsulation Enforces Modularity

Encapsulation refers to the creation of self-contained modules that bind
processing functions to the data. These user-defined data types are called
"classes," and one instance of a class is an "object." For example, in a payroll
system, a class could be Manager, and Pat and Jan could be two instances
(two objects) of the Manager class. Encapsulation ensures good code
modularity, which keeps routines separate and less prone to conflict with each
other.

Inheritance Passes "Knowledge" Down

Classes are created in hierarchies, and inheritance allows the structure and
methods in one class to be passed down the hierarchy. That means less
programming is required when adding functions to complex systems. If a step
is added at the bottom of a hierarchy, only the processing and data associated
with that unique step needs to be added. Everything else is inherited. The
ability to reuse existing objects is considered a major advantage of object
technology.

Polymorphism takes any Shape

Object-oriented programming allows procedures about objects to be created
whose exact type is not known until runtime. For example, a screen cursor
may change its shape from an arrow to a line depending on the program
mode. The routine to move the cursor on screen in response to mouse
movement would be written for "cursor," and polymorphism allows that cursor
to take on whatever shape is required at runtime. It also allows new shapes to
be easily integrated.

Describe physical packaging with example.

Programs are made of discrete physical units that can be edited, compiled,
imported, or otherwise manipulated. In C and Fortran the units are source files; In
Ada, it is packages. In object oriented languages, there are various degrees of
packaging. In any large project, careful partitioning of an implementation into
packages is important to permit different persons to cooperatively work on a
program.
Packaging include issues:
. Hiding internal information from outside view
. Coherence of entities
. Constructing physical modules.
Notation − Graphically, a package is represented by a tabbed folder. A package
is generally drawn with only its name. However it may have additional details
about the contents of the package. See the following figures.

What are the different aspects of packaging?

The different aspects of packaging are −

 Hiding Internal Information from Outside View − It allows a class to be

viewed as a “black box” and permits class implementation to be changed
without requiring any clients of the class to modify code.
 Coherence of Elements − An element, such as a class, an operation, or a
module, is coherent if it is organized on a consistent plan and all its parts
are intrinsically related so that they serve a common goal.
 Construction of Physical Modules − The following guidelines help while
constructing physical modules −
o Classes in a module should represent similar things or components
in the same composite object.
o Closely connected classes should be in the same module.
o Unconnected or weakly connected classes should be placed in
separate modules.
o Modules should have good cohesion, i.e., high cooperation among
its components.
 o A module should have low coupling with other modules, i.e.,
interaction or interdependence between modules should be
minimum.

What do you mean by documentation? What are the various

considerations in documentation designing? Explain.

In computer hardware and software product development, documentation is the

information that describes the product to its users. It consists of the product
technical manuals and online information (including online versions of the
technical manuals and help facility descriptions). The term is also sometimes
used to mean the source information about the product contained in design
documents, detailed code comments, white papers, and blackboard session
notes.
Documentation is an essential part of any software development process that
records the procedure of making the software. The design decisions need to be
documented for any non–trivial software system for transmitting the design to
others.
Usage Areas
Though a secondary product, a good documentation is indispensable, particularly
in the following areas −

 In designing software that is being developed by a number of developers

 In iterative software development strategies
 In developing subsequent versions of a software project
 For evaluating a software
 For finding conditions and areas of testing
 For maintenance of the software.
Contents
A beneficial documentation should essentially include the following contents −

 High–level system architecture − Process diagrams and module

diagrams
 Key abstractions and mechanisms − Class diagrams and object
diagrams.
 Scenarios that illustrate the behavior of the main aspects −
Behavioural diagrams
Features
The features of a good documentation are −

 Concise and at the same time, unambiguous, consistent, and complete

 Traceable to the system’s requirement specifications
 Well-structured
 Diagrammatic instead of descriptive

Describe passing arguments to method with example.

There are different ways in which parameter data can be passed into and out
of methods and functions. Let us assume that a function B() is called from
another function A(). In this case A is called the “caller function” and B is called
the “called function or callee function”. Also, the arguments which A sends
to B are called actual arguments and the parameters of B are called formal
arguments.

Types of parameters:
Formal Parameter : A variable and its type as they appear in the prototype of
the function or method.
Syntax:
function_name(datatype variable_name)

Actual Parameter : The variable or expression corresponding to a formal

parameter that appears in the function or method call in the calling environment.
Syntax:
func_name(variable name(s));
Pass By Value: Changes made to formal parameter do not get transmitted back
to the caller. Any modifications to the formal parameter variable inside the called
function or method affect only the separate storage location and will not be
reflected in the actual parameter in the calling environment. This method is also
called as call by value.

Call by reference(aliasing): Changes made to formal parameter do get

transmitted back to the caller through parameter passing. Any changes to the
formal parameter are reflected in the actual parameter in the calling environment
as formal parameter receives a reference (or pointer) to the actual data. This
method is also called as call by reference. This method is efficient in both time
and space.

Other methods of Parameter Passing

These techniques are older and were used in earlier programming languages
like Pascal, Algol and Fortran. These techniques are not applicable in high level
languages.
1. Pass by Result : This method uses out-mode semantics. Just before control
is transferred back to the caller, the value of the formal parameter is
transmitted back to the actual parameter. This method is sometimes
called call by result. In general, pass by result technique is implemented by
copy.
2. Pass by Value-Result: This method uses in/out-mode semantics. It is a
combination of Pass-by-Value and Pass-by-result. Just before the control is
transferred back to the caller, the value of the formal parameter is
transmitted back to the actual parameter. This method is sometimes called
as call by value-result
3. Pass by name: This technique is used in programming language such
as Algol. In this technique, symbolic “name” of a variable is passed, which
allows it both to be accessed and update.
Example:
To double the value of C[j], you can pass its name (not its value) into the
following procedure.

procedure double(x);
real x;
begin
x:=x*2
end;
In general, the effect of pass-by-name is to textually substitute the argument
in a procedure call for the corresponding parameter in the body of the
procedure.
Implications of Pass-by-Name mechanism:
 The argument expression is re-evaluated each time the formal parameter
is passed.
 The procedure can change the values of variables used in the argument
expression and hence change the expression’s value.