Assignment-2

Ques:1 List the principles of OOSE with its concepts.

Ans:1 There are 4 major principles that make a language Object Oriented. These are
Encapsulation, Data Abstraction, Polymorphism and Inheritance. These are also called as four
pillars of Object-Oriented Programming.

Encapsulation
Encapsulation is the mechanism of hiding of data implementation by restricting access to public
methods. Instance variables are kept private and accessor methods are made public to achieve
this.
Abstraction
Abstract means a concept or an Idea which is not associated with any particular instance. Using
abstract class/Interface we express the intent of the class rather than the actual
implementation. In a way, one class should not know the inner details of another in order to
use it, just knowing the interfaces should be good enough.
Inheritance
Inheritances expresses “is-a” and/or “has-a” relationship between two objects. Using
Inheritance, in derived classes we can reuse the code of existing super classes. In Java, concept
of “is-a” is based on class inheritance (using extends) or interface implementation
(using implements).
Polymorphism
It means one name many forms. It is further of two types — static and dynamic. Static
polymorphism is achieved using method overloading and dynamic polymorphism using method
overriding. It is closely related to inheritance. We can write a code that works on the superclass,
and it will work with any subclass type as well.
Ques:2 What are the metrics of Process? Explain it with example?
Ans:2
Process Metrics: -These are metrics that pertain to Process Quality. They are used to measure
the efficiency and effectiveness of various processes.
Types of Process Metrics: -

1.Cost of quality: It is a measure of the performance of quality initiatives in an organization.

It’s expressed in monetary terms.
Cost of quality = (review + testing + verification review + verification testing + QA +
configuration management + measurement + training + rework review + rework testing)/ total
effort x 100.

2.Cost of poor quality: It is the cost of implementing imperfect processes and products.
Cost of poor quality = rework effort/ total effort x 100.

3.Defect density: It is the number of defects detected in the software during development
divided by the size of the software (typically in KLOC or FP)
Defect density for a project = Total number of defects/ project size in KLOC or FP

4.Review efficiency: defined as the efficiency in harnessing/ detecting review defects in the
verification stage.
Review efficiency = (number of defects caught in review)/ total number of defects caught) x 100.

5.Testing Efficiency: Testing efficiency = 1 – ((defects found in acceptance)/ total number of

testing defects) x 100.

6.Defect removal efficiency: Quantifies the efficiency with which defects were detected and
prevented from reaching the customer.
Defect removal efficiency = (1 – (total defects caught by customer/ total number of defects)) x
100.

7.Residual defect density = (total number of defects found by a customer)/ (Total number of
defects including customer found defects) x 100.

Ques:3 Write in detail about Object Oriented approach for Scheduling.

Ans:3 The design presented here is in every aspect object-oriented. There are many advantages
in following an object-oriented design approach in the development of a scheduling system. First,
the design is modular, which makes maintenance and modification of the system relatively easy.
Second, large segments of the code are reusable. This implies that two scheduling systems that
are substantially different still may share a significant amount of code. Third, the designer thinks
in terms of the behavior of objects, not in low-level detail. In other words, the object- oriented
design approach can speed up the design process and separate the design process from the
implementation process. Object-oriented systems are usually designed around two basic entities,
namely objects and methods Objects usually refer to various types of entities or concepts. The
most obvious ones are jobs and machines. However, a schedule is also an object and so are user
interface widgets, such as buttons, menus and canvases. There are two basic kinds of
relationships between object types, namely the is-a relationship and the has-a relationship.
According to an is-a relationship, an object type is a special case of another object type. According
to a has-a relationship, an object type may consist of other object types. Objects usually carry
along static information, also referred to as attributes, and dynamic information, usually referred
to as the state of the object. An object may have a number of attributes which are descriptors
associated with the object. An object may be in any one of a number of states. For example, a
machine may be working, 08, or broken down. Changes in the state of an object are referred to
as events.

