BC0057 – Object Oriented Analysis and Design

Q. 1) Discuss the importance of object orientation during system

development.

Ans.: Object oriented systems are easier to adapt to changing requirements, easier
to maintain, more robust, and promote greater design and code reuse.

· Higher level of abstraction:

Top-down approach supports abstraction at the function level. The object-oriented

approach supports abstraction at the object level. Since objects encapsulate both
data (attributes) and functions (methods), they work at a higher level of abstraction.

· Seamless transition among different phases of software development:

The object-oriented approach essentially uses the same language to talk about
analysis, design, programming and database design. This seamless approach
reduces the level of complexity and redundancy and makes for clearer, more robust
system development.

· Encouragement of good programming techniques:

In a properly designed system, the classes will be grouped into subsystems but
remain independent. Therefore, changing one class has no impact on other classes,
and so, the impact is minimized which encourages good programming.

· Promotion of reusability:

Objects are reusable because they are modeled directly out of real-world problem
domain. The object orientation adds inheritance, which is a powerful technique that
allows classes to be built from each other and therefore, only differences and
enhancements between the classes need to be designed and coded.

_______________________________________________________________________

Q. 2) What is polymorphism? Explain it with one example.

Ans.: Poly means “many” and morph means “form”. In the context of object-
oriented systems, it means objects that can take on or assume many different
forms. Polymorphism means that the same operation may behave differently on
different classes.

Polymorphism allows us to write generic, reusable code more easily, because we can
specify general instructions and delegate the implementation details to the objects
involved. Since no assumption is made about the class of an object that receives a
message, fewer dependencies are needed in the code and, therefore maintenance is
easier. For example, in a payroll system, manager, office worker, and production
worker objects all will respond to the compute payroll message, but the actual
operations performed are object specific.

A payroll program

An organization has three types of employees:

1. Managers receive a regular salary

2. Office workers receive an hourly wage and are eligible for overtime after 40
hours
3. Production workers are paid according to a piece rate

Structured Approach

The Structured Analysis / Structured Design (SA / SD) approach encourages the top-
down design (also known as top-down decomposition or stepwise refinement),
characterized by moving from a general statement about the process involved in
solving a problem down toward more and more detailed statements about each
specific task in the process.

The object-oriented approach

Object-oriented systems development consists of;

• Object-oriented analysis
• Object-oriented information modeling
• Object-oriented design
• Prototyping and implementation
• Testing, iteration and documentation

The first task in object-oriented analysis is to find the class of objects that will
compose the system. At the first level of analysis, we can look at the physical entities
in the system. Coad and Yourdon have listed the following clues for finding the
candidate classes and objects:

· Persons. What role does a person play in the system? For example, customers,
employees of which the system needs to keep track.

· Places. These are physical locations, buildings, stores, sites or offices about which
the system keeps information.

· Things or events. These are events, points in time that must be recorded.

Q. 3) Explain the various tools for software implementation.

Ans.: CASE Tools: Computer Aided Software Engineering (CASE) tools allow their
users to rapidly develop information systems. The main goal of CASE technology is
the automation of the entire information systems development life cycle process
using a set of integrated software tools, such as modeling, methodology, and
automatic code generation. However, most often, the code generated by CASE tools
is only the skeleton of an application and a lot needs to be filled in by programming
by hand. A new generation of CASE tools is beginning to support Component Based
Development.

Component Based Development: CBD is an industrialized approach to the

software development process. Application development moves from custom
development to assembly of prebuilt, pretested, reusable software components that
operate with each other. Two basic ideas underlie component-based development.
First, the application development can be improved significantly if applications can
be assembled quickly from prefabricated software components. Second, an
increasingly large collection of interpretable software components could be made
available to developers in both general and specialist catalogs. Put together, these
two ideas move application development from a craft activity to an industrial process
fit to meet the needs of modern, highly dynamic, competitive, global businesses.

Software Components: The software components are the functional units of a

