OOSE Minor Exam

Q. Discuss basic concepts of object-orientation. Explain each concept with example.

A. Object: An object is characterised by a number of operations and a state which remembers the
effect of these operations.

Class: A class represents a template for several objects and describes how these objects are
structured internally. Objects of the same class have the same definition both for their operation
and for their information structure.

Instance: An instance is an object created from a class. The class describes (behaviour and
information) structure of the instance, while current state of the instance is defined by the
operations performed on the instance.

Polymorphism: Polymorphism means that the sender of a stimulus does not need to know the
receiving instance’s class. The receiving instance can belong to an arbitrary class.

Inheritance: If class B inherits class A, then both the operations and the information structure
described in class A will become part of class B.

Q. Explain with suitable examples the different types of requirement problems that should be
identified and resolved during the requirements analysis activity.

A. Analyzing requirements: determining whether the stated requirements are unclear, incomplete,
ambiguous, or contradictory, and then resolving these issues.

Q. What is the aim of the analysis model? What are the various dimensions of the analysis model?
Describe various strategies for allocating the functionality.

A. When the requirements model has been developed, and often also signed by the orderers, we can
focus on the structuring of the system. This is initially done by developing the analysis model. In the
analysis model, we describe the system using three different types of objects: interface objects,
entity objects and control objects. Each of these objects has its own purpose and will model a
specific aspect of the system. We also use subsystems to group these objects into manageable units.

In the requirements model we have specified what is to take place within the system. The analysis
model aims at creating a good model for the system design and will also form the basis of the
design. The requirements model is thus structured by the analysis model.

The dimensions of the analysis model are information, behaviour and presentation. The
information dimension specifies the information held in the system, both short term and long term.
Along this dimension, we specify the system’s internal state. In the behaviour dimension, we specify
the behaviour which the system shall adopt. Here, we specify when and how the system will change
state. The presentation dimension provides the details for presenting the system to the outside
world.
Functionality Allocation Strategies

Interface objects are quite simple to identify. We have at least three strategies. Either they are
clearly identified from the system interface descriptions accompanying the requirements model, or
we can start from the actors, or we can read the use case descriptions and extract the functionality
that is interface specific.

The entity objects are identified from the use cases, just the same as the interface objects. Entities
usually correspond to some concept in real life, outside the system, although this is not always the
case.

The control objects are normally found directly from the use cases. In a preliminary draft, we will
one control object for each concrete and abstract use case. Each use case normally involves
interface objects and entity objects. Thus behaviour that remains after the interface objects and
entity objects have obtained their parts will be placed in the control objects.

Q. Explain the waterfall and iterative waterfall methods of software development.

A. Classical waterfall model is the basic software development life cycle model. It is very simple but
idealistic. Earlier this model was very popular but nowadays it is not used. But it is very important
because all the other software development life cycle models are based on the classical waterfall
model.
Classical waterfall model divides the life cycle into a set of phases. This model considers that one phase
can be started after completion of the previous phase. That is the output of one phase will be the
input to the next phase. Thus the development process can be considered as a sequential flow in the
waterfall. Here the phases do not overlap with each other. The different sequential phases of the
classical waterfall
model are shown in the below figure:

Let us now learn about each of these phases in brief details:

1. Feasibility Study: The main goal of this phase is to determine whether it would be financially
and technically feasible to develop the software.
 2. Requirements analysis and specification: The aim of the requirement analysis and specification
phase is to understand the exact requirements of the customer and document them properly.
3. Design: The aim of the design phase is to transform the requirements specified in the SRS
document into a structure that is suitable for implementation in some programming language.
4. Coding and Unit testing: In coding phase software design is translated into source code using
any suitable programming language. Thus each designed module is coded. The aim of the unit
testing phase is to check whether each module is working properly or not.
5. Integration and System testing: Integration of different modules are undertaken soon after
they have been coded and unit tested. Integration of various modules is carried out
incrementally over a number of steps. During each integration step, previously planned modules
are added to the partially integrated system and the resultant system is tested. Finally, after all
the modules have been successfully integrated and tested, the full working system is obtained
and system testing is carried out on this.
6. Maintainence: Maintenance is the most important phase of a software life cycle. The effort
spent on maintenance is the 60% of the total effort spent to develop a full software.
Advantages of Classical Waterfall Model
 This model is very simple and is easy to understand.
 Phases in this model are processed one at a time.
 Process, actions and results are very well documented.
 This model works well for smaller projects.
Drawbacks of Classical Waterfall Model
 No feedback path: In classical waterfall model evolution of a software from one phase to
another phase is like a waterfall. It assumes that no error is ever committed by developers
during any phases. Therefore, it does not incorporate any mechanism for error correction.
 Difficult to accommodate change requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
actually customers’ requirements keep on changing with time. It is difficult to accommodate any
change requests after the requirements specification phase is complete.
 No overlapping of phases: This model recommends that new phase can start only after the
completion of the previous phase. But in real projects, this can’t be maintained. To increase the
efficiency and reduce the cost, phases may overlap.

The iterative waterfall model provides feedback paths from every phase to its preceding phases,
which is the main difference from the classical waterfall model.
Feedback paths introduced by the iterative waterfall model are shown in the figure below.

When errors are detected at some later phase, these feedback paths allow correcting errors
committed by programmers during some phase. The feedback paths allow the phase to be reworked
in which errors are committed and these changes are reflected in the later phases. But, there is no
feedback path to the stage – feasibility study, because once a project has been taken, does not give
up the project easily.
It is good to detect errors in the same phase in which they are committed. It reduces the effort and
time required to correct the errors.
Phase Containment of Errors: The principle of detecting errors as close to their points of commitment
as possible is known as Phase containment of errors.
Advantages of Iterative Waterfall Model
 Feedback Path: In the classical waterfall model, there are no feedback paths, so there is no
