You are on page 1of 7

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 per-object 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:

You might also like