END TERM EXAMINATION- Sample Paper (1)

FORTH SEMESTER [MCA]

Code: MCA208 Subject: Object-Oriented Analysis and Design

Time: 3 Hours Maximum Marks: 60

Note: Attempt five questions including Q.no. 1 which is compulsory. Select one question
from each unit.

Q1 (a) Attempt any five of the following:- (2 x 5 = 10)

i. Define Negative Test with example.

When tester test the application from negative point of mind than it is known as negative testing.
Testing the application always with invalid input and data is known as negative testing. Negative
testing improves the testing coverage of your application. Using the negative testing approach
allows you to test your applications with any possible input data (both valid and invalid) and can
help you make your application more stable and reliable.

For Example, an application contains a textbox and as per the user's Requirements the textbox
should accept only Strings. By providing input other than String as input data to the textbox & to
check whether its working properly or not means it is Negative Testing.

ii. What is Association Class? Give example.

An association class is used to model an association as a class. Association classes often occur in
many-to-one and many-to-many associations where the association itself has attributes. An
association class is rendered by a dashed line from the association to the class rectangle. Each
link in the association is an object of the association class. An association class is essentially a
class attached to an association; the association itself is modeled as a class.
As an example, consider a many-to-many association between classes Person and Company. The
association could have properties; e.g., salary, job Classification, start Date, etc. In this case, the
association is more correctly modeled as an association class with attributes rather than trying to
fold the attributes into one of the classes in the association.
 iii. Differentiate Message and Signal with example.

An intraprocess stimulus (normal call inside one process) is called as a message. For example, a
c++ message.

An interprocess stimulus is sent between two processes. Such a stimulus is called as signal.
Signal may be synchronous and asynchronous.

A message and a signal are represented by a two separate symbols

A message

A signal

iv. Define Probe in Sequential Diagram with example.

The probe position indicates a position in the use case to be extended. The probe position
indicates a position in the use case to be extended.
 v. Define Homogenization with example.
In parallel design process, several stimuli with the same purpose or meaning are defined by
several designers. These stimuli should be consolidated to obtain as few stimuli as possible.
It is called homogenization.

For Example:

What_is_your_phone_number?
Where_do_you_live?
Get_address
Get_address_and_phone_number

Homogenized into:

Get_address
Get_phone_number

VI. What is a CRC card? How it helps in the development of Object Oriented System?

A CRC cards is an index card that is use to represent the responsibilities of classes and the
interaction between the classes. CRC cards are an informal approach to object oriented
modeling. The cards are created through scenarios, based on the system requirements that model
the behavior of the system. Not part of the UML design process but useful in detecting
responsibilities of objects are CRC cards (developed by Kent Beck and Ward Cunningham).
CRC stands for Class-Responsibility-Collaborator. They look like:

Name Responsibilitie
Collaborator s
s

CRC helps in the development of Object Oriented System because:

They allow the (group) participants to experience firsthand how the system will
work.
They are a useful tool for teaching the object-oriented paradigm.

They can be used as a methodology themselves or as a front end to a more formal

methodology such as Booch, Wirfs-Brock, Jacobson, etc.

(vii). Discuss system development as a part of larger activity.

System development does not take place in isolation. It is part of a larger activity, often aimed at
developing a product in which software is an integrated part. The main characteristics are:

Only person involved in production skilled in duplicating products, assembling and

configuring system and testing.
To minimize the development department with customer contacts.
Product is described as sets of packages of functionality services termed as service
packages.
Service Packages are translated into building blocks.

Q2. Differentiate the following with example: (2.5 x 4 = 10)

(i). Extend vs Include relationship in usecase diagram.

Extend is used when a use case conditionally adds steps to another first class use case. For
example, imagine "Withdraw Cash" is a use case of an ATM machine. "Assess Fee" would
extend Withdraw Cash and describe the conditional "extension point" that is instantiated when
the ATM user doesn't bank at the ATM's owning institution. Notice that the basic "Withdraw
Cash" use case stands on its own, without the extension.

Include is used to extract use case fragments that are duplicated in multiple use cases. The
included use case cannot stand alone and the original use case is not complete without the
included one. This should be used sparingly an only in cases where the duplication is significant
and exists by design (rather than by coincidence).