mechanism for error correction. But in iterative waterfall model feedback path from one phase
to its preceding phase allows correcting the errors that are committed and these changes are
reflected in the later phases.
 Simple: Iterative waterfall model is very simple to understand and use. That’s why it is one of
the most widely used software development models.
Drawbacks of Iterative Waterfall Model
 Difficult to incorporate change requests: The major drawback of the iterative waterfall model
is that all the requirements must be clearly stated before starting of the development phase.
Customer may change requirements after some time but the iterative waterfall model does not
leave any scope to incorporate change requests that are made after development phase starts.
 Incremental delivery not supported: In the iterative waterfall model, the full software is
completely developed and tested before delivery to the customer. There is no scope for any
intermediate delivery. So, customers have to wait long for getting the software.
 Overlapping of phases not supported: Iterative waterfall model assumes that one phase can
start after completion of the previous phase, But in real projects, phases may overlap to reduce
the effort and time needed to complete the project.
 Risk handling not supported: Projects may suffer from various types of risks. But, Iterative
waterfall model has no mechanism for risk handling.
 Limited customer interactions: Customer interaction occurs at the start of the project at the
time of requirement gathering and at project completion at the time of software delivery. These
fewer interactions with the customers may lead to many problems as the finally developed
software may differ from the customers’ actual requirements.

Q. Explain the spiral model of software development. What are the limitations of such a model?

A. Spiral model is one of the most important Software Development Life Cycle models, which provides
support for Risk Handling.

Each phase of Spiral Model is divided into four quadrants as shown in the above figure. The functions
of these four quadrants are discussed below-
 1. Objectives determination and identify alternative solutions: Requirements are gathered from
the customers and the objectives are identified, elaborated and analyzed at the start of every
phase. Then alternative solutions possible for the phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant all the possible solutions are evaluated
to select the best possible solution. Then the risks associated with that solution is identified and
the risks are resolved using the best possible strategy. At the end of this quadrant, Prototype is
built for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified features are
developed and verified through testing. At the end of the third quadrant, the next version of the
software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far
developed version of the software. In the end, planning for the next phase is started.

Advantages of Spiral Model: Below are some of the advantages of the Spiral Model.
 Risk Handling: The projects with many unknown risks that occur as the development proceeds,
in that case, Spiral Model is the best development model to follow due to the risk analysis and
risk handling at every phase.
 Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.
 Flexibility in Requirements: Change requests in the Requirements at later phase can be
incorporated accurately by using this model.
 Customer Satisfaction: Customer can see the development of the product at the early phase of
the software development and thus, they habituated with the system by using it before
completion of the total product.
Disdvantages of Spiral Model: Below are some of the main disadvantages of the spiral model.
 Complex: The Spiral Model is much more complex than other SDLC models.
 Expensive: Spiral Model is not suitable for small projects as it is expensive.
 Too much dependable on Risk Analysis: The successful completion of the project is very much
dependent on Risk Analysis. Without very highly experienced expertise, it is going to be a failure
to develop a project using this model.
 Difficulty in time management: As the number of phases is unknown at the start of the project,
so time estimation is very difficult.

Q. What is the incremental process model?

A. Incremental process model is also know as Successive version model.

First, a simple working system implementing only a few basic features is built and then that is delivered
to the customer. Then thereafter many successive iterations/ versions are implemented and delivered
to the customer until the desired system is realized.

A, B, C are modules of Software Product that are incrementally developed and delivered.
Life cycle activities –
Requirements of Software are first broken down into several modules that can be incrementally
constructed and delivered. At any time, the plan is made just for the next increment and not for any
king of long term plans. Therefore, it is easier to modify the version as per the need of the customer.
Development Team first undertakes to develop core features (these do not need services from other
features) of the system.

Once the core features are fully developed, then these are refined to increase levels of capabilities by
adding new functions in Successive versions. Each incremental version is usually developed using an
iterative waterfall model of development.
As each successive version of the software is constructed and delivered, now the feedback of the
Customer is to be taken and these were then incorporated in the next version. Each version of the
software have more additional features over the previous ones.

After Requirements gathering and specification, requirements are then spitted into several different
versions starting with version-1, in each successive increment, next version is constructed and then
deployed at the customer site. After the last version (version n), it is now deployed at the client site.
When to use this –
1. Funding Schedule, Risk, Program Complexity, or need for early realization of benefits.
2. When Requirements are known up-front.
3. When Projects having lengthy developments schedules.
4. Projects with new Technology.
Advantages –
 Error Reduction (core modules are used by the customer from the beginning of the
phase and then these are tested thoroughly)
 Uses divide and conquer for breakdown of tasks.
 Lowers initial delivery cost.
 Incremental Resource Deployment.
Disadvantages –
 Requires good planning and design.
 Total cost is not lower.
 Well defined module interfaces are required.
Q. Explain Object Oriented Analysis and Structured Analysis. What are functional and non-
functional requirements? Explain with example.

A.
Object Oriented Analysis contains, in some order, the following activities:
 Finding the objects
 Organizing the objects
 Describing how objects interact
 Defining the operations of the objects
 Defining the objects internally

Q. Define artifacts. List the artifacts of each phase of object oriented software development
process.

A. An artifact is one of many kinds of tangible by-products produced during the development of
software.
Requirements Set: SRS Document, Use Case Models
Design Set: Design model, Software Architecture Description
Implementation Set: Source Code and Executables
Deployment Set: Executable Software, Build Scripts, Installation Scripts