0% found this document useful (0 votes)

319 views

Object Oriented Programming - CS8392 PDF

This document provides information about the Object Oriented Analysis and Design course for the third semester at Anna University. It includes the course code, regulations, units of study, outcomes, and table of contents. The five units cover UML diagrams, design patterns, a case study on requirements analysis, applying design patterns, and mapping design to code and testing. Specific topics include the unified process, various UML diagrams, design patterns like factory method and strategy, domain modeling, logical architecture, and testing techniques. The document aims to guide students in learning OO analysis and design skills and applying principles and patterns to create better object designs.

Uploaded by

Varman

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

319 views

Object Oriented Programming - CS8392 PDF

Uploaded by

Varman

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 215

Visit & Downloaded from : www.LearnEngineering.

ENGINEERING COLLEGES
2017 – 18 Odd Semester
IMPORTANT QUESTIONS & ANSWERS
Department of Computer Science and Engineering
& Information Technology
SUBJECT CODE: CS6502

SUBJECT NAME: Object Oriented Analysis and Design

Regulation: 2013 Semester and Year: 05 & III

Visit & Downloaded from : www.LearnEngineering.in

Anna University,Regulation 2013

CS6502 OBJECT ORIENTED ANALYSIS AND DESIGN L T P C 3 0 0 3
UNIT I UML DIAGRAMS 9
Introduction to OOAD – Unified Process - UML diagrams – Use Case – Class Diagrams–
Interaction Diagrams – State Diagrams – Activity Diagrams – Package, component and
Deployment Diagrams.
UNIT II DESIGN PATTERNS 9
GRASP: Designing objects with responsibilities – Creator – Information expert – Low
Coupling – High Cohesion – Controller - Design Patterns – creational - factory method -
structural – Bridge – Adapter -behavioral – Strategy – observer
UNIT III CASE STUDY 9
Case study – the Next Gen POS system, Inception -Use case Modeling - Relating Use
cases – include, extend and generalization - Elaboration - Domain Models - Finding
conceptual classes and description classes – Associations – Attributes – Domain model
refinement – Finding conceptual class Hierarchies - Aggregation and Composition
UNIT IV APPLYING DESIGN PATTERNS 9
System sequence diagrams - Relationship between sequence diagrams and use cases
Logical architecture and UML package diagram – Logical architecture refinement - UML
class diagrams - UML interaction diagrams - Applying GoF design patterns
UNIT V CODING AND TESTING 9
Mapping design to code – Testing: Issues in OO Testing – Class Testing – OO
Integration Testing – GUI Testing – OO System Testing. TOTAL: 45 PERIODS
OUTCOMES: At the end of the course, the student should be able to:
Design and implement projects using OO concepts
Use the UML analysis and design diagrams
Apply appropriate design patterns
Create code from design
Compare and contrast various testing techniques

Visit & Downloaded from : www.LearnEngineering.in

TABLE OF CONTENTS
S. PAGE
TOPIC
NO NO
a Aim and Objective of the subject 1
b Detailed Lesson Plan 2
c Part A UNIT I 5
d Part B UNIT I 10
1. Unified Process 10
2. Use Case Modeling 15
3. UML State Machine Diagram & Modeling 17
4. UML Activity Diagram 21
5. UML Deployment and Component Diagram 25
e Part A UNIT II 30
f Part B UNIT II 35
6. GRASP Design patterns 35
7. Information Expert, Low Coupling High Cohesion, Controller 39
8. Creational Design patterns 52
9. Structural Design patterns 59
10. Behavioral Design Patterns 63
g Part A UNIT III 66
h Part B UNIT III 70
11. NextGen POS 70
12. Inception & Elaboration Phase 73
13. Include, Extend & Generalization Relationship 77
14. Strategies used to identify Conceptual Classes 82
15. Domain Model Refinement 91
i Part A UNIT IV 95
j Part B UNIT IV 100

Visit & Downloaded from : www.LearnEngineering.in

S. PAGE
TOPIC
NO NO
16. Relationship Between Sequence Diagram & Use Cases 100
17. UML Notations for Class Diagram 104
18. Interaction Diagrams 112
19. Logical Architecture & UML Package Diagram 122
20. Logical Architecture Refinement 125
k Part A UNIT V 130
l Part B UNIT V 134
21. Mapping Design to Code 134
22. OO Testing 137
23. OO Integration Testing 140
24. OO System testing 145
25. GUI Testing 148
26. Class Testing 154
m Industrial Connectivity and Latest Developments 160
n Anna University Previous Years Question Papers 161

Visit & Downloaded from : www.LearnEngineering.in

AIM AND OBJECTIVE OF THE SUBJECT

 Apply Principles and Patterns to create better object designs

 Learn the basics of OO analysis and design skills
 Learn the UML design diagrams
 Learn to map design to code
 Be exposed to the various testing techniques.

Visit & Downloaded from : www.LearnEngineering.in

DETAILED LESSON PLAN

TEXT BOOK:
1. Craig Larman, "Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development‖, Third Edition, Pearson
Education, 2005.
REFERENCES:
1. Simon Bennett, Steve Mc Robb and Ray Farmer, ―Object Oriented Systems
Analysis and Design Using UML‖, Fourth Edition, Mc-Graw Hill Education,
2010.
2. Erich Gamma, and Richard Helm, Ralph Johnson, John Vlissides, ―Design
patterns: Elements of Reusable Object-Oriented Software‖, Addison-Wesley,
1995.
3. Martin Fowler, ―UML Distilled: A Brief Guide to the Standard Object Modeling
Language‖, Third edition, Addison Wesley, 2003.
4. Paul C. Jorgensen, ―Software Testing:- A Craftsman‟s Approach‖, Third Edition,
Auerbach Publications, Taylor and Francis Group, 2008.

Hours
Sl. Cumulativ Books
Unit Topic / Portions to be Covered Required
No e Hrs Referred
/ Planned
UNIT I – UML DIAGRAMS
1 I Introduction to OOAD 1 1 T
2 I Unified Process 1 2 T
3 I UML diagrams 1 3 T, PPT
4 I Use Case Diagrams 1 4 T
5 I Class Diagrams 1 5 T
T, NPTEL
6 I Interaction Diagrams 1 6
Video
7 I State Diagrams and Activity Diagrams 1 7 T

Visit & Downloaded from : www.LearnEngineering.in

Hours
Sl. Cumulativ Books
Unit Topic / Portions to be Covered Required
No e Hrs Referred
/ Planned
8 I Package Diagrams 1 8 T
9 I Component and Deployment Diagrams 1 9 T
UNIT II – DESIGN PATTERNS
GRASP: Designing objects with
10 II 2 11 T, PPT
responsibilities
11 II Creator, Information expert 1 12 T
T, NPTEL
12 II Low Coupling, High Cohesion 1 13
Video
13 II Controller, Design Patterns 1 14 T
14 II Creational, factory method 1 15 T
15 II Structural, Bridge, Adapter 1 16 T
16 II Behavioural, Strategy, observer 2 18 T
UNIT III – CASE STUDY
17 III Case study: the Next Gen POS system 1 19 T
T, NPTEL
18 III Inception -Use case Modelling 1 20
Video
Relating Use cases, include, extend and
19 III 1 21 T
generalization
20 III Elaboration - Domain Models 1 24 T, PPT
Finding conceptual classes and description
21 III 1 25 T
classes
22 III Associations, Attributes 1 26 T
23 III Domain model refinement 1 25 T
24 III Finding conceptual class Hierarchies 1 26 T
25 III Aggregation and Composition 1 27 T
UNIT IV – APPLYING DESIGN PATTERNS

Visit & Downloaded from : www.LearnEngineering.in

Hours
Sl. Cumulativ Books
Unit Topic / Portions to be Covered Required
No e Hrs Referred
/ Planned
26 IV System sequence diagrams 1 28 T
Relationship between sequence diagrams and
27 IV use cases, Logical architecture and UML 2 30 T
package diagram
28 IV Logical architecture refinement 2 32 T
T, PPT,
29 IV UML class diagrams 1 33 NPTEL
Video
30 IV UML interaction diagrams 1 34 T
31 IV Applying GoF design patterns 2 36 T
UNIT V – CODING AND TESTING
32 V Mapping design to code 2 38 T
33 V Testing: Issues in OO Testing 1 39 R4
34 V Class Testing 1 40 R4, PPT
R4, NPTEL
35 V OO Integration Testing 2 42
Video
36 V GUI Testing 1 43 R4
37 V OO System Testing 2 45 R4

Visit & Downloaded from : www.LearnEngineering.in

UNIT I - UML DIAGRAMS

Introduction to OOAD – Unified Process - UML diagrams – Use Case – Class

Diagrams– Interaction Diagrams – State Diagrams – Activity Diagrams –
Package, component and Deployment Diagrams

PART – A

1. What is OOAD? [April/May 2011, Nov/Dec 2013, May/June 2014, Nov/Dec 2014,
Apr/May 2015, Nov/Dec 2015]

The essence of object oriented analysis and design is to consider a problem domain
and logical solution from the prescriptive of object.

2. Define agile modeling. (or) What is the need for Modeling? [May/June 2014]

Agile development methods usually apply iterative and evolutionary development

and employ
 Adaptive planning
 Promote incremental delivery
 Other values and practices which encourages agility

3. Can you list the phases of unified process?

 Inception.
 Elaboration.
 Construction.
 Transition

Visit & Downloaded from : www.LearnEngineering.in

4. What is Elaboration? [May/June 2012, May/June 2014, Nov/Dec 2014,

May/June 2016]

The primary goals of Elaboration are to address known risk factors and to
establish and validate the system architecture. Common processes undertaken in this
phase include the creation of use case diagrams, conceptual diagrams (class diagrams
with only basic notation) and package diagrams (architectural diagrams).

5. What is UML? [May/June 2012, Nov/Dec 2014]

Unified modeling language is a visual language used for specifying, constructing

and documenting a system. It is a standard diagrammatic notation used for drawing,
presenting pictures related to software engineering.

6. What are the three ways and perspectives to apply UML? [April/May 2013]

 UML as sketch
 UML as blueprint
 UML as programming language

7. What are the three perspectives to apply UML? [April/May 2013]

 Conceptual perspective – The diagrams are interpreted as described things in a

situation of real world or domain of interest.
 Specification perspective - The diagrams describe software abstractions or
components with specifications and interfaces, but no commitment to a particular
implementation.

Visit & Downloaded from : www.LearnEngineering.in

 Implementation perspective – The diagrams describe software implementation in

a particular technology.
8. Define use case. Mention its formats. [Nov/Dec 2013, April/May 2015]

Use cases are text stories widely used to discover and record requirements. Use
cases are not diagrams; they are text stories of some actor using a system to meet
goals.
 Brief
 Casual
 Fully dressed
9. What is the use of component diagram? [May/June 2012, Nov/Dec 2014,
April/May 2015]
The Component Diagram helps to model the physical aspect of an Object-
Oriented software system. It illustrates the architectures of the software components
and the dependencies between them.
10. Give the meaning of event, state and transition. [April/May 2011 May/June
2012, Nov/Dec 2013, Nov/Dec 2015]
 An event is a significant or noteworthy occurrence. It is a label associated with a
transition that identifies the message which causes a state change.
 A state is the condition of an object at a moment in time—the time between events.
 A transition is a relationship between two states that indicates that when an event
occurs, the object moves from the prior state to the subsequent state.
11. What is the basic element of deployment diagram? Mention its types.

A deployment diagram shows the assignment of concrete software artifacts to

computational nodes. It shows the deployment of software elements to the physical
architecture and the communication between physical elements.
The basic element of deployment diagram is node.

Visit & Downloaded from : www.LearnEngineering.in

 Device node – A physical computing resource with processing and memory

services to execute software.
 Execution Environment Node (EEN) – This is a software computing resource
that runs within an outer node and which itself provides a service to host and
executes other executable software element.

12. How do you represent a node in deployment diagram? What kind of information
can appear in a node? [Nov/Dec 2013]

The basic element of a deployment diagram is a node, of two types.

a. Device Node: A Physical computing resource with processing and memory
services to execute software such as a typical computer or mobile phone.
b. Execution Environment Node (EEN) : This is a software computing resource
that runs within an outer node and which itself provides a service to host and
execute other executable software elements.

<<device>>
DB Server
<<artifact>>
MySQL Server

13. Give the use of UML State Diagram. [May/June 2016]

 It illustrates the interesting events and states of an object, and the behavior of an
object in reaction to an event.
 Transitions are shown by arrows, labeled with their event.
 It shows the life cycle of the object: What events its experiences, its transitions,
and the states it is in between these events.

14. Why do we need Object Oriented System development? [May/June 2016]

Visit & Downloaded from : www.LearnEngineering.in

 Systems Development refers to all activities that go into producing an information

systems solution. These activities consist of systems analysis, modeling, design,
implementation, testing and maintenance.
 Object oriented systems development is a way to develop software by building self
– contained modules or objects that can be easily replaced, modified and reused.

15. Distinguish between Method and Message in Object. [Nov/Dec 2015]

Method Message

1. Provides response to a message. It 1. Objects communicate by sending messages

is an implementation of an to each other. A message is sent to invoke
operation. a method.
2. A method is a block of code 2. A message is any packet of communication
attached to an object by some between objects. The objects may be in the
means. It may be implicitly same program, or they may be on
attached by means of a class different systems. It simply doesn't matter.

Visit & Downloaded from : www.LearnEngineering.in

PART – B

1. UNIFIED PROCESS

 Explain in detail about/unified process in Object Oriented Analysis and

Design? Explain the phases with neat diagrams. [May/June 2016]

 Briefly explain the different phases of Unified Process. [April/May 2011]

 What do you mean by Unified Process in OOAD? Explain the phases with
suitable diagrams. [Nov/Dec 2011]

 Explain the different phases of Unified Process. [May June 2012, Nov/Dec
2013, Nov/Dec 2014, Nov/Dec 2015]

The Unified Software Development Process or Unified Process is a popular

iterative and incremental software development process framework. The best-known and
extensively documented refinement of the Unified Process is the Rational Unified
Process (RUP). Other examples are OpenUP and Agile Unified Process.

Unified Process Characteristics

Iterative and Incremental

The Unified Process is an iterative and incremental development process. The

Elaboration, Construction and Transition phases are divided into a series of timeboxed
iterations. (The Inception phase may also be divided into iterations for a large project.)
Each iteration results in an increment, which is a release of the system that contains

Visit & Downloaded from : www.LearnEngineering.in

added or improved functionality compared with the previous release.

Although most iterations will include work in most of the process disciplines (e.g.
Requirements, Design, Implementation, Testing) the relative effort and emphasis will
change over the course of the project.

Architecture Centric

The Unified Process insists that architecture sit at the heart of the project team's
efforts to shape the system. Since no single model is sufficient to cover all aspects of a
system, the Unified Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable

architecture baseline which is created during the Elaboration phase. This partial
implementation of the system serves to validate the architecture and act as a foundation
for remaining development.

Risk Focused

The Unified Process requires the project team to focus on addressing the most
critical risks early in the project life cycle. The deliverables of each iteration, especially
in the Elaboration phase, must be selected in order to ensure that the greatest risks are
addressed first.

Project Lifecycle (Phases of Unified Process)

The Unified Process divides the project into four phases:

 Inception
 Elaboration
 Construction
 Transition

Visit & Downloaded from : www.LearnEngineering.in

Figure 1.1 Unified Process Phases

Inception Phase

Inception is the smallest phase in the project, and ideally it should be quite short. If
the Inception Phase is long then it may be an indication of excessive up-front
specification, which is contrary to the spirit of the Unified Process.

The following are typical goals for the Inception phase.

 Establish a justification or business case for the project

 Establish the project scope and boundary conditions
 Outline the use cases and key requirements that will drive the design tradeoffs
 Outline one or more candidate architectures
 Identify risks
 Prepare a preliminary project schedule and cost estimate

The Lifecycle Objective Milestone marks the end of the Inception phase. Develop an
approximate vision of the system, make the business case, define the scope, and produce
rough estimate for cost and schedule.

Elaboration Phase

During the Elaboration phase the project team is expected to capture a healthy
majority of the system requirements. However, the primary goals of Elaboration are to
address known risk factors and to establish and validate the system architecture. Common

Visit & Downloaded from : www.LearnEngineering.in

processes undertaken in this phase include the creation of use case diagrams, conceptual
diagrams (class diagrams with only basic notation) and package diagrams (architectural
diagrams).

The architecture is validated primarily through the implementation of an

Executable Architecture Baseline. This is a partial implementation of the system which
includes the core, most architecturally significant, components. It is built in a series of
small, time boxed iterations. By the end of the Elaboration phase the system architecture
must have stabilized and the executable architecture baseline must demonstrate that the
architecture will support the key system functionality and exhibit the right behaviour in
terms of performance, scalability and cost.

The final Elaboration phase deliverable is a plan (including cost and schedule
estimates) for the Construction phase. At this point the plan should be accurate and
credible, since it should be based on the Elaboration phase experience and since
significant risk factors should have been addressed during the Elaboration phase.

Construction Phase

Construction is the largest phase in the project. In this phase the remainder of the
system is built on the foundation laid in Elaboration. System features are implemented in
a series of short, timeboxed iterations. Each iteration results in an executable release of
the software. It is customary to write full text use cases during the construction phase and
each one becomes the start of a new iteration. Common UML (Unified Modeling
Language) diagrams used during this phase include Activity, Sequence, Collaboration,
State (Transition) and Interaction.

Transition Phase

The final project phase is Transition. In this phase the system is deployed to the
target users. Feedback received from an initial release (or initial releases) may result in

Visit & Downloaded from : www.LearnEngineering.in

further refinements to be incorporated over the course of several Transition phase

iterations. The Transition phase also includes system conversions and user training.

Summary of the Four Phases of Unified Process

The Unified Process consists of cycles that may repeat over the long-term life of
a system. A cycle consists of four phases: Inception, Elaboration, Construction and
Transition. Each cycle is concluded with a release, there are also releases within a cycle.
Let's briefly review the four phases in a cycle:

Inception Phase - During the inception phase the core idea is developed into a product
vision. In this phase, we review and confirm our understanding of the core business
drivers. We want to understand the business case for why the project should be
attempted. The inception phase establishes the product feasibility and delimits the project
scope.

Elaboration Phase - During the elaboration phase the majority of the Use Cases are
specified in detail and the system architecture is designed. This phase focuses on t he
"Do- Ability" of the project. We identify significant risks and prepare a schedule, staff
and cost profile for the entire project.

Construction Phase - During the construction phase the product is moved from the
architectural baseline to a system complete enough to transition to the user community.
The architectural baseline grows to become the completed system as the design is refined
into code.

Transition Phase - In the transition phase the goal is to ensure that the requirements
have been met to the satisfaction of the stakeholders. This phase is often initiated with a
beta release of the application. Other activities include site preparation, manual

Visit & Downloaded from : www.LearnEngineering.in

completion, and defect identification and correction. The transition phase ends with a
postmortem devoted to learning and recording lessons for future cycles.

2. USECASE MODELLING

 Explain with an example, how use case modeling is used to describe

functional requirements. Identify the actors, scenario and use cases for the
example. [April/May 2011, May/June 2012, April/May 2013, Nov/Dec 2013,
May/June 2014, May/June 2016]

 Describe the basic activities in object oriented analysis and explain how use
case modeling is useful in analysis. [Nov/Dec 2014]

 Explain about Use-case Model for a case study of your choice. [Nov/Dec 2015]

The Use Case Model describes the proposed functionality of the new system. A
Use Case represents a discrete unit of interaction between a user (human or machine) and
the system. A Use Case is a single unit of meaningful work; for example login to system,
register with system and create order are all Use Cases. Each Use Case has a description
which describes the functionality that will be built in the proposed system. A Use Case
may 'include' another Use Case's functionality or 'extend' another Use Case with its own
behavior.
Use Cases are typically related to 'actors'. An actor is a human or machine entity
that interacts with the system to perform meaningful work.
A Use Case description will generally include:
1. General comments and notes describing the use case;
2. Requirements - Things that the use case must allow the user to do, such as <ability to
update order>, <ability to modify order> & etc.

Visit & Downloaded from : www.LearnEngineering.in

3. Constraints- Rules about what can and can't be done. Includes i) pre-conditions that
must be true before the use case is run -e.g. <create order> must precede <modify
order>; ii) post-conditions that must be true once the use case is run e.g. <order is
modified and consistent>; iii) invariants: these are always true - e.g. an order
4. Scenarios - Sequential descriptions of the steps taken to carry out the use case. May
include multiple scenarios, to cater for exceptional circumstances and alternate
processing paths;
5. Scenario diagrams -Sequence diagrams to depict the workflow - similar to (4) but
graphically
6. Additional attributes such as implementation phase, version number, complexity
rating.

Actors
An Actor is a user of the system. This includes both human users and other
computer systems. An Actor uses a Use Case to perform some piece of work which is of
value to the business. The set of Use Cases an actor has access to define their overall
role in the system and the scope of their action.

Constraints, Requirements and Scenarios

The formal specification of a Use Case includes:

1. Requirements. These are the formal functional requirements that a Use Case must
provide to the end user. They correspond to the functional specifications found in
structured methodologies. A requirement is a contract that the Use Case will perform
some action or provide some value to the system.

Visit & Downloaded from : www.LearnEngineering.in

Figure 1.2 Use Case Modeling

1. Constraints. These are the formal rules and limitations that a Use Case operates
under, and includes pre- post- and invariant conditions. A pre-condition specifies
what must have already occurred or be in place before the Use Case may start. A
post-condition documents what will be true once the Use Case is complete. An
invariant specifies what will be true throughout the time the Use Case operates
2. Scenarios. Scenarios are formal descriptions of the flow of events that occurs during
a Use Case instance. These are usually described in text and correspond to a textual
representation of the Sequence Diagram.

3. UML STATE MACHINE DIAGRAM

 Explain UML state machine diagram and modeling.

[Nov/Dec 2011, Nov/Dec 2013, May/June 2014, May/June 2016]
17

Visit & Downloaded from : www.LearnEngineering.in

The state diagram in the Unified Modelling Language is essentially a Harel state
chart with standardized notation which can describe many systems, from computer
programs to business processes. In UML 2 the name has been changed to State Machine
Diagram. The following are the basic notational elements that can be used to make up a
diagram:

 Filled circle, representing to the initial state

 Hollow circle containing a smaller filled circle, indicating the final state (if any)
 Rounded rectangle, denoting a state. Top of the rectangle contains a name of the
state. Can contain a horizontal line in the middle, below which the activities that
are done in that state are indicated

Figure 1.3 State Machine Diagram of a Telephone

 Arrow, denoting transition. The name of the event (if any) causing this transition
labels the arrow body. A guard expression may be added before a "/" and enclosed
in square-brackets (eventName[guardExpression] ), denoting that this expression
must be true for the transition to take place. If an action is performed during this
transition, it is added to the label following a "/"

Visit & Downloaded from : www.LearnEngineering.in

(eventName[guardExpression]/action ).

 Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line
entering and x>1 lines leaving. These denote join/fork, respectively.

Figure 1.4 State Machine Diagram for ATM Transaction

Transition Actions and Guards:

A transition can cause an action to fire. In a software implementation this may

represent the invocation of a method of the class of the state machine diagram.

Visit & Downloaded from : www.LearnEngineering.in

Figure 1.5 Transition Action and Guard Notation

Nested States :
A state allows nesting to contain substates; a substate inherits the transitions of its
superstate (the enclosing state).

Figure 1.6 Nested States

Visit & Downloaded from : www.LearnEngineering.in

Figure 1.7 State Machine Diagram for Process Sales

4.UML ACTIVITY DIAGRAM

 Illustrate UML activity diagram with an example. [April/May 2011, Nov/Dec

2011, , April/May 2013, Nov/ Dec 2013, May/June 2014, Nov/Dec 2014,
Nov/Dec 2015, May/June 2016]

 When to use Activity diagrams? Describe the situations with an example

[May/June 2012]

Activity diagrams are graphical representations of workflows of stepwise

activities and actions with support for choice, iteration and concurrency. In the Unified
Modeling Language, activity diagrams are intended to model both computational and
organizational processes (i.e. workflows). Activity diagrams show the overall flow of
control.

Activity diagrams are constructed from a limited number of shapes, connected with

Visit & Downloaded from : www.LearnEngineering.in

