BC0057-Object Oriented Analysis & Design

Question 1 Why is object oriented system important? State 2

orthogonal views of the software.
Answer: In an object-oriented environment, software is a collection of discrete
objects that encapsulate their data as well as the functionality to model real
world objects. In an object oriented system, everything is an object and each
object is responsible for itself. In a payroll application, instead of saying,
System, compute the payroll of this employee, you tell the employee object,
Compute your payroll. 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 modelled
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

Two orthogonal views of the software

Niklaus Wirth, the inventor of Pascal says:
Algorithms + Data structures = Programs
A software system is a set of mechanisms for performing certain action on
certain data. Traditional development techniques focus on the functions of the
system. Object oriented systems development centres on object, which
combines data and functionality.

Question 2 Explain about Encapsulation & information hiding and class

hierarchy.
Answer: Information hiding is the principle of concealing the internal data and
procedures of an object and providing an interface to each object in such a way
as to reveal as little as possible about its inner workings. C++ has a very general
encapsulation protection mechanism with public, private, and protected
members. Public members (member data and member functions) may be
accessed from anywhere. Private members are accessible one from within a
class. An object data representation, such as a list or an array, usually will be
private. Protected members can be accessed only from subclasses.
In per-class protection, the most common form (e.g. Ada, C++, Eiffel), class
methods can access any object of that class and not just the receiver. In perobject protection, methods can access only the receiver.
An important factor in achieving encapsulation is the design of different classes
of objects that operate using common protocol, or objects user interface. This
means that many objects will respond to the same message but each will
perform the message using operations tailored to its class.
Data abstraction is the benefit of the object-oriented concept that incorporates
encapsulation and polymorphism.
Class hierarchy
An object-oriented system organizes classes into a subclass-super class
hierarchy. Different properties and behaviours are used as the basis for making
distinctions between classes and subclasses. At the top of the class hierarchy are
the most general classes and at the bottom are the most specific. A subclass
inherits all of the properties and methods (procedures) defined in its super class.
Subclasses generally add new methods and properties specific to that class.
Subclasses may refine or constrain the state and behaviour inherited from its
super class.
An object-oriented system eliminates duplicated effort by allowing classes to
share and reuse behaviours.
Formal or abstract classes have no instances but define the common behaviours
that can be inherited by more specific classes.
Super and subclasses may also be called as base and derived classes

Question 3 Describe Rumbaugh et als Object Modeling Technique.

Answer: The object-modeling technique (OMT) is an object modeling language for
software modeling and designing. It was developed circa 1991 by Rumbaugh,
Blaha, Premerlani, Eddy and Lorensen as a method to develop object-oriented
systems, and to support object-oriented programming.
OMT was developed as an approach to software development. The purposes of
modeling are:
testing physical entities before building them (simulation)
communication with customers
visualization (alternative presentation of information)
reduction of complexity.

OMT has proposed three main types of models:

Object model: The object model represents the static and most stable
phenomena in the modeled domain. Main concepts are classes and
associations, with attributes and operations. Aggregation and
generalization (with multiple inheritance) are predefined relationships.
Dynamic model: The dynamic model represents a state/transition view on
the model. Main concepts are states, transitions between states, and
events to trigger transitions. Actions can be modeled as occurring within
states. Generalization and aggregation are predefined relationships.
Functional model: The functional model handles the process perspective of
the model, corresponding roughly to data flow diagrams. Main concepts
are process, data store, data flow, and actors.
The entire OMT software development process has four phases:
Analysis, system design, object design, and implementation of the software. Most
of the modeling is performed in the analysis phase. The recommended method
incorporates the following activities:
a) Develop a Problem Statement.
b) Build an Object Model:
1. Identify object classes.
2. Develop a data dictionary for classes, attributes, and associations.
3. Add associations between classes.
4. Add attributes for objects and links.
5. Organize and simplify object classes using inheritance.
6. Test access paths using scenarios and iterate the above steps as
necessary.

7. Group classes into modules, based on close coupling and related

function.
c) Build a Dynamic Model:
1. Prepare scenarios of typical interaction sequences.
2. Identify events between objects and prepare an event trace for
each scenario.
3. Prepare an event flow diagram for the system.
4. Develop a state diagram for each class that has important dynamic
behaviour.
5. Check for consistency and completeness of events shared among
the state diagrams.
d) Build a Functional Model:
1. Identify input and output values.
2. Use data flow diagrams as needed to show functional dependencies.
3. Describe what each function does. Identify constraints.
4. Specify optimization criteria.