For example, the flow of events that occurs at the beginning of every ATM use case (when the
user puts in their ATM card, enters their PIN, and is shown the main menu) would be a good
candidate for aninclude.
(ii). Object Oriented Analysis (OOA) and Object Oriented Design (OOD).

Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a
conceptual model of the information that exists in the area being analyzed. Analysis models do
not consider any implementation constraints that might exist, such as concurrency, distribution,
persistence, or how the system is to be built. Implementation constraints are dealt during object-
oriented design (OOD). Analysis is done before the Design. The result of object-oriented analysis
is a description of what the system is functionally required to do, in the form of a conceptual
model.

Object-oriented design (OOD) transforms the conceptual model produced in object-oriented

analysis to take account of the constraints imposed by the chosen architecture and any non-
functional - technological or environmental - constraints, such as transaction throughput,
response time, run-time platform, development environment, or programming language.
The concepts in the analysis model are mapped onto implementation classes and interfaces. The
result is a model of the solution domain, a detailed description of how the system is to be built.

(iii). Sequence Diagram vs. Collaboration Diagram.

Sequence Diagram:
Sequence diagrams describe in detail how actors use use cases, they can also model external
business processes the new system will support (e.g., processing a book order)
An interaction is a behavior that consists of a set of messages exchanged between
external and system objects.
 Interactions consist of one or more messages. Interactions may be synchronous (e.g.,
calling someone on the phone), or asynchronous (e.g., sending someone email).
Sequence diagrams defined during requirements analysis should not include design
objects;
specify message signatures in any detail;

Collaboration diagram:
Collaboration diagrams show interaction without the time dimension, but do include
object links.
Like sequence diagrams, collaboration diagrams are intended to model scenario; each
scenario describes a possible sequence of events and actions.
Sequence diagrams are helpful because they capture visually the sequence of events over
time.
Collaboration diagrams capture more directly the interactions between actors and objects.

(iv). OOSA and OOSD.

Object-Oriented Systems Analysis (OOSA)
Many heuristics for object identification and analysis, which help with initial abstraction and
object modeling.
Data modeling approach (ER modeling)
Models an object relationship network with subclasses. State transition specifications are
constructed for each object and functions are
State-modeled with data-flow diagrams.
Produces a composite activity-data model (synthesis not clearly specified)
Lack of support for inheritance.
Underspecified in the design phase.

Object-Oriented System Design:

Assumes analysis phase has been completed.
Provides detailed notation for object classes and management of inheritance.
Inter-object communications (event/message types).
Detailed notation for interface description and encapsulation.
No analysis advice is given.

UNIT I

Q2(a). Discuss Software Development Process? Also elaborate the software process that is
transforming needs to software product. (6)

Analysis, design, implementation, testing & refinement to transform users need into software
solution that satisfies those needs Object-oriented approach:
 More rigorous process to do things right.

More time spent on gathering requirements, developing requirements model &

analysis model, then turn into Process to change, refine, transform & add to existing
product transformation (analysis) - translates users need into systems requirements
& responsibilities.

How they use system can give insight into requirements, eg: analyzing incentive
payroll - capacity must be included in requirements transformation (design) - begins
with problem statement, ends with detailed design that can be transformed into
operational system.
#
Bulk of development activity, include definition on how to build software, its
development, its testing, design description and testing material transformation 3
(implementation) - refines detailed design into system deployment that will satisfy
users needs.

Account of equipment, procedures, resources, people, etc - how to embed software

product within its operational environment, eg: new compensation method prg needs
new form, gives new report.
Q 2(b). How you will support the Object-Oriented Analysis and Design paradigm over the
structure Oriented Analysis and Design paradigm?
(4)

Structured Object-Oriented
Methodology SDLC Iterative/Incremental
Focus Processes Objects
Risk High Low
Reuse Low High
Maturity Mature and Wide spread Emerging (1997)
Suitable for Well-defined projects with Risky large projects with
stable user requirements changing user requirements
Analysis Structuring Requirements Requirement Engineering
DFD Use case model
Decision Table Object model
ER Analysis
Design DB design Physical DB design
GUI design GUI design

Q3(a). Write a note on different traditionla methods of system development. (6)

Analysis/Structured Design (SASD):

Top-down functional decomposition.
Analyses system in terms of a network of processes connected by data flow
messages.
Functional cohesion and low coupling.
Does not support any OO concepts (separates data and process specification)
More recent versions have added state-transition diagrams and bottom-up
analysis driven by event identification (more potential for OO specifications)

Structured Systems Analysis and Design Method (SSADM):

Composite method derived from structured analysis, structured design and data
analysis.
Process analysis is separated from data analysis functionally related processing
structures.
Most of the views expressed about IE also apply to SSADM.

Structured Analysis and Design Techniques (SADT):

Uses top-down decomposition to analyze systems.

 Specification uses network diagrams of processes connected by data flows, control
messages, and mechanisms.
Encourages modeling of real world problems, but constructs separate activity and
data models.
Does not support type-instance concepts.
Separation of process specification from data makes it unsuitable for an OO approach.

Jackson System Development (JSD):

System models based on networks of concurrent communication processes.

Type-instance concept.
Classification and property inheritance are not supported.
System control is modeled in terms of time-ordering of actions associated with entities.
More recent versions have placed more emphasis on data modeling object model that combines
data and operations.
Much in common with OO methods.
No object classification, instead entity roles.

Q3(b). Discuss and compare OMT and OOSE object oriented methodologies. (4)

OMT [Rumbaugh et al.,1991] consists of

building three complementary models of the system
adding implementation details to the models
implementing the models

OMT includes a set of phases [processes] and diagramming techniques. It has four phases:

Object-oriented analysis builds a real-world model

System design determines overall architecture of system
Object design decides upon data structures and algorithms
Implementation translates design into programming language

OOSE:

Originated from Objectory (Object Factory for software development)

Aim to fit the development of large real-time system
Covers entire life cycle
Stress traceability among the different phases (Backward & forward)
Usecase concept is core

UNIT- II

Q 4(a). What do you mean by requirement model? Discuss it with suitable diagram? (5)
The Requirement Model consist of

A use case model

Interface description
A Problem domain model

The use case model involves the use of actors and use cases. Actors show what interact with a
system. Their actions are non-deterministic. A user is different from an actor. A user is an actual
person who uses the system while an actor represents a certain role that a user can play. A use
case represents the functionality of a system. Each use case is a specific way of using the system.
Every execution of the use case is an instance of the use case. When a user inputs a stimulus, the
use case instance executes and starts a transaction belonging to the use case. The use case
instance exists as long as the use case is operating. A use case class is a description that specifies
the transactions of the use case. The set of all use case description specifies the complete
functionality of the system. A use case is a complete flow of the system which has a state and
behavior. Here the object model should consist of problem domain objects that help in the
development of requirement model.

Q 4(b). What do you mean by system development. Also discuss different models of system
development. (5)

The work that occurs when we develop computer support to aid an organization. System
development is model building. It starts when a requirement of system identified and
Specification can be used for contract and to plan and control the development process. It is a
complex process handle poorly. OOSE can used from start to end of system life cycle. It is b ased
on three technologies:

Object oriented programming

Conceptual modeling
Block design

It consists of five different models:

 The requirement model
Aims to capture the functional requirements
Analysis model
Give the system a robust and changeable object structure
Design model
Adopt and refine the object structure to the current implementation environment
Implementation model
Implement the system
Test model
Verify the system

Seamless transition between the models is important. The method layer define the transformation
rules. For maintainability traceability is very important between the models.

Models are tightly coupled to the architecture, and aim is to find concepts which are simple
to learn and use. It simplify our understanding of the system and provide us with a changeable
model of the system. These models are sufficiently powerful to express the information which is
required to model the system. These models are sufficiently defined that different people can
discuss the system in terms of these concepts without being misunderstood.

Q5 (a). Write a short note on model architecture. (4)

System development includes the development of different models of a software system. It aim is
to find powerful modeling language, notation or modeling technique for each model. It consists
of set of modeling techniques defines architecture upon which the system development method
is based. The architecture of a method is the denotation of its set of modeling techniques
Architecture can be view as the class of models that can be built with a certain modeling notation
Modeling technique is described by means of syntax, semantics and pragmatics:
#
Syntax (How it looks)
Semantics (What it means)
Pragmatics (heuristics or rules of thumb for using modeling technique)

Features of modeling techniques:

 Easy to use
Contain few but powerful modeling objects to enable easy learning
Help to handle complexity of the system
To build these models method are required to show how to work with modeling
techniques
The specific system architecture is formulated in terms of the modeling object used
Specific system architecture is the result obtained after applying a method to a
system.

Q 5(b). What do you mean by analysis model. How requirement model structured in
analysis model. (6)

When a SRS document has been mutually agreed upon by both customer and developer, we start
the actual development process. This starts with an analysis model. The aim of this model is to
structure the system independently of the actual implementation environment. This means that
we focus on the logical structure of the system. It is here that we define the stable robust and
maintainable structure is also extensible.

Although it is possible to use the object model developed in the requirement model as a base for
the actual construction of the system but this does not result in a robust structure. It is, however,
our analysis model that is more stable and maintainable system structure that will be robust for
the entire SDLC.

Changes will come but will affect this logical structuring. We also want minimum changes to this
ideal, logical and stable structure. The analysis model has three dimensions as shown in diagram:

These three dimensions are as:

(a). information (data) on x-axis:

This dimension specifies the information held in the system. Along the x-axis we describe the
system internal state.

(b). behavior (functions) on y-axis:

On this axis, we specify the behavior that this system will adopt. We specify when and how the
system will change state.

(c). presentation (outside world) on z-axis:

This dimension provides the details for presenting the system to the outside world.

The main features of analysis model are:

Requirement model aims to define the limitations of the system and to specify its behavior
Development of actual system starts with analysis model
Focus on the logical structure
Define the stable, robust and maintainable structure that is also extensible
Creating analysis model corresponding to assigning functionality of use cases to objects

The object models are:

Entity object: Information about an entity object is stored even after

a use case is completed.
Control object: A control object illustrates functionality that is not contained in any
other object in the system
Interface object: Interface objects interact directly with the environment

UNIT- III

Q6(a). Define the term Design. Also discuss the objectives of design and elaborate why
design is so difficult. (6)

It is specification about what, and Design is the start of the how inputs to the design process. The
main specification document, including models etc. and the outputs of the design process
consists of a design document that describes how the code will be written. Includes design
models.

Design goals:

Correctness: It Should Lead To A Correct Implementation

#
Completeness: It Should Do Everything. Everything? It should follow the
specifications.
 Changeable: It Should Facilitate ChangeChange Is Inevitable.

Efficiency: It Should Not Waste Resources. But better a working slow design than a
fast design that does not work.

Simplicity: It Should Be As Understandable As Possible.

Why design is so difficult:

Because here analysis focuses on the application domain. Design focuses on the solution domain.
Design knowledge is a moving target and the reasons for design decisions are changing very
rapidly. It consists of halftime knowledge in software engineering and cost of hardware rapidly
sinking.

Q6(b). Elaborate the term Traceability. (4)

It refines the analysis model in light of actual implementation environment. The explicit
definition of interfaces of objects, semantics of operation. Additionally, different issues like
DBMS, programming language etc. can be considered. The model is composed of BLOCKS
which are the design objects. One block is implemented as one class. The blocks abstract the
actual implementation. Traceability is extremely important aspect of the system. Changes made
will be only local to a module. It provides high functional localization (high cohesion).

Q7(a). What the reasons for having construction phase in object oriented software
engineering? Explain the procedure of converting analysis model into construction model.

(5)
Construction Phase: All about BUILDING the system from model of analysis & requirement
phase. It consists of Design and Implementation.
Implementation: It start from elaboration & continues to construction. The main reason of why
construction consists of transition to source code; analysis model not sufficient. The actual
system must be adapted to the implementation environment. It must explore into more
dimensions.

Analysis to Design Model:

Artifacts of Construction:

Q 7(b). What do you mean by object oriented testing. Also discuss object oriented testing.
(5)

According to Hetzel, software testing is any activity aimed at evaluating an attribute or capability
of a program or system and determining that it meets its required result. However, testing still
remains an art as we have limited understanding of testing principles. In object oriented systems,
class is the smallest unit for testing. Object oriented test cases will concentrate on the state of a
class. We can do both white box and box testing here.

Object oriented concept includes:

Verification
 Validation
Debugging
Certification
Clean Room Software Engineering
Error
Testing Techniques
Regression Test
Testing Focuses
Operation test
Full-scale test
Stress test
Overload test
Fault
Failure
Testing Level
Unit testing
Integration Testing
System Testing
Negative test
Test based on requirements
Ergonomic tests
Testing of the user documentation
Acceptance testing

Stubs
Drivers
Test bed
Equivalence set
Equivalence partitioning

UNIT-IV

Q8(a). Consider the Order System of an application. It has the following conditions: (7)

First of all Order and Customer are identified as the two elements of the system and
they have a one to many relationship because a customer can have multiple orders.

We would keep Order class is an abstract class and it has two concrete classes
(inheritance relationship) SpecialOrder and NormalOrder.

The two inherited classes have all the properties as the Order class. In addition they
have additional functions like dispatch () and receive ().
So draw the class diagram based on the above mentioned case.

Q 8(b). Give different reasons where to use class diagrams. (3)

Class diagram is a static diagram and it is used to model static view of a system. The static view
describes the vocabulary of the system.

Class diagram is also considered as the foundation for component and deployment diagrams.
Class diagrams are not only used to visualize the static view of the system but they are also used
to construct the executable code for forward and reverse engineering of any system.

Generally UML diagrams are not directly mapped with any object oriented programming
languages but the class diagram is an exception.

Class diagram clearly shows the mapping with object oriented languages like Java, C++ etc. So
from practical experience class diagram is generally used for construction purpose.

So in a brief, class diagrams are used for:

 Describing the static view of the system.

Showing the collaboration among the elements of the static view.

Describing the functionalities performed by the system.

Construction of software applications using object oriented languages.

Q 9(a). What do you mean by building blocks of UML? Also discuss different building
blocks in detail. (7)

UML describes the real time systems it is very important to make a conceptual model and then
proceed gradually. Conceptual model of UML can be mastered by learning the following three
major elements:

UML building blocks

Rules to connect the building blocks

Common mechanisms of UML

The building blocks of UML can be defined as:

Things

Relationships

Diagrams

(1) Things:

Things are the most important building blocks of UML. Things can be:

Structural

Behavioral

Grouping

Annotational

Structural things:
The Structural things define the static part of the model. They represent physical and
conceptual elements. Following are the brief descriptions of the structural things.

Class:

Class represents set of objects having similar responsibilities.

Interface:

Interface defines a set of operations which specify the responsibility of a class.

Collaboration:

Collaboration defines interaction between elements.

Use case:

Use case represents a set of actions performed by a system for a specific goal.

Component:

Component describes physical part of a system.

Node:

A node can be defined as a physical element that exists at run time.

Behavioral things:

A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral
things:

Interaction:

Interaction is defined as a behavior that consists of a group of messages exchanged among

elements to accomplish a specific task.

State machine:

State machine is useful when the state of an object in its life cycle is important. It defines the
sequence of states an object goes through in response to events. Events are external factors
responsible for state change.

Grouping things:

Grouping things can be defined as a mechanism to group elements of a UML model together.
There is only one grouping thing available:

Package:

Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things:
Annotational things can be defined as a mechanism to capture remarks, descriptions, and
comments of UML model elements. Note is the only one Annotational thing available.

Note:

A note is used to render comments, constraints etc of an UML element.

(2) Relationship :

Relationship is another most important building block of UML. It shows how elements are
associated with each other and this association describes the functionality of an application.

There are four kinds of relationships available.

Dependency:

Dependency is a relationship between two things in which change in one element also affects the
other one.

Association:

Association is basically a set of links that connects elements of an UML model. It also describes
how many objects are taking part in that relationship.

Generalization:

Generalization can be defined as a relationship which connects a specialized element with a

generalized element. It basically describes inheritance relationship in the world of objects.

Realization:
Realization can be defined as a relationship in which two elements are connected. One element
describes some responsibility which is not implemented and the other one implements them. This
relationship exists in case of interfaces.

(3) UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are
used to make a complete UML diagram and the diagram represents a system.

The visual effect of the UML diagram is the most important part of the entire process. All the
other elements are used to make it a complete one.

UML includes the following nine diagrams:

1. Class diagram

2. Object diagram

3. Use case diagram

4. Sequence diagram

5. Collaboration diagram

6. Activity diagram

7. Statechart diagram

8. Deployment diagram

9. Component diagram

Q 9(b). Write a short note on UML modeling techniques. (3)

Structural modeling:

Structural modeling captures the static features of a system. They consist of the followings:

Classes diagrams

Objects diagrams
 Deployment diagrams

Package diagrams

Composite structure diagram

Component diagram

Structural model represents the framework for the system and this framework is the place where
all other components exist. So the class diagram, component diagram and deployment diagrams
are the part of structural modeling. They all represent the elements and the mechanism to
assemble them.

Behavioral Modeling:

Behavioral model describes the interaction in the system. It represents the interaction among the
structural diagrams. Behavioral modeling shows the dynamic nature of the system. They consist
of the following:

Activity diagrams

Interaction diagrams

Use case diagrams

Architectural Modeling:

Architectural model represents the overall framework of the system. It contains both structural
and behavioral elements of the system. Architectural model can be defined as the blue print of
the entire system. Package diagram comes under architectural modeling.