program, building blocks offering a collection of reusable services. A software
component can request a service from another component or deliver its own services
on request. The delivery of services is independent, which means that components
work together to accomplish a task. In short, the object-oriented concept addresses
analysis, design, and programming, whereas component-based development is
concerned with the implementation and system integration aspects of software
development.

Rapid Application Development: RAD is a set of tools and techniques that can be
used to build an application faster than typically possible with traditional methods.
The term often is used in conjunction with software prototyping. RAD does not
replace the system development life cycle but complements it, since it focuses more
on process description and can be combined perfectly with the object-oriented
approach. The task of RAD is to build the application quickly and incrementally
implement the design and user requirements, through tools such as Delphi, Visual
Age, Visual Basic, or Power Builder.

Incremental testing

If you wait until after development to test an application for bugs and performance,
you could be wasting thousands of dollars and hours of time. Testing should be an
integral part of SDLC.

_______________________________________________________________________

Q. 4) Explain Jacobson et al.’s methodologies.

Ans.: The Jacobson et al. methodologies:

The Jacobson et al. methodologies (e.g. Object-Oriented Business Engineering

(OOBE), Object-Oriented Software Engineering (OOSE), and Object Factory for
Software Development (Objectory)) cover the entire life cycle and stress traceability
between the different phases, both forward and backward.

Use Cases:-Use cases are scenarios for understanding system requirements. A use
case is an interaction between users and a system. The use-case model captures the
goal of the user and the responsibility of the system to its users. In the requirements
analysis, the use cases are described as one of the following:
· Non-formal text with no clear flow of events

· Text, easy to read but with a clear flow of events to follow (this is a recommended
style)

· Formal style using pseudo code

The use case description must contain:

· How and when the use case begins and ends

· The interaction between the use case and its actors, including when the interaction
occurs and what is exchanged

· How and when the use case will need data stored in the system or will store data in
the system

· Exceptions to the flow of events

· How and when concepts of the problem domain are handled.

Every single use case should describe one main flow of events. An exceptional or
additional flow of events could be added. The exceptional use case extends another
use case to include the additional one. The use case model employs extends and
uses relationships. The extends relationship is used when you have one use case that
is similar to another use case but does a bit more. In essence, it extends the
functionality of the original use case (like a subclass). The uses relationship reuses
common behavior in different use cases

Object-Oriented Software Engineering: Objectory

Object-oriented software engineering (OOSE), also called Objectory, is a method of

object-oriented development with the specific aim to fit the development of large,
real-time systems.

Objectory is built around several different models:

· Use case model. The use-case model defines the outside (actors) and inside (use
case) of the systems behavior.

· Domain object model. The objects of the “real” world are mapped into the
domain object model.

· Analysis object model. The analysis object model presents how the source code
(implementation) should be carried out and written.

· Implementation model. The implementation model represents the

implementation of the system.

· Test model. The test model constitutes the test plans, specifications, and reports.
Object-Oriented Business Engineering

OOBE is object modeling at the enterprise level.

· Analysis phase. The analysis phase defines the system to be built in terms of the
problem-domain object model, the requirements model, and the analysis model. The
analysis process should not take into account the actual implementation
environment. This reduces complexity and promotes maintainability over the life of
the system, since the description of the system will be independent of hardware and
software requirements.

· Design and implementation phases. The implementation environment must be

identified for the design model. This includes factors such as DBMS, distribution of
process, constraints due to the programming language, available component
libraries, and incorporation of graphical user interface tools.

· Testing phase. Finally, Jacobson describes several testing levels and techniques.
The levels include unit testing, integration testing, and system testing.

_______________________________________________________________________

Q. 5) Justify that UML is a language for modeling, visualizing, specifying,

constructing, and documenting.

Ans.: The Unified Modeling Language, or the UML, is a graphical modeling

language that provides us with syntax for describing the major elements
(called artifacts in the UML) of software systems. The UML is gaining adoption as a
single, industry wide language. The UML was originally designed by the three amigos
at Rational Corp. namely Grady Booch, Rumbaugh and Jacobson. The language is
very rich and carries with it many aspects of software engineering best practices. The
UML is a language for modeling, visualizing, specifying, constructing and
documenting the artifacts of a software intensive system.