Question 4 Write short notes on:

Answer: Sequence Diagram:
A sequence diagram is an interaction diagram that shows how processes operate
with one another and in what order. It is a construct of a Message Sequence
Chart. A sequence diagram shows object interactions arranged in time sequence.
It depicts the objects and classes involved in the scenario and the sequence of
messages exchanged between the objects needed to carry out the functionality
of the scenario. Sequence diagrams are typically associated with use case
realizations in the Logical View of the system under development. Sequence
diagrams are sometimes called event diagrams, event scenarios
A sequence diagram shows, as parallel vertical lines (lifelines), different
processes or objects that live simultaneously, and, as horizontal arrows, the
messages exchanged between them, in the order in which they occur. This allows
the specification of simple runtime scenarios in a graphical manner.

Collaboration diagrams : A collaboration diagram, also called a

communication diagram or interaction diagram, is an illustration of the

relationships and interactions among software objects in the Unified Modeling

Language (UML). The concept is more than a decade old although it has been
refined as modeling paradigms have evolved.
A collaboration diagram resembles a flowchart that portrays the roles,
functionality and behavior of individual objects as well as the overall operation of
the system in real time. Objects are shown as rectangles with naming labels
inside. These labels are preceded by colons and may be underlined. The
relationships between the objects are shown as lines connecting the rectangles.
The messages between objects are shown as arrows connecting the relevant
rectangles along with labels that define the message sequencing.
It aim at showing the communications that happen between objects, by defining
messages that flow between each other. They basically consist of superimposing
the communication actions upon an object diagram. The temporal aspect can be
shown here too, by numbering the interactions with sequential labels. A
collaboration diagram shows the interactions between objects or classes in terms
of links (solid undirected lines connecting the elements that can interact) and
messages that flow through the links. This describes at the same time some kind
of static structure (links and nodes) and dynamic behaviour (messages) of the
system. An example is shown below.

Question 5 Explain the 3 steps in extracting Entity Classes with a

flowchart.
Answer: Entity class extraction consists of three steps that are carried out
iteratively and incrementally:
Functional Modeling. Present scenarios of all the use cases (a scenario is
an instance of a use case).
Class Modeling. Determine the entity classes and their attributes. Then,
determine the interrelationships and interactions between the entity
classes. Present this information in the form of a Class Diagram.
Dynamic Modeling. Determine the operations performed by or to each
entity class or subclass. Present this information in the form of a
Statechart.

These steps are shown in below figure. However, as with all iterative and
incremental processes, the three steps are not necessarily always performed in
the order shown in the figure a change in one model will simply trigger
corresponding revisions of the other two models.
Extracting the Entity Classes Step 1:
Functional Modeling -- Use Cases
There are two possible use cases for the elevator problem,
Press an Elevator Button, and
Press a Floor Button
Functional Modeling -- Use Cases

Extracting the Entity Classes Step 2:

Entity Class Modeling
Extract entity classes and their attributes
Represent them using a UML diagram
One alternative: Deduce the entity classes from use cases and their
scenarios
Possible danger: Many scenarios, and hence
Too many candidate classes
Other alternatives:
CRC (Class-Responsibility-Collaboration) cards
Noun extraction
The 1st Iteration of Class Diagram

The 2nd Iteration of Class Diagram

Extracting the Entity Classes Step 3:

Dynamic Modeling
Dynamic modeling is the third step in extracting the entity classes
A statechart is constructed that reflects all the operations performed by or
to the software product
The operations are determined from the Scenarios

Question 6 What are the reasons that operations not added during the analysis
workflow,
but
rather
during
the
design
workflow?
Explain.
Answer:
There are two reasons:

First, as explained, as a consequence of the iterative nature of the Unified Process, it

is unwise to add an item to a UML diagram before it is strictly necessary to do so.

Second, the operations to be allocated to the classes are deduced from the
interaction diagrams of the realizations of the use cases. In more detail, the messages
in interaction diagrams are used to deduce the operations of the information system.
However, these interaction diagrams of realizations of use cases are produced after
the class diagram. In other words, first we determine the initial class diagram, and later
the interaction diagrams of the realizations of the use cases. We then use these
interaction diagrams to deduce the operations; only then can we allocate the
operations to the classes.