arrows. The most important shape types:

 rounded rectangles represent actions;

 diamonds represent decisions;
 bars represent the start (split) or end (join) of concurrent activities;
 a black circle represents the start (initial state) of the workflow;
 an encircled black circle represents the end (final state).

Arrows run from the start towards the end and represent the order in which activities
happen. Activity diagrams may be regarded as a form of flowchart. However, the join and
split symbols in activity diagrams only resolve this for simple cases; the meaning of the
model is not clear when they are arbitrarily combined with decisions or loops.

While in UML 1.x, activity diagrams were a specialized form of state diagrams, in
UML 2.x, the activity diagrams were renormalized to be based on Petri net-like
semantics, increasing the scope of situations that can be modelled using activity
diagrams. These changes cause many UML 1.x activity diagrams to be interpreted
differently in UML 2.x.

UML activity diagrams in version 2.x can be used in various domains, i.e. in design
of embedded systems. It is possible to verify such a specification using model checking
technique.

Rake Symbol:
To show an activity expanded in another activity diagram.

Visit & Downloaded from : www.LearnEngineering.in

Figure 1.8 UML Activity Diagram for a Sales Order

Visit & Downloaded from : www.LearnEngineering.in

Figure 1.9 UML Activity Diagram for ATM Withdrawal Transaction

Figure 1.10 An activity expanded in another diagram

Visit & Downloaded from : www.LearnEngineering.in

Figure 1.11 Expansion of an activity

Signals:

Signals are needed to model events such as time triggering an action or an

cancellation request.

Figure 1.12 Signals

Visit & Downloaded from : www.LearnEngineering.in

5.UML DEPLOYMENT & COMPONENT DIAGRAMS

 Discuss about UML deployment and component diagrams.

[April/May 2011, May/June 2012, April/May 2013, Nov/
Dec 2014, Nov/Dec 2015, May/June 2016]
Deployment Diagram

A deployment diagram in the Unified Modeling Language models the physical

deployment of artifacts on nodes. To describe a web site, for example, a deployment
diagram would show what hardware components ("nodes") exist (e.g., a web server, an
application server, and a database server), what software components ("artifacts") run on
each node (e.g., web application, database), and how the different pieces are connected
(e.g. JDBC, REST, RMI).

Figure 1.13 Deployment Diagram

The nodes appear as boxes, and the artifacts allocated to each node appear as
rectangles within the boxes. Nodes may have subnodes, which appear as nested boxes. A
single node in a deployment diagram may conceptually represent multiple physical

Visit & Downloaded from : www.LearnEngineering.in

nodes, such as a cluster of database servers.

There are two types of Nodes:

 Device Node
 Execution Environment Node

Device nodes are physical computing resources with processing memory and
services to execute software, such as typical computers or mobile phones. An execution
environment node (EEN) is a software computing resource that runs within an outer node
and which itself provides a service to host and execute other executable software
elements.

Component Diagram

In the Unified Modeling Language, a component diagram depicts how

components are wired together to form larger components and or software systems. They
are used to illustrate the structure of arbitrarily complex systems.
A component is something required to execute a stereotype function. Examples of
stereotypes in components include executables, documents, database tables, files, and
library files. Components are wired together by using an assembly connector to connect
the required interface of one component with the provided interface of another
component. This illustrates the service consumer - service provider relationship between
the two components.

An assembly connector is a "connector between two components that defines that

one component provides the services that another component requires. An assembly
connector is a connector that is defined from a required interface or port to a provided
interface or port."
When using a component diagram to show the internal structure of a component, the
provided and required interfaces of the encompassing component can delegate to the
corresponding interfaces of the contained components.

Visit & Downloaded from : www.LearnEngineering.in

A delegation connector is a "connector that links the external contract of a

component (as specified by its ports) to the internal realization of that behavior by the
component‘s parts." The example above illustrates what a typical Insurance policy
administration system might look like. Each of the components depicted in the above
diagram may have other component diagrams illustrating its internal structure.

Symbols
A component is something required to execute a stereotype function. Examples of
stereotypes in components include executables, documents, database tables, files, and
library files. Components are wired together by using an assembly connector to connect
the required interface of one component with the provided interface of another
component. This illustrates the service consumer - service provider relationship between
the two components.

An assembly connector is a "connector between two components that defines that

one component provides the services that another component requires. An assembly
connector is a connector that is defined from a required interface or port to a provided
interface or port."

When using a component diagram to show the internal structure of a component,

the provided and required interfaces of the encompassing component can delegate to the
corresponding interfaces of the contained components.

A delegation connector is a "connector that links the external contract of a

component (as specified by its ports) to the internal realization of that behavior by the
component‘s parts."
The example above illustrates what a typical Insurance policy administration system
might look like. Each of the components depicted in the above diagram may have other
component diagrams illustrating its internal structure.

Visit & Downloaded from : www.LearnEngineering.in

Figure 1.14 UML Components

Figure 1.15 UML Components Insurance Policy Administration System

Visit & Downloaded from : www.LearnEngineering.in

PART - C

Draw the Use case diagram, class diagram, activity diagram, sequence diagram and
collaboration diagram for online examination system.

Use case diagram:

Visit & Downloaded from : www.LearnEngineering.in

Class Diagram:

Visit & Downloaded from : www.LearnEngineering.in

Activity Diagram:

Visit & Downloaded from : www.LearnEngineering.in

Sequence Diagram:

Visit & Downloaded from : www.LearnEngineering.in

Collaboration Diagram:

Visit & Downloaded from : www.LearnEngineering.in

UNIT II - DESIGN PATTERNS

GRASP: Designing objects with responsibilities – Creator – Information

expert – Low Coupling – High Cohesion – Controller - Design Patterns –
creational - factory method - structural – Bridge – Adapter -behavioral –
Strategy – observer

PART – A
1. What is GRASP?

 General Responsibility Assignment Software Patterns (or Principles), abbreviated

GRASP, consists of guidelines for assigning responsibility to classes and objects in
object- oriented design.
 GRASP principles or patterns are a learning aid to help us to understand essential
object design and apply reasoning in a methodical, rational and explainable way.
 GRASP patterns are creator, information expert, controller, low coupling, high
cohesion.

2. What is Responsibility-Driven Design?

A popular way of thinking about the design of software objects and also larger
scale Components are in terms of responsibilities, roles, and collaborations.
 Describing actions and activities for which software is responsible.
 Describing responsibilities in terms that both users and developers can understand.
 Designing software objects that implement those responsibilities.

3. Define doing and knowing responsibilities.

Visit & Downloaded from : www.LearnEngineering.in

 Doing responsibilities of an object include:

o Doing something itself, such as creating an object or doing a calculation
o Initiating action in other objects
o Controlling and coordinating activities in other objects
 Knowing responsibilities of an object include:
o Knowing about private encapsulated data
o Knowing about related objects
o Knowing about things it can derive or calculate

4. What are design patterns? Mention its categories. [April/May 2011, April/ May
2013, Nov/Dec 2013, May/June 2014, Nov/Dec 2014, Nov/Dec 2015, May./June
2016]
A design pattern is a general reusable solution to a commonly occurring
problem in software design. Design pattern is not a finished design that can be
transformed directly into code.
 Creational patterns
 Structural patterns
 Behavioral patterns

5. Define patterns. When to use them? [Nov/Dec 2011, May/June 2012, April/May
2015, Nov/Dec 2015]

 Pattern is a named description of a problem and solution that can be applied to new
contexts.
 Pattern advices on how to apply its solution in varying circumstances to be taken
into account.
 It also guides the assignment of responsibilities to objects.

Visit & Downloaded from : www.LearnEngineering.in

6. What is Responsibilities? Mention its types. [April/May 2013]

The UML defines are responsibility as ―a contractor obligation of a classifier‖.

Responsibilities are related to the obligations or behavior of an object in terms of its
role.
 Doing responsibility
 Knowing responsibility

7. Define bloated controller

Bloated controllers are poorly designed, a controller class will have low cohesion
– unfocused and handling too many areas of responsibility.

8. What is delegation-event model?

Observer pattern is also known as delegation event model because the publisher
delegates handling of events to listeners. Observer pattern is used when there is one
to many relationship between objects such as if one object is modified, its dependent
objects are to be notified automatically.
9. Define abstract factory and builder pattern.

 Abstract factory – groups object factories that have a common theme.

 Builder pattern – constructs complex objects by separating construction and
representation.

10. Distinguish between coupling and cohesion. [Nov/Dec 2011, Nov/Dec 2015]

Visit & Downloaded from : www.LearnEngineering.in

Coupling Cohesion
1. Coupling measures how much 1. Cohesion measures how strongly
each of the program modules are each of the functions are related
dependent on the other program within a program module. Well
modules. structured classes lead to highly
cohesive programs.
2. Cohesion of a single
2. Coupling between modules / module/component is the degree to
components is their degree of which its responsibilities form a
mutual interdependence; lower meaningful unit; higher cohesion is
coupling is better. better.

11. Define Coupling. What is meant by Low Coupling? [April/May 2011, May/June
2012, Nov/Dec 2013, May/June 2014, Nov/Dec 2014, Nov/Dec 2015, May/June
2016]

 Coupling is a measure of how strongly one element is connected to, has

knowledge of, or depends on other elements. If there is coupling or dependency,
then when the depended upon element changes, the dependant may be affected.
 Low Coupling means assign responsibilities so that (unnecessary) coupling
remains low.

12. Define Modular Design. [May/June 2016]

 Modularity is the process of decomposing a problem (program) into a set of

modules so as to reduce the overall complexity of the problem.
38

Visit & Downloaded from : www.LearnEngineering.in

 Modularity can be visualized as a way of mapping encapsulated abstractions into

real, physical modules having high cohesion within the modules and their inter–
module interaction or coupling is low.

13. Define Component with an example. [Nov/Dec 2011]

 A Component is a modular part of a system that encapsulates its contents and

whose manifestation is replaceable within its environment.
 A component defines its behavior in terms of provided and required interfaces.

14. A System must be loosely coupled and highly cohesive. Justify. [April/May 2015]

 Coupling is a measure of the interdependence between classes. Loose coupling

means that objects work more independently of each other. Loose Coupling makes
it possible to
o Understand one class without reading others
o Change one class without affecting others
o Thus: improves maintainability
 Cohesion is a measure of strength of the association of variables and methods
within a class. If a class is responsible for a few related logical tasks, we say it has
high cohesion. High Cohesion makes it easier to
o Understand what a class or method does
o Use descriptive names

Visit & Downloaded from : www.LearnEngineering.in

o Reuse classes or methods

15. Mention the interface and domain layer responsibilities. [May/June 2016]

 Domain Layer Responsibilities - this is where your business rules and logic
resides, your domain models are defined here. Do not put presentation specific
logic within your models or domain objects

 Interface Responsibilities - Use UML class diagram

o Look messages that are going to objects
o They become responsibilities of the destination object
o Model as operations in a class icon

PART – B

1. GRASP DESIGN PATTERNS

 Explain in detail about GRASP design patterns.

[April/May 2011, Nov/Dec 2011, May/June 2012, April/May 2013,
May/June 2014, Nov/Dec 2014]

General Responsibility Assignment Software Patterns (or Principles), abbreviated

GRASP, consists of guidelines for assigning responsibility to classes and objects in
object-oriented design.

Visit & Downloaded from : www.LearnEngineering.in

The different patterns and principles used in GRASP are: Information Expert,
Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication,
Indirection, and Protected Variations. All these patterns answer some software problem,
and in almost every case these problems are common to almost every software
development project. These techniques have not been invented to create new ways of
working but to better document and standardize old, tried-and-tested programming
principles in object oriented design.

It has been said that "the critical design tool for software development is a mind
well educated in design principles. It is not the UML or any other technology". Thus,
GRASP is really a mental toolset, a learning aid to help in the design of object oriented
software.

Responsibility can be: – accomplished by a single object. – or a group of object

collaboratively accomplish a responsibility.
 GRASP helps us in deciding which responsibility should be assigned to
which object/class.
 Identify the objects and responsibilities from the problem domain, and also
identify how objects interact with each other.
 Define blue print for those objects – i.e. class with methods implementing
those responsibilities.

Pattern is a named description of a problem and solution that can be applied to

new contexts; ideally a pattern advises us on how to apply its solution in varying
circumstances. It is a well known problem/solution pair.

Creator

Who creates an Object? Or who should create a new instance of some class?
 ―Container‖ object creates ―contained‖ objects.

Visit & Downloaded from : www.LearnEngineering.in

 Decide who can be creator based on the objects association and their
interaction.

Figure 2.1 Partial Domain Model

Figure 2.2 Creating a SalesLineItem

Expert
Given an object o, which responsibilities can be assigned to o?
 Expert principle says – assign those responsibilities to o for which o has the
information to fulfill that responsibility.
 They have all the information needed to perform operations, or in some
cases they collaborate with others to fulfill their responsibilities.

Visit & Downloaded from : www.LearnEngineering.in

Low Coupling
 How strongly the objects are connected to each other?
 Coupling – object depending on other object.
 When depended upon element changes, it affects the dependant also.
 Low Coupling – How can we reduce the impact of change in depended
upon elements on dependant elements.
 Prefer low coupling – assign responsibilities so that coupling remain low.
 Minimizes the dependency hence making system maintainable, efficient
and code reusable

Polymorphism
How to handle related but varying elements based on element type?
 Polymorphism guides us in deciding which object is responsible for
handling those varying elements.
 Benefits: handling new variations will become easy.

Pure Fabrication
Fabricated class/ artificial class – assign set of related responsibilities that doesn't
represent any domain object.
 Provides a highly cohesive set of activities.
 Behavioral decomposed – implements some algorithm.
 Examples: Adapter, Strategy
 Benefits: High cohesion, low coupling and can reuse this class.
Indirection
How can we avoid a direct coupling between two or more elements.
 Indirection introduces an intermediate unit to communicate between the
other units, so that the other units are not directly coupled.
 Benefits: low coupling

Visit & Downloaded from : www.LearnEngineering.in

 Example: Adapter, Facade, Observer

Protected Variation

How to avoid impact of variations of some elements on the other elements.

 It provides a well defined interface so that the there will be no affect on
other units.
 Provides flexibility and protection from variations.
 Provides more structured design.
 Example: polymorphism, data encapsulation, interfaces

2. INFROMATION EXPERT, LOW COUPLING, HIGH COHESION,

CONTROLLER

 Write short notes on following.

(i) Information Expert
(ii) Low Coupling
(iii) High Cohesion
(iv) Controller
[May/June 2012, April/May 2913, Nov/Dec 2015, May/June 2016]

(i) Information Expert

Information Expert is a principle used to determine where to delegate

responsibilities. These responsibilities include methods, computed fields and so on.

Using the principle of Information Expert a general approach to assigning

responsibilities is to look at a given responsibility, determine the information needed to
fulfill it, and then determine where that information is stored.

Visit & Downloaded from : www.LearnEngineering.in

Information Expert will lead to placing the responsibility on the class with the
most information required to fulfill it. This one is pretty simple and yet very important.
Start by assigning responsibilities by clearly stating the responsibility: In this case, we
are talking about a Sale.

Who should be responsible for knowing the grand total of a sale? (We know we
need a grand total from Use Cases / requirements and interaction diagrams for this
scenario) So, the real question then becomes, ‗who‘ has the information needed to
determine the total?

Expert (Grasp Pattern)

Domain Model contains conceptual classes of the real-world domain; These are
often business/ application entities in common use enterprise-wide. (attributes not
responsibilities) Design Model contains the software classes. (These will have attributes
and methods)

Figure 2.3 Sale – Domain Model

Visit & Downloaded from : www.LearnEngineering.in

First choice: If we have relevant classes in Design Model, choose this first.

Second choice: look into Domain Model and attempt to use (or expand) its
representations to inspire the creation of corresponding design classes

Expert (Grasp Pattern) – Using Domain Model

Assume we are just starting. We have no real Design Model. So look to Domain
Model and we find ―Sale.‖

Figure 2.4 Partial Interaction and Class Diagrams

What information do we need to determine the grand total?

A Sale instance contains these; therefore by the guideline of the Information
expert, Sale is a suitable class of object for this responsibility; it is an information expert
for the work.

Benefits of Expert:

1. Information encapsulation is maintained, since objects use their own information

to fulfill tasks. This usually supports low coupling, which leads to a more robust
and maintainable system. (‗Low Coupling‘ is also a GRASP pattern).
2. Behavior is distributed across the classes that have the required information thus
encouraging more cohesive, ‗lightweight‘ class definitions that are easier to
understand and maintain.

Visit & Downloaded from : www.LearnEngineering.in

 High cohesion is usually supported.

 Reuse potential up.

Figure 2.5 – Calculating the Sale Total

(ii) Low Coupling

Low Coupling is an evaluative pattern, which dictates how to assign responsibilities

to support:

 Lower dependency between the classes,

Visit & Downloaded from : www.LearnEngineering.in

 Change in one class having lower impact on other classes,

 Higher reuse potential.

 Coupling is a measure of how strongly one element is connected to, has

knowledge of, or relies upon other elements. An element with Low Coupling is not
dependent upon too many other elements. But how many is too many?

 High coupling is not really the problem; it is high coupling to potentially unstable
(likely to be changed) objects.

 Problems with high coupling

Forced local changes because of changes in related classes

Harder to understand in isolation

Harder to reuse because it requires other classes

 Assign responsibility so coupling remains low

 This reduces the impact of change

NextGen example

 If we need to create a Payment instance and associate it with Sale, who should do
it? Since Register records a payment, the Creator pattern suggests it

Figure 2.6 Partial Class diagram for NextGen POS

Visit & Downloaded from : www.LearnEngineering.in

Figure 2.7 Register Creates Payment

 On the other hand, Sale could create Payment and that would not increase the
coupling

 In practice, level of coupling alone is not sufficient

Figure 2.8 Sale Creates Payment

Forms of Coupling

 X has an attribute of type Y

 A type X object calls on services in Y

 X has a method that references an instance of Y

Visit & Downloaded from : www.LearnEngineering.in

 X is a direct or indirect subclass of Y

 Y is an interface that X implements

(iii) High Cohesion

High Cohesion is an evaluative pattern that attempts to keep objects appropriately

focused, manageable and understandable. High cohesion is generally used in support of
Low Coupling.

High cohesion means that the responsibilities of a given element are strongly
related and highly focused. Breaking programs into classes and subsystems is an example
of activities that increase the cohesive properties of a system. Alternatively, low cohesion
is a situation in which a given element has too many unrelated responsibilities. Elements
with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to
maintain and averse to change.

A class with low cohesion does many unrelated things. Such classes are undesirable.

 hard to comprehend

 hard to reuse

 hard to maintain

 delicate; constantly affected by change

Visit & Downloaded from : www.LearnEngineering.in

Figure 2.9 Register Creates Payment

Let us take an example used in Low coupling and analyse it for high cohesion. Here
Register is responsible for payment. If register does the work, it will become an
incohesive task.

Figure 2.10 Sale Creates Payment

This second design Figure 2.10 supports both low coupling and high cohesion.

Visit & Downloaded from : www.LearnEngineering.in

Various Degrees of Functional Cohesion :

 A very Low cohesion class A is solely responsible for many things in very
different functional areas.
 Low cohesion A class has sole responsibility for a complex task in one functional
area.
 High cohesion A class has moderate responsibilities in one functional area and
collaborates with other classes to fulfill tasks.
 Moderate cohesion A class has light weight and sole responsibilities in a few
different areas that are logically related to the class concept but not to each other.
A class with High cohesion has a relatively small number of methods.

(iv) Controller

The Controller pattern assigns the responsibility of dealing with system events to a
non-UI class that represents the overall system or a use case scenario. A Controller object
is a non-user interface object responsible for receiving or handling a system event.

A use case controller should be used to deal with all system events of a use case,
and may be used for more than one use case (for instance, for use cases Create User and
Delete User, one can have a single User Controller, instead of two separate use case
controllers).

It is defined as the first object beyond the UI layer that receives and coordinates
("controls") a system operation. The controller should delegate the work that needs to be
done to other objects; it coordinates or controls the activity. It should not do much work
itself. The GRASP Controller can be thought of as being a part of the Application/Service
layer (assuming that the application has made an explicit distinction between the
application/service layer and the domain layer) in an object-oriented system with
Common layers in an information system logical architecture.

This GRASP Pattern is very useful for those developing web-based applications,

Visit & Downloaded from : www.LearnEngineering.in

among other things.

Problem:
Who should be responsible for handling an input system ‗event?‘
So, first, what is a ―system event?‖System Event – event generated by external actor.
Associated with system operations in response to a system event.

Example:
An actor may depress a button signifying End Sale, but this is only used to
indicate a desired system operation. The ‗View‘ certainly does NOT realize this request.
Rather, it is passed on to a controller.

Solution:

Assign the responsibility for handling some kind of event message to some kind of
class representing one of the following choices:

A class that represents overall system, device, or subsystem (façade controller) or

A class that represents a use case scenario within which the system event occurs, often
named

<usecasename> Handler, or
<UseCaseName> Coordinator or
<UseCaseName> Session
A Controller is a non-user interface object responsible for receiving or handling a
system event. A Controller may represent a receiver of a signal or a handler of all system
events in a use case scenario.
Input events might come from
o a GUI operated by a person, or
o a call from a telecommunications switch, or
o a signal from a sensor, etc.

Visit & Downloaded from : www.LearnEngineering.in

Controller Pattern: System Events

Figure 2.11 Some System Operations of the NextGen POS Application

Most applications have ‗System Events.‘Typically the ‗system‘ is modeled as a

class during analysis Consider: (Larman)

Do not infer that there will be a class named System in Design. Rather, during
Design, a Controller class is assigned the responsibilities for system operations.

Remember who is developing requirements and performing analysis. We simply

do not know what the implementation (solution) will be at this time.

Figure 2.12 Controller Choices

Visit & Downloaded from : www.LearnEngineering.in

Who is the Controller for System Events?

Presumably, there is an interface layer (a GUI, sensor activation, other things…)

that needs to send a message (a system event message) to the application or domain layer
A Controller (coordinator…) is the class of object that is responsible for receiving
such a message and delegating the follow-on work to other objects.
A Controller object in this context is often a kind of ‗façade‘ onto the domain
layer from an interface layer.
There are several different kinds of Controllers.
Main two:
o Façade controller
o Use Case controller

Façade Controller

This kind of controller in design may represent the system, a device, or a

subsystem, as we have stated. Select some class name that suggests a ‗cover‘ or façade
over the other layers of the application, and that provides the main point of service calls
from the UI layer down to other layers. Again, it is a class that represents the entire
software system or subsystem.

Note: ‗Façade‘ Controllers are used when there are not too many events to control, and
there is not sufficient need for alternating controllers.

Visit & Downloaded from : www.LearnEngineering.in

Use Case Controller

Figure 2.13 Use Case Controllers

Usually a different controller for each use case Note that a use case controller is
NOT a domain object; in fact, it is a fabrication used to handle events. Consider
switching to a use case controller when a façade controller starts becoming too large and
starts to lose cohesion and starts having high coupling.
A use case controller is a good choice when there are a number of system events
across different processes; it factors their handling into manageable classes and Also
forms the basis for knowing the state of the current scenario in progress.

Additional Controllers: Page and Front

Two other design patterns related to Use Case controllers:

o Page Controller
o Front Controller

Visit & Downloaded from : www.LearnEngineering.in

Figure 2.14 Additional Controllers - Page and Front

In a Page Controller pattern, the controller uses a single Presenter which interacts with
the Model (the data for the page). When it receives a request, the Page Controller can
determine which partial View to display within the page, and then interact with that View
following the MVP pattern.

In the Front Controller pattern, a separate controller examines each request and
determines which page to display. Each page is a complete MVP implementation, with
its own View, and each Presenter interacts with the View and the Model (the data) .

3. CREATIONAL DESIGN PATTERNS

 Discuss about creational design patterns in detail.

[May/June 2012, Nov/Dec 2013, May/June 2014, Nov/Dec
2014, Nov/Dec 2015, May/June 2016]

Visit & Downloaded from : www.LearnEngineering.in

In software engineering, creational design patterns are design patterns that deal
with object creation mechanisms, trying to create objects in a manner suitable to the
situation. The basic form of object creation could result in design problems or added
complexity to the design. Creational design patterns solve this problem by somehow
controlling this object creation.

Some examples of creational design patterns include:

 Abstract factory pattern: centralize decision of what factory to instantiate

 Factory method pattern: centralize creation of an object of a specific type choosing