The UML is a Language for Modeling

A language provides a vocabulary and the rules for combining words in that
vocabulary for the purpose of communication. A modeling language is a language
whose vocabulary and rules focus on the conceptual and physical representation of a
system. A modeling language such as the UML is thus a standard language for
software blueprints.

Modeling yields an understanding of a system. No one model is ever sufficient.

Rather, you often need multiple models that are connected to one another in order to
understand anything but the most trivial system. For software intensive systems, this
requires a language that addresses the different views of a system’s architecture as
it evolves throughout the software development life cycle.

The vocabulary and rules of a language such as the UML tell you how to create and
read well formed models. But they don’t tell you what models you should create and
when you should create them. That’s the role of the software development process. A
well defined process will guide you in deciding what artifacts to produce, what
activities and what workers to use them, create them and manage them, and how to
use those artifacts to measure and control the project as a whole.
The UML is a Language for Visualizing

The UML is more than just a bunch of graphical symbols. Rather, behind each symbol
in the UML notation is a well defined semantics. In this manner, one developer can
write a model in the UML, and another developer, or even another tool, can interpret
that model unambiguously. Some things are best modeled textually; others are best
modeled graphically. Indeed, in all interesting systems, there are structures that
transcend what can be represented in a programming language. The UML is such a
graphical language. Using UML you can produce explicit models that facilitate
communication.

The UML is a Language for Specifying

In this context, specifying means building models that are precise, unambiguous, and
complete. In particular, the UML addresses the specification of all the important
analysis, design, and implementation decisions that must be made in developing and
deploying a software intensive system.

The UML is a Language for Constructing

The UML is not a visual programming language, but its models can be directly
connected to a variety of programming languages. This means that it is possible to
map from a model in the UML to a programming language such as Java, C++, or
Visual Basic, or even to tables in a relational database or the persistent store of an
object oriented database. Things that are best expressed graphically are done
so graphically in the UML, whereas things that are best expressed textually
are done so in the programming language.

This mapping permits forward engineering: The generation of code from a UML
model into a programming language. The reverse is also possible: You can
reconstruct a model from an implementation back into the UML. Reverse
engineering is not magic. Unless you encode that information in the
implementation, information is lost when moving forward from models to code.
Reverse engineering thus requires tool support with human intervention. Combining
these two paths of forward code generation and reverse engineering yields round
trip engineering, meaning the ability to work in either a graphical or a textual view,
while tools keep the two views consistent.

In addition to this direct mapping, the UML is sufficiently expressive and

unambiguous to permit the direct execution of models, the simulation of systems,
and the instrumentation of running systems.

The UML is a Language for Documenting

A healthy software organization produces all sorts of artifacts in addition to raw

executable code. These artifacts include (but are not limited to),

· Requirements

· Architecture

· Design
· Source code

· Project plans

· Tests

· Prototypes

· Releases

Depending on the development culture, some of these artifacts are treated more or
less formally than others. Such artifacts are not only the deliverables of a project,
they are also critical in controlling, measuring, and communicating about a system
during its development and after its deployment.

The UML addresses the documentation of a system’s architecture and all of its
details. The UML also provides a language for expressing requirements and for tests.
Finally, the UML provides a language for modeling the activities of project planning
and release management.

Q. 6) Explain Statecharts and Activity Diagrams with examples.

Ans.:

Statecharts:

A statechart diagram shows a state machine, consisting of states,

transitions, events, and activities.

Statechart diagrams address the dynamic view of a system. They are especially
important in modeling the behavior of an interface, class, or collaboration and
emphasize the event-ordered behavior of an object, which is especially useful in
modeling reactive systems. Fig. 6.16 shows a state chart diagram.

Activity Diagram:

An activity diagram is a special kind of a statechart diagram that shows the flow from
activity to activity within a system.

Activity diagrams address the dynamic view of a system. They are especially
important in modeling the function of a system and emphasize the flow of control
among objects. Fig. 6.17 shows an example of activity diagram.