A method is implemented in a system by means of one or more operators. Operators are used
to manipulate the attributes corresponding to objects and may result in changes of object states,
i.e., events. On the other hand, events may trigger opera- tors as well. The sequence of states of
the different objects can be described by a state-transition or event diagram. Such an event
diagram may describe the links between operators and events. An operator may be regarded as
the way in which a method is implemented in the software. Any given operator may be part of
several methods. Some methods may be very basic and can be used for simple manipulations of
objects, e.g., a pairwise interchange of two jobs in a schedule. Some methods may be very
sophisticated or high level. They may be intricate heuristics for application on given sets of jobs
(objects) in given machine environments (also objects). The application of a method to an object
usually triggers an event.
The application of a method to an object may cause information to be transmitted from one
object to another. In what follows, such information is referred to as a message, Messages
represent information (or content) that are transmitted from one object (for example, a
schedule) via a method to another object (for example, a user interface display). A message may
consist of simple attributes or of an entire object. Messages are transmitted at the times that
events occur (caused by the application of methods to objects). Messages have also been
referred to in the literature as memos. The transmission of messages from one object to another
can be described by a transition event diagram. Such transmissions require the specification of
protocols. However, the specification of protocols is at a level of detail of system design that we
will not address in this paper. Figure 2 depicts the interplay between objects, methods and
messages. In order to see the sometimes-complicated relationships between objects, methods
and messages, consider the following example of a somewhat specialized object, a so- called
agent object. This very specialized object usually contains other objects, e.g., machines, jobs and
so on, as well as one or more methods. An input message into such an object is the states of one
or more objects, while the output message may be the states of the same objects or other
objects. An agent object usually performs a decision-making function.
A scheduling system may be object-oriented in its conceptual design and/or in its development.
A scheduling system is object-oriented in its conceptual design if the design of the system is
object-oriented throughout. The design being object- oriented throughout implies that every
concept used and every functionality of the system is either an object or a method of an object
(whether it is in the data or knowledge base, the algorithm library, the schedule generator or the
user interfaces). Even the largest modules within the system are objects, including the algorithm
library and the user interface modules. A scheduling system is object-oriented in it development
if only the more detailed design aspects are object-oriented and the code is based on a
programming language with object-oriented extensions, e.g., C++. Many scheduling systems
developed in the past have object-oriented aspects and many systems tend to be object-oriented
in their development. A number of these systems also have conceptual design aspects that are
object oriented.

Ques:4 Explain in detail about Design Patterns.

Ans:4 In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which
initiated the concept of Design Pattern in Software development.
These authors are collectively known as Gang of Four (GOF). According to these authors design
patterns are primarily based on the following principles of object orientated design.
• Program to an interface not an implementation
• Favor object composition over inheritance

Usage of Design Pattern

Design Patterns have two main usages in software development.
Common platform for developers
Design patterns provide a standard terminology and are specific to particular scenario. For
example, a singleton design pattern signifies use of single object so all developers familiar with
single design pattern will make use of single object and they can tell each other that program is
following a singleton pattern.
Best Practices
Design patterns have been evolved over a long period of time and they provide best solutions to
certain problems faced during software development. Learning these patterns helps
unexperienced developers to learn software design in an easy and faster way.

Types of Design Patterns

As per the design pattern reference book Design Patterns - Elements of Reusable Object-Oriented
Software, there are 23 design patterns which can be classified in three categories: Creational,
Structural and Behavioral patterns. We'll also discuss another category of design pattern: J2EE
design patterns.

S.N. Pattern & Description

1 Creational Patterns
These design patterns provide a way to create objects while hiding the creation logic, rather
than instantiating objects directly using new operator. This gives program more flexibility in
deciding which objects need to be created for a given use case.

2 Structural Patterns
These design patterns concern class and object composition. Concept of inheritance is used
to compose interfaces and define ways to compose objects to obtain new functionalities.

3 Behavioral Patterns
These design patterns are specifically concerned with communication between objects.

4 J2EE Patterns
These design patterns are specifically concerned with the presentation tier. These patterns
are identified by Sun Java Center.

Ques:5 Explain in detail about Design Concepts & Principles.

Ans:5
Design Concepts: -
Every software process is characterized by basic concepts along with certain practices or
methods. Methods represent the manner through which the concepts are applied. As new
 technology replaces older technology, many changes occur in the methods that are used to
apply the concepts for the development of software.

1)Abstraction: - Abstraction refers to a powerful design tool, which allows software designers
to consider components at an abstract level, while neglecting the implementation details of the
components. IEEE defines abstraction as 'a view of a problem that extracts the
essential information relevant to a particular purpose and ignores the remainder of the
information.' The concept of abstraction can be used in two ways: as a process and as an entity.
As a process, it refers to a mechanism of hiding irrelevant details and representing only the
essential features of an item so that one can focus on important things at a time. As an entity, it
refers to a model or view of an item.
There are three commonly used abstraction mechanisms in software design, namely, functional
abstraction, data abstraction and control abstraction. All these mechanisms allow us to control
the complexity of the design process by proceeding from the abstract design model to concrete
design model in a systematic manner.
1. Functional abstraction: This involves the use of parameterized subprograms. Functional
abstraction can be generalized as collections of subprograms referred to as 'groups'. Within these
groups there exist routines which may be visible or hidden. Visible routines can be used within
the containing groups as well as within other groups, whereas hidden routines are hidden from
other groups and can be used within the containing group only.
2. Data abstraction: This involves specifying data that describes a data object. For example, the
data object window encompasses a set of attributes (window type, window dimension) that
describe the window object clearly. In this abstraction mechanism, representation and
manipulation details are ignored.
3. Control abstraction: This states the desired effect, without stating the exact mechanism of
control. For example, if and while statements in programming languages (like C and C++) are
abstractions of machine code implementations, which involve conditional instructions. In the
architectural design level, this abstraction mechanism permits specifications of sequential
subprogram and exception handlers without the concern for exact details of implementation.