one of several implementations
 Builder pattern: separate the construction of a complex object from its
representation so that the same construction process can create different
representations
 Lazy initialization pattern: tactic of delaying the creation of an object, the
calculation of a value, or some other expensive process until the first time it is
needed
 Object pool pattern: avoid expensive acquisition and release of resources by
recycling objects that are no longer in use
 Prototype pattern: used when the type of objects to create is determined by a
prototypical instance, which is cloned to produce new objects
 Singleton pattern: restrict instantiation of a class to one object

(i) Factory Pattern

Factory pattern is one of most used design pattern in Java. This type of design
pattern comes under creational pattern as this pattern provides one of the best ways to
create an object.

Visit & Downloaded from : www.LearnEngineering.in

In Factory pattern, we create object without exposing the creation logic to the
client and refer to newly created object using a common interface.
Implementation

Create a Shape interface and concrete classes implementing the Shapeinterface.

FactoryPatternDemo, class will use ShapeFactory to get a Shape object. It will pass
information (CIRCLE / RECTANGLE / SQUARE) to ShapeFactory to get the type of
object it needs.
Step 1 Create an interface.
Step 2 Create concrete classes implementing the same interface.
Step 3 Create a Factory to generate object of concrete class based on given information.
ShapeFactory.java
Step 4 Use the Factory to get object of concrete class by passing information such as
type.
Step 5 Verify the output.

Figure 2.15 Factory Pattern

Visit & Downloaded from : www.LearnEngineering.in

(ii) Singleton pattern

Singleton pattern is one of the simplest design patterns in Java. This type of
design pattern comes under creational pattern as this pattern provides one of the best
ways to create an object. This pattern involves a single class which is responsible to
create an object while making sure that only single object gets created. This class
provides a way to access its only object which can be accessed directly without need to
instantiate the object of the class.
Implementation
Create a SingleObject class. SingleObject class has its constructor as private and
has a static instance of itself.

SingleObject class provides a static method to get its static instance to outside world.
SingletonPatternDemo, class will use SingleObject class to get a SingleObjectobject.

Step 1

Create a Singleton Class.

SingleObject.java

publicclassSingleObject{
//create an object of SingleObject
privatestaticSingleObject instance =newSingleObject();
//make the constructor private so that this class cannot be
//instantiated
privateSingleObject(){}
//Get the only object available
publicstaticSingleObjectgetInstance(){
return instance;
}
60

Visit & Downloaded from : www.LearnEngineering.in

publicvoidshowMessage(){
System.out.println("Hello World!");
}
}

Figure 2.16 Singleton Pattern

Step 2

Get the only object from the singleton class.

SingletonPatternDemo.java

publicclassSingletonPatternDemo{
publicstaticvoid main(String[]args){
//illegal construct
//Compile Time Error: The constructor SingleObject() is not visible

Visit & Downloaded from : www.LearnEngineering.in

//SingleObject object = new SingleObject();

//Get the only object available
SingleObjectobject=SingleObject.getInstance();
//show the message
object.showMessage();
}}

Step 3
Verify the output.
4. STRUCTURAL DESIGN PATTERNS

 Describe in detail about structural design patterns.

[April/May 2011, May/June 2012, Nov/Dec 2013, May/ June 2014,
Nov/Dec 2014, Nov/Dec 2015, May/June 2016]
(i) Adapter pattern

Adapter pattern works as a bridge between two incompatible interfaces. This type
of design pattern comes under structural pattern as this pattern combines the capability
of two independent interfaces.
This pattern involves a single class which is responsible to join functionalities of
independent or incompatible interfaces. Demonstrating use of Adapter pattern via
following example in which an audio player device can play mp3 files only and wants to
use an advanced audio player capable of playing vlc and mp4 files.

Implementation

Visit & Downloaded from : www.LearnEngineering.in

We have a MediaPlayer interface and a concrete class AudioPlayer implementing

theMediaPlayer interface. AudioPlayer can play mp3 format audio files by default. We
are having another interface AdvancedMediaPlayer and concrete classes implementing
the AdvancedMediaPlayer interface. These classes can play vlc and mp4 format files.

We want to make AudioPlayer to play other formats as well. To attain this, we

have created an adapter class MediaAdapter which implements
the MediaPlayer interface and usesAdvancedMediaPlayer objects to play the required
format. AudioPlayer uses the adapter class MediaAdapter passing it the desired audio
type without knowing the actual class which can play the desired
format. AdapterPatternDemo, our demo class will use AudioPlayer class to play various
formats.

Step 1 Create interfaces for Media Player and Advanced Media Player.
Step 2 Create concrete classes implementing the AdvancedMediaPlayer interface.
Step 3 Create adapter class implementing the MediaPlayer interface.
Step 4 Create concrete class implementing the MediaPlayer interface.
Step 5 Use the AudioPlayer to play different types of audio formats.
Step 6 Verify the output.

Visit & Downloaded from : www.LearnEngineering.in

Figure 2.17 Adapter Pattern

(ii) Bridge

Bridge is used when we need to decouple an abstraction from its implementation

so that the two can vary independently. This type of design pattern comes under
structural pattern as this pattern decouples implementation class and abstract class by
providing a bridge structure between them.
This pattern involves an interface which acts as a bridge which makes the
functionality of concrete classes independent from interface implementer classes. Both
types of classes can be altered structurally without affecting each other. Demonstrating
use of Bridge pattern via following example in which a circle can be drawn in different
colors using same abstract class method but different bridge implementer classes.

Visit & Downloaded from : www.LearnEngineering.in

Implementation

We have a DrawAPI interface which is acting as a bridge implementer and

concrete classesRedCircle, GreenCircle implementing the DrawAPI interface. Shape is
an abstract class and will use object of DrawAPI. BridgePatternDemo, our demo class
will use Shape class to draw different colored circle.

Step 1 Create bridge implementer interface.

Step 2 Create concrete bridge implementer classes implementing the DrawAPI interface.
Step 3 Create an abstract class Shape using the DrawAPI interface.
Step 4 Create concrete class implementing the Shape interface.
Step 5 Use the Shape and DrawAPI classes to draw different colored circles.
Step 6 Verify the output.

Figure 2.18 Bridge Pattern

Visit & Downloaded from : www.LearnEngineering.in

(iii) Composite pattern

Composite pattern is used where we need to treat a group of objects in

similar way as a single object. Composite pattern composes objects in term of a tree
structure to represent part as well as whole hierarchy. This type of design pattern comes
under structural pattern as this pattern creates a tree structure of group of objects.

This pattern creates a class that contains group of its own objects. This class
provides ways to modify its group of same objects. We are demonstrating use of
composite pattern via following example in which we will show employees hierarchy of
an organization.

Implementation

Figure 2.19 Composite Pattern

Visit & Downloaded from : www.LearnEngineering.in

We have a class Employee which acts as composite pattern actor

class.CompositePatternDemo, our demo class will use Employee class to add department
level hierarchy and print all employees.
Step 1 Create Employee class having list of Employee objects.
Step 2 Use the Employee class to create and print employee hierarchy.
Step 3 Verify the output.

(iv) Facade pattern

Facade pattern hides the complexities of the system and provides an interface to
the client using which the client can access the system. This type of design pattern
comes under structural pattern as this pattern adds an interface to existing system to hide
its complexities. This pattern involves a single class which provides simplified methods
required by client and delegates calls to methods of existing system classes.

Implementation

We are going to create a Shape interface and concrete classes implementing

the Shapeinterface. A facade class ShapeMaker is defined as a next step.
ShapeMaker class uses the concrete classes to delegate user calls to these
classes.FacadePatternDemo, our demo class, will use ShapeMaker class to show the
results.
Step 1 Create an interface.
Step 2 Create concrete classes implementing the same interface.
Step 3 Create a facade class.
Step 4 Use the facade to draw various types of shapes.
Step 5 Verify the output.

Visit & Downloaded from : www.LearnEngineering.in

Figure 2.20 Façade Pattern

5. BEHAVIORAL DESIGN PATTERNS

 Discuss in detail about behavioral design patterns.

[May/June 2012, Nov/Dec 2015]
(i) OBSERVER

Observer pattern is used when there is one-to-many relationship between objects

such as if one object is modified, its dependent objects are to be notified automatically.
Observer pattern falls under behavioral pattern category.
Implementation
Observer pattern uses three actor classes. Subject, Observer and Client. Subject is
an object having methods to attach and detach observers to a client object. We have
created an abstract class Observer and a concrete class Subject that is extending
class Observer.
ObserverPatternDemo will use Subject and concrete class object to show observer
pattern in action.

Visit & Downloaded from : www.LearnEngineering.in

Figure 2.21 Observer Pattern

Step 1 Create Subject class.

Step 2 Create Observer class.
Step 3 Create concrete observer classes
Step 4 Use Subject and concrete observer objects.
Step 5 Verify the output.

(ii) STRATEGY

In Strategy pattern, a class behavior or its algorithm can be changed at run time.
This type of design pattern comes under behavior pattern.
In Strategy pattern, we create objects which represent various strategies and a
context object whose behavior varies as per its strategy object. The strategy object
changes the executing algorithm of the context object.

Visit & Downloaded from : www.LearnEngineering.in

Implementation
Create a Strategy interface defining an action and concrete strategy classes
implementing the Strategy interface. Context is a class which uses a Strategy.
StrategyPatternDemo will use Context and strategy objects to demonstrate change in
Context behaviour based on strategy it deploys or uses.

Figure 2.22 Strategy Pattern

Step 1 Create an interface.
Step 2 Create concrete classes implementing the same interface.
Step 3 Create Context Class.
Step 4 Use the Context to see change in behaviour when it changes its Strategy.
Step 5 Verify the output.

Visit & Downloaded from : www.LearnEngineering.in

PART - C
1. Difference between various design patterns.
Factory pattern Vs Abstract factory pattern:
Factory pattern Abstract factory pattern
Create object through inheritance Create object through composition
Produce only one product Produce families of products
Implements code in the abstract creator Concrete factories implements factory
that make use of the concrete type that method to create product
sub class produces

Factory pattern Vs builder pattern

Builder pattern Abstract factory pattern
In builder pattern, there will be one Abstract factory pattern will return the
director class which will instruct builder instance directly
class to build the different parts of our
object and finally retrieve the object
It will have reference to the created It does not keep the track of it‘s created
object object

Builder pattern Vs Composite pattern

Builder pattern Composite pattern
It is used to create group of objects of It creates parent-child relations between
predefined types our objects

Visit & Downloaded from : www.LearnEngineering.in

MVC Vs MVP
MVP MVC
MVP is a bit more complex to MVC is easier to implement than MVP
implement than MVC. Also it has
additional layer for view interfaces
The request is always received by the The request is received by the controller
view and delegated to the presenter which in turn gets the required data and
which in turn gets the data does the loads up the appropriate view
processing
The presentation and view logic can be The controller logic can be unit tested
unit tested as the view is loosely
coupled
MVP is best suitable for Windows MVC is best suitable for web
programming as the flow naturally tend programming
towards this pattern

Visit & Downloaded from : www.LearnEngineering.in

UNIT III - CASE STUDY

Case study – the Next Gen POS system, Inception -Use case Modeling -
Relating Use cases – include, extend and generalization - Elaboration -
Domain Models - Finding conceptual classes and description classes –
Associations – Attributes – Domain model refinement – Finding conceptual
class Hierarchies - Aggregation and Composition

PART – A
1. List the relationships used in use cases. [May/June 2012]

 Include
 Extend
 Generalization
 Communication

2. What are the tests involved in use case. [May/June 2016]

 Boss test – Is your Boss happy? If not, the use case fails the Boss test which
implies it is not strongly related to achieving results of measurable value.
 EBP test - Elementary business process is related to business engineering. The
task is performed by one person in one place at one time in response to business
events which gives measurable business value.
 Size test – A use case is very seldom single action or step; rather a use case
typically contains many steps, and in the fully dressed format will often require 3-
10 pages of text.

3. Define description classes.

Visit & Downloaded from : www.LearnEngineering.in

A description class contains information that describes something else. Add a

description class when:
 There needs to be a description about an item or service, independent of current
existence of any examples of those items or services.
 Deleting instances of things they describe results in a loss of information that
needs to be maintained, but was incorrectly associated with the deleted thing.

4. What are the four terminologies of use cases?

 Concrete use case

 Abstract use case
 Base use case
 Addition use case

5. What is qualified association? [May/June 2016]

A qualified association has a qualifier that is used to select an object (or objects)
from a larger set of related objects, based upon the qualifier key. Informally, in a
software perspective, it suggests looking things up by a key, such as objects in
a HashMap.
For example, if a ProductCatalog contains manyProductDescriptions, and each
one can be selected by an itemID

6. What is domain model? [April/May 2011, April/May 2013, Nov/Dec 2013,

April/May 2015, Nov/Dec 2015]

Visit & Downloaded from : www.LearnEngineering.in

A domain model is the visual representation of conceptual classes or real situation

objects in a domain. It is also known as conceptual models, domain object models and
analysis object model.

7. How to create a domain model? [Nov/Dec 2015]

 Find the conceptual classes

 Draw them as classes in a UML class diagram
 Add associations and attributes

8. Define 100% rule and Is- a rule.

 100% Rule – 100% of the conceptual super class‘s definition should be applicable
to the sub class. The subclass must conform to 100% of super class‘s: attributes
and associations.
 Is- a Rule - All the members of a subclass set must be members of their super
class set. Conceptual subclass is a kind of super class. More tersely, is-a-kind-of is
called is-a.
9. Define Conceptual Classes. [May/June 2016]

A conceptual class is a real-world concept or thing; a conceptual or essential

perspective. At the noun filtering stage we are looking for conceptual classes.

10. Define attributes.

An attribute is a logical data value of an object. It is useful to identify attributes of

conceptual classes that are needed to satisfy the information requirements of the current
scenarios under development.

Visit & Downloaded from : www.LearnEngineering.in

11. How to identify composition?

 The life time of the part is bound within the life time of the composite – there is a
create- delete dependency of the part on a whole.
 There is an obvious whole-part physical or logical assembly.
 Some properties of the composite propagate to the parts, such as location.

12. How to name an association in UML?

 Name an association based on a ClassName – VerbPhrase – ClassName format

where the VerbPhrase creates a sequence that is readable and meaningful.
 Association names should start with a capital letter, since an association represents
a classifier of links between instances.

13. When to define a new type class? [May/June 2016]

Objects are described by classes and the blueprint for construction of objects. OO
program code resides in classes and the Objects have type specified by their class.
Classes can inherit from each other implies special relation between corresponding
objects.

14. Define Classifier. [May/June 2016]

A classifier is a category of Unified Modeling Language (UML) elements that
have some common features, such as attributes or methods. A classifier is an abstract
metaclass classification concept that serves as a mechanism to show interfaces,
classes, datatypes and components.

Visit & Downloaded from : www.LearnEngineering.in

PART – B

1. NEXTGEN POS SYSTEM

 Discuss about NextGen POS system in detail.

[Nov/Dec 2014]
The Next Gen POS System – Point of Sale
 A computerized application used to record sales and handle payments
 It interfaces to various service applications
 Bank (credit card system)
 Inventory control
 Third party tax calculator
 Increasingly must support multiple and varied terminals and interfaces
 A commercial POS system that will serve different clients with disparate needs in
terms of business rule processing

The case study is the NextGen point-of-sale (POS) system. In this apparently straight
forward Problem domain, we shall see that there are very interesting requirement and
design problems to solve. In addition, it is a realistic problem; organizations really do
write POS systems using object technologies.

A POS system is a computerized application used (in part) to record sales and
handle Payments; it is typically used in a retail store. It includes hardware components
such as a computer and bar code scanner, and software to run the system. It interfaces to
various service applications, such as a third-party tax calculator and inventory control.
These systems must be relatively fault-tolerant; that is, even if remote services are
temporarily unavailable (such as the inventory system), they must still be capable of
capturing sales and handling at least cash payments (so that the business is not crippled).

A POS system increasingly must support multiple and varied client-side terminals
and interfaces. These include a thin-client Web browser terminal, a regular personal
77

Visit & Downloaded from : www.LearnEngineering.in

computer with something like a Java Swing graphical user interface, touch screen input,
wireless PDAs, and so forth. Furthermore, we are creating a commercial POS system that
we will sell to different clients with disparate needs in terms of business rule processing.

Each client will desire a unique set of logic to execute at certain predictable points
in scenarios of using the system, such as when a new sale is initiated or when a new line
item is added. Therefore, we will need a mechanism to provide this flexibility and
customization. Using an iterative development strategy, we are going to proceed through
requirements, object-oriented analysis, design, and implementation.

Figure 3.1 NextGen POS System Context

Diagram

Visit & Downloaded from : www.LearnEngineering.in

Figure 3.2 NextGen POS System

Inception Phase this is the part of the project where the original idea is developed.
The amount of work done here is dependent on how formal project planning is done in
your organization and the size of the project. During this part of the project some
technical risk may be partially evaluated and/or eliminated. This may be done by using a
few throw away prototypes to test for technical feasibility of specific system functions.

Normally this phase would take between two to six weeks for large projects and
may be only a few days for smaller projects. The following should be done during this
phase:

1. Project idea is developed.

2. Assess the capabilities of any current system that provides similar functionality to
the new project even if the current system is a manual system. This will help
determine cost savings that the new system can provide.

3. Utilize as many users and potential users as possible along with technical staff,
customers, and management to determine desired system features, functional
capabilities, and performance requirements. Analyze the scope of the proposed
system.

4. Identify feature and functional priorities along with preliminary risk assessment of
each system feature or function.

5. Identify systems and people the system will interact with.

6. For large systems, break the system down into subsystems if possible.

7. Identify all major use cases and describe significant use cases. No need to make
expanded use cases at this time. This is just to help identify and present system
functionality.

Visit & Downloaded from : www.LearnEngineering.in

8. Develop a throw away prototype of the system with breadth and not depth. This
prototype will address some of the greatest technical risks. The time to develop
this prototype should be specifically limited. For a project that will take about one
year, the prototype should take one month.

9. Present a business case for the project (white paper) identifying rough cost and
value of the project. The white paper is optional for smaller projects. Define goals,
estimate risks, and resources required to complete the project.

10. Set up some major project milestones (mainly for the elaboration phase). A rough
estimate of the overall project size is made.

11. Preliminary determination of iterations and requirements for each iteration. This
outlines system functions and features to be included in each iteration. Keep in
mind that this plan will likely be changes as risks are further assessed and more
requirements are determined.

12. Management Approval for a more serious evaluation of the project.

This phase is done once the business case is presented with major milestones
determined (not cast in stone yet) and management approves the plan. At this point the
following should be complete:

 Business case (if required) with risk assessment.

 Preliminary project plan with preliminary iterations planned.
 Core project requirements are defined on paper.
 Major use cases are defined.

2. UNIFIED PROCESS PHASES : INCEPTION & ELABORATION

 Write short notes on inception and elaboration phase.
[April/May 2013, May/June 2014, Nov/Dec 2015]

Visit & Downloaded from : www.LearnEngineering.in

i. Inception Phase

The inception phase has only one iteration. All other phases may have multiple
iterations. The overriding goal of the inception phase is to achieve concurrence among all
stakeholders on the lifecycle objectives for the project.
The inception phase is of significance primarily for new development efforts, in
which there are significant business and requirements risks which must be addressed
before the project can proceed. For projects focused on enhancements to an existing
system, the inception phase is more brief, but is still focused on ensuring that the project
is both worth doing and possible to do.

Objectives

The primary objectives of the Inception phase include:

 Establishing the project's software scope and boundary conditions, including an
operational vision, acceptance criteria and what is intended to be in the product
and what is not.
 Discriminating the critical use cases of the system, the primary scenarios of
operation that will drive the major design tradeoffs.
 Exhibiting, and maybe demonstrating, at least one candidate architecture against
some of the primary scenarios
 Estimating the overall cost and schedule for the entire project (and more detailed
estimates for the elaboration phase that will immediately follow)
 Estimating potential risks (the sources of unpredictability) Preparing the
supporting environment for the project.

Essential Activities
The essential activities of the Inception include:

Visit & Downloaded from : www.LearnEngineering.in

Formulating the scope of the project. This involves capturing the context and
the most important requirements and constraints to such an extent that you can derive
acceptance criteria for the end product.
Planning and preparing a business case. Evaluating alternatives for risk
management, staffing, project plan, and cost/schedule/profitability tradeoffs.
Synthesizing a candidate architecture, evaluating tradeoffs in design, and in
make/buy/reuse, so that cost, schedule and resources can be estimated. The aim here is to
demonstrate feasibility through some kind of proof of concept. This may take the form of
a model which simulates what is required, or an initial prototype which explores what are
considered to be the areas of high risk. The prototyping effort during inception should be
limited to gaining confidence that a solution is possible - the solution is realized during
elaboration and construction.
Preparing the environment for the project, assessing the project and the
organization, selecting tools, deciding which parts of the process to improve.
Milestone
The Lifecycle Objectives Milestone evaluates the basic viability of the project.
Tailoring Decisions
The example iteration workflow shown at the top of this page represents a typical
Inception iteration in medium sized projects. The Sample Iteration Plan for Inception
represents a different perspective of the breakdown of activities to undertake in Inception
iteration. This iteration plan is more complete in terms of workflow details and activities,
and as such, more suitable for large projects. Small projects might decide to do only a
subset of these workflow details, deviations should be challenged and documented as part
of the project-specific process. Inception Phase includes:

 Refining the scope of the project

 Project planning
 Risk identification and analysis
 Preparing the project environment

Visit & Downloaded from : www.LearnEngineering.in

 Estimating the Budget

ii. Elaboration Phase

The purpose of this phase is to establish the baseline of the architecture of the
system and provide a stable basis for the bulk of the development effort in the next phase.

There are objectives for the Elaboration phase that help you address risks associated with
requirements, architecture, costs, and schedule:

 Get a more detailed understanding of the requirements. Having a good

understanding of the majority of requirements enables you to create a more detailed
plan and to get buy-in from stakeholders. Be sure to gain an in-depth understanding
of the most critical requirements to be validated by the architecture.

 Design, implement, validate, and establish the baseline for the

architecture. Design, implement, and test a skeleton structure of the system.
Although the functionality is not complete yet, most of the interfaces between the
building blocks are implemented and tested. This is referred to as an executable
architecture.

 Mitigate essential risks, and produce accurate schedule and cost estimates. Many
technical risks are addressed as a result of detailing the requirements and of
designing, implementing, and testing the architecture. Refine and detail the high-
level project plan.

Key considerations

The number of iterations in the Elaboration phase is dependent on, but not limited to,
factors such as green-field development compared to maintenance cycle, unprecedented
system compared to well-known technology and architecture, and so on.

Visit & Downloaded from : www.LearnEngineering.in

Typically, on the first iteration, it is better to design, implement, and test a small number
of critical scenarios to identify what type of architecture and architectural mechanisms
you need, so you can mitigate the most crucial risks. You also detail high-risk
requirements that have to be addressed early in the project. You test enough to validate
that the architectural risks are mitigated.

During the subsequent iterations, you fix whatever was not right from the previous
iteration. You design, implement, and test the remaining architecturally significant
scenarios, ensuring that you check all major areas of the system (architectural coverage),
so that potential risks are identified as early as possible.

3. USECASE RELATIONSHIP

 Explain the include, extend and generalization relationship with an example.

[Nov/Dec 2011]
Relationships between Use Cases

Use cases could be organized using following relationships:

i. Generalization
ii. Association
iii. Extend
iv. Include

i. Generalization between Use Cases

Generalization between use cases is similar to generalization between classes –

child use case inherits properties and behavior of the parent use case and may override
the behavior of the parent. Notation: Generalization is rendered as a solid directed line
with a large open arrowhead (same as generalization between classes).

Visit & Downloaded from : www.LearnEngineering.in

Generalization between use cases

Figure 3.3 Generalization Relationship

ii. Association between Use Cases

Use cases can only be involved in binary Associations. Two use cases
specifying the same subject cannot be associated since each of them individually
describes a complete usage of the system.

Figure 3.4 Associations

iii. Extend Relationship

Visit & Downloaded from : www.LearnEngineering.in

Extend is a directed relationship from an extending use case to an extended use

case that specifies how and when the behavior defined in usually supplementary
(optional) extending use case can be inserted into the behavior defined in the use case to
be extended.
Note: Extended use case is meaningful on its own, independently of the
extending use case, while the extending use case typically defines behavior that is not
necessarily meaningful by itself.
The extension takes place at one or more extension points defined in the
extended use case. The extend relationship is owned by the extending use case. The same
extending use case can extend more than one use case, and extending use case may itself
be extended.
Extend relationship between uses cases is shown by a dashed arrow with an
open arrowhead from the extending use case to the extended (base) use case. The arrow is
labeled with the keyword «extend». Registration use case is meaningful on its own, and it
could be extended with optional Get Help on Registration use case. The condition of the
extend relationship as well as the references to the extension points are optionally shown
in a Note attached to the corresponding extend relationship.
Registration use case is conditionally extended by Get Help On Registration use
case in extension point Registration Help

Extension Point

An extension point is a feature of a use case which identifies (references) a

point in the behavior of the use case where that behavior can be extended by some other
(extending) use case, as specified by an extend relationship.
Extension points may be shown in a compartment of the use case oval symbol
under the heading extension points. Each extension point must have a name, unique
within a use case. Extension points are shown as text string according to the syntax:
<extension point> ::= <name> [: <explanation>]

Visit & Downloaded from : www.LearnEngineering.in

The optional description is given usually as informal text, but can also be given
in other forms, such as the name of a state in a state machine, an activity in an activity
diagram, a precondition, or a post condition.

Figure 3.5 Extension Relationship

Registration use case with extension points Registration Help and User
Agreement Extension points may be shown in a compartment of the use case rectangle
with ellipse icon under the heading extension points.

Figure 3.6 Extension Relationship

Extension points of the Registration use case shown using the rectangle notation

Figure 3.7 The Extend Relationship

Visit & Downloaded from : www.LearnEngineering.in

iv. Include Relationship

An include relationship is a directed relationship between two use cases,

implying that the behavior of the required (not optional) included use case is inserted into
the behavior of the including (base) use case. Including use case depends on the addition
of the included use case. They include relationship is intended to be used when there are
common parts of the behavior of two or more use cases. This common part is extracted
into a separate use case to be included by all the base use cases having this part in
common.
Execution of the included use case is analogous to a subroutine call or macro
command in programming. All of the behavior of the included use case is executed at a
single location in the including use case before execution of the including use case is
resumed.
As the primary use of the include relationship is to reuse common parts,
including use cases are usually not complete by themselves but dependent on the
included use cases. Include relationship between use cases is shown by a dashed arrow
with an open arrowhead from the including (base) use case to the included (common part)
use case. The arrow is labeled with the keyword «include».

Figure 3.8 Include Relationship

Visit & Downloaded from : www.LearnEngineering.in

Figure 3.9 Include Relationship in the Use case Model

4. CONCEPTUAL CLASSES

 Describe the strategies used to identify conceptual classes and the steps in
detail to create a domain model used for representing conceptual classes.

[April/May 2011, Nov/Dec 2011, May/June 2012, April/May 2013,

Nov/Dec 2013, May.June 2014, Nov/Dec 2014, Nov/Dec 2015, May/June 2016]

A domain model captures the most important types of objects in the context of the
business. The domain model represents the ‗things‘ that exist or events that transpire in
the business environment. A domain model in problem solving and software

Visit & Downloaded from : www.LearnEngineering.in

engineering is a conceptual model of all the topics related to a specific problem. It

describes the various entities, their attributes, roles, and relationships, plus the constraints
that govern the problem domain.
Simple domain model

Figure 3.10 Domain Model

Why do a domain model?

• Gives a conceptual framework of the things in the problem space

• Helps you think – focus on semantics
• Provides a glossary of terms – noun based
• It is a static view - meaning it allows us convey time invariant business rules
• Foundation for use case/workflow modelling

Visit & Downloaded from : www.LearnEngineering.in

• Based on the defined structure, we can describe the state of the problem domain at
any time.

Features of a domain model

The following features enable us to express time invariant static business rules for
a domain:-
 Domain classes – each domain class denotes a type of object.
 Attributes – an attribute is the description of a named slot of a specified type in
a domain class; each instance of the class separately holds a value.

Figure 3.11 Domain Model

 Associations – an association is a relationship between two (or more) domain

classes that describes links between their object instances. Associations can
have roles, describing the multiplicity and participation of a class in the
relationship.

Visit & Downloaded from : www.LearnEngineering.in

 Additional rules – complex rules that cannot be shown with symbology can be
shown with attached notes.

Domain classes?

 Each domain class denotes a type of object. It is a descriptor for a set of things
that share common features. Classes can be:-
 Business objects - represent things that are manipulated in the business e.g.
Order.
 Real world objects – things that the business keeps track of e.g. Contact, Site.
 Events that transpire - e.g. sale and payment.
 A domain class has attributes and associations with other classes (discussed
below). It is important that a domain class is given a good description
How do I make a domain model?

Perform the following in very short iterations:

 Make a list of candidate domain classes.
 Draw these classes in a UML class diagram.
 If possible, add brief descriptions for the classes.
 Identify any associations that are necessary.
 Decide if some domain classes are really just attributes.
 Where helpful, identify role names and multiplicity for associations.
 Add any additional static rules as UML notes that cannot be conveyed with
UML symbols.
 Group diagrams/domain classes by category into packages.

Visit & Downloaded from : www.LearnEngineering.in

Identifying domain classes?

An obvious way to identify domain classes is to identify nouns and phrases in

textual descriptions of a domain.
Consider a use case description as follows:-
1. Customer arrives at a checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records the sale line item and presents the item description, price
and running total.

Identifying attributes?

A domain class sounds like an attribute if: -

 It relies on an associated class for it‘s identity – e.g. ‗order number‘ class
associated to an ‗order‘ class. The ‗order number‘ sounds suspiciously like
an attribute of ‗order‘.
 It is a simple data type – e.g. ‗order number‘ is a simple integer. Now it
really sounds like an attribute!

Business Object Model (BOM) versus Domain Model?

 The domain model is a variant of the RUP BOM. The BOM shows how
business workers and business entities need to be related and how they need
to collaborate in order to perform business.
 The domain model primarily uses class diagrams to show domain classes.
A domain class is synonymous with a business entity in a BOM. Business
workers are generally not elaborated.
 Domain classes do not have operations

Visit & Downloaded from : www.LearnEngineering.in

 Domain classes are pulled out of the knowledge base of domain experts or
from the knowledge represented in existing IT systems. Business entities,
on the other hand, are derived by starting from the customers of the
business, identifying business use cases etc.

Decomposition
 A central distinction between Object-oriented analysis and structured analysis is
the division by objects rather than by functions during decomposition.
 During each iteration, only objects in current scenarios are considered for addition
to the domain model.

Conceptual Class Identification

 It is better to overspecify a domain with lots of fine-grained conceptual classes

than it is to underspecify it.
 Discover classes up front rather than later.
 Unlike data modeling, it is valid to include concepts for which there are no
attributes, or which have a purely behavioral role rather than an informational role.

Identify Conceptual Classes by Category List

Common Candidates for classes include

Tangible objects, Descriptions, Roles, Places, Transactions, Containers, Systems,

Abstract nouns, Rules, Organizations, Events, Processes, Written Materials, Catalogs,
Records, Financial Instruments and Services

Identify Conceptual Classes by Noun Phrase

 Identify Nouns and Noun Phrases in textual descriptions of the domain.

Visit & Downloaded from : www.LearnEngineering.in

 Fully dressed Use Cases are good for this type of linguistic analysis.
 It‘s not strictly a mechanical process:
 Words may be ambiguous
 Different phrases may represent the same concepts.

Sales Domain example - ‘Purchase Items’ Use Case

 We find concepts such as Register, Sale, Item, Customer, Receipt etc. in this use
case.
 Should we include Receipt in the Model?
 Con: As a report of a sale, it‘s duplicate info.
 Pro: Business Rules for a Return require that the customer has a receipt.
 Suggestion: Include it in the iteration where the Return Use Case is covered.

Steps to create a Domain Model

 Identify Candidate Conceptual classes

 Draw them in a Domain Model
 Add associations necessary to record the relationships that must be retained
 Add attributes necessary for information to be preserved
 Apply existing Analysis Patterns

Apply the Mapmaker Strategy

 Use existing names for things, the vocabulary of the domain

 Exclude irrelevant features
 Do not add things that are not there

Visit & Downloaded from : www.LearnEngineering.in

A Common Mistake - Classes as Attributes

 Rule: If we do not think of a thing as a number or text in the real world, then it is
probably a conceptual class.
 If it takes up space, then it is likely a conceptual class.
Examples:
 A Store is not an attribute of a Sale
 A Destination is not an attribute of a flight

Specification or Description Conceptual Classes

 A Class that records information about an item.

 Even if all Instances of the item are sold out, the description remains.
 Avoids duplication of recording the descriptive information with each instance of
the item.
Class
 A class is a description of objects that share the same attributes, oprations,
methods, relationships and semantics
 A class is a template for creating objects.
 A class models the data and behavior an object will have.
 Classes can be domain (or analysis) classes, design classes,
or implementation classes

Definition of the class must include attributes, operations and constraints

Visit & Downloaded from : www.LearnEngineering.in

Description of a Service Example (Flight)

Figure 3.12 Classes in Flight Service

 An object is a specific instance of a class.

Domain Model is a class diagram with conceptual classes in the problem domain

Stereotype Classes

<<Entity Class>>

 Problem-domain classes
 Persistent data classes

<<Boundary Class>>

 IO classes such as windows, screens, forms, dialogs, menus,

communication classes
 Also called Interface Class

<<Control Class>>

 Transaction class handling sequence of operations.

 Captures business rules and policies

Visit & Downloaded from : www.LearnEngineering.in

 Connects boudary classes with their entity classes

 Also called control or handler

Attributes

 A data variable with object scope.

 Examples: book attributes: title, author, publisher, ISBN
 The value of an object's attributes define its state.
 Attributes should not be accessible to entities outside the object.

Behaviors

1. Method: a function with object scope.

2. Methods can operate on that object's attributes.
3. Defines the objects behaviors - how it does what it does.
4. Methods define the objects responsibilities.

5. DOMAIN MODEL REFINEMENT

 Illustrate domain model refinement with an example.
[Nov/Dec 2015]
Generalization and Specialization
• Conceptual class hierarchies are the basis for software class hierarchies that
exploit inheritance
• Association classes capture information about the association
• Time intervals capture the idea that some objects are valid for a limited time
Defining Superclasses and Subclasses
• A conceptual superclass definition is more general than a subclass definition
• A subclass is a subset of its superclass
• Conformance: 100% of the superclass definition should be applicable to the
subclass‘s attributes and associations

Visit & Downloaded from : www.LearnEngineering.in

When to Define a Subclass?

• The subclass has additional attributes of interest
• The subclass has additional associations
• The subclass is operated on differently from the superclass or other subclasses
• The subclass represents an animated thing that behaves differently from the
superclass

When to Define a Superclass?

• Possible subclasses represent variations of a similar concept
• Subclasses will conform to the 100% and is-a rules
• All subclasses have the same attribute that can be factored out and put in the
superclass
• All subclasses have the same association that can be related to the superclass
Abstract Conceptual Classes
• If every member of a class C must also be a member of a subclass, then C is called
an abstract class
• That is, if C is never used by itself, but only derived classes are used, C is abstract
• UML uses italics for abstract classes

Payment abstract class

indicated by italics
amount : Money

Cash Credit Check

Payment Payment Payment

Figure 3.13 Conceptual Classes

Composition

• Implies the following:

Visit & Downloaded from : www.LearnEngineering.in

– An instance of the part belongs to only one composite instance at a time

– The part must always belong to a composite (Fingers always belong to a
Hand)
– The composite is responsible for the creation and deletion of its parts. If
the composite is destroyed, the parts must either be destroyed or attached to
another composite

Association Role Names

• Each end of an association is a role. Properties are: Name and multiplicity
• For example, a City is an object in an association, but its role in a flight might be
destination
Flies-to 1
Flight * destination
City

role name

describes the role of a city in the

Flies-to association

Person

2
*
child
parent


Creates

Figure 3.14 Association Roles

Qualified Association

• A qualifier may be used in an association. The qualifier value makes each thing
on the left unique.
• Use carefully; they don‘t usually add new information.

100

Visit & Downloaded from : www.LearnEngineering.in

(a) Product Contains Product

Catalog Specification
1 1..*

1 1
Product Contains Product
(b) itemID
Catalog Specification

qualifier multiplicity reduced to 1

Figure 3.15 Qualified Association

Reflexive Association
• A concept may have an association to itself.

Person

2
*
parent child

Creates

Figure 3.16 Reflexive Association

101

Visit & Downloaded from : www.LearnEngineering.in

PART - C
1.Explain in detail about association and aggregation with example.
Association:
At this level of class design, the links between objects which allows them to
communicate is called as association
Types:
o One to one association
o One to many association
o Many to many association
Directions of message passing:
 Associations are generally to be bidirectional. Message can be passed in both the
directions.
Associations in applications:
Associations also form hierarchies as follows:
 Aggregation
 Composition
 Part-Whole
 A part of
 Has a
 Containment
Example:

102

Visit & Downloaded from : www.LearnEngineering.in

Example:
Association
Association is a semantically weak relationship (a semantic dependency) between otherwise
unrelated objects. An association is a "using" relationship between two or more objects in which
the objects have their own life time and there is no owner. As an example, imagine the
relationship between a doctor and a patient. A doctor can be associated with multiple patients
and at the same time, one patient can visit multiple doctors for treatment and/or consultation.
Each of these objects have their own life-cycle and there is no owner. In other words, the objects
that are part of the association relationship can be created and destroyed independently.

public class IDGBlogAccount

{
private IDGBlogEntry[] blogEntries;
//Other members of the IDGBlogAccount class
}
public class IDGBlogEntry
{
Int32 blogId;
string caption;
string text;
//Other members of the IDGBlogEntry class
}

Aggregation:

Aggregation is a specialized form of association between two or more objects in which the
objects have their own life-cycle but there exists an ownership as well. Aggregation is a typical
whole/part relationship but it may or may not denote physical containment -- the objects may or
may or be a part of the whole. In aggregation the objects have their own life-cycle but they do
have ownership as well. As an example, an employee may belong to multiple departments in the
organization. However, if the department is deleted, the employee object wouldn't be destroyed.
Note that objects participating in an aggregation relationship cannot have cyclic aggregation
103

Visit & Downloaded from : www.LearnEngineering.in

relationships, i.e., a whole can contain a part but the reverse is not true. In the following code
example, an aggregation relationship is evident between the IDGBlogAuthor and
IDGBlogAccount classes.

public class IDGBlogAuthor

{
private Int32 authorId;
private string firstName;
private string lastName;
//Other members of the IDGBlogAuthor class
}
public class IDGBlogAccount
{
private IDGBlogEntry[] blogEntries;
//Other members of the IDGBlogAccount class
}
Aggregation is usually represented in UML using a line with a hollow diamond. Aggregation
like association can be used to represent a one-to-many or many-to-many relationship between
the participating objects due to which we may say that it is a redundant relationship.

Composition:
Composition is a specialized form of aggregation in which if the parent object is destroyed, the
child objects would cease to exist. It is actually a strong type of aggregation and is also referred
to as a "death" relationship. As an example, a house is composed of one or more rooms. If the
house is destroyed, all the rooms that are part of the house are also destroyed as they cannot exist
by themselves. The following code snippet illustrates a composition relationship between two
classes, House and Room.

public class House

{
private Room room;

104

Visit & Downloaded from : www.LearnEngineering.in

public House()
{
room = new Room();
}
}
In essence, Composition is also a whole/part relationship but unlike aggregation, here the
lifetime of the "part" is controlled by the "whole". It should be noted that this control can either
be direct or transitive, i.e., the "whole" may directly be responsible for creation or destruction of
the "part" or it may use a "part" that has been already created and then delegate the control to
some other "whole" to destroy the "part." Composition is represented in UML using a line
connecting the objects with a solid diamond at the end of the object that owns the other object.

105

Visit & Downloaded from : www.LearnEngineering.in

UNIT IV - APPLYING DESIGN PATTERNS

System sequence diagrams - Relationship between sequence diagrams and

use cases Logical architecture and UML package diagram – Logical
architecture refinement - UML class diagrams - UML interaction diagrams
- Applying GoF design patterns

PART – A
1. What is the use of system sequence diagram? Mention its use.
[April/May 2011, Nov/Dec 2011, May/June 2012, May/June 2014,
Nov/Dec 2014, Nov/Dec 2015]

It is a fast and easily created artifact that illustrates the input and output events
related to the systems under discussion. System sequence diagram is a picture that shows,
for one particular scenario of a use case, the events that external actors generate their
order, and inter-system events.

2. Define package and draw the UML notation for package.

[May/June 2012, May/June 2016]

Package is a namespace used to group together elements that are semantically

related and might change together. It is a general purpose mechanism to organize
elements into groups to provide better structure for system model.

106

Visit & Downloaded from : www.LearnEngineering.in

3. What is meant by layer in logical architecture? Mention its use. [Nov/Dec 2013]

A layer is a very coarse-grained grouping of classes, packages, or subsystems that

has cohesive responsibility for a major aspect of the system. Also, layers are organized
such that ―higher‖ layers call upon services of ―lower‖ layers, but normally vice versa.
 UI layer
 Application logic or domain layer
 Technical services
4. Define tier, layer and partition. [April/May 2013]

Tier:
It always represents the logical layer. But not the physical node but the word has
become widely used to mean a physical processing node.
Layer:
In layered architecture, vertical slices are called as layers.
Partition:
It represents horizontal division of relatively parallel subsystems of a layer.

5. Differentiate domain layer and domain model.

Domain Layer Domain Model

1. Domain layer is a part of the 1. Domain model is a part of

software. conceptual perspective analysis.

2. Domain layer contains domain 2. Domain model is a visualization

objects to handle application logic. of domain concepts.

6. List the relationships used in class diagram. [April/May 2011, Nov/Dec 2013,

107

Visit & Downloaded from : www.LearnEngineering.in

May/June 2014, Nov/Dec 2014, Nov/Dec 2015, May/June 2016]

 Generalization (class to class)

 Association (object to object)
 Aggregation (object to object)
 Composition (object to object)

7. Define aggregation and composition.

[April/May 2011, May/June 2012, Nov/Dec 2013, May/June 2014,
Nov/Dec 2014, Nov/Dec 2015, May/June 2016]

 Aggregation - When an object contains the other object, if the contained object
can exist without the existence of the container object, then it is called
Aggregation.
 Composition - When an object contains the other object, if the contained object
cannot exist without the existence of the container object, then it is called
aggregation.

8. What is the purpose of association relationship? [April/May 2015]

Association relationship is used to find and show associations that are needed to
satisfy the information requirements of the current scenarios under development and
which aid in understanding the domain.
Association is a relationship between classes that indicates some meaningful and
interesting connections.

9. What do you mean by sequence number in UML? Where and for what it is
used? [Nov/Dec 2011]

108

Visit & Downloaded from : www.LearnEngineering.in

 Sequence number is used in-between two objects in communication diagram along

with message.
 The numbers of message indicates the order of message within an interaction.
 It is used for ordering of message.

10. Differentiate sequence diagram and communication diagram.

[April/May 2013, April/May 2015]

Type Strength Weakness

Clearly shows sequence or time
Forced to extend to the right
ordering of messages.
Sequence Diagram when adding new objects;
Large set of detailed notation
consumes horizontal space.
options.
Space economical – flexibility to More difficult to see the
Communication
add new objects in two sequence of messages.
Diagram
dimensions. Fewer notation options.

11. Define User Interface (UI) layer

UI layer should focus on UI work such as creating windows, capturing mouse and
keyboard events.
12. Define Swimlane. [Nov/Dec 2011]

A swim lane (or swimlane diagram) is a visual element used in process flow
diagrams, or flowcharts, that visually distinguishes job sharing and responsibilities for
sub-processes of a business process. Swim lanes may be arranged either horizontally
or vertically.

109

Visit & Downloaded from : www.LearnEngineering.in

13. How will you reflect the version information in UML diagrams? [Nov/Dec 2011]

Version Date Description Author

First draft. To be refined primarily
Inception draft Jan 10, 2031 Craig Larman
during elaboration

14. What is meant by System Behaviour? [Nov/Dec 2015]

UML System behavioral diagrams visualize, specify, construct, and document the
dynamic aspects of a system. The behavioral diagrams are categorized as follows: use
case diagrams, interaction diagrams, state–chart diagrams, and activity diagrams.

15. What is the use of Interaction Diagrams? [Nov/Dec 2015]

 From the name Interaction it is clear that the diagram is used to describe some
type of interactions among the different elements in the model. So this interaction
is a part of dynamic behavior of the system.
 This interactive behavior is represented in UML by two diagrams known as
Sequence diagram and Collaboration diagram.
 Sequence diagram emphasizes on time sequence of messages and
collaboration diagram emphasizes on the structural organization of the objects that
send and receive messages.

110

Visit & Downloaded from : www.LearnEngineering.in

PART – B

1. RELATIONSHIP BETWEEN SEQUENCE DIAGRAM & USECASES

 Illustrate with an example, the relationship between sequence diagram and

use cases. [April/May 2011, April/May 2013, Nov/Dec 2013,
May/June 2014, Nov/Dec 2014, Nov/Dec 2015, May/June 2016]

A system sequence diagram is, as the name suggests, a type of sequence diagram
in UML. These charts show the details of events that are generated by actors from outside
the system.
System sequence diagrams are actually a sub-type of sequence diagrams, whose
style and notation is dictated by the Unified Modeling Language. This language provides
a toolkit for diagram creators to make and read diagrams that are comprehensible
regardless of location or industry.

Sequence diagrams show the progression of events over a certain amount of time,
while system sequence diagrams go step further and present sequences for specific use
cases. Use cases are simply another diagram type which represents a user's interaction
with the system. For a refresher course on sequence diagrams, you may want to visit this
page on ―What is a sequence diagram in UML?‖. Most elements you see on that page
remain in use throughout a system sequence diagram, including:
Objects - this box shape with an underlined title represents a class, or object, in UML.
Within a SSD, this shape models the system as a black box (a system with inner workings
that are not immediately visible).
Actors - shown by stick figures, actors are entities that interact with the system, and yet
are external to it.

111

Visit & Downloaded from : www.LearnEngineering.in

Events - the system events that the actors generate in the sequence. A dashed line, known
as a lifeline, represents events in an SSD. Lifelines may begin with a labeled rectangle
shape or an actor symbol.

When to Draw a System Sequence Diagram

SSDs are ideal for demonstrating when and how tasks are completed in a system,
especially as those tasks relate to use cases. Here are a few specific examples of when to
use SSDs:

 In a step-wise fashion, modeling operations of the system in response to

events.
 Building a blueprint for the main success scenario of a given use case, then
creating alternative paths.
 Identifying major system events and operations in order to come up with
realistic estimates on resources needed.

UML provides two types of diagrams for the representation of interactions: the
sequence diagram and the communication diagram. Both diagrams visualize the
exchange of information. However, the emphasis is different: communication
diagrams emphasize the relationships of individual objects and their topology;sequence
diagrams emphasize the chronological course of exchanged information. In the external
view, we opt for the representation through sequence diagrams and do without
communication diagrams for two reasons:

 Sequence diagrams are easier to understand for developers and readers. In our
practical work in projects we have observed a much higher acceptance of
sequence diagrams because of their simplicity.
 We avoid using unnecessarily many diagram types for the same facts. Less is
often more!

112

Visit & Downloaded from : www.LearnEngineering.in

Figure 4.1 System Sequence Diagram

If a customer or business partner uses an offered service, partners communicate

with each other. The process can be described as a series of interactions. These
interactions are clearly laid out in the sequence diagram, whereas the activities of each
partner and the conditions under which the interactions take place are omitted in the
diagram. However, they can be described with supplementary comments.

Like the activity diagrams, sequence diagrams can be modeled spanning several
use cases, as well as being used to refine business use cases. A sequence diagram
illustrates the various scenarios of a business use case.

Sequence diagrams can be used as the basis for message exchange between the
business system and outside parties. We will treat this topic in Modeling for System
Integration:

113

Visit & Downloaded from : www.LearnEngineering.in

Figure 4.2 The elements of the sequence diagram

In a sequence diagram, we work with the following elements:

Comment
Sequence diagrams can be annotated with comments (UML generally permits
comments in all diagrams.):
IF ticket not OK
refer
passenger to
customer service
...

For instance, activities of partners or conditions can be specified as comments.

Object
Objects that are involved in interactions are placed on the x-axis. Objects are
senders and receivers of messages in the sequence diagram:

114

Visit & Downloaded from : www.LearnEngineering.in

Figure 4.3 Object Notation

In the business system model (external view) these objects represent the actors of
the business system and the business system itself.

Message and Business Object

The messages that objects send and receive are shown on the y-axis. Messages are
inserted in increasing chronological order from top to bottom. The direction of the arrow
indicates the direction in which a message is sent:

Message
(Business Object)

Figure 4.4 Message and Business Object

The business object is listed in parenthesis. Business objects are conveyed together
with messages. Some examples of business objects are tickets, boarding passes, and
luggage. These examples will be treated in more detail in Package Diagram.

2. UML NOTATIONS FOR CLASS DIAGRAM

 Describe the UML notations for class diagram with an example.

[May/June 2012, Nov/Dec 2014, Nov/Dec 2015]

The class diagram is the main building block of object oriented modelling. It is used

115

Visit & Downloaded from : www.LearnEngineering.in

both for general conceptual modelling of the systematic of the application, and for
detailed modelling translating the models into programming code. Class diagrams can
also be used for data modelling. The classes in a class diagram represent both the main
objects, interactions in the application and the classes to be programmed.

Figure 4.5 UML Notation for Class Diagram

A class with three sections.

In the figure: 4.6, classes are represented with boxes which contain three parts:

 The top part contains the name of the class. It is printed in bold and centered, and
the first letter is capitalized.
 The middle part contains the attributes of the class. They are left-aligned and the
first letter is lowercase.
 The bottom part contains the methods the class can execute. They are also left-
aligned and the first letter is lowercase.

In the design of a system, a number of classes are identified and grouped together
in a class diagram which helps to determine the static relations between those objects.
With detailed modelling, the classes of the conceptual design are often split into a number
of subclasses. In order to further describe the behaviour of systems, these class diagrams
can be complemented by a state diagram or UML state machine.

Members
UML provides mechanisms to represent class members, such as attributes and
methods, and additional information about them.

116

Visit & Downloaded from : www.LearnEngineering.in

Visibility
To specify the visibility of a class member (i.e., any attribute or method), these
notations must be placed before the member's name

+ Public
- Private
# Protected
Derived (can be combined with one of the
/
others)
~ Package
Scopes
The UML specifies two types of scope for members: instance and classifier and
these last are represented by underlined names.

Classifier members are commonly recognized as ―static‖ in many programming

languages. The scope is the class itself.
Attribute values are equal for all instances
Method invocation does not affect the instance‘s state
Instance members are scoped to a specific instance.
Attribute values may vary between instances
Method invocation may affect the instance‘s state (i.e., change instance‘s attributes)

To indicate a classifier scope for a member, its name must be underlined. Otherwise,
instance scope is assumed by default.

Relationships
A relationship is a general term covering the specific types of logical connections
found on class and object diagrams. UML shows the following relationships:

117

Visit & Downloaded from : www.LearnEngineering.in

Instance level relationships

Links

A Link is the basic relationship among objects.

Association
Class diagram example of association between two classes. An association
represents a family of links. A binary association (with two ends) is normally represented
as a line. An association can link any number of classes. An association with three links is
called a ternary association. An association can be named, and the ends of an association
can be adorned with role names, ownership indicators, multiplicity, visibility, and other
properties.
There are four different types of association: bi-directional, uni-directional, Aggregation
(includes Composition aggregation) and Reflexive.
Bi-directional and uni-directional associations are the most common ones.
For instance, a flight class is associated with a plane class bi-directionally. Association
represents the static relationship shared among the objects of two classes.

Aggregation

Class diagram showing Aggregation between two classes

Aggregation is a variant of the "has a" association relationship; aggregation is
more specific than association. It is an association that represents a part-whole or part-of
relationship. As shown in the image, a Professor 'has a' class to teach. As a type of
association, an aggregation can be named and have the same adornments that an
association can. However, an aggregation may not involve more than two classes; it must
be a binary association.

Aggregation can occur when a class is a collection or container of other classes,

but the contained classes do not have a strong lifecycle dependency on the container. The
contents of the container are not automatically destroyed when the container is.

118

Visit & Downloaded from : www.LearnEngineering.in

In UML, it is graphically represented as a hollow diamond shape on the containing

class with a single line that connects it to the contained class. The aggregate is
semantically an extended object that is treated as a unit in many operations, although
physically it is made of several lesser objects.

Composition

Class diagram showing Composition between two classes at top and Aggregation
between two classes at bottom
Composition is a stronger variant of the "has a" association relationship;
composition is more specific than aggregation.

Composition usually has a strong lifecycle dependency between instances of the

container class and instances of the contained class(es): if the container is destroyed,
normally every instance that it contains is destroyed as well. (Note that, where allowed, a
part can be removed from a composite before the composite is deleted, and thus not be
deleted as part of the composite.)

The UML graphical representation of a composition relationship is a filled

diamond shape on the containing class end of the tree of lines that connect contained
class(es) to the containing class.

Differences between composition and aggregation

Composition relationship

When attempting to represent real-world whole-part relationships.

Aggregation relationship

When representing a software or database relationship, e.g., car model engine

ENG01 is part of a car model CM01, as the engine, ENG01 may be also part of a
different car model. Thus the aggregation relationship is often "catalog" containment to
distinguish it from composition's "physical" containment.

119

Visit & Downloaded from : www.LearnEngineering.in

Class level relationships

Generalization

Class diagram showing generalization between one superclass and two subclasses
The Generalization relationship ("is a") indicates that one of the two related
classes (the subclass) is considered to be a specialized form of the other (the super type)
and the superclass is considered a 'Generalization' of the subclass.

In practice, this means that any instance of the subtype is also an instance of the
superclass. An exemplary tree of generalizations of this form is found in biological
classification: human beings are a subclass of simian, which are a subclass of mammal,
and so on. The relationship is most easily understood by the phrase 'an A is a B' (a human
is a mammal, a mammal is an animal).

The UML graphical representation of a Generalization is a hollow triangle shape

on the superclass end of the line (or tree of lines) that connects it to one or more
subtypes.The generalization relationship is also known as the inheritance or "is a"
relationship.The superclass (base class) in the generalization relationship is also known as
the "parent", superclass, base class, or base type.

The subtype in the specialization relationship is also known as the "child",

subclass, derived class, derived type, inheriting class, or inheriting type.

Note that this relationship bears no resemblance to the biological parent/child

relationship: the use of these terms is extremely common, but can be misleading.

 Generalization-Specialization relationship

A is a type of B
E. g. "an oak is a type of tree", "an automobile is a type of vehicle"

Generalization can only be shown on class diagrams and on Use case diagrams.

120

Visit & Downloaded from : www.LearnEngineering.in

Realization

In UML modelling, a realization relationship is a relationship between two model

elements, in which one model element (the client) realizes (implements or executes) the
behavior that the other model element (the supplier) specifies.

The UML graphical representation of a Realization is a hollow triangle shape on

the interface end of the dashed line (or tree of lines) that connects it to one or more
implementers. A plain arrow head is used on the interface end of the dashed line that
connects it to its users. In component diagrams, the ball-and-socket graphic convention is
used (implementers expose a ball or lollipop, while users show a socket). Realizations
can only be shown on class or component diagrams.

A realization is a relationship between classes, interfaces, components, and

packages that connects a client element with a supplier element. A realization relationship
between classes and interfaces and between components and interfaces shows that the
class realizes the operations offered by the interface.

General relationship

Class diagram showing dependency between "Car" class and "Wheel" class (An
even clearer example would be "Car depends on Wheel", because Car already aggregates
(and not just uses) Wheel)

Dependency

Dependency is a weaker form of bond which indicates that one class depends on
another because it uses it at some point in time. One class depends on another if the
independent class is a parameter variable or local variable of a method of the dependent
class. This is different from an association, where an attribute of the dependent class is an
instance of the independent class. Sometimes the relationship between two classes is very
weak. They are not implemented with member variables at all. Rather they might be
implemented as member function arguments.

121

Visit & Downloaded from : www.LearnEngineering.in

Multiplicity

This association relationship Members.UML provides mechanisms to represent

class members, such as attributes and methods, and additional information about them.

Analysis stereotypes

In the early stages of a project's technical analysis, class diagrams can be used to
produce early conceptual models of the system. Classes at this stage often take the form
of boundaries, controls and entities and rarely survive into the design without heavy
changes.

Entities

Figure 4.6 Entities

Entity classes model the information handled by the system, and sometimes the
behavior associated with the information. They should not be identified as database tables

122

Visit & Downloaded from : www.LearnEngineering.in

or other data-stores. They are drawn as circles with a short line attached to the bottom of
the circle. Alternatively, they can be drawn as normal classes with the «entity» stereotype
notation above the class name.

3. UML INTERACTION DIAGRAM IN DYNAMIC ASPECTS

 Explain with an example, how interaction diagrams are used to model the
dynamic aspects of a system.
[April/May 2011, Nov/Dec 2011, May/June 2012, Nov/Dec 2013,
Nov/Dec 2015, May/June 2016]

Interaction Overview Diagram is one of the thirteen types of diagrams of the

Unified Modeling Language (UML), which can picture a control flow with nodes that can
contain interaction diagrams.

Sequence Diagram
Illustrate interactions in a kind of fence format, in which each new
object is added to the right.
Objects as well as classes can be targets on a sequence diagram, which means that
messages can be sent to them. A target is displayed as a rectangle with some text in it.
Below the target, its lifeline extends for as long as the target exists. The lifeline is
displayed as a vertical dashed line.

The basic notation for an object is

Figure 4.7 Notation for Object

123

Visit & Downloaded from : www.LearnEngineering.in

Where 'name' is the name of the object in the context of the diagram and 'Type' indicates
the type of which the object is an instance. Note that the object doesn't have to be
a direct instance of Type, a type of which it is an indirect instance is possible too. So
'Type' can be an abstract type as well.
When a target sends a message to another target, it is shown as an arrow between
their lifelines. The arrow originates at the sender and ends at the receiver. Near the arrow,
the name and parameters of the message are shown.

Synchronous message
A synchronous message is used when the sender waits until the receiver has
finished processing the message, only then does the caller continue (i.e. a blocking call).
Most method calls in object-oriented programming languages are synchronous. A closed
and filled arrowhead signifies that the message is sent synchronously.

Figure 4.8 Synchronous Message

The white rectangles on a lifeline are called activations and indicate that an object is
responding to a message. It starts when the message is received and ends when the object
is done handling the message.

When messages are used to represent method calls, each activation corresponds to the
period during which an activation record for its call is present on the call stack.

124

Visit & Downloaded from : www.LearnEngineering.in

If you want to show that the receiver has finished processing the message and returns
control to the sender, draw a dashed arrow from receiver to sender. Optionally, a value
that the receiver returns to the sender can be placed near the return arrow.

Figure 4.9 Synchronous Message

If you want your diagrams to be easy to read, only show the return arrow if a value is
returned. Otherwise, hide it.

Instantaneous message
Messages are often considered to be instantaneous, i.e. the time it takes to arrive at
the receiver is negligible. For example, an in-process method call. Such messages are
drawn as a horizontal arrow.

Figure 4.10 Instantaneous Message

Sometimes however, it takes a considerable amount of time to reach the receiver

(relatively speaking of course) . For example, a message across a network. Such a non-
instantaneous message is drawn as a slanted arrow.

125

Visit & Downloaded from : www.LearnEngineering.in

Figure 4.11 Instantaneous Message

You should only use a slanted arrow if you really want to emphasize that a message
travels over a relatively slow communication channel (and perhaps want to make a
statement about the possible delay). Otherwise, stick with a horizontal arrow.

Found message
A found message is a message of which the caller is not shown. Depending on the
context, this could mean that either the sender is not known, or that it is not important
who the sender was. The arrow of a found message originates from a filled circle.

Figure 4.12 Found Message

Asynchronous messages
With an asynchronous message, the sender does not wait for the receiver to finish
processing the message, it continues immediately. Messages sent to a receiver in another
process or calls that start a new thread are examples of asynchronous messages. An open
arrowhead is used to indicate that a message is sent asynchronously.

126

Visit & Downloaded from : www.LearnEngineering.in

Figure 4.13 Asynchronous Message

A small note on the use of asynchronous messages: once the message is received, both
sender and receiver are working simultaneously. However, showing two simultaneous
flows of control on one diagram is difficult. Usually authors only show one of them, or
show one after the other.

Message to self

A message that an object sends itself can be shown as follows :

Figure 4.14 Message to self

Keep in mind that the purpose of a sequence diagram is to show the interaction between
objects, so think twice about every self message you put on a diagram.

Creation and destruction

127

Visit & Downloaded from : www.LearnEngineering.in

Targets that exist at the start of an interaction are placed at the top of the diagram.
Any targets that are created during the interaction are placed further down the diagram, at
their time of creation.

Figure 4.15 Creation and Destruction

A target's lifeline extends as long as the target exists. If the target is destroyed during the
interaction, the lifeline ends at that point in time with a big cross.

Conditional Interaction

A message can include a guard, which signifies that the message is only sent if a
certain condition is met. The guard is simply that condition between brackets.

128

Visit & Downloaded from : www.LearnEngineering.in

Figure 4.16 Conditional Interaction

If you want to show that several messages are conditionally sent under the same guard,
you'll have to use an 'opt' combined fragment. The combined fragment is shown as a
large rectangle with an 'opt' operator plus a guard, and contains all the conditional
messages under that guard.

Figure 4.17 Conditional Interaction

A guarded message or 'opt' combined fragment is somewhat similar to the if-construct in

a programming language.

If you want to show several alternative interactions, use an 'alt' combined fragment. The
combined fragment contains an operand for each alternative. Each alternative has a guard
and contains the interaction that occurs when the condition for that guard is met.

129

Visit & Downloaded from : www.LearnEngineering.in

Figure 4.18 Conditional Interaction

At most one of the operands can occur. An 'alt' combined fragment is similar to nested if-
then-else and switch/case constructs in programming languages.

Communication Diagram

Communication diagram (called collaboration diagram in UML 1.x) is a kind

of UML interaction diagram which shows interactions between objects
and/or parts (represented as lifelines) using sequenced messages in a free-form
arrangement.
Communication diagram corresponds (i.e. could be converted to/from or
replaced by) to a simple sequence diagram without structuring mechanisms such as
interaction uses and combined fragments. It is also assumed that message

130

Visit & Downloaded from : www.LearnEngineering.in

overtaking (i.e., the order of the receptions are different from the order of sending of a
given set of messages) will not take place or is irrelevant.
The following nodes and edges are drawn in a UML communication
diagrams: frame, lifeline, message. These major elements of the communication diagram
are shown on the picture below.

Figure 4.19 Communication Diagram

Frame

Communication diagrams could be shown within a rectangular frame with

the name in a compartment in the upper left corner.

131

Visit & Downloaded from : www.LearnEngineering.in

There is no specific long form name for communication diagrams heading types. The
long form name interaction (used for interaction diagrams in general) could be used.

Figure 4.20 Frame with Long Name

There is also no specific short form name for communication diagrams. Short form
name sd (which is used for interaction diagrams in general) could be used. This sd is bit
confusing as it looks like abbreviation of sequence diagram.

Figure 4.21 Frame with Short Name

Message
Message in communication diagram is shown as a line with sequence
expression and arrow above the line. The arrow indicates direction of the communication.

Figure 4.22 Message in Communication Diagram

132

Visit & Downloaded from : www.LearnEngineering.in

4. LOGICAL ARCHITECTURE & UML PACKAGE DIAGRAM

 Explain the logical architecture and UML package diagram in detail.

[May/June 2014, May/June 2016]
The Large-Scale
At this level, the design of a typical OO system is based on several architectural
layers, such as UI layer, Application logic (or ―domain‖) layer, Technical Services.

Software Architecture

A set of significant decisions about:

 Organization of a software system
 Selection of structural elements
 Interfaces between elements
 Behavioral collaboration between elements
 Composition of elements into subsystems
 Architectural ―style‖ of organization

Logical Architecture and UML Package Diagrams.

 High level, large scale Architecture Model.

 At this level, the design of a typical OO system is based on several architectural
layers, such as a UI layer, an application logic (or ―domain‖) layer, and so forth.
 Goal is to design a logical architecture with layers and partitions using UML
package diagrams

133

Visit & Downloaded from : www.LearnEngineering.in

Logical Architecture And Layers

 Logical architecture is the large-scale organization of the software classes into

packages (or namespaces), subsystems, and layers.
 Logical – because there‘s no decision about how these elements are deployed
across different operating system processes or across physical computers in a
network (deployment architecture).

Layering Pattern
 A layer is a very coarse-grained grouping of classes, packages, or subsystems that
has cohesive responsibility for a major aspect of the system.
 Also, layers are organized such that ―higher‖ layers (such as the UI layer) call
upon services of ―lower‖ layers, but not normally vice versa.
 Strict layered architecture VS Relaxed Layered Achitecture
 A logical architecture doesn‘t have to be organized in layers. But it‘s very
common, and hence, introduced at this time.

Why use Layers
 Source code changes are rippling throughout the system many parts of the systems
are highly coupled.
 Application logic intertwined with UI, neither reusable
 Potentially general technical services or business logic is intertwined with more
application-specific logic, so it cannot be reused, distributed to another node, or
easily replaced with a different implementation.
 High coupling across different areas of concern. It is thus difficult to divide the
work along clear boundaries for different developers.
 The purpose and number of layers varies across applications and application
domains (information systems, operating systems, and so forth).

134

Visit & Downloaded from : www.LearnEngineering.in

Typical Layers

not the Java

Swing Swing libraries, but Web
our GUI classes
based on Swing

Domain

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

Figure 4.23 Typical Layers

Typically layers in an OO system

 User Interface.
 Application Logic and Domain Objects software objects representing domain
concepts (for example, a software class Sale) that fulfill application requirements,
such as calculating a sale total.
 Technical Services general purpose objects and subsystems that provide
supporting technical services, such as interfacing with a database or error logging.
These services are usually application-independent and reusable across several
systems

135

Visit & Downloaded from : www.LearnEngineering.in

UI Domain

Swing Web Sales

UI::Swing UI::Web

Swing Web
Domain::Sales
Domain

Sales

Figure 4.24 Typical Layers

5. LOGICAL ARCHITECTURE REFINEMENT

 Discuss in detail about Logical Architecture Refinement.

 Large-scale organization of software classes into packages, subsystems and
layers
 Logical — not related to actual deployment
 Big Picture
 Transition from analysis to design
 Not a deployment view (e.g. don‘t indicate MySQL or Solaris)

Logical Architecture — How Much?

 Process specific

136

Visit & Downloaded from : www.LearnEngineering.in

 Top-down (UP) puts emphasis on up-front effort in architectural design early

iterations build core architecture
 Bottom-up (XP) architecture is empirical result of effort — don‘t design for the
future

Grouping Types
 Package — Namespace — Register. Record
 Subsystem — group of packages forming a discrete engine with cohesive
responsibilities — Reports
 Layer — major subsystems — UI
 Each group should be internally cohesive and weakly coupled with outside

UML Package Diagram

Figure 4.25 UML Package Diagram

 Package
 Dependency line — large scale coupling

137

Visit & Downloaded from : www.LearnEngineering.in

Packages as Namespaces

Figure 4.25 Packages as Namespaces

Principles for Grouping Classes in Packages

 Common Closure Principle — classes in a package should need changing for

similar reasons.
 Common Reuse Principle — classes in a package should all be reused together

Clear Flow of Dependency

 Flow in one direction (with well-defined exceptions)

138

Visit & Downloaded from : www.LearnEngineering.in

 Acyclic Dependency Principle — limit cycles in the dependencies — cycles

should be localized
 Stable Dependencies Principle — the more dependencies coming into a package,
the more stable the package‘s interface needs to be (changes have greater impact)
 Stable Abstractions Principle — more stable packages tend to have a higher
proportion of interfaces and abstract classes
 Dependency relationships are not transitive — Asset Domain changes effects
Leasing Domain not Leasing Presentation
 Packages are used in many places — use a keyword, such as «global»
 General dependency notation enough

Separating Interface and Implementation

Figure 4.26 Interfaces

 Delegation / Realization
 Generalization arrow — Inheritance / sub-classing

139

Visit & Downloaded from : www.LearnEngineering.in

Layers
 Large-scale logical structure of distinct, related responsibilities
 Clean, cohesive separation of concerns
 Lower layers more general
 Higher layers more application specific
 Coupling and collaboration is from higher to lower layers

Layers — Why?
 Low coupling avoids changes rippling through system
 Separation of concerns allows for more flexibility — changing UI or changing
DBMS
 Separation of concerns allow for reuse of packages in other systems (particularly
lower layers)
 Easier division of work among teams

Model-View Separation Principle

 Do not connect or couple UI objects to non-UI objects
 Do not put application logic in the UI object methods
 Allows for changing views or having multiple views
 Allows for no-gui call to application logic

140

Visit & Downloaded from : www.LearnEngineering.in

PART - C
1.What is the relationship between logical architecture and sequence diagram.
• Logical architecture: Large-scale organization of the software classes into
– packages (or namespaces)
– subsystems
– layers
• Distinct from ―deployment architecture‖
– No decision about how the elements are deployed
• to different OS processes
• across physical computers in a network
• A layer: A coarse-grained grouping of classes, packages or subsystems that
together have responsibility for one major aspect of a system
• Examples of layers:
– UI layer
– Application logic and domain objects layer
– Technical services (interfacing with a database, error logging)
• Typically application-independent and reusable
Example:
UI

not the Java

Swing Swing libraries, but Web
our GUI classes
based on Swing

Domain

Sales Payments Taxes

Technical Services

Persistence Logging
141 RulesEngine

Visit & Downloaded from : www.LearnEngineering.in

Architecture:
• Strict layered architecture: Each layer only calls upon services of the layer directly
below it.
– Common in network protocol stacks
– Not so common in information systems
– The set of significant decisions about
• the organization of a software system
– hieararchical composition of smaller subsystems to
progressively larger subsystems
– the selection of structural elements and interfaces
• the style that guides this organization
• Architecture: Related to large scale, not implementation details.
UML Package Diagrams:
• UML Package Diagrams:
– Used to illustrate the logical architecture of a system
• Layers, subsystems, Java packages
– Provides a way to group elements
• Different from (more general than) a Java package
• Can group anything
– Classes, other packages, diagrams, use cases, …
• Nesting packages is very common

142

Visit & Downloaded from : www.LearnEngineering.in

Alternative UML Package Diagram Notations:

UI Domain

Swing Web Sales

UI::Swing UI::Web

Swing Web
Domain::Sales
Domain

Sales

Layers vs. Partitions

Domain

POS Inventory Tax

Vertical Layers
Technical Services

Persistence Security Logging

Horizontal Partitions

143

Visit & Downloaded from : www.LearnEngineering.in

UNIT V - CODING AND TESTING

Mapping design to code – Testing: Issues in OO Testing – Class Testing –

OO Integration Testing – GUI Testing – OO System Testing

PART – A
1. How will you implement the design in object oriented language?

Implementation in an object-oriented programming language requires writing

source code for:
 Class and interface definitions
 Method definitions

2. Define TDD.

 TDD – Test Driven Development.

 TDD is a software development process where the developers first writes a failing
automated test case that defines a desired improvement or new function, then
produces code to pass the test and finally refactors the new code to acceptable
standards.

3. Define Testing. What are the implications of OO testing? [ Nov/Dec 2015]

In Object Oriented Systems, testing is conducted on object oriented programs to

catch errors or to check the fitness for its intended purpose.
 Implications of composition and encapsulation
 Implications of inheritance
 Implications of polymorphism

144

Visit & Downloaded from : www.LearnEngineering.in

4. What are the levels of object oriented testing?

 Operation / Method
 Class
 Integration
 System Testing

5. Define unit.

 A unit is the smallest software component that can be compiled and executed.
 A unit is a software component that would never be assigned to more than one
designer to develop.

6. What is flattened class?

A flattened class is an original class expanded to include all attributes and

operations it inherits.

7. Define collection class.

A collection class is a container which holds a number of items in a data structure

and provides various operations to manipulate the contents of the collection.

8. Define MM- path.

A Method/Message Path (MM-Path) is a sequence of method executions linked by

messages. An MM-Path starts with a method and ends when it reaches a method which
does not issue any messages of its own.

145

Visit & Downloaded from : www.LearnEngineering.in

9. Define ASF.

An Atomic System Function (ASF) is an input port event, followed by a set of

MM-Paths, and terminated by an output port event. An atomic system function is an
elemental function visible at the system level.

10. Define EMDPNs.

An Event and Message Driven Petrinet (EMDPN) is a quadripartite directed graph

(P, D, M, In, Out) composed of four set of nodes P, D, M and S and two mappings In and
Out. EMDPN provides the needed framework for data flow analysis of object oriented
software.
 P – is a set of port events
 D – is a set of data places
 M– is a set of message places
 S– is a set of transitions
 In– is a set of ordered pairs from (P U D U M) X S
 Out – is a set of ordered pairs from S X (P U D U M)

11. What are the steps for mapping designs to code? [Nov/Dec 2015]

Process: Write source code for

 Class and interface definitions
 Method definitions

12. Distinguish between OO Integration testing and OO System testing.

[May/June 2016]

146

Visit & Downloaded from : www.LearnEngineering.in

OO Integration Testing:
 The entire system is viewed as a collection of subsystems (sets of classes)
determined during the system and object design
 Goal: Test all interfaces between subsystems and the interaction of subsystems
 The Integration testing strategy determines the order in which the subsystems
are selected for testing and integration

OO System Testing :
 Functional Testing-Validates functional requirements
 Performance Testing-Validates non-functional requirements
 Acceptance Testing-Validates clients expectations

PART – B

1. MAPPING DESIGN TO CODE

147

Visit & Downloaded from : www.LearnEngineering.in

 Describe in detail about implementation model (mapping design to code).

[April/May 2011, Nov/Dec 2013, Nov/Dec 2015, May/June 2016]

Process: Write source code for

 Class and interface definitions
 Method definitions

Design Class Diagrams

 DCDs contain class or interface names, classes, method and simple attributes.
 These are sufficient for basic class definitions.
 Elaborate from associations to add reference attributes.

Reference Attributes
 An attribute that refers to another complex objects.
 Reference Attributes are suggested by associations and navigability in a class
diagram.
 Example: A product specification reference on a Sales Line Item. So here we can
use product spec as a complex reference attribute to sales line item class.

148

Visit & Downloaded from : www.LearnEngineering.in

Figure 5.1 Mapping Design to Code

Role Names

Each end of an association is a role. Reference Attributes are often suggested by

role names. (use role names as the names of reference attributes).

Figure 5.2 Role Names

149

Visit & Downloaded from : www.LearnEngineering.in

Creating methods from Interaction Diagrams

Figure 5.3 Creating Methods from Interaction Diagrams

 Interaction Diagrams are used to specify methods.
 They give most of the details for what the method does.

Containers and Collections

 Where an object must maintain visibility to a group of other objects, such as a

group of Sales Line Items in a Sale, object-oriented languages often use an
intermediate container or collection.
 These will be suggested by a multiplicity value greater than one on a class
diagram.

150

Visit & Downloaded from : www.LearnEngineering.in

Figure 5.4 Containers and Collections

2. ISSUES IN OO TESTING

 Write briefly about various issues in OO Testing.

[Nov/Dec 2015]

A common way of testing OO software testing-by-poking-around (Binder, 1995).

In this case the developer's goal is to show that the product can do something useful
without crashing. Attempts are made to "break" the product. If and when it breaks, the
errors are fixed and the product is then deemed "tested". Testing-by-poking-around
method of testing OO software is, in my opinion, as unsuccessful as random testing of
procedural code or design. It leaves the finding of errors up to a chance.
Another common problem in OO testing is the idea that since a superclass has
been tested, any subclasses inheriting from it don't need to be. This is not true because by
defining a subclass we define a new context for the inherited attributes. Because of
interaction between objects, we have to design test cases to test each new context and re-
151

Visit & Downloaded from : www.LearnEngineering.in

test the superclass as well to ensure proper working order of those objects. Yet another
misconception in OO is that if you do proper analysis and design (using the class
interface or specification), you don't need to test or you can just perform black-box
testing only.
However, function tests only try the "normal" paths or states of the class. In order
to test the other paths or states, we need code instrumentation. Also it is often difficult to
exercise exception and error handling without examination of the source code.
Testing in an OO context must address the basics of testing a base class and the
code that uses the base class. Factors that affect this testing are inheritance and dynamic
binding. Therefore, some systems are harder to test (e.g., systems with inheritance of
implementations harder than inheritance of interfaces) and OO constructs such as
inheritance and dynamic binding may serve to hide faults
Use the OO Metrics techniques to assess the design and identify areas that need
special attention in testing for adequate coverage. For example, depth of tree complicates
testing and number of methods that have to be tested in a class and a lack of cohesion in
methods means more tests to ensure there are no side effects among the disjoint methods.

OO Testing Strategies
While there are efforts underway to develop more automated testing processes
from test models of the object model characteristics (for example states, data flows, or
associations), testing is still based on the creation of test cases and test data by team
members using a structural (White Box Testing) and/or a functional.

Strategies for Selecting Test Cases

Preparing Test Cases and Scenarios discusses strategies for test cases. Two
common strategies to select test cases are based on an assessment of "likely faults" and
"likely usage."
Likely faults - These types of tests are based on practical experience of areas in which
errors are most likely to occur (e.g., certain syntax in a particular programming language

152

Visit & Downloaded from : www.LearnEngineering.in

or boundaries like beginning and end conditions). Checklists may be developed for types
of applications or development environments. These help formalize this process and
ensure more consistency and coverage in developing these types of tests.
Likely usage - These tests test to exercise the system in the ways that the user of the
system will be likely to use the system. Or they aim to test "completely" the elements of
the system most likely to be used. These strategies apply to each type of test (structural or
functional). Derive the plan and the test cases to test the system sufficiently for it to be
effective, i.e., to conform to its acceptance criteria.

Levels of Testing
Within the development life cycle, testing can occur at different levels: unit test,
integration test, and system or acceptance tests.

Unit - Here the unit is a class, often a "bigger" or more complex thing than a procedural
unit which may be a single function or sub-routine. Complicated by inheritance,
encapsulation, and dynamic binding. A unit test is more complicated and more effective
in the overall system than with procedural unit tests.

Integration - Focus on interactions among classes. Complicated by dynamic binding.

Recommended that unit be integrated in an incremental fashion, a few at a time, not one
―big bang‖ integration of the system units. This approach lets interface problems be
detected as early as possible but may complicate the design of a test since the cluster of
units may not correspond neatly to a functional grouping. When the integration units
don‘t comprise a functional grouping, the test may, of necessity, focus on structural
issues.

Acceptance - Largely functional based tests. Ensure that all of the use cases appear in a
test. Weight the tests to the most important functionality.

153

Visit & Downloaded from : www.LearnEngineering.in

3. OO INTEGRATION TESTING

 Explain the Concept of OO integration testing

[May/June 2016]

Integration of object-oriented system is a complex task. One of the major strengths

of object-oriented programming is the possibility of building independently manageable
blocks (i.e., classes), which can be combined to obtain the whole system. A well designed
objectoriented application is composed of simple building blocks assembled together.
Therefore, in object-oriented systems the complexity tends to move from modules to
interfaces between modules, i.e., from units to interactions among them. If for traditional
imperative language 40% of software errors can be traced to integration problems , we
could expect percentage to be much higher in object-oriented software.
The rest of this chapter is organized as follows. we illustrate the different levels of
integration testing of object-oriented systems. we discuss how traditional integration
strategies can be adapted to the object-oriented case and present different approaches
proposed so far for object-oriented integration testing. we propose an integration strategy
that takes into account the different relations between classes, and combine them to
identify a suitable order of integration for either bottom up or top-down integration.
Finally we classify possible object oriented integration errors with respect to errors
occurring in traditional software, and identify which errors can be considered specific to
the object oriented case and require new techniques to be addressed.

Levels
Integration testing as the activity of exercising interactions among units. While for
traditional software there is a general consensus on considering single procedures as
units, the definition of the elemental unit for object-oriented systems is not
straightforward. Even though it would still be possible to treat methods as units, most

154

Visit & Downloaded from : www.LearnEngineering.in

authors agree on considering unproductive treating anything smaller than a class as an

independent unit.
A well-designed class is a strongly cohesive entity, and the test driver that would
be required to test individual methods would essentially be a reinvention of the class.
Provided that classes can be considered as the basic units of object-oriented systems,
object-oriented integration testing aims at verifying whether classes (more precisely, their
instances) cooperate as expected. Such activity is also referred to as interclass level
testing.
In general, it is possible to consider different and more sophisticated levels of
integration for object-oriented programs. Due to the particular structure of object oriented
systems, the simple distinction between intra and interclass testing may lack the
expressiveness required for precisely representing the different aspects of integration. In
literature, different classifications of testing levels have been proposed, and the same
terms have been used for identifying different concepts in different contexts. To avoid
misunderstanding, in the rest of this work we refer to the following terminology:

Inter-class testing: testing of any set of cooperating classes, aimed at verifying that
involved classes correctly interact. There are no constraint on how these classes are
selected.

Intra-cluster testing (or cluster testing): testing of the interactions between the
different classes belonging to a subset of the system having some specific properties (a
cluster). Usually, a cluster is composed of cooperating classes providing particular
functionalities (e.g., all the classes which can be used to access the file-system, or the
classes composing a Java package). Clusters should provide a well-defined interface, i.e.,
their interfaces should be well understood and they should mutually interact only by
means of their interfaces.

155

Visit & Downloaded from : www.LearnEngineering.in

Inter-cluster testing: testing of the interactions between already tested clusters. The
result of the integration of all clusters is the whole system.

Integration testing: a general way of indicating any of the above.

Integration Strategies
As stated in main traditional integration testing strategies can be classified as top-
down integration, bottom-up integration, big-bang integration, threads integration, and
critical modules integration. Some of these strategies can be suitably tailored for object-
oriented systems, while some other might not be applicable in this context. In the
following we reconsider these strategies in an object-oriented environment

Top-down and Bottom-up Strategies

Top-down and bottom-up integration strategies are still applicable to object-
oriented systems, provided that we correctly identify dependencies among classes. Unlike
traditional procedural languages, where the identification of the use relation among
modules is straightforward, object-oriented systems are characterized by several different
relations which can hold between classes. These relations have to be taken into account,
and more subtle interactions between units have to be considered, with respect to the
traditional case. A class can depend on another class even if it does not ―use‖ it in the
traditional sense of the term.
As an example, let us consider a class together with its elements of type, which
represent a typical case of aggregation relation. In this case, objects of class contains
objects of class but they might never invoke any of their methods (i.e., might never ―use‖
them). Nevertheless, the presence of class is necessary for class to be instantiated (to be
tested). The same holds for hierarchical relations. A subclass cannot be tested in the
absence of its ancestors.
The main problem when applying this strategies to object-oriented systems is
related to the presence of cyclic dependencies among classes. In the presence of cycles, it

156

Visit & Downloaded from : www.LearnEngineering.in

is impossible to find an integration order for bottomup (resp., top-down) strategies which
allows for avoiding the construction of stubs (resp., drivers). In its incremental
integration strategy, Overbeck [66] provides a detailed analysis of integration testing and
a bottom-up integration strategy addressing the problem of cyclic dependencies.
The approach is based on test patterns, defined according to relationships between
client and server classes and by taking into account inheritance relationships. Two basic
level of testing are identified: unit test (performed by means of self-test suites) and
pairwise interclass test (performed by means of contract-test suites). Overbeck addresses
the problem of cyclic dependencies within a system by means of stubs which are used to
break cycles. To minimize the cost of scaffolding, attention is paid to accurately select
which classes have to be replaced by stubs. Kung proposes a technique for defining the
integration order when testing an object-oriented system.
The technique is based on a program representation called the Object Relation
Diagram (ORD). This diagram contains information about the classes composing the
system and the relations between them. In order to address the problem of cycles, Kung
proposes a technique based on the breaking of cycles. The author asserts that every cycle
must contain at least one association, whose elimination allows for breaking that cycle.
When the testing has been completed, the association may be reintroduced and
tested. Even though the proposed solution is interesting, the author does not provide any
evidence supporting his assertion about the inevitable presence of associations within
cycles. Moreover, no explanation is provided about how association elimination can be
accomplished.

Big-bang Strategies
Big-bang integration strategies can be straightforwardly applied by just pulling all
the objects composing a system together and exercising the whole resulting system. We
consider this approach to be applicable only to small systems, composed of a few classes.
In accordance to Siegel‘s experience

157

Visit & Downloaded from : www.LearnEngineering.in

we expect such an approach to be ruinous in the general case. Due to the complexity of
the interactions among objects, integration should aim at minimizing the number of
interfaces exercised at once. Localization of faults by means of debugging can become
prohibitive, in the case of a whole system whose components‘ interactions have never
been exercised on smaller subsets.

Threads Integration
Threads integration strategies can be adapted to object-oriented systems as
follows. As long as we consider object-oriented systems as sets of cooperating entities
exchanging messages, threads can be naturally identified with sequences of subsequent
message invocations. Therefore, a thread can be seen as a scenario of normal usage of an
object-oriented system. Testing a thread implies testing interactions between classes
according to a specific sequence of method invocations. This kind of technique has been
applied by several authors. Kirani and Tsai propose a technique for generating test cases
from functional specification for module and integration testing of object-oriented
systems.
The method aims at generating test cases that exercise specific combinations of
method invocations and provides information on how to choose classes to be integrated.
A similar approach is proposed by Jorgensen and Erickson, which introduce the notion of
method-message path (MM-path), defined as a sequence of method executions linked by
messages. For each identified MM-path, integration is performed by pulling together
classes involved in the path and exercising the corresponding message sequence. More
precisely, Jorgensen and Erickson identify two different levels for integration testing.

Message quiescence: This level involves testing a method together with all methods it
invokes, either directly or transitively.

Event quiescence: This level is analogous to the message quiescence level, with the
difference that it is driven by system level events. Testing at this level means exercising

158

Visit & Downloaded from : www.LearnEngineering.in

message chains (threads), such that the invocation of the first message of the chain is
generated at the system interface level (i.e., the user interface) and, analogously, the
invocation of the last message results in event which can be observed at the system
interface level.
An end-to-end thread is called an atomic system function (ASF) The main
drawback of this method is the difficulty in the identification of ASFs, Which requires
either the understanding of the whole system or an analysis of the source code. McGregor
and Korson propose a strategy called wave front integration, based on a specific
development technique. Developers reach an agreement on the functionality to be
achieved for each component during each integration. To achieve such functionality all
involved classes must provide a subset of their features. Therefore, development proceeds
across all of the classes at the same time.
This approach can be considered a variation of the threads integration strategies,
characterized by development and testing being tightly coupled. The main drawback of
this approach is that it requires much communications among different teams. Its main
advantage is the little need for scaffolding.

Critical Integration
We do not see many differences between critical integration for traditional and
object-oriented systems. As long as the characteristics of the system under test require it
to be integrated according to some criticality related criterion, and it is possible to order
classes according to their criticality level, this strategy can be applied by simply
integrating more critical classes first. This strategy is usually very costly in terms of
scaffolding production.

4. OO SYSTEM TESTING

 Explain OO System testing with a neat sketch.

[May/June 2016]
159

Visit & Downloaded from : www.LearnEngineering.in

System Testing (ST) is a black box testing technique performed to evaluate the
complete system the system's compliance against specified requirements. In System
testing, the functionalities of the system are tested from an end-to-end perspective.

System Testing is usually carried out by a team that is independent of the

development team in order to measure the quality of the system unbiased. It includes
both functional and Non-Functional testing.

Types of System Tests:

System Under Test (SUT)

System under test (SUT) refers to a system that is being validated by the testers. The
terminology is also known as application under test.

The System Under Test (SUT) also corresponds to a software that is matured and has
gone through unit and integration testing.

System testing of software or hardware is testing conducted on a complete, integrated

system to evaluate the system's compliance with its specified requirements. System
testing falls within the scope of black box testing, and as such, should require no
knowledge of the inner design of the code or logic. [1]

160

Visit & Downloaded from : www.LearnEngineering.in

Figure 5.5 Types of System Tests

As a rule, system testing takes, as its input, all of the "integrated" software components
that have passed integration testing and also the software system itself integrated with
any applicable hardware system(s). The purpose of integration testing is to detect any
inconsistencies between the software units that are integrated together
(called assemblages) or between any of the assemblages and the hardware. System
testing is a more limited type of testing; it seeks to detect defects both within the "inter-
assemblages" and also within the system as a whole.

Testing the whole System

System testing is performed on the entire system in the context of a Functional

Requirement Specification(s) (FRS) and/or aSystem Requirement Specification (SRS).
System testing tests not only the design, but also the behaviour and even the believed
expectations of the customer. It is also intended to test up to and beyond the bounds
defined in the software/hardware requirements specification(s).

161

Visit & Downloaded from : www.LearnEngineering.in

Approach for System Testing:

System testing is performed when integration testing is completed.

System testing is mainly a black box type testing. This testing evaluates working of
system from user point of view, with the help of specification document. It does not
require any internal knowledge of system like design or structure of code.

Figure 5.6 System Tests

System Testing contains functional and non-functional areas of application/product.

5. GUI TESTING

 Illustrate the concept of GUI testing.

[May/June 2016]

GUI testing is a process to test application's user interface and to detect if

application is functionally correct. GUI testing involves carrying set of tasks and
comparing the result of same with the expected output and ability to repeat same set of
tasks multiple times with different data input and same level of accuracy.

162

Visit & Downloaded from : www.LearnEngineering.in

GUI Testing includes how the application handles keyboard and mouse events,
how different GUI components like menu bars, toolbars, dialogs, buttons, edit fields, list
controls, images etc. reacts to user input and whether or not it performs in the desired
manner. Implementing GUI testing for your application early in the software
development cycle speeds up development improves quality and reduces risks towards
the end of the cycle. GUI Testing can be performed both manually with a human tester or
could be performed automatically with use of a software program.
Every software organization tests its softwares, still the end product always have
some issues left. Testing team tries their best to find all the bugs before release of the
software but still there are issues left in the product and they often re-appear as new
modules are added to the software. Even the best of manual testing process struggle to
deliver effective, efficient, accurate and increased test coverage.
Manual testing is often error prone and there are chances of most of the test
scenarios left out. Also with the project in development phase where source code changes
appear every other day, manually keeping up with the pace to test each and every feature
is a difficult task. More often then not the newly added features would bring regression
along with them, so to accurately cover all the old test cases (manually) are very time
consuming and error prone.
Automated GUI Testing is use of software program to detect if your desktop
application is functionally correct. Automated GUI Testing includes automating manual
testing tasks which are mostly time consuming and error prone. Automated GUI Testing
is a more accurate, efficient, reliable and cost effective replacement to manual testing.
Automated GUI Testing involves carrying set of tasks automatically and comparing the
result of same with the expected output and ability to repeat same set of tasks multiple
times with different data input and same level of accuracy. Implementing GUI Testing for
your application early in the software development cycle speeds up development,
improves quality and reduces risks towards the end of the cycle.
Automated GUI Testing is a solution to all the issues raised with Manual GUI
Testing. An Automated GUI Testing tool can playback all the recorded set of tasks,

163

Visit & Downloaded from : www.LearnEngineering.in

compare the results of execution with the expected behavior and report success or failure
to the test engineers. Once the GUI tests are created they can easily be repeated for
multiple number of times with different data sets and can be extended to cover additional
features at a later time.
Most of the software organizations consider GUI Testing as critical to their
functional testing process and there are many things which should be considered before
selecting an Automated GUI Testing tool. A company can make great strides using
functional test automation. The important benefits include, higher test coverage levels,
greater reliability, shorted test cycles, ability to do multi user testing at no extra cost, all
resulting in increased levels of confidence in the software.

GUI Testing with AppPerfect

AppPerfect offers GUI Testing solution in form of AppPerfect App Test.

AppPerfect App Test is found to be most affordable, cost effective, efficient, reliable and
accurate solution by its customers.

Designing Test Scripts for GUI Testing:

One of the most important aspects in successfully implementing GUI Testing is

designing the test cases. Before recording your test scripts you should be ready with the
Test Plan for same. You should have the list of modules documented which you would
like to test in your application.
Once you have figured out the modules to test, pick each module and list down the
features to test for that module, Once you have identified the features, design test cases
for each of the feature to test. For each of the test case, define the data set with which you
will like to parameterize your test case.

164

Visit & Downloaded from : www.LearnEngineering.in

Also define the validations you will like to perform for your test case.
Once you are ready with the test plan, you can start creating Test Scripts for each of the
identified modules.
 Creating new project is an easy one step process. Just start AppPerfect App Test
product and select File -> New.. menu option to create a New GUI Testing
project. For details on New Project creation refer to Creating a New
Project chapter. For details on configuring project properties refer to Setting
Project Properties chapter.
 You can now start creating New Groups for each of the feature you have identified
in the current module under test. To create a new Group just select Project Node in
the Editor tree, and right click and select the option Add Group... from the popup
menu. Provide descriptive name for the group clearly stating what feature this
group is going to implement.
 AppPerfect supports two kinds of Groups. For Java Applications you can create
Java Type Group and for Windows/desktop GUI application you need to create
Windows Group. In case of Windows Application Group you need to provide with
executable path for your application. In case of Java Group you need to provide
Main class, classpath and other environment settings required to start the Java
application.
 This way you can functionally structure your test scripts where each test project
will represent one functional module for your application and each Group in the
Test Project will represent one test case or feature in the module to test. Properly
structuring and designing test scripts early in testing cycle will help maintenance
process easy over longer run. Properly designing and grouping test cases in
different groups will help increase re-usability of groups across different test
scripts. In case some of the actions are common and are required to be processed
in new test scripts, you can just link or import already existing groups instead of
re-recording them all over again in new scripts.

165

Visit & Downloaded from : www.LearnEngineering.in

Figure 5.7 Add Groups

Easy-to-use Test Recorder helps Automating Tests instantly:

AppPerfect's GUI Testing tool does not require programming or scripting skills and
allows even non-technical and inexperienced testers start automating tests instantly. We
provide easy to use Test Recorder which records each event or action as you interact with
your application.

 To start recording test just select the Project -> Record Test... menu option. This
will launch the Test Recording dialog. select the Group in which you need to
record.

 Click on Start Recording button and you are ready to record your test. Test
Recorder will take care of launching your application and you are all set to record
your test case. Just do the actions you intend to record and Test Recorder will
capture all the actions you perform on your Windows or Java application. For

166

Visit & Downloaded from : www.LearnEngineering.in

details on Test Recording refer to Recording an App Test chapter.

Figure 5.8 Test Recording

 Once you are done recording, you can browse though the recorded test in Editor
view. AppPerfect's Test Recorder takes care of recording all the steps you
performed on your application along with all the windows and images in your
desktop application. The recorded test script is object-based, making GUI Testing
stable and increases the usability of recorded scripts as your target application
evolves / changes.

 Application simulates recorded actions by finding the elements based on recorded

attributes of the element like window's class, name, text etc. rather than using
167

Visit & Downloaded from : www.LearnEngineering.in

screen-coordinates. The actual user actions are simulated using Low-level

keypress and mouse events.

PART - C
1. Illustrate the concept of Class testing.
[May/June 2016]
The shift from traditional to object-oriented environment involves looking at and
reconsidering old strategies and methods for testing the software. The traditional
programming consists of procedures operating on data, while the object-oriented
paradigm focuses on objects that are instances of classes.
In object-oriented (OO) paradigm, software engineers identify and specify the objects
and services provided by each object. In addition, interaction of any two objects and
constraints on each identified object are also determined. The main advantages of OO
paradigm include increased reusability, reliability, interoperability, and extendibility.

With the adoption of OO paradigm, almost all the phases of software development
have changed in their approach, environments, and tools. Though OO paradigm helps
make the designing and development of software easier, it may pose new kind of
problems. Thus, testing of software developed using OO paradigm has to deal with the
new problems also. Note that object-oriented testing can be used to test the object-
oriented software as well as conventional software.

OO program should be tested at different levels to uncover all the errors. At the
algorithmic level, each module (or method) of every class in the program should be tested
in isolation. For this, white-box testing can be applied easily. As classes form the main
unit of object-oriented program, testing of classes is the main concern while testing an
OO program.

At the class level, every class should be tested as an individual entity. At this level,
programmers who are involved in the development of class conduct the testing. Test
cases can be drawn from requirements specifications, models, and the language used. In

168

Visit & Downloaded from : www.LearnEngineering.in

addition, structural testing methods such as boundary value analysis are extremely used.
After performing the testing at class level, cluster level testing should be performed.

As classes are collaborated (or integrated) to form a small subsystem (also known as
cluster), testing each cluster individually is necessary. At this level, focus is on testing the
components that execute concurrently as well as on the interclass interaction. Hence,
testing at this level may be viewed as integration testing where units to be integrated are
classes. Once all the clusters in the system are tested, system level testing begins. At this
level, interaction among clusters is tested.

Usually, there is a misconception that if individual classes are well designed and have
proved to work in isolation, then there is no need to test the interactions between two or
more classes when they are integrated. However, this is not true because sometimes there
can be errors, which can be detected only through integration of classes. Also, it is
possible that if a class does not contain a bug, it may still be used in a wrong way by
another class, leading to system failure.

Developing Test Cases in Object-oriented Testing

The methods used to design test cases in OO testing are based on the conventional
methods. However, these test cases should encompass special features so that they can be
used in the object-oriented environment. The points that should be noted while
developing test cases in an object-oriented environment are listed below.

 It should be explicitly specified with each test case which class it should test.
 Purpose of each test case should be mentioned.
 External conditions that should exist while conducting a test should be clearly
stated with each test case.
 All the states of object that is to be tested should be specified.
 Instructions to understand and conduct the test cases should be provided with each
test case.

169

Visit & Downloaded from : www.LearnEngineering.in

Object-oriented Testing Methods

As many organizations are currently using or targeting to switch to the OO paradigm, the
importance of OO software testing is increasing. The methods used for performing
object-oriented testing are discussed in this section.

Figure 5.9 OO Testing methods

State-based testing is used to verify whether the methods (a procedure that is executed by
an object) of a class are interacting properly with each other. This testing seeks to
exercise the transitions among the states of objects based upon the identified inputs.

For this testing, finite-state machine (FSM) or state-transition diagram representing the
possible states of the object and how state transition occurs is built. In addition, state-
based testing generates test cases, which check whether the method is able to change the
state of object as expected. If any method of the class does not change the object state as
expected, the method is said to contain errors.

To perform state-based testing, a number of steps are followed, which are listed below.

1. Derive a new class from an existing class with some additional features, which are
used to examine and set the state of the object.

170

Visit & Downloaded from : www.LearnEngineering.in

2. Next, the test driver is written. This test driver contains a main program to create
an object, send messages to set the state of the object, send messages to invoke methods
of the class that is being tested and send messages to check the final state of the object.
3. Finally, stubs are written. These stubs call the untested methods.

Fault-based Testing

Fault-based testing is used to determine or uncover a set of plausible faults. In other

words, the focus of tester in this testing is to detect the presence of possible faults. Fault-
based testing starts by examining the analysis and design models of OO software as these
models may provide an idea of problems in the implementation of software. With the
knowledge of system under test and experience in the application domain, tester designs
test cases where each test case targets to uncover some particular faults.

The effectiveness of this testing depends highly on tester experience in application

domain and the system under test. This is because if he fails to perceive real faults in the
system to be plausible, testing may leave many faults undetected. However, examining
analysis and design models may enable tester to detect large number of errors with less
effort. As testing only proves the existence and not the absence of errors, this testing
approach is considered to be an effective method and hence is often used when security
or safety of a system is to be tested.

Integration testing applied for OO software targets to uncover the possible faults in both
operation calls and various types of messages (like a message sent to invoke an object).
These faults may be unexpected outputs, incorrect messages or operations, and incorrect
invocation. The faults can be recognized by determining the behavior of all operations
performed to invoke the methods of a class.

Scenario-based Testing

Scenario-based testing is used to detect errors that are caused due to incorrect
specifications and improper interactions among various segments of the software.
Incorrect interactions often lead to incorrect outputs that can cause malfunctioning of

171

Visit & Downloaded from : www.LearnEngineering.in

some segments of the software. The use of scenarios in testing is a common way of
describing how a user might accomplish a task or achieve a goal within a specific context
or environment. Note that these scenarios are more context- and user specific instead of
being product-specific. Generally, the structure of a scenario includes the following
points.

 A condition under which the scenario runs.

 A goal to achieve, which can also be a name of the scenario.
 A set of steps of actions.
 An end condition at which the goal is achieved.
 A possible set of extensions written as scenario fragments.

Scenario- based testing combines all the classes that support a use-case (scenarios are
subset of use-cases) and executes a test case to test them. Execution of all the test cases
ensures that all methods in all the classes are executed at least once during testing.
However, testing all the objects (present in the classes combined together) collectively is
difficult. Thus, rather than testing all objects collectively, they are tested using either top-
down or bottom-up integration approach.

This testing is considered to be the most effective method as scenarios can be organized
in such a manner that the most likely scenarios are tested first with unusual or exceptional
scenarios considered later in the testing process. This satisfies a fundamental principle of
testing that most testing effort should be devoted to those paths of the system that are
mostly used.

Challenges in Testing Object-oriented Programs

Traditional testing methods are not directly applicable to OO programs as they involve
OO concepts including encapsulation, inheritance, and polymorphism. These concepts
lead to issues, which are yet to be resolved. Some of these issues are listed below.

1. Encapsulation of attributes and methods in class may create obstacles while

testing. As methods are invoked through the object of corresponding class, testing cannot

172

Visit & Downloaded from : www.LearnEngineering.in

be accomplished without object. In addition, the state of object at the time of invocation
of method affects its behavior. Hence, testing depends not only on the object but on the
state of object also, which is very difficult to acquire.
2. Inheritance and polymorphism also introduce problems that are not found in
traditional software. Test cases designed for base class are not applicable to derived class
always (especially, when derived class is used in different context). Thus, most testing
methods require some kind of adaptation in order to function properly in an OO
environment.

173

Visit & Downloaded from : www.LearnEngineering.in

INDUSTRY CONNECTIVITY AND LATEST DEVELOPMENTS

 Design and implementation of Object Oriented Analysis and Design.

 Object-oriented modeling (OOM) is a common approach to modeling
applications, systems, and business domains by using the object-oriented
paradigm throughout the entire development life cycles. OOM is a main
technique heavily used by both OOA and OOD activities in modern software
engineering.
 Provides a tool set for supporting a software engineering process
 Allows greater participation in the design process

174

Visit & Downloaded from : www.LearnEngineering.in

175

Visit & Downloaded from : www.LearnEngineering.in

UNIVERSITY QUESTION PAPERS

Anna University
B.E./B.Tech. DEGREE EXAMINATION, APRIL/MAY 2011.
Sixth Semester
Computer Science and Engineering
CS 2353—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. What is Object Oriented Analysis and Design? [Pg.No: 5]

2. Define the inception step.
3. What is a Domain Model? [Pg.No: 67]
4. Define Aggregation and Composition. [Pg.No: 97]
5. What is the use of System sequence diagram? [Pg.No: 95]
6. List the relationships used in class diagram. [Pg.No: 96]
7. What is Design Pattern? [Pg.No: 31]
8. Define Coupling. [Pg.No: 32]
9. What is the use of operation contracts?
10. Give the meaning of Event, State and Transition. [Pg.No: 8]

PART B—(5 × 16 = 80marks)

11. (a) Briefly explain the different phases of Unified Process. [Pg.No:10] (16)
Or

176

Visit & Downloaded from : www.LearnEngineering.in

(b) Explain with an example, how use case modeling is used to describe functional
requirements. Identify the actors, scenario and use cases for the example.
[Pg.No: 15] (16)

12. (a) Describe the strategies used to identify conceptual classes. Describe the steps to
create a domain model used for representing conceptual classes. [Pg.No: 82] (16)
Or
13. (b) Explain about activity diagram with an example. [Pg.No: 21] (16)

14. (a) Illustrate with an example, the relationship between sequence diagram and use
cases. [Pg.No: 100] (16)
Or
15. (b)Explain with an example Interaction diagram. [Pg.No: 112] (16)

16. (a) Explain about GRASP Patterns. [Pg.No: 35] (16)

Or
17. (b) Write short notes on adapter, singleton, factory and observer patterns.
[Pg.No: 52] (16)

18. (a) Explain about implementation model (mapping design to code). [Pg.No: 134] (16)
Or
(b) Discuss about UML deployment and component diagrams. Draw the diagrams for
a banking application. [Pg.No: 25] (16)

177

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, NOVEMBER/DECEMBER 2011.
Sixth Semester
Computer Science and Engineering
CS 2353—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. List out any four reasons for the complexity of software.

2. What do you mean by use cases and actors? [Pg.No: 6]
3. Give the hint to identify the attributes of a class.
4. Define swim lane. [Pg.No: 98]
5. What do you mean by sequence diagram? Mention its use. [Pg.No:65]
6. What do you mean by sequence number in UML? Where and for what it issued?
[Pg.No: 97]
7. Distinguish between coupling and cohesion. [Pg.No: 5]
8. Write a note on Patterns. [Pg.No: 31]
9. Define component with an example. [Pg.No: 34]
10. How will you reflect the version control information in UML diagram? [Pg.No: 99]

PART B—(5 × 16 = 80marks)

11. (a) What do you mean by Unified Process in OOAD? Explain the phases with suitable
diagrams. [Pg.No: 10] (16)
Or

178

Visit & Downloaded from : www.LearnEngineering.in

(b) By considering the Library Management system, perform the Object Oriented
System Development and give the use case model for the same (use include,
extend and generalization). [Pg.No: 77] (16)

12. (a) Explain the relationships that are possible among the classes in the UML
representation with your own example. (16)
Or
(b) Explain the following with an example :
(i) Conceptual class diagram [Pg.No: 82]
(ii) Activity Diagram. [Pg.No: 21] (8 + 8)

13. (a) With a suitable example explain how to design a class. Give all possible
representation in a class (name, attribute, visibility, methods, and responsibilities).
[Pg.No: 100] (16)
Or
(b) What do you mean by interaction diagrams? Explain them with a suitable
example. [Pg.No: 112] (16)

14. (a) What is GRASP? Explain the design patterns and the principles used in it.
[Pg.No: 35] (16)
Or
(b) What is design pattern? Explain the GoF design patterns. [Pg.No: 36,52] (16)

15. (a) Explain the state chart diagram with a suitable example. Also define its
components and use. [Pg.No: 17] (16)
Or
(b) Consider the Hospital Management System application with the following
requirements

179

Visit & Downloaded from : www.LearnEngineering.in

(i) System should handle the in-patient, out-patient information through

receptionist.
(ii) Doctors are allowed to view the patient history and give their prescription.
(iii) There should be a information system to provide the required
information. Give the state chart, component and deployment diagrams.
(6 + 6 + 4)

180

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, MAY/JUNE 2012
Sixth Semester
Computer Science and Engineering
CS 2353—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. What is UML? [Pg.No: 6]

2. List the relationships used in use cases. [Pg.No: 67]
3. What is Elaboration? [Pg.No: 5]
4. Define Aggregation and Composition. [Pg.No: 97]
5. What is the use of System sequence diagram? [Pg.No: 95]
6. Define package and draw the UML notation for Package. [Pg.No: 95]
7. When to use Patterns? [Pg.No: 31]
8. Define Coupling. [Pg.No: 32]
9. What is the use of Component diagram? [Pg.No: 6]
10. Give the meaning of Event, State and Transition. [Pg.No: 7]

PART B—(5 × 16 = 80marks)

11. (a) Explain the different phases of Unified Process. [Pg.No: 10] (16)
Or
(b) Explain with an example, how use case modeling is used to describe functional

181

Visit & Downloaded from : www.LearnEngineering.in

requirements. Identify the actors, scenario and use cases for the example.
[Pg.No: 15] (16)

12. (a) Describe the strategies used to identify conceptual classes. Describe the steps to
create a domain model used for representing conceptual classes. [Pg.No: 82] (16)
Or
(b) When to use Activity diagrams? Describe the situations with an example .
[Pg.No: 21] (16)

13. (a) Compare Sequence Versus Collaboration diagram with suitable example.
(16)
Or
(b)
(i) Describe the UML notation for class diagram with an example. [Pg.No: 100] (8)
(ii) Explain the concept of Link, Association, and Inheritance. (8)

14. (a) (i) Explain the concept of creator. [Pg.No: 52] (7)
(ii) Explain about Low coupling, Controller and High Cohesion. [Pg.No: 39] (3x3=9)
Or
(b) Write short notes on adapter, singleton, factory and observer patterns.
[Pg.No: 52] (4 x 4 = 16)

15. (a) Explain about Operation Contracts. (16)

Or
(b) Discuss about UML deployment and component diagrams with suitable example.
[Pg.No: 25] (16)

182

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, APRIL/MAY 2013.
Sixth Semester
Computer Science and Engineering
CS 2353—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. Define domain model. [Pg.No: 67]

2. What are the three perspectives to apply UML? [Pg.No: 6]
3. What is conceptual category list?
4. What is subclass conformance?
5. What are the strength and weakness of sequence and communication diagrams?
[Pg.No: 98]
6. What are the tiers, layers, and partitions? [Pg.No: 97]
7. Define patterns and Design patterns. [Pg.No: 31]
8. Explain the two types of responsibilities in object design. [Pg.No: 32]
9. What is transition action?
10. What is system operation?

PART B—(5 × 16 = 80marks)

11. (a) Explain with an example, how use case modeling is used to describe functional

183

Visit & Downloaded from : www.LearnEngineering.in

requirements. Identify the actors, scenario, and use cases for the example.
[Pg.No: 15] (16)
Or.
(b) (i) What are the sample inception artifacts? (8)
(ii) What are the types and categories of requirements? (8)

12. (a) Discuss in detail three strategies to find conceptual classes? [Pg.No: 82] (16)
Or
(b) What are the guidelines used to partition the classes in the domain model to be
organized into packages? Explain with suitable examples. (16)

13. (a) Illustrate with an example, the relationship between sequence diagram and use
cases. [Pg.No: 81] (16)
Or
(b) Explain with an example features of Common Class Diagram Notation.
[Pg.No: 100] (16)

14. (a) (i)What are the artifact inputs and their relationships to object design?
(8)
(ii) What is the connection between responsibilities, GRASP, and UML diagrams?
(8)
Or
(b) Explain in detail with examples the patterns a) Creator b) Controller and c) High
Cohesion [Pg.No: 39] (16)

15. (a) What is a component diagram? Draw a component diagram and explain its
features. [Pg.No: 25] (16)
Or
(b) Explain UI navigation modeling with State machine diagram. [Pg.No: 17] (16)

184

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, NOVEMBER/DECEMBER 2013.
Sixth Semester
Computer Science and Engineering
CS 2353—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. What is Object Oriented Analysis and Design? [Pg.No: 5]

2. Define Use case. [Pg.No: 6]
3. What is Domain model? [Pg.No: 67]
4. Define Aggregation and Composition. [Pg.No: 97]
5. What is the use of UML Package Diagram? [Pg.No: 95]
6. List the relationships used in class diagram. [Pg.No: 96]
7. State the use of Design pattern. [Pg.No: 31]
8. Define Coupling. [Pg.No: 32]
9. How do you represent a node in a Deployment diagram? What kind of information
can appear in a node? [Pg.No: 7]
10. Give the meaning of Event, State and Transition. [Pg.No: 7]

PART B—(5 × 16 = 80marks)

11. (a) Briefly explain the different phases of Unified Process. [Pg.No: 10] (16)
Or

185

Visit & Downloaded from : www.LearnEngineering.in

(b) Explain with an example, how use case modeling is used to describe functional
requirements. Identify the actors, scenario and use cases for the example.
[Pg.No: 15] (16)

12. (a) Describe the strategies used to identify conceptual classes. Describe the steps to
create a domain model used for representing conceptual classes.[Pg.No: 82] (16)
Or
(b) Explain about UML activity diagram with an example. [Pg.No: 21] (16)

13. (a) Illustrate with an example, the relationship between sequence diagram and use
cases. [Pg.No: 100] (16)
Or
(b) Explain with an example how interaction diagrams are used to model the dynamic
aspects of a system. [Pg.No: 112] (16)

14. (a) Explain GRASP designing objects with responsibilities. [Pg.No: 35] (16)
Or
(b) Write short notes on adapter, singleton, factory and observer patterns.
[Pg.No: 52] (16)

15. (a) Explain UML State machine diagrams and modeling. [Pg.No: 17] (16)
Or
(b) Write short notes on the following.
(i) Operation contracts (6)
(ii) Implementation model (Mapping Design to Code) [Pg.No: 122] (10)

186

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, MAY/JUNE 2014
Sixth Semester
Computer Science and Engineering
CS 2353—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. What is the need for modeling? [Pg.No: 5]

2. What is Object Oriented Analysis and Design? [Pg.No: 5]
3. What is Elaboration? [Pg.No: 6]
4. Define Aggregation and Composition. [Pg.No: 97]
5. What is the use of System sequence diagram? [Pg.No: 95]
6. List the relationships used in class diagram. [Pg.No: 95]
7. What is Design Pattern? [Pg.No: 31]
8. What is meant by Low Coupling. [Pg.No: 32]
9. Give the use of UML State diagram? [Pg.No: 8]
10. When are Contracts Useful?

PART B—(5 × 16 = 80marks)

11. (a) List various UML diagrams and explain the purpose of each diagram.
[Pg.No: 17] (16)
Or
(b) Explain with an example, how use case modeling is used to describe functional

187

Visit & Downloaded from : www.LearnEngineering.in

requirements. Identify the actors, scenario and use cases for the example.
[Pg.No: 15] (16)

12. (a) Describe the strategies used to identify conceptual classes. Describe the steps to
create a domain model used for representing conceptual classes.[Pg.No: 82] (16)
Or
(b) Write briefly about elaboration and discuss the differences between Elaboration
and Inception with an example . [Pg.No: 73] (16)

13. (a) Illustrate with an example, the relationship between sequence diagram and use
cases. [Pg.No: 100] (16)
Or
(b) Explain the logical architecture and UML package diagram. [Pg.No:122] (16)

14. (a) Explain about GRASP Patterns. [Pg.No: 35] (16)

Or
(b) Write short notes on adapter, singleton, factory and observer patterns.
[Pg.No: 52] (16)

15. (a) Explain UML state machine diagrams and modeling. [Pg.No: 17] (16)
Or
(b) Discuss about UML deployment and component diagrams. Draw the diagrams for
a banking application. [Pg.No: 25] (16)

188

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, NOVEMBER/DECEMBER 2014.
Sixth Semester
Computer Science and Engineering
CS 2353—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. What is OOAD? [Pg.No: 5]

2. What is UML? [Pg.No: 6]
3. What is Elaboration? [Pg.No: 6]
4. Define Aggregation and Composition. [Pg.No: 97]
5. List the relationships used in class diagram. [Pg.No: 95]
6. What is the use of System sequence diagram? [Pg.No: 97]
7. What is meant by Low Coupling. [Pg.No: 33]
8. What is Design Pattern? [Pg.No: 32]
9. What is the use of Component diagram? [Pg.No: 7]
10. When are Contracts Useful?

PART B—(5 × 16 = 80marks)

11. (a) Briefly explain the different phases of Unified Process. [Pg.No: 10 ] (16)
Or
(b) (i) Describe the basic activities in object oriented analysis and explain how use
case modeling is useful in analysis. [Pg.No: 15] (10)

189

Visit & Downloaded from : www.LearnEngineering.in

(ii) Explain about the Next Gen POS System. [Pg.No: 70] (6)

12. (a) Describe the strategies used to identify conceptual classes. Describe the steps to
create a domain model used for representing conceptual classes.
[Pg.No: 82] (16)
Or
(b) Explain about Activity diagrams with an example. [Pg.No: 21] (16)

13. (a) Illustrate with an example, the relationship between sequence diagram and use
cases. [Pg.No: 100] (16)
Or
(b) Describe the UML notation for class diagram with an example. Explain the
concept of link, association and inheritance. [Pg.No: 104] (16)

14. (a) Explain about GRASP patterns. [Pg.No: 35] (16)

Or
(b) Write short notes on adapter, singleton, factory and observer patterns.
[Pg.No: 52] (16)

15. (a) (i) Briefly explain about operation contracts. (8)

(ii) Write short notes about deployment diagram. [Pg.No: 25] (8)
Or
(b) What is the purpose of state chart diagram? How to draw state chart diagram
explain. [Pg.No: 17] (16)

190

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, APRIL/MAY 2015.
Sixth Semester
Computer Science and Engineering
CS 2353—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. What is Object Oriented Analysis and Design? [Pg.No: 5]

2. Define : Use Case. [Pg.No: 6]
3. What is a Domain Model? [Pg.No: 67]
4. What is the purpose of the association relationship? [Pg.No: 97]
5. What is System sequence diagram? [Pg.No: 97]
6. Differentiate Sequence and Communication diagrams. [Pg.No: 98]
7. Define : Pattern? [Pg.No: 31]
8. ‗A system must be loosely coupled and highly cohesive‘. Justify. [Pg.No: 34]
9. Draw the state machine diagram for telephone. [Pg.No: 17]
10. What is the purpose of using a component diagram? [Pg.No: 7]

PART B—(5 × 16 = 80marks)

11. (a) (i) What is UML? [Pg.No: 6] (2)

(ii) Explain the include, extend and generalization relationship with an example
[Pg.No: 77] (6)
(iii) Draw the use case diagram for the following specification. (8)

191

Visit & Downloaded from : www.LearnEngineering.in

A Coffee Vending Machine dispenses coffee to customers. Customers order

coffee by selecting a recipe from a set of recipes. Customers pay for the
coffee using coins. Change is given back if any, to the customers. The
‗Service Staff‘ loads ingredients (coffee powder, milk, sugar, and water,
chocolate) into the coffee machine. The ‗Service Staff‘ can also add a
recipe by indicating the name of the coffee, the units of coffee powder,
milk, sugra and water to be added as well as the cost of the coffee.
Or
(b) (i) What is the Unified Process? Is the UP Iterative and incremental? Explain.
[Pg.No:10] (8)
(ii) For the specification given below, evolve a domain model. (8)
‗Deep-Blue‘ a multi-Cuisine restaurant would like to automate its billing
service. A waiter takes an order for each table in the restaurant, along with order
details (item, name and quantity). Customers are allowed to order more items after
first order. A bill is generated at the end for each customer having the following
details: Restaurant name, date, bill no, item, quantity, amount, and total amount.

12. (a) (i) Differentiate aggregation and composition with examples. [Pg.No: 95 ] (4)
(ii) What are the constructs (notation) used in the activity diagram? [Pg.No:21] (4)
(iii) Draw the activity diagram for the following scenario. [Pg.No: 21] (8)
Booking a ticket on the Indian railways e-ticketing System (IRCTC).
Or
(b) (i) Explain the domain model refinement with suitable examples. [Pg.No: 73] (8)
(ii) Draw and explain the activity diagram for an on-line purchase system.
[Pg.No: 21] (8)

13. (a) (i) What is the relationship between sequence diagram and use cases. Take an
example to show the relationship, highlighting the advantages.[Pg.No:100] (8)

192

Visit & Downloaded from : www.LearnEngineering.in

(ii) For an ATM system, every user has to be validated with a PIN number to
make a transaction. A customer is allowed three times to validate the card giving
the correct PIN number. Show the use case representation for the same and
elaborate the ‗Validate User‘ use case using a sequence diagram.[Pg.No:100] (8)
Or
(b) With examples explain the notation used in sequence diagrams for the following:
Object Destruction, Frames, Conditional message, mutually exclusive conditional
message, Iterations over a collection. (16)

14. (a) What is GRASP? Explain the following GRASP patterns : Creator, Information
Expert, Low Coupling and High Cohesion. [Pg.No: 35] (16)
Or
(b) (i) What is visibility? List four common ways that visibility can be achieved from
Object A to Object B. (4)
(ii) Explain the following design patterns: Adapter, Singleton, Factory and
Observer. [Pg.No: 52] (12)

15. (a) (i) What is the purpose of the state diagram? [Pg.No: 17] (2)
(ii) List two advantages of using the state diagram. [Pg.No: 17] (2)
(iii) List the constructs (notation) for state diagram. Use the same to draw the state
diagram for a software that controls an elevator in a building with five floors.
[Pg.No: 17] (12)
Or
(b) What is the purpose of deployment diagrams? Explain the basic elements of a
deployment diagram through an example. [Pg.No: 25] (16)

193

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, NOVEMBER/DECEMBER 2015.
Sixth Semester
Computer Science and Engineering
CS 2353—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. What is Object Oriented Analysis and Design? [Pg.No: 5]

2. Define the inception step.
3. What is a Domain Model? [Pg.No: 67 ]
4. Define Aggregation and Composition. [Pg.No: 97 ]
5. What is the use of System sequence diagram? [Pg.No: 95 ]
6. List the relationships used in class diagram. [Pg.No: 96 ]
7. What is Design Pattern? [Pg.No: 31 ]
8. Define Coupling. [Pg.No: 32]
9. What is the use of operation contracts?
10. Give the meaning of Event, State and Transition. [Pg.No: 7 ]

PART B—(5 × 16 = 80marks)

11. (a) Briefly explain the different phases of Unified Process. [Pg.No: 10 ] (16)
Or
(b) Explain with an example, how use case modeling is used to describe functional
requirements. Identify the actors, scenario and use cases for the example.

194

Visit & Downloaded from : www.LearnEngineering.in

[Pg.No: 15 ] (16)

12. (a) Describe the strategies used to identify conceptual classes. Describe the steps to
create a domain model used for representing conceptual classes. [Pg.No: 82 ] (16)
Or
(b) Explain about activity diagram with an example. [Pg.No: 21 ] (16)

13. (a) Illustrate with an example, the relationship between sequence diagram and use
cases. [Pg.No: 100 ] (16)
Or
(b)Explain with an example Interaction diagram. [Pg.No: 112] (16)

14. (a) Explain about GRASP Patterns. [Pg.No:35 ] (16)

Or
(b) Write short notes on adapter, singleton, factory and observer patterns.
[Pg.No: 52 ] (16)

15. (a) Explain about implementation model (mapping design to code).[Pg.No: 134 ] (16)
Or
(b) Discuss about UML deployment and component diagrams. Draw the diagrams for
a banking application. [Pg.No: 25 ] (16)

195

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, NOVEMBER/DECEMBER 2015.
Fifth Semester
Computer Science and Engineering
CS 6502—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2013)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. Distinguish between method and message in object. [Pg.No: 9]

2. What are the three ways and perspective to apply UML? [Pg.No: 6]
3. Distinguish between coupling and cohesion. [Pg.No: 32]
4. When to use patterns? [Pg.No:31 ]
5. What are the tasks performed in elaboration? [Pg.No:6 ]
6. How to create a Domain model? [Pg.No: 68]
7. List the relationships used in class diagram. [Pg.No:96 ]
8. What is meant by System Behavior? [Pg.No: 99]
9. What are the steps for mapping Designs to code? [Pg.No: 132]
10. List out the issues in OO testing. [Pg.No:157]

PART B—(5 × 16 = 80marks)

11. (a) Explain about Unified Process Phases. [Pg.No:10 ] (16)

Or
(b) Explain about Use-case Model for a case study of your choice. [Pg.No: 15] (16)

196

Visit & Downloaded from : www.LearnEngineering.in

12. (a) (i) Compare cohesion and coupling with suitable examples. [Pg.No: 32] (8)
(ii) State the role of patterns while developing system design. (8)
Or
(b) (i) Differentiate Bridge and Adaptor. [Pg.No: 57 ] (8)
(ii) How will you design the behavioral pattern? [Pg.No:63] (8)

13. (a)Write about elaboration and discuss the differences between elaboration and
Inception with suitable diagram for university domain. [Pg.No: 73] (16)
Or
(b) Construct design for Library Information System which comprises and following
notations
(i) Aggregations
(ii) Compositions
(iii) Associations [Pg.No: 100 ] (16)

14. (a) (i) How to Add New SSDs and Contracts to the design diagram ?[Pg.No:95 ] (8)
(ii) What are the concepts involved in domain refinement? [Pg.No: 91] (8)
Or
(b) Explain about Interaction Diagram Notation for inventory management system.
[Pg.No: 112] (16)

15. (a) Elucidate the operation of Mapping Designs to Code. [Pg.No: 134 ] (16)
Or
(b) What is OO testing? Explain in detail about the concepts of OO testing in OOAD.
[Pg.No: 140 ] (16)

197

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, MAY/JUNE 2016
Fifth Semester
Computer Science and Engineering
CS 6502—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. Why do we need object oriented systems development? [Pg.No: 8]

2. List out the steps for finding use cases. [Pg.No: 6]
3. What is Elaboration? [Pg.No: 6]
4. Define Aggregation and Composition. [Pg.No: 97]
5. Define Package and draw the UML notation for Package. [Pg.No: 95]
6. What is the use of interaction diagram? [Pg.No:99 ]
7. State the use of Design Pattern. [Pg.No:31 ]
8. Define Coupling. [Pg.No:32]
9. Give the use of UML state diagram? [Pg.No: 8]
10. When are Contracts Useful?

PART B—(5 × 16 = 80marks)

11. (a) Explain in detail about/unified process in OOAD? Explain the phases with
suitable diagrams. [Pg.No: 10] (16)

198

Visit & Downloaded from : www.LearnEngineering.in

Or
(b) By considering your own application, perform the Object Oriented System
Development and give the use case model for the same (use include, extend
and generalization). [Pg.No:77] (16)

12. (a) Describe the strategies used to identify conceptual class. Describe the steps to
create a domain model used for representing conceptual classes.
[Pg.No:82] (16)

Or
(b) Explain about activity diagram with an example. [Pg.No:21 ] (16)

13. (a) Illustrate with an example, the relationship between sequence diagram and use
cases. [Pg.No: 100] (16)
Or
(b) Explain with a example, how interaction diagrams are used to model the
dynamic aspects of a system. [Pg.No:112 ] (16)

14. (a) Describe the concept of Creator, Low coupling, Controller and High cohesion.
[Pg.No:39] (16)
OR
(b) Write short notes on adapter, singleton, factory and observer patterns.
[Pg.No: 52 ] (16)

15. (a) Explain UML state machine diagrams and Modeling. [Pg.No: 17] (16)
OR
(b) Discuss about UML deployment and component diagrams. Draw the diagrams
for a banking application. [Pg.No: 25] (16)

199

Visit & Downloaded from : www.LearnEngineering.in

200

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, MAY/JUNE 2016
Fifth Semester
Computer Science and Engineering
CS 6502—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2013)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. Define design class diagrams.

2. What tests can help find useful Use Cases? [Pg.No:6 ]
3. Define modular design [Pg.No: 31]
4. Mention the interface and domain layer responsibilities. [Pg.No: 35]
5. Define conceptual classes. [Pg.No:68 ]
6. When to define new type classes? [Pg.No: 69]
7. Define classifier. [Pg.No: 69]
8. What is qualified association? [Pg.No: 67]
9. What are the steps for mapping designs to code? [Pg.No: 132]
10. Distinguish between OO integration testing and OO system testing. [Pg.No: 133]

PART B—(5 × 16 = 80marks)

11. (a) (i) Explain in detail about/unified process in Object Oriented Analysis and
Design? Explain the phases with neat diagrams. [Pg.No:10] (8)
(ii) What is UML Activity Diagram? Using an example explain the features of
basic UML activity diagram notation. [Pg.No:21] (8)
Or

201

Visit & Downloaded from : www.LearnEngineering.in

(b) Write a problem statement for Library management system. Draw the UML
Use Case, Activity diagram, class diagram, sequence diagram, state chart
diagram, package diagram, component diagram and Deployment diagrams.
[Pg.No: 25] (16)

12. (a) Designing the Use-Case Realizations with GoF Design patterns.
[Pg.No:52,57 ] (16)

Or
(b) What is GRASP? Explain the following GRASP patterns: Creator, Information
Expert, Low Coupling, High Cohesion and Controller.[Pg.No:35,39] (16)

13. (a) What are the guidelines used to partition the classes in the domain model to be
organized into packages? (16)
Or
(b) (i) Explain the guidelines for finding Conceptual Classes with neat diagrams
[Pg.No:82] (8)
(ii) Illustrate the concept of Domain model with examples. [Pg.No:91] (8)

14. (a) Describe UML notation for Class diagram with an example. Explain the
concept of link, association and inheritance. [Pg.No: 100] (16)

Or
(b) What is Model-View-Separation Principle? Explain the motivation for Model-
View separation. (16)

15. (a) Explain in detail the design artifacts to implementation code in an object
oriented language. [Pg.No:134] (16)

202

Visit & Downloaded from : www.LearnEngineering.in

(b) Explain in detail about the different types of testing in OOAD.

[Pg.No:140,145 ] (16)

203

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, NOV/DEC 2016
Fifth Semester
Computer Science and Engineering
CS 6502—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2013)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. What are the three perspectives to apply UML?

2. What are the primary goals in the design of UML?
3. Define patterns and design patterns.
4. Distinguish between coupling and cohesion.
5. Why call a domain model a ‗visual dictionary‘?
6. How to create a Domain model?
7. How to Naming system events and operations?
8. Define system events and system boundary.
9. What is refactoring?
10. What is regression testing?

PART B—(5 × 16 = 80marks)

204

Visit & Downloaded from : www.LearnEngineering.in

(b) Apply interactive modeling for a payroll system in UML. (16)

12. (a) Explain creator and controller design patterns with example. (16)

Or
(b) Explain the design principles in object modeling. Explain in detail the GRASP
method for designing objects with example. [Pg.No:35,39] (16)

13. (a) What is the purpose of a use case model? Identify the actors, scenarios and
usecase for a library management system. (16)
Or
(b) (i) Explain in detail about the strategies to find Conceptual Classes.[Pg.No:82]
(8)
(ii) Explain association, aggregation and composition relationships in detail. (8)

14. (a) What are system sequence diagrams? What is the relationship between SSDs
and usecases? Explain with an example. (16)

Or
(b) Draw the neat sketch of the logical layered architecture of NextGen application
and explain the components in detail. (16)

15. (a) Explain in detail about the mapping of design to code implementation in an
object oriented language. [Pg.No:134] (16)

Or
(b) Explain in detail about OO integration testing and OO System testing.
[Pg.No:140,145 ] (16)

205

Visit & Downloaded from : www.LearnEngineering.in

Anna University
B.E./B.Tech. DEGREE EXAMINATION, APRIL/MAY 2017
Fifth Semester
Computer Science and Engineering
CS 6502—OBJECT ORIENTED ANALYSIS AND DESIGN
(Common to Information Technology)
(Regulation 2008/2010)
Time : Three hours Maximum : 100marks
Answer ALL questions.

PART A—(10 × 2 = 20marks)

1. What is analysis and design?

2. State the role of UML in designing a software.
3. What is domain model?
4. Define Aggregation and Composition.
5. List the relationships used in class diagram.
6. What is the use of sequence diagram?
7. What is design pattern?
8. What is meant by low coupling?
9. Define component with an example.
10. What is UML deployment?

PART B—(5 × 16 = 80marks)

11. (a) List various UML diagrams and explain the purpose of each diagram.
[Pg.No:21] (16)

206

Visit & Downloaded from : www.LearnEngineering.in

(b) Explain with an example, how use case modeling is used to describe
functional requirements. Identify the actors, scenario and use cases for the
example. (16)

12. (a) Describe the strategies used to identify conceptual classes. Explain the steps to
create a domain model used for representing conceptual classes. (16)

Or
(b) (i) Explain about activity diagram with an example (6)
(ii) With an example compare aggregation and composition relationship. (10)

13. (a) With a suitable example explain how to design a class. Give all possible
representation in a class(such as name, attribute, visibility, methods,
responsibilities) (16)
Or
(b) Explain about UML interaction diagrams with a suitable example. (16)

14. (a) Explain ―GRASP‖ in terms of designing objects with responsibilities in detail.
(16)

Or
(b) Write short notes on adapter, singleton, factory and observer patterns. (16)

15. (a) (i) Briefly explain about operation contracts. (8)

(ii)Write short notes about deployment diagram. (8)

Or
(b) What is the purpose of state chart diagram? How to draw state chart diagram?
Explain with an example state machine.
(16)

207

Visit & Downloaded from : www.LearnEngineering.in

PART A—(10 × 2 = 20marks)

1. What are the three perspectives to apply UML?

PART B—(5 × 16 = 80marks)

208

Visit & Downloaded from : www.LearnEngineering.in

(b) Apply interactive modeling for a payroll system in UML. (16)

12. (a) Explain creator and controller design patterns with example. (16)

Or
(b) Explain the design principles in object modeling. Explain in detail the GRASP
method for designing objects with example. [Pg.No:35,39] (16)

14. (a) What are system sequence diagrams? What is the relationship between SSDs
and usecases? Explain with an example. (16)

Or
(b) Draw the neat sketch of the logical layered architecture of NextGen application
and explain the components in detail. (16)

15. (a) Explain in detail about the mapping of design to code implementation in an
object oriented language. [Pg.No:134] (16)

Or
(b) Explain in detail about OO integration testing and OO System testing.
[Pg.No:140,145 ] (16)

209

Visit & Downloaded from : www.LearnEngineering.in

PART A—(10 × 2 = 20marks)

1. What is analysis and design?

PART B—(5 × 16 = 80marks)

11. (a) List various UML diagrams and explain the purpose of each diagram.
[Pg.No:21] (16)

210

Visit & Downloaded from : www.LearnEngineering.in

(b) Explain with an example, how use case modeling is used to describe
functional requirements. Identify the actors, scenario and use cases for the
example. (16)

12. (a) Describe the strategies used to identify conceptual classes. Explain the steps to
create a domain model used for representing conceptual classes. (16)

Or
(b) (i) Explain about activity diagram with an example (6)
(ii) With an example compare aggregation and composition relationship. (10)

14. (a) Explain ―GRASP‖ in terms of designing objects with responsibilities in detail.
(16)

Or
(b) Write short notes on adapter, singleton, factory and observer patterns. (16)

15. (a) (i) Briefly explain about operation contracts. (8)

(ii)Write short notes about deployment diagram. (8)

Or
(b) What is the purpose of state chart diagram? How to draw state chart diagram?
Explain with an example state machine. (16)

211

Visit & Downloaded from : www.LearnEngineering.in

OOP Lab Manual Solution
No ratings yet
OOP Lab Manual Solution
38 pages
Chapter 10
No ratings yet
Chapter 10
36 pages
Professor Dr. Teuvo Kohonen (Auth.) Associative Memory - A System-Theoretical Approach 1977 PDF
No ratings yet
Professor Dr. Teuvo Kohonen (Auth.) Associative Memory - A System-Theoretical Approach 1977 PDF
187 pages
Lab 1.2.2 Configure A Security Appliance - 2
No ratings yet
Lab 1.2.2 Configure A Security Appliance - 2
2 pages
F1 Race Track: Group-1
0% (1)
F1 Race Track: Group-1
33 pages
Data Structures by Fareed Sem IV 27-Jan-2020 Pages 213 Completed W1
No ratings yet
Data Structures by Fareed Sem IV 27-Jan-2020 Pages 213 Completed W1
213 pages
Lecture 1 DS Using C++
No ratings yet
Lecture 1 DS Using C++
26 pages
OOPs 1
No ratings yet
OOPs 1
267 pages
C++ STL Standard Template Librairy
No ratings yet
C++ STL Standard Template Librairy
24 pages
109search Hash Malik Ch09
No ratings yet
109search Hash Malik Ch09
62 pages
C++ STL: CSCI 3110
No ratings yet
C++ STL: CSCI 3110
30 pages
Data Structures & Its Application-2
No ratings yet
Data Structures & Its Application-2
356 pages
Introduction To Object Oriented Paradigm, Procedural Paradigm
No ratings yet
Introduction To Object Oriented Paradigm, Procedural Paradigm
64 pages
Data Structures Using C++ 2E: Graphs
No ratings yet
Data Structures Using C++ 2E: Graphs
60 pages
C++ STL
No ratings yet
C++ STL
11 pages
Ch03 Pressman Software Engineering Slides
No ratings yet
Ch03 Pressman Software Engineering Slides
12 pages
285 - OOPS Lecture Notes Complete PDF
No ratings yet
285 - OOPS Lecture Notes Complete PDF
146 pages
Database Management System
No ratings yet
Database Management System
161 pages
110sort Malik Ch10
No ratings yet
110sort Malik Ch10
81 pages
CPP v1.2 Modern CPP OOP Slides Margit Antal 2021
No ratings yet
CPP v1.2 Modern CPP OOP Slides Margit Antal 2021
486 pages
Data Structure
No ratings yet
Data Structure
30 pages
OOPS - Concepts Using C++
No ratings yet
OOPS - Concepts Using C++
87 pages
1 Alg Lecture1 (1) (7 Files Merged)
No ratings yet
1 Alg Lecture1 (1) (7 Files Merged)
185 pages
CH 07
No ratings yet
CH 07
52 pages
Notes - Data Structure - Algorithm
No ratings yet
Notes - Data Structure - Algorithm
65 pages
Lecture 25 STL
No ratings yet
Lecture 25 STL
28 pages
Iv Semester Ooc (18CS45) Notes
No ratings yet
Iv Semester Ooc (18CS45) Notes
181 pages
OOP - Final Notes PDF
No ratings yet
OOP - Final Notes PDF
133 pages
Algorithm Timecomplexity
No ratings yet
Algorithm Timecomplexity
45 pages
Datastructures Lab Programs
100% (5)
Datastructures Lab Programs
70 pages
Database Management System CS-116: E-R Model
No ratings yet
Database Management System CS-116: E-R Model
76 pages
Iare Oops Through Java Lab Manual Updated 0
No ratings yet
Iare Oops Through Java Lab Manual Updated 0
121 pages
Data Structures & Its Application
No ratings yet
Data Structures & Its Application
138 pages
OOPs Lab Manual
0% (1)
OOPs Lab Manual
88 pages
Introduction To Data Structures & Algorithms
No ratings yet
Introduction To Data Structures & Algorithms
62 pages
Vectors, Points, Dot Product Coordinates, Transformations Lines, Edges, Intersections Triangles Circles
100% (1)
Vectors, Points, Dot Product Coordinates, Transformations Lines, Edges, Intersections Triangles Circles
61 pages
OO Case Studies With Patterns and C++
No ratings yet
OO Case Studies With Patterns and C++
26 pages
C++ Program To Implement Binary Search Tree 6
No ratings yet
C++ Program To Implement Binary Search Tree 6
33 pages
Algorithms For The Masses: Robert Sedgewick Princeton University
No ratings yet
Algorithms For The Masses: Robert Sedgewick Princeton University
73 pages
C Programming & Data Strucutres Lab Manual
100% (1)
C Programming & Data Strucutres Lab Manual
108 pages
Software Engineering
No ratings yet
Software Engineering
146 pages
Object Oriented Programming Using C Plus Plus
No ratings yet
Object Oriented Programming Using C Plus Plus
223 pages
Introduction To C++: By: Mohammad Mirza Aghatabar Instructor: Dr. Shahin Nazarian Summer 2010
No ratings yet
Introduction To C++: By: Mohammad Mirza Aghatabar Instructor: Dr. Shahin Nazarian Summer 2010
72 pages
System Sequence Diagrams
No ratings yet
System Sequence Diagrams
16 pages
Vectors and Matrices in STL
No ratings yet
Vectors and Matrices in STL
9 pages
String Operations in C++ Builder Are Mainly Performed Using A Class Called AnsiString
No ratings yet
String Operations in C++ Builder Are Mainly Performed Using A Class Called AnsiString
10 pages
C++ Neural Networks and Fuzzy Logic
No ratings yet
C++ Neural Networks and Fuzzy Logic
547 pages
CPP CPP MSVC 170
No ratings yet
CPP CPP MSVC 170
1,237 pages
The C++ Standard Template Library
No ratings yet
The C++ Standard Template Library
80 pages
Object-Oriented Design & Methodology CS 312
No ratings yet
Object-Oriented Design & Methodology CS 312
58 pages
Data Structures Using C++ by DR Varsha Patil: Oxford University Press © 2012
No ratings yet
Data Structures Using C++ by DR Varsha Patil: Oxford University Press © 2012
49 pages
CS6502 OOAD Notes 2013 Regulation
No ratings yet
CS6502 OOAD Notes 2013 Regulation
54 pages
IT6513 CASE TOOLS LABORATORY & ooad syllabuses
No ratings yet
IT6513 CASE TOOLS LABORATORY & ooad syllabuses
4 pages
OOAD Syllabus
No ratings yet
OOAD Syllabus
1 page
Syllabus - Se Uml
No ratings yet
Syllabus - Se Uml
3 pages
CS2353 Ooad Syllabus
No ratings yet
CS2353 Ooad Syllabus
1 page
Cs6502 Object Oriented Analysis and Design Syllabus
No ratings yet
Cs6502 Object Oriented Analysis and Design Syllabus
2 pages
Syllabus R2017 Anna University
No ratings yet
Syllabus R2017 Anna University
2 pages
Ooad LP
No ratings yet
Ooad LP
3 pages
Anna University, Chennai: Affiliated Institutions R-2008 B.Tech. Information Technology
No ratings yet
Anna University, Chennai: Affiliated Institutions R-2008 B.Tech. Information Technology
1 page
CS8592 Ooad Syllabus
No ratings yet
CS8592 Ooad Syllabus
1 page
CS8592 Ooad Syllabus
No ratings yet
CS8592 Ooad Syllabus
1 page
Snap
0% (1)
Snap
3 pages
Architectural History
No ratings yet
Architectural History
29 pages
David Hatton Resume 2015 PDF
No ratings yet
David Hatton Resume 2015 PDF
1 page
Vsphere Esxi Vcenter Server 55 Command Line Interface Concepts Examples Guide
No ratings yet
Vsphere Esxi Vcenter Server 55 Command Line Interface Concepts Examples Guide
148 pages
Seven Layers of The OSI Model: User Support Layer
No ratings yet
Seven Layers of The OSI Model: User Support Layer
44 pages
Default - Config Stepp II Keep30
No ratings yet
Default - Config Stepp II Keep30
2 pages
IGBC Green New Buildings Rating System (Version 3.0 With Fifth Addendum) PDF
No ratings yet
IGBC Green New Buildings Rating System (Version 3.0 With Fifth Addendum) PDF
146 pages
Ahqua Catalog
No ratings yet
Ahqua Catalog
203 pages
Walt Disney Concert Hall / Frank Gehry: Share On Email
100% (1)
Walt Disney Concert Hall / Frank Gehry: Share On Email
11 pages
Design of Retaining Wall: General Input
No ratings yet
Design of Retaining Wall: General Input
4 pages
Commodity Description: H.S. Code Item No Description Unit Quantity
No ratings yet
Commodity Description: H.S. Code Item No Description Unit Quantity
3 pages
English 7. Unit 6. Test. Grammar. Điền Từ. Suy Luận
No ratings yet
English 7. Unit 6. Test. Grammar. Điền Từ. Suy Luận
2 pages
Samson Walelign
100% (1)
Samson Walelign
104 pages
HPS QA Checklists
No ratings yet
HPS QA Checklists
24 pages
SOAP Over JMS With SoapUI
No ratings yet
SOAP Over JMS With SoapUI
14 pages
Msi 7093
No ratings yet
Msi 7093
131 pages
Citra Log
No ratings yet
Citra Log
9 pages
HP OfficeJet Pro X Series Firmware Readme Updated 1-19-16 PDF
No ratings yet
HP OfficeJet Pro X Series Firmware Readme Updated 1-19-16 PDF
3 pages
Shorelines Casino Peterborough
No ratings yet
Shorelines Casino Peterborough
41 pages
Okareem Resume
No ratings yet
Okareem Resume
3 pages
Sauna Technical Specifications1
No ratings yet
Sauna Technical Specifications1
21 pages
New Horizon Catalog 2020-1
No ratings yet
New Horizon Catalog 2020-1
110 pages
Log
No ratings yet
Log
16 pages
Defining Next Generation Firewall
No ratings yet
Defining Next Generation Firewall
3 pages
Test & Data Management Software: The Integrated Testing Solution
No ratings yet
Test & Data Management Software: The Integrated Testing Solution
12 pages
Facade - Poche
No ratings yet
Facade - Poche
4 pages
Reliability of Core Test
No ratings yet
Reliability of Core Test
16 pages
MTF Task 1
No ratings yet
MTF Task 1
6 pages