2.Architecture: - Software architecture refers to the structure of the system, which is composed
of various components of a program/ system, the attributes (properties) of those components
and the relationship amongst them. The software architecture enables the software engineers
to analyze the software design efficiently. In addition, it also helps them in decision-making and
handling risks. The software architecture does the following.
• Provides an insight to all the interested stakeholders that enable them to communicate
with each other
• Highlights early design decisions, which have great impact on the software engineering
activities (like coding and testing) that follow the design phase
• Creates intellectual models of how the system is organized into components and how
these components interact with each other. Currently, software architecture is
represented in an informal and unplanned manner. Though the architectural concepts
 are often represented in the infrastructure (for supporting particular architectural styles)
and the initial stages of a system configuration, the lack of an explicit independent
characterization of architecture restricts the advantages of this design concept in the
present scenario.
Note that software architecture comprises two elements of design model, namely, data design
and architectural design.

3.Patterns: - A pattern provides a description of the solution to a recurring design problem of

some specific domain in such a way that the solution can be used again and again.
Types of Design Patterns: -
Software engineer can use the design pattern during the entire software design process. When
the analysis model is developed, the designer can examine the problem description at different
levels of abstraction to determine whether it complies with one or more of the following types
of design patterns.
a) Architectural patterns: These patterns are high-level strategies that refer to the overall
structure and organization of a software system. That is, they define the elements of a software
system such as subsystems, components, classes, etc. In addition, they also indicate the
relationship between the elements along with the rules and guidelines for specifying these
relationships. Note that architectural patterns are often considered equivalent to software
architecture.
b) Design patterns: These patterns are medium-level strategies that are used to solve design
problems. They provide a means for the refinement of the elements (as defined by architectural
pattern) of a software system or the relationship among them. Specific design elements such as
relationship among components or mechanisms that affect component-to-component
interaction are addressed by design patterns. Note that design patterns are often considered
equivalent to software components.

c) Idioms: These patterns are low-level patterns, which are programming-language specific. They
describe the implementation of a software component, the method used for interaction among
software components, etc., in a specific programming language. Note that idioms are often
termed as coding patterns.

4.Modularity: - Modularity is achieved by dividing the software into uniquely named and
addressable components, which are also known as modules. A complex system (large program)
is partitioned into a set of discrete modules in such a way that each module can be developed
independent of other modules. After developing the modules, they are integrated together to
meet the software requirements. Note that larger the number of modules a system is divided
into, greater will be the effort required to integrate the modules.
Modularizing a design helps to plan the development in a more effective manner, accommodate
changes easily, conduct testing and debugging effectively and efficiently, and conduct
maintenance work without adversely affecting the functioning of the software.

5.Information Hiding: - Modules should be specified and designed in such a way that the data
structures and processing details of one module are not accessible to other modules. They pass
only that much information to each other, which is required to accomplish the software
functions. The way of hiding unnecessary details is referred to as information hiding. IEEE defines
information hiding as 'the technique of encapsulating software design decisions in modules in
such a way that the module's interfaces reveal as little as possible about the module's inner
workings; thus, each module is a 'black box' to the other modules in the system.

6.Stepwise Refinement: - Stepwise refinement is a top-down design strategy used for

decomposing a system from a high level of abstraction into a more detailed level (lower level) of
abstraction. At the highest level of abstraction, function or information is defined conceptually
without providing any information about the internal workings of the function or internal
structure of the data. As we proceed towards the lower levels of abstraction, more and more
details are available.
Software designers start the stepwise refinement process by creating a sequence of compositions
for the system being designed. Each composition is more detailed than the previous one and
contains more components and interactions.
7.Refactoring: - Refactoring is an important design activity that reduces the complexity of
module design keeping its behavior or function unchanged. Refactoring can be defined as a
process of modifying a software system to improve the internal structure of design without
changing its external behavior. During the refactoring process, the existing design is checked for
any type of flaws like redundancy, poorly constructed algorithms and data structures, etc., in
order to improve the design. For example, a design model might yield a component which
exhibits low cohesion (like a component performs four functions that have a limited relationship
with one another). Software designers may decide to refactor the component into four different
components, each exhibiting high cohesion. This leads to easier integration, testing, and
maintenance of the software components.

8.Structural Portioning: - When the architectural style of a design follows a hierarchical nature,
the structure of the program can be partitioned either horizontally or vertically.
In horizontal partitioning, the control modules are used to communicate between functions and
execute the functions. Structural partitioning provides the following benefits.
• The testing and maintenance of software becomes easier.
• The negative impacts spread slowly.
• The software can be extended easily.
Besides these advantages, horizontal partitioning has some disadvantage also. It requires to pass
more data across the module interface, which makes the control flow of the problem more
complex. This usually happens in cases where data moves rapidly from one function to another.

In vertical partitioning, the functionality is distributed among the modules--in a top-down

manner. The modules at the top level called control modules perform the decision-making and
do-little processing whereas the modules at the low level called worker modules perform all
input, computation and output tasks.

9.Concurrency: - Computer has limited resources and they must be utilized efficiently as much
as possible. To utilize these resources efficiently, multiple tasks must be executed concurrently.
This requirement makes concurrency one of the major concepts of software design. Every system
must be designed to allow multiple processes to execute concurrently, whenever possible. For
example, if the current process is waiting for some event to occur, the system must execute some
other process in the meantime.
Design Principle: -

1. Divide and conquer: The layers can be independently designed.

2. Increase cohesion: Well-designed layers have layer cohesion.
3. Reduce coupling: Well-designed lower layers do not know about the higher layers and the only
connection between layers is through the API.
4. Increase abstraction: you do not need to know the details of how the lower layers are
implemented.
5. Increase reusability: The lower layers can often be designed generically.
6. Increase reuse: You can often reuse layers built by others that provide the services you need.
7. Increase flexibility: you can add new facilities built on lower-level services, or replace higher-
level layers.
8. Anticipate obsolescence: By isolating components in separate layers, the system becomes
more resistant to obsolescence.
9. Design for portability: All the dependent facilities can be isolated in one of the lower layers.
10. Design for testability: Layers can be tested independently.
11.Design defensively: The APIs of layers are natural places to build in rigorous assertion-
checking.

Ques:6 How OOA and OOD models helps while Testing a software?
Ans:6 OO Testing begins by evaluating the correctness and consistency of the OOA and OOD
models.
o The nature of OO software changes testing strategies.
o the concept of the ‘unit’ broadens due to encapsulation
o cannot test class methods in isolation due to object collaborations and inheritance
o class testing is driven by its methods and behavior (states).
o Conventional integration testing (top-down and bottom-up) are not applicable to OO
software.

Class integration options:

1. Thread-based integration (classes that respond to one event (input) to the system)
2. Use-based integration (independent classes first, then dependent classes)
3. Collaboration-based (cluster) integration (classes that collaborate together to complete one
collaboration).

Note: always apply regression testing for side effects.

Test case design draws on conventional methods, but also encompasses special features.

• OO Testing Strategy Class testing is the equivalent of unit testing

- operations within the class are tested
- the state behavior of the class is examined.

Integration testing applies three different strategies:

1. Thread-based testing: integrates the set of classes required to respond to one input or event
2. Use-based testing: integrates the set of classes required to respond to one use-case (usage
scenario).
3. Cluster testing: integrates the set of classes required to demonstrate one collaboration
(determined from the object relationship and CRC models).

Ques:7 Software Maintainability Metrics Help Identify Problem Areas. Justify

Ans:7 Software maintainability requires more developer effort than any other phase of the
development life cycle. A programming team will perform four types of maintenance on new
deployments or enhancements: corrective, adaptive, perfective, and preventative. These
activities will take additional time to complete if the code is not easy to manage in the first place.
An application with these qualities will require increased programming effort:
• Poor Code Quality
• Source Code Defects
• Undetected Vulnerabilities
• Excessive Technical Complexity
• Large Systems
• Poorly Documented Systems
• Excessive Dead Code

Resource needs continue to grow as environments become increasingly complex and

applications are rapidly developed. Software maintainability metrics deliver an inexpensive,
accurate approach to detecting potential causes of unmaintainable systems. As a result, your
organization obtains insight into improvement areas and can monitor critical systems throughout
its application life cycle.
A software maintainability measurement is a rating used to assess the amount of effort or
resources currently committed to an application. Automated solutions offer an accurate,
objective way to measure each program. They supply a benchmarking measurement for reducing
application complexity, improving quality, and mitigating risk as an application is created,
enhanced, or maintained. Automated analysis is a viable, cost-effective approach to identifying
software maintainability issues and determining what actions should be taken to reduce
programming efforts or costs.
Hence, Software maintainability is defined as the degree to which an application is understood,
repaired, or enhanced. Software maintainability is important because it is approximately 75% of
the cost related to a project.