cs8592 Ooad PDF

WHO WE ARE
“Facultytalkies-An Innovative Engineering Professors Hub”
Faculty Talkies began as an imitative experiment in online teaching, when

professor vijayanand shanmugam and professor prabu A elected to offer their
courses online to anyone, for free. The potential to educate at a global scale was
awe-inspiring, and facultytalkies was founded to pursue a mission to innovative
engineering education, and we care to make a innovative engineering professors
community around the world. How we interact with each other internally as well
as with the thousands of Lecturers, professors, doctorates students, that make
up our facultytalkies community
 Increase access to high-quality of innovative engineering knowledge for every

student, everywhere in the engineering college
 Enhance teaching and learning on Engineering campus and online
 Advance teaching and learning through research
WHAT WE DO
Faculties Talkies team typically do the following:
 Teach courses in a wide variety of subjects, such as all engineering courses

under the annauniversity,and other private university
 Work with students who are studying for a degree or a certificate or
certification or are taking classes to improve their knowledge or career skills
 Develop a curriculum for their course and ensure that it meets college and
department standards
 Plan lessons and assignments
 Advise students about which classes to take and how to achieve their goals
 Stay informed about changes and innovations in their field
 Conduct research and experiments to advance knowledge in their field
 Supervise graduate students who are working toward doctoral degrees
 Publish original research and analysis in books and academic journal
Contents
S.No Topic Page. No.

1 Cover Page
2 Syllabus copy
3 Course objectives and outcomes
4 Brief notes on the importance of the course and how it fits into
the curriculum
5 Prerequisites if any
6 Instructional Learning Outcomes
7 Brief notes on the importance of the course and how it fits into
the curriculum
8 Lecture schedule with methodology being used/adopted
9 Detailed notes
10 Additional topics
11 University Question papers of previous years
12 Question Bank
13 Assignment Questions
14 Unit wise Quiz Questions and long answer questions
15 Tutorial problems
16 Known gaps ,if any and inclusion of the same in lecture
schedule
17 Discussion topics , if any
18 References, Journals, websites and E-links if any
19 Quality Measurement Sheets
20 Course End Survey
21 Teaching Evaluation
22 Student List
23 Group-Wise students list for discussion topic
24 Lecture schedule with methodology being used/adopted
25 Detailed notes
SYLLABUS
WHAT YOU WILL LEARN

 Understand what is object oriented analysis, design & programming
 Understand how to analyze a problem using object oriented analysis
 Implement OO design in C++, C# & Java
 Create common UML diagrams, such as use case, state, class, activity, etc
OBJECTIVES:
 To understand the fundamentals of object modeling
 To understand and differentiate Unified Process from other approaches.
 To design with static UML diagrams.
 To design with the UML dynamic and implementation diagrams.
 To improve the software design with design patterns.
 To test the software against its requirements specification
UNIT I UNIFIED PROCESS AND USE CASE
DIAGRAMS
Introduction to OOAD with OO Basics – Unified Process – UML diagrams – Use
Case –Case study – the Next Gen POS system, Inception -Use case Modelling –
Relating Use cases – include, extend and generalization – When to use Use-
cases
UNIT II STATIC UML DIAGRAMS

Class Diagram–– Elaboration – Domain Model – Finding conceptual classes
and description classes – Associations – Attributes – Domain model refinement
– Finding conceptual class Hierarchies – Aggregation and Composition –
Relationship between sequence diagrams and use cases – When to use Class
Diagrams
UNIT III DYNAMIC AND IMPLEMENTATION UML

DIAGRAMS
Dynamic Diagrams – UML interaction diagrams – System sequence diagram –
Collaboration diagram – When to use Communication Diagrams – State
machine diagram and Modelling –When to use State Diagrams – Activity
diagram – When to use activity diagrams Implementation Diagrams – UML
package diagram – When to use package diagrams – Component and
Deployment Diagrams – When to use Component and Deployment diagrams
UNIT IV 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 –Applying GoF design patterns – Mapping design to code
UNIT V TESTING
Object Oriented Methodologies – Software Quality Assurance – Impact of object
orientation on Testing – Develop Test Cases and Test Plans
INTENDED AUDIENCE : UG, PG Course, BCA, MCA, B.Tech., M.Tech.

PRE-REQUISITES :
1. Basic Knowledge of Programming & Data Structure
2. Experience of Programming Projects would help; but is not mandatory
3. Attending a course on C++ with this course will help
OUTCOMES:
At the end of the course, the students will be able to:
 Express software design with UML diagrams

 Design software applications using OO concepts.
 Identify various scenarios based on software requirements
 Transform UML based software design into pattern based design using
design patterns
 Understand the various testing methodologies for OO software
INDUSTRY SUPPORT :
Object-Oriented Analysis and Design is at the core of software development
processes. Hence all software development companies have a need for the
same. These include – Microsoft, Samsung, Xerox, Yahoo, Google, IBM, TCS,
Infosys, Amazon, Flipkart, etc.
6. Course Objectives & Outcomes
Course Objectives:
In this course, the students will learn how to produce detailed object models and
designs from system requirements; use the modeling concepts provided by UML;
identify use cases and expand into full behavioral designs; expand the analysis into a
design ready for implementation and construct designs that are reliable. The course
begins with an overview of the object oriented analysis and design.
Course Outcomes:
At the end of this course student will:
COA60524.1) Be able to discuss the overview of object oriented modeling and
benefits of each.
COA60524.2) Identify the characteristics of the UML and why the UML is
relevant to the process development.
COA60524.3) Be able to analyze and design the classes, relationships and

diagrams.
COA60524.4) Be able to analyze and compare advanced classes and

relationships.
COA60524.5) Be able to draw class Diagrams, Object Diagram and Interaction
Diagram.
COA60524.6) Be able to describe the use cases, use cases Diagrams and
Activity Diagram.
COA60524.7) Identify and discuss the concept of events and signals, process
and threads and state chart Diagrams.
COA60524.8) Be able to draw Component Diagram and the Deployment

Diagram.
1.
Brief Notes on the importance of the course and how it fits into the curriculum
Object-oriented analysis and design (OOAD) is a popular technical approach for analyzing,
designing an application, system, or business by applying the object-oriented paradigm and
visual modeling throughout the development life cycles to foster better stakeholder
communication and product quality.
According to the popular guide Unified Process, OOAD in modern software engineering is
best conducted in an iterative and incremental way. Iteration by iteration, the outputs of
OOAD activities, analysis models for OOA and design models for OOD respectively, will be
refined and evolve continuously driven by key factors like risks and business value.
Prerequisites
Object Oriented Programming System
Learning Outcomes/Instructional Outcomes
S.No Unit Contents Outcomes
I Introduction to UML:  Students Can able to explain the

Importance of modeling, importance of the Object oriented
principles of modeling, modeling.
object oriented modeling,
conceptual model of the  Students Can able to discuss the
UML, Architecture, principles of modeling.
Software Development Life
Cycle.  Students Can able to describe
Basic Structural Modeling: the conceptual model and
Classes, Relationships, Architecture of UML.
common Mechanisms, and  Students Can able to Analyze
diagrams. and apply the importance and
use of UML in software
Development Life Cycle.
 Students Can able to identify

how to apply the UML to solve a
number of common modeling
problems.
 Students Can able to Analyze

and design the implementation of
the classes.
2 II
Advanced Structural
Modeling: Advanced  Students Can able to predict how
classes, advanced to maintain the relationships
relationships, Interfaces, between the classes or things.
Types and Roles, Packages.
 Students Can able to evaluate
Class & Object Diagrams:
the common Mechanism of basic
Terms, concepts, modeling
structural Modeling.
techniques for Class &
Object  Students Can able to explain
Diagrams. Advanced Structural Modeling.
 Students Can able to compare

the concept of interfaces,
packages, types and roles of each
entity.
 Students Can able to analyze

how to draw class Diagram and
Object Diagram.
 Students Can able to

demonstrate how to solve
common modeling problems.
 Students Can able to model the

vocabulary of a system.
 Students Can able to model an

object Structure.
 Students Can able to model a

logical database schema.
3 III Basic Behavioral Modeling-  Students can analyze how to
I: Interactions, Interaction draw Interaction Diagram.
diagrams.
Basic Behavioral Modeling-  Students can evaluate how the
II: Use cases, Use case objects communicate with each
Diagrams, Activity other.
Diagrams.
 Students can explain how to
model a flow of control.
 Students can analyze how to

draw sequence Diagram.
 Students can prepare how to

draw Collaboration Diagram.
 Students can identify what the

Use cases are.
 Students can analyze how to

draw Use case Diagram.
 Students can design an Activity

Diagram.
 Students can evaluate how to

model a behavior of an element.
 Students can plan how to model

a work flow.
4 IV Advanced Behavioral  Students Can able to compare
Modeling: Events and Events and Signals.
signals, state machines,
processes and  Students Can able to discuss
Threads, time and space, Processes, Threads and State
state chart diagrams. Machine.
Architectural Modeling:
Component, Deployment,  Students Can able to analyze how
Component diagrams and to draw State chart Diagram.
Deployment diagrams.  Students Can able to model a
multiple flow of control.
 Students Can able to explain the

Architecture model.
 Students Can able to design and

draw Component Diagram.
 Students Can able to analyze and

draw Deployment Diagram.
 Students Can able to explain how

to model an Executables and
Libraries.
 Students Can able to discuss how

to model Processors and Devices.
5 V Case Study: The Unified  Students Can able to analyze and

Library application design how to implement a real
Library application.
 Students Can able to analyze and

design any real application.
 Students Can able to prepare

how to implement a real
application.
 Students Can able to create how

to model a real application.
Contents Plan
S.L Unit Total Topics to be covered Page
no No no. of No
hours
1 1 Introduction to OOAD with OO Basics
2 1 Unified Process in Object Oriented Analysis and Design
3 1 UML diagrams in OOAD
4 1 Case study:the Next Gen POS system
5 1 Inception Concepts in OOAD
6 I 1 Use Case Modelling in OOAD
7 2 Relating Use Cases Include, Extend and Generalization
8 1 When to use Use-Cases in OOAD
9 1 Class Diagram in OOAD
10 1 Elaboration Concepts in OOAD
11 1 Domain Model in OOAD
12 1 Finding Conceptual Classes and Description Classes in
OOAD
13 1 Associations and Attributes in OOAD
14 1 Domain Model Refinement in OOAD
15 1 Finding Conceptual Class Hierarchies in OOAD
16 II 1 Aggregation and Composition in OOAD
17 1 Relationship Between Sequence and Use Cases in
OOAD
18 1 When to Use Class Diagrams in OOAD
19 1 Dynamic and Interaction Diagram in OOAD
20 1 System Sequence and Collaboration Diagram in OOAD
21 1 When to use Communication Diagrams
22 1 State machine diagram and Modelling
23 1 When to use State Diagrams
524 III 1 Activity Diagram and When to Use in OOAD
25 1 UML Package Diagram and When to Use it
26 1 Component Diagrams in OOAD
27 1 Deployment Diagrams in OOAD
28 IV 2 General Responsibility Assignment Software
Patterns(GRASP)
29 3 Design Patterns in OOAD
30 3 Applying GoF Design Patterns
31 V 2 Object Oriented Methodologies in OOAD
32 2 Software Quality Assurance in OOAD
33 V 2 Impact of Object Orientation on Testing
34 2 Develop Test Cases and Test Plans in OOAD
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS
Introduction to OOAD with OO Basics – Unified Process – UML diagrams – Use Case –Case study –
the Next Gen POS system, Inception -Use case Modelling – Relating Use cases – include, extend and
generalization – When to use Use-cases
Topic 1: Introduction to OOAD with OO Basics
Definition of OOP Concepts in Java

OOP concepts in Java are the main ideas behind Java’s Object Oriented
Programming. They are an abstraction, encapsulation, inheritance,
and polymorphism. Grasping them is key to understanding how Java works.
Basically, Java OOP concepts let us create working methods and variables, then re-
use all or part of them without compromising security.
List of OOP Concepts in Java

There are four main OOP concepts in Java. These are:
 Abstraction. Abstraction means using simple things to represent complexity.

We all know how to turn the TV on, but we don’t need to know how it works in
order to enjoy it. In Java, abstraction means simple things
like objects, classes, and variables represent more complex underlying code
and data. This is important because it lets avoid repeating the same work
multiple times.
 Encapsulation. This is the practice of keeping fields within a class private,
then providing access to them via public methods. It’s a protective barrier that
keeps the data and code safe within the class itself. This way, we can re-use
objects like code components or variables without allowing open access to the
data system-wide.
 Inheritance. This is a special feature of Object Oriented Programming in Java.
It lets programmers create new classes that share some of the attributes of
existing classes. This lets us build on previous work without reinventing the
wheel.
 Polymorphism. This Java OOP concept lets programmers use the same word
to mean different things in different contexts. One form of polymorphism in
Java is method overloading. That’s when different meanings are implied by
the code itself. The other form is method overriding.
Object-Oriented Analysis
Object–Oriented Analysis (OOA) is the procedure of identifying software engineering
requirements and developing software specifications in terms of a software system’s
object model, which comprises of interacting objects.
The primary tasks in object-oriented analysis (OOA) are:
 Identifying objects
 Organizing the objects by creating object model diagram
 Defining the internals of the objects, or object attributes
 Defining the behavior of the objects, i.e., object actions
 Describing how the objects interact
Object-Oriented Design
Object–Oriented Design (OOD) involves implementation of the conceptual model
produced during object-oriented analysis.
The implementation details generally include:
 Restructuring the class data (if necessary),

 Implementation of methods, i.e., internal data structures and algorithms,
 Implementation of control, and
 Implementation of associations.
Object-Oriented Programming
Object-oriented programming (OOP) is a programming paradigm based upon objects
(having both data and methods) that aims to incorporate the advantages of
modularity and reusability.
The important features of object–oriented programming are:
 Bottom–up approach in program design

 Programs organized around objects, grouped in classes
 Focus on data with methods to operate upon object’s data
 Interaction between objects through functions
 Reusability of design through creation of new classes by adding features to
existing classes
Object
An object is a real-world element in an object–oriented environment that may have a
physical or a conceptual existence.Class
A class represents a collection of objects having same characteristic properties that
exhibit common behavior
Do You Want Video Lecture for this Topic
Scan this QR Code From QR Code Scanner App Using Your Smart Phone
**************************************************************************************************
Topic 2:Unified Process in Object Oriented Analysis and Design
Unified Process
Unified Process is based on the enlargement and refinement of a system
through multiple iterations, with cyclic feedback and adaptation. The system
is developed incrementally over time, iteration by iteration, and thus this
approach is also known as iterative and incremental software development.
Four Phases
Inception
 the first and the shortest phase in the project. It is used to prepare basis
for the project, including preparation of business case
 establishing project scope and setting boundaries,
 outlining key requirements, and possible architecture solution together
with design trade offs,
 identifying risks, and development of initial project plan
 schedule with main milestones and cost estimates.
Elaboration
 during this phase the project team is expected to capture a majority of

system’s requirements (e.g., in the form of use cases).
 to perform identified risk analysis and make a plan of risk management
to reduce or eliminate their impact on final schedule and product.
 to establish design and architecture (e.g., using basic class diagrams,
package diagrams, and deployment diagrams).
 to create a plan (schedule, cost estimates, and achievable milestones) for
the next (construction) phase.
Construction
 the longest and largest phase within Unified Process. During this phase,
the design of the system is finalized and refined and the system is built
using the basis created during elaboration phase.
 The construction phase is divided into multiple iterations, for each
iteration to result in an executable release of the system.
 The final iteration of construction phase releases fully completed system
which is to be deployed during transition phase.
Transition
 the final project phase which delivers the new system to its end-users.
Transition phase includes also data migration from legacy systems and
user training.
The disciplines described by Unified Process are as follows
 Business modeling—domain object modeling and dynamic modeling of

the business processes,
 Requirements—requirements analysis of system under consideration.
Includes activities like writing use cases and identifying nonfunctional
requirements,
 Analysis and design—covers aspects of design, including the overall
architecture,
 Implementation—programming and building the system (except the
deployment),
 Test—involves testing activities such as test planning, development of
test scenarios, alpha and beta testing, regression testing, acceptance
testing, and
 Deployment—the deployment activities of developed system.
Do You Want Video Lecture for this topic
Scan this QR Code from QR Code Scanner App Using Your Smart Phone
*********************************************************************************************
Topic 3 UML diagrams in OOAD
A UML diagram is a diagram based on the UML (Unified Modeling Language) with the
purpose of visually representing a system along with its main actors, roles,
actions, artifacts or classes, in order to better understand, alter, maintain, or
document information about the system.
What is UML?
UML is an acronym that stands for Unified Modeling Language. Simply put, UML is
a modern approach to modeling and documenting software. In fact, it’s one of the
most popular business process modeling techniques.
UML was created as a result of the chaos revolving around software development and
documentation. In the 1990s, there were several different ways to represent and
document software systems. The need arose for a more unified way to visually
represent those systems and as a result, in 1994-1996, the UML was developed by
three software engineers working at Rational Software. It was later adopted as the
standard in 1997 and has remained the standard ever since, receiving only a few
updates.
What is the use of UML?

Mainly, UML has been used as a general-purpose modeling language in the field of
software engineering. However, it has now found its way into the documentation of
several business processes or workflows. For example, activity diagrams, a type of
UML diagram, can be used as a replacement for flowcharts. They provide both a more
standardized way of modeling workflows as well as a wider range of features to
improve readability and efficacy.
Types of UML Diagrams

The two most broad categories that encompass all other types are Behavioral UML
diagram and Structural UML diagram.
Behavioral UML Diagram
 Activity Diagram
 Use Case Diagram
 Interaction Overview Diagram
 Timing Diagram
 State Machine Diagram
 Communication Diagram
 Sequence Diagram
Structural UML Diagram
 Class Diagram
 Object Diagram
 Component Diagram
 Composite Structure Diagram
 Deployment Diagram
 Package Diagram
 Profile Diagram
Activity Diagram
Activity diagrams are probably the most important UML diagrams for doing business
process modeling. In software development, it is generally used to describe the flow of
different activities and actions. These can be both sequential and in parallel. They
describe the objects used, consumed or produced by an activity and the relationship
between the different activities. All the above are essential in business process
modeling.
Use Case Diagram
A cornerstone part of the system is the functional requirements that the system
fulfills. Use Case diagrams are used to analyze the system’s high-level requirements.
These requirements are expressed through different use cases. We notice three main
components of this UML diagram:
 Functional requirements – represented as use cases; a verb describing an

action
 Actors – they interact with the system; an actor can be a human being, an
organization or an internal or external application
 Relationships between actors and use cases – represented using straight
arrows
Interaction Overview Diagram
Interaction Overview UML diagrams are probably some of the most complex ones. So
far we have explained what an activity diagram is. Additionally, within the set of
behavioral diagrams, we have a subset made of four diagrams, called Interaction
Diagrams:
 Interaction Overview Diagram

 Timing Diagram
 Sequence Diagram
 Communication Diagram
Timing diagram
Timing UML diagrams are used to represent the relations of objects when the center
of attention rests on time. We are not interested in how the objects interact or change
each other, but rather we want to represent how objects and actors act along a linear
time axis.
Each individual participant is represented through a lifeline, which is essentially a
line forming steps since the individual participant transits from one stage to
another.The main focus is on time duration of events and the changes that occur
depending on the duration constraints.
The main components of a timing UML diagram are:
 Lifeline – individual participant

 State timeline – a single lifeline can go through different states within a
pipeline
 Duration constraint – a time interval constraint that represents the duration
of necessary for a constraint to be fulfilled
 Time constraint – a time interval constraint during which something needs to
be fulfilled by the participant
 Destruction occurrence – a message occurrence that destroys the individual
participant and depicts the end of that participant’s lifeline
State Machine UML diagram
State machine UML diagrams, also referred to as Statechart diagrams, are used to
describe the different states of a component within a system. It takes the name state
machine because the diagram is essentially a machine that describes the several
states of an object and how it changes based on internal and external events.
Sequence UML Diagram

Sequence diagrams are probably the most important UML diagrams among not only
the computer science community but also as design-level models for business
application development. Lately, they have become popular in depicting business
processes, because of their visually self-explanatory nature.
Communication UML diagram
In UML 1.x, communication diagrams used to be called collaborative diagrams. As
the name suggests, the main focus of this type of UML diagram is on communication
between objects.
Since the core components are the messages that are exchanged between objects, we
can build communication diagrams the same way we would make a sequence
diagram. The only difference between the two is that objects in communication
diagrams are shown with association connections.
Class Diagram
Class UML diagram is the most common diagram type for software documentation.
Since most software being created nowadays is still based on the Object-Oriented
Programming paradigm, using class diagrams to document the software turns out to
be a common-sense solution. This happens because OOP is based on classes and the
relations between them.
Component Diagram
When dealing with documentation of complex systems, component UML diagrams
can help break down the system into smaller components. Sometimes it is hard to
depict the architecture of a system because it might encompass several departments
or it might employ different technologies.
Composite Structure Diagram

This type of UML diagram is not commonly used because its function is very specific.
It only represents the internal structure of a class and the relations between different
class components.
***************************************************************************************
Topic 4 Use Case Diagram in OOAD
A use case diagram is a graphic depiction of the interactions among the elements of a
system.
A use case is a methodology used in system analysis to
1. identify,
2. clarify,
3. Organize system requirements.
In this context, the term "system" refers to something being developed or operated,
such as a mail-order product sales and service Web site. Use case diagrams are
employed in UML (Unified Modeling Language), a standard notation for the modeling
of real-world objects and systems.
Purpose of Use Case Diagrams

The purpose of use case diagram is to capture the dynamic aspect of a system.
However, this definition is too generic to describe the purpose, as other four
diagrams (activity, sequence, collaboration, and Statechart) also have the same
purpose. We will look into some specific purpose, which will distinguish it from other
four diagrams.
In brief, the purposes of use case diagrams can be said to be as follows −
 Used to gather the requirements of a system.

 Used to get an outside view of a system.
 Identify the external and internal factors influencing the system.
 Show the interaction among the requirements are actors.
UML use case diagrams are ideal for:

 Representing the goals of system-user interactions
 Defining and organizing functional requirements in a system
 Specifying the context and requirements of a system
 Modeling the basic flow of events in a use case
Use Case Diagram objects

Use case diagrams consist of 4 objects.
 Actor
 Use case
 System
 Package
The objects are further explained below.
Actor
Actor in a use case diagram is any entity that performs a role in one given system.
This could be a person, organization or an external system and usually drawn like
skeleton shown below.
Use Case
A use case represents a function or an action within the system. It’s drawn as an
oval and named with the function.
System
The system is used to define the scope of the use case and drawn as a rectangle.
This an optional element but useful when you’re visualizing large systems. For
example, you can create all the use cases and then use the system object to define
the scope covered by your project. Or you can even use it to show the different areas
covered in different releases.
Package
The package is another optional element that is extremely useful in complex
diagrams. Similar to class diagrams, packages are used to group together use
cases. They are drawn like the image shown below.
How to Draw a Use Case Diagram?

Following is a sample use case diagram representing the order management system.
Hence, if we look into the diagram then we will find three use cases (Order,
SpecialOrder, and NormalOrder) and one actor which is the customer.
The SpecialOrder and NormalOrder use cases are extended from Order use case.
Hence, they have extended relationship. Another important point is to identify the
system boundary, which is shown in the picture. The actor Customer lies outside the
system as it is an external user of the system.
***************************************************************
Topic 5 Case study:the Next Gen POS system

The first case study is the NextGen point - of - sale (POS) system.
Case Study Focus
• Applications generally can be divided into 3 layers

– User interface
– Application logic
– Other components/layers
• Focus on application logic layer because:
Architectural Layers and Case Study Emphasis
A typical object-oriented information system is designed in terms of several

architectural layers or subsystems (see Figure 3.1). The following is not a complete
list, but provides an example:
 User Interface—graphical interface; windows.

 Application Logic and Domain Objects—software objects representing
domain concepts (for example, a software class named Sale) that fulfill
application requirements.
 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
OOAD is generally most relevant for modeling the application logic and
technical service layers.
 The NextGen case study primarily emphasizes the problem domain objects,
allocating responsibilities to them to fulfill the requirements of the application.
 Object-oriented design is also applied to create a technical service subsystem
for interfacing with a database.
 In this design approach, the UI layer has very little responsibility; it is said to
be thin. Windows do not contain code that performs application logic or
processing. Rather, task requests are forwarded on to other layers.
 In this apparently straightforward problem domain, we shall see that there are
interesting requirement and design problems to solve. In addition, it’s a real
problem groups really do develop POS systems with 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).
POS Support:
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 computer with something like a Java Swing graphical user interface, touch
screen input, wireless PDAs, and so forth.
Commercial POS System

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.
Development Strategy
Using an iterative development strategy, we are going to proceed through
 requirements,
 object –oriented analysis,
 design,
 and implementation.
Topic 6 Inception Concepts in OOAD
The life of a software system can be represented as a series of cycles. A cycle ends with the release of a
version of the system to customers.
Define Unified Process:

Within the Unified Process, each cycle contains four phases. A phase is simply the
span of time between two major milestones, points at which managers make
important decisions about whether to proceed with development and, if so, what's
required concerning project scope, budget, and schedule.
Each phase contains one or more iterations. We'll explore the concept of iterations in
the section "Iterations and Increments"
The following subsections describe the key aspects of each of these phases.
Inception
The primary goal of the Inception phase is to establish the case for the viability of
the proposed system.
The tasks that a project team performs during Inception include the following:
 Defining the scope of the system (that is, what's in and what's out)
 Outlining a candidate architecture, which is made up of initial versions of six
different models
 Identifying critical risks and determining when and how the project will
address them
 Starting to make the business case that the project is worth doing, based on
initial estimates of cost, effort, schedule, and product quality
The concept of candidate architecture is discussed in the section "Architecture-

Centric" later in this chapter. The six models are covered in the next major section of
this chapter, "The Five Workflows."
The major milestone associated with the Inception phase is called Life-Cycle
Objectives. The indications that the project has reached this milestone include the
following:
 The major stakeholders agree on the scope of the proposed system.

 The candidate architecture clearly addresses a set of critical high-level
requirements.
 The business case for the project is strong enough to justify a green light for
continued development.
Elaboration
The primary goal of the Elaboration phase is to establish the ability to build the new
system given the financial constraints, schedule constraints, and other kinds of
constraints that the development project faces.
The tasks that a project team performs during Elaboration include the following:
 Capturing a healthy majority of the remaining functional requirements

 Expanding the candidate architecture into a full architectural baseline, which
is an internal release of the system focused on describing the architecture
 Addressing significant risks on an ongoing basis
 Finalizing the business case for the project and preparing a project plan that
contains sufficient detail to guide the next phase of the project (Construction)
The architectural baseline contains expanded versions of the six models initialized
during the Inception phase.The major milestone associated with the Elaboration
phase is called Life-Cycle Architecture.
The indications that the project has reached this milestone include the following:
 Most of the functional requirements for the new system have been captured in
the use case model.
 The architectural baseline is a small, skinny system that will serve as a solid
foundation for ongoing development.The business case has received a green
light, and the project team has an initial project plan that describes how the
Construction phase will proceed.
The use case model is described in the upcoming section "The Five Workflows." Risks
are discussed in the section "Iterations and Increments" later in this chapter.
Construction
 The primary goal of the Construction phase is to build a system capable of

operating successfully in beta customer environments.
 During Construction, the project team performs tasks that involve building the
system iteratively and incrementally (see "Iterations and Increments" later in
this chapter), making sure that the viability of the system is always evident in
executable form.
 The major milestone associated with the Construction phase is called Initial
Operational Capability. The project has reached this milestone if a set of beta
customers has a more or less fully operational system in their hands.
Transition
 The primary goal of the Transition phase is to roll out the fully functional
system to customers.
 During Transition, the project team focuses on correcting defects and
modifying the system to correct previously unidentified problems.
 The major milestone associated with the Transition phase is called Product
Release.
***************************************************************
Topic 7 Use Case Modelling in OOAD
Define Use Case Modelling
A use-case model is a model of how different types of users interact with the system
to solve a problem. As such, it describes the goals of the users, the interactions
between the users and the system, and the required behavior of the system in
satisfying these goals.
A use-case model consists of a number of model elements. The most mportant

model elements are:
 use cases,
 actors
 and the relationships between them.
The use-case model may contain packages that are used to structure the model
to simplify
 analysis,
 communications,
 navigation,
 development,
 maintenance
 and planning.
Basic model elements

The use-case model contains, as a minimum, the following basic model elements.
Actor
A model element representing each actor. Properties include the actors name and
brief description. See Concept: Actor for more information.
Use Case
A model element representing each use case. Properties include the use case name
and use case specification. See Artifact: Use Case and Concept: Use Case for more
information.
Associations
Associations are used to describe the relationships between actors and the use cases
they participate in. This relationship is commonly known as a “communicates-
association”.
Advanced model elements

The use-case model may also contain the following advanced model elements.
Subject
A model element that represents the boundary of the system of interest.
Use-Case Package
A model element used to structure the use case model to simplify analysis,
communications, navigation, and planning. If there are many use cases or actors,
you can use use-case packages to further structure the use-case model in much the
same manner you use folders or directories to structure the information on your
hard-disk.
You can partition a use-case model into use-case packages for several reasons,
including:
 To reflect the order, configuration, or delivery units in the finished system thus
supporting iteration planning.
 To support parallel development by dividing the problem into bite-sized pieces.
 To simplify communication with different stakeholders by creating packages for
containing use cases and actors relevant to a particular stakeholder.
Generalizations
A relationship between actors to support re-use of common properties.
Dependencies
A number of dependency types between use cases are defined in UML. In particular,
<<extend>> and <<include>>.
<<extend>> is used to include optional behavior from an extending use case in an
extended use case.
<<include>> is used to include common behavior from an included use case into a
base use case in order to support re-use of common behavior.
The latter is the most widely used dependency and is useful for:
 Factoring out behavior from the base use case that is not necessary for the
understanding of the primary purpose of the use case to simplify
communications.
 Factoring out behavior that is in common for two or more use cases to
maximize re-use, simplify maintenance and ensure consistency.Example Use-
Case Diagram
Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-
case model.

**********************************************************
Toipc 8 Relating Use Cases Include, Extend and Generalization
In UML, a relationship is a connection between model elements. A UML relationship

is a type of model element that adds semantics to a model by defining the structure
and behavior between the model elements.
UML relationships are grouped into the following categories:
Category Function
Activity edges Represent the flow between activities
Associations Indicate that instances of one model element are connected to
instances of another model element
Dependencies Indicate that a change to one model element can affect another
model element
Generalizations Indicate that one model element is a specialization of another model
element
Realizations Indicate that one model element provides a specification that
another model element implements
Transitions Represent changes in state
You can set properties and use keywords to create variations of these relationships.
The following topics describe the relationships that you can use in use-case
diagrams:
 Association relationships
In UML models, an association is a relationship between two classifiers, such
as classes or use cases, that describes the reasons for the relationship and the
rules that govern the relationship.
 Generalization relationships
In UML modeling, a generalization relationship is a relationship in which one
model element (the child) is based on another model element (the parent).
Generalization relationships are used in class, component, deployment, and
use-case diagrams to indicate that the child receives all of the attributes,
operations, and relationships that are defined in the parent.
 Include relationships
In UML modeling, an include relationship is a relationship in which one use
case (the base use case) includes the functionality of another use case (the
inclusion use case). The include relationship supports the reuse of
functionality in a use-case model.
 Extend relationships
In UML modeling, you can use an extend relationship to specify that one use
case (extension) extends the behavior of another use case (base). This type of
relationship reveals details about a system or application that are typically
hidden in a use case.
There can be 5 relationship types in a use case diagram.
 Association between actor and use case

 Generalization of an actor
 Extend between two use cases
 Include between two use cases
 Generalization of a use case
Let’s take a look at these relationships in detail.
Association Between Actor and Use Case

This one is straightforward and present in every use case diagram. Few things to
note.
 An actor must be associated with at least one use case.

 An actor can be associated with multiple use cases.
 Multiple actors can be associated with a single use case.
Different ways association relationship appears in use case diagrams
Check out the use case diagram guidelines for other things to consider when adding
an actor.
Generalization of an Actor
Generalization of an actor means that one actor can inherit the role of the other
actor. The descendant inherits all the use cases of the ancestor. The descendant has
one or more use cases that are specific to that role. Let’s expand the previous use
case diagram to show the generalization of an actor.
A generalized actor in an use case diagram
Extend Relationship Between Two Use Cases

Many people confuse the extend relationship in use cases. As the name implies it
extends the base use case and adds more functionality to the system. Here are a few
things to consider when using the <<extend>> relationship.
 The extending use case is dependent on the extended (base) use case. In
the below diagram the “Calculate Bonus” use case doesn’t make much sense
without the “Deposit Funds” use case.
 The extending use case is usually optional and can be triggered
conditionally. In the diagram, you can see that the extending use case is
triggered only for deposits over 10,000 or when the age is over 55.
 The extended (base) use case must be meaningful on its own. This means it
should be independent and must not rely on the behavior of the extending use
case.
Lets expand our current example to show the <<extend>> relationship.

Extend relationship in use case diagrams
Although extending use case is optional most of the time it is not a must. An
extending use case can have non-optional behavior as well. This mostly happens
when your modeling complex behaviors.
For example, in an accounting system, one use case might be “Add Account Ledger
Entry”. This might have extending use cases “Add Tax Ledger Entry” and “Add
Payment Ledger Entry”. These are not optional but depend on the account ledger
entry. Also, they have their own specific behavior to be modeled as a separate use
case.
Include Relationship Between Two Use Cases

Include relationship show that the behavior of the included use case is part of the
including (base) use case. The main reason for this is to reuse common
actions across multiple use cases. In some situations, this is done to simplify
complex behaviors. Few things to consider when using the <<include>> relationship.
 The base use case is incomplete without the included use case.
 The included use case is mandatory and not optional.
Lest expand our banking system use case diagram to show include relationships as
well.
Includes is usually used to model common behavior
For some further reading regarding the difference between extend and include
relationships in use case diagrams check this StackOverflow link.
Generalization of a Use Case

This is similar to the generalization of an actor. The behavior of the ancestor is
inherited by the descendant. This is used when there is common behavior between
two use cases and also specialized behavior specific to each use case.
For example, in the previous banking example, there might be a use case called “Pay
Bills”. This can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

*********************************************************************
Topic 9 When to use Use-Cases in OOAD
A Process for Writing Use Cases

A use-case model includes actors, use cases and the relationships between actors
and use cases. These elements will emerge incrementally and become more refined
over time. For example, you might start out by identifying an actor which suggests a
use case and in the process of detailing the use case you discover another actor.
You can develop the elements of a use-case model in any order but the following
sequence of steps tends to be most efficient.
Step 1: Identify Actors
The actors represent users and external systems that will interact with the system
under development. Actors represent categories of users or external systems. One
way to identify actors is to list the specific users that will use the system and then
organize them into categories based on their role or the purpose they have for using
the system.
Less obvious actors include system maintenance and admin personnel.
Example:
Consider the task of finding actors for a software system which simulates a virtual
mall. A virtual mall connects buyers and merchants.
Potential actors are:
Customer - A customer represents any person who uses the services of the virtual
mall.
Affiliate - An affiliate represents a person or organization who is authorized to sell
merchandise at the virtual mall.
Credit Bureau - A credit bureau represents an external system used to verify the
creditworthiness of a customer.
Step 2: Identify Use Cases

This step may be performed simultaneously with the previous step. Finding an actor
may suggest a use case which may suggest another actor.Many development projects
start with a high-level list of desired features.
For example, the feature list for a virtual mall might include:
1) list item for sale,
2) browse items for sale,
3) purchase an item. Each feature is a potential use case.
Interviews
Use cases emerge during interviews with the client and end users of the system. The
ways that actors use the system will also suggest use cases.
During this step it's sufficient to name each use case and provide a short description
of the use case.
During the next step you will describe each use case in detail. A use case name
should include a noun and a verb. Usually the name will start with an action verb
followed by a noun which represents the recipient of the action. The name should
suggest what is achieved by the use case.
For example: deactivate alarm, post article, find and read article.
Scope
During this step and the next you will need to determine the scope of each use case.
For a given activity the challenge is to decide if the activity should be a use case by
itself or be included as a part of another use case. Use cases tend to split and
combine like lava in a lava lamp until they settle into an well organized group. A well
organized group is one that is easy to understand, review, test, and implement in one
iteration.
Example:
The use cases that emerge from exploring how each actor gets value from or provides
value to the system are:
Browse Inventory - This use cases is used by a customer to shop for items to
purchase.
Purchase an Item - This use case is used by a customer to purchase an item.

Offer Item For Sale - This use case is used by an affiliate to make an item available
for purchase.
The following UML use-case diagram shows the relationships between actors and use
cases:
Step 3: Prioritize Use Cases
There are two reasons to prioritize use cases.
First, it helps determine what order the uses cases will be implemented.
Implementing the highest priority use cases first reduces the risk a high priority item
won't make the schedule and provides more time to insure the item is implemented
correctly.
Second, a prioritized list of use cases helps establish architecture. A system

structure that is organized around high priority use cases tends to be more stable
over time.
Step 4: Elaborate Use Cases
Developers work from use cases when they implement the system. Therefore, they
must contain all the details of interaction between actors and the system.
It's convenient to organize the interaction between a use case and its associated
actors as a flow of events with one common flow of events though the use case and
zero or more alternate paths or variations. Each path through the use case is called a
scenario. Alternate paths can be listed inline with the common path description or
separately after the common path description. It may be helpful to number the steps
of the use case to indicate order and to facilitate referencing portions of a use case.
Example:
Purchase an Item - This use case is used by a customer to purchase an item.
UNIT II STATIC UML DIAGRAMS
Class Diagram–– Elaboration – Domain Model – Finding conceptual classes and

description classes – Associations – Attributes – Domain model refinement – Finding
conceptual class Hierarchies – Aggregation and Composition – Relationship between
sequence diagrams and use cases – When to use Class Diagrams
Topic 1 Class Diagram in OOAD
Class Diagram gives the static view of an application. A class diagram describes the
types of objects in the system and the different types of relationships that exist
among them. This modeling method can run with almost all Object-Oriented
Methods. A class can refer to another class. A class can have its objects or may
inherit from other classes.
Class diagram shows a collection of
 classes,
 interfaces,
 associations
 collaborations
 and constraints.
It is also known as a structural diagram.

Class diagrams are the main building block in object-oriented modeling. They are
used to show the different objects in a system, their attributes, their operations and
the relationships among them.
The following figure is an example of a simple class:
Simple class diagram with attributes and operations
In the example, a class called “loan account” is depicted. Classes in class diagrams
are represented by boxes that are partitioned into three:
1. The top partition contains the name of the class.

2. The middle part contains the class’s attributes.
3. The bottom partition shows the possible operations that are associated with
the class.
Basic Class Diagram Symbols and Notations
Class
A class represents a relevant concept from the domain, a set of persons, objects, or
ideas that are depicted in the IT system:
Examples of classes are passengers, planes, or tickets.
Attribute
An attribute of a class represents a characteristic of a class that is of interest for the
user of the IT system:
Characteristics of interest of a passenger, for example, are name and age.

Generalization
Generalization is a relationship between two classes: a general class and a special
class:
Association
An association represents a relationship between two classes:
An association indicates that objects of one class have a relationship with objects of
another class, in which this connection has a specifically defined meaning (for
example, “is flown with”).
Multiplicity
A multiplicity allows for statements about the number of objects that are involved in
an association:
Also see Figure 4.32.
Aggregation
An aggregation is a special case of an association (see above) meaning “consists of”:
The diamond documents this meaning; a caption is unnecessary.
Purpose of Class Diagrams

The purpose of class diagram is to model the static view of an application. Class
diagrams are the only diagrams which can be directly mapped with object-oriented
languages and thus widely used at the time of construction.
The purpose of the class diagram can be summarized as −
 Analysis and design of the static view of an application.

 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.
Benefits of Class Diagram
 Class Diagram Illustrates data models for even very complex information
systems
 It provides an overview of how the application is structured before studying the
actual code. This can easily reduce the maintenance time
 It helps for better understanding of general schematics of an application.
 Allows drawing detailed charts which highlights code required to be
programmed
 Helpful for developers and other stakeholders.
Class diagram is basically a graphical representation of the static view of the system
and represents different aspects of the application. A collection of class diagrams
represent the whole system.
The following points should be remembered while drawing a class diagram −
 The name of the class diagram should be meaningful to describe the aspect of
the system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly
identified
 For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. At the
end of the drawing it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain
paper and reworked as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It

describes a particular aspect of the entire application.
 First of all, Order and Customer are identified as the two elements of the
system. They have a one-to-many relationship because a customer can have
multiple orders.
 Order class is an abstract class and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In
addition, they have additional functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned
above.
Class diagram examples
Online Shopping Cart class diagram

Pattern Adapter class diagram
Topic 2 Elaboration Concepts in OOAD

Elaboration
The primary goal of the Elaboration phase is to establish the ability to build the new
system given the financial constraints, schedule constraints, and other kinds of
constraints that the development project faces.
The tasks that a project team performs during Elaboration include the following:
 Capturing a healthy majority of the remaining functional requirements
 Expanding the candidate architecture into a full architectural baseline, which
is an internal release of the system focused on describing the architecture
 Addressing significant risks on an ongoing basis
 Finalizing the business case for the project and preparing a project plan that
contains sufficient detail to guide the next phase of the project (Construction)
The architectural baseline contains expanded versions of the six models initialized
during the Inception phase.
The major milestone associated with the Elaboration phase is called Life-Cycle
Architecture. The indications that the project has reached this milestone include the
following:
 Most of the functional requirements for the new system have been captured in
the use case model.
 The architectural baseline is a small, skinny system that will serve as a solid
foundation for ongoing development.
 The business case has received a green light, and the project team has an
initial project plan that describes how the Construction phase will proceed.
Elaborationis the initial series of iterations during which, on a normal project:
 the core, risky software architecture is programmed and tested

 the majority of requirements are discovered and stabilized
 the major risks are mitigated or retired
Elaboration is the initial series of iterations during which the team does serious
investigation, implements (programs and tests) the core architecture, clarifies most
requirements, and tackles the high - risk issues. In the UP, "risk" includes business
value. Therefore, early work may include implementing scenarios that are deemed
important, but are not especially technically risky.
Elaboration often consists of two or more iterations; each iteration is recommended

to be between two and six weeks; prefer the shorter versions unless the team size is
massive. Each iteration is timeboxed, meaning its end date is fixed.
Elaboration is not a design phase or a phase when the models are fully developed in
preparation for implementation in the construction step - that would be an example
of superimposing waterfall ideas on iterative development and the UP.
During this phase, one is not creating throw - away prototypes; rather, the code and
design are production - quality portions of the final system. In some UP descriptions,
the potentially misunderstood term "architectural prototype"is used to describe the
partial system. This is not meant to be a prototype in the sense of a discardable
experiment; in the UP, it means a production subset of the final system. More
commonly it is called the executable architectureor architectural baseline.
Some key ideas and best practices will manifest in elaboration:

 do short timeboxed risk - driven iterations
 start programming early
 adaptively design, implement, and test the core and risky parts of the
architecture
 test early, often, realistically
 adapt based on feedback from tests, users, developers
 write most of the use cases and other requirements in detail, through a series
of workshops, once per elaboration iteration.
What Artifacts May Start in Elaboration?

Table lists sample artifacts that may be started in elaboration, and indicates the
issues they address. Subsequent chapters will examine some of these in greater
detail, especially the Domain Model and Design Model. For brevity, the table excludes
artifacts that may have begun in inception; it introduces artifacts that are more likely
to start in elaboration. Note these will not be completed in one iteration; rather, they
will be refined over a series of iterations.
Table 8.1 Sample elaboration artifacts, excluding those started in inception
You Know You Didn't Understand Elaboration When...
 It is more than "a few" months long for most projects.

 It only has one iteration (with rare exceptions for well - understood problems).
 Most requirements were defined before elaboration.
 The risky elements and core architecture are not being tackled.
 It does not result in an executable architecture; there is no production - code
programming.
 It is considered primarily a requirements or design phase, preceding an
implementation phase in construction.
 There is an attempt to do a full and careful design before programming.
 Thereisminimal feedbackandadaptation; usersarenot continually engaged in
evaluation and feedback.
 There is no early and realistic testing.
 The architecture is speculatively finalized before programming.

Topic 3 Domain Model in OOAD
A domain model is a visual representation of conceptual classes or real - situation

objects in a domain [M095, Fowler96]. Domain models have also been
called conceptual models (the term used in the first edition of this book), domain
object models, and analysis object models.
 "A domain model is a representation of real-world conceptual classes, not of

software components."
 Domain modeling is a technique used to understand the project problem
description and to translate the requirements of that project into software
components of a solution. The software components are commonly
implemented in an object oriented programming language.
 A domain model contains conceptual classes, associations between conceptual
classes, and attributes of a conceptual class. "Informally, a conceptual class is
an idea, thing, or object".
The UP defines the Domain Model as one of the artifacts that may be created in the
Business Modeling discipline. More precisely, the UP Domain Model is a
specialization of the UP Business Object Model (BOM) "focusing on explaining
'things' and products important to a business domain" [RUP]. That is, a Domain
Model focuses on one domain, such as POS related things.
The more broad BOM, not covered in this introductory text and not something I
encourage creating (because it can lead to too much up - front modeling), is an
expanded, often very large and difficult to create, multi - domain model that covers
the entire business and all its sub - domains.
Applying UML notation, a domain model is illustrated with a set of class diagrams in
which no operations (method signatures) are defined. It provides a conceptual
perspective. lt may show:
 domain objects or conceptual classes

 associations between conceptual classes
 attributes of conceptual classes
Domain models
Domain models are the initial artifacts created in Object-Oriented-Analysis. An object
has:
 identity,
 state, and
 behaviour.
An object can be
 related to other objects and

 complex (with sub-objects).
A class is a description of a set of objects that share the same attributes,

operations/responsibilities, relationships and semantics.
Identifying objects in the problem domain is used to identify conceptual classes in
the problem domain. Conceptual classes model entities in the problem domain, not
in the software domain.
Identifying Conceptual Classes
1. Modify or reuse an existing model.

2. Use a conceptual class category list.
3. Identify noun phrases.
Categories in no particular order.
 Physical or tangible objects: quiz, game piece, die

 Specification, designs, or description of things: game piece image, marking
scheme
 transaction: game move, order item, work item grade
 roles of people: marker, instructor, player
 container of things: game board, card deck
 events: start turn, finish game
 rules and policy: games ruler, submit assignment policy
 records: work item grade
Using noun phrases

Conceptual class can be identified by studying the use case looking for relevant noun
phrases. Just like search term used in an Internet search engine, not all nouns are
relevant.
Some heuristics for identification are:
 terms that developers or users need to clarify in order to understand the use
case,
 recurring nouns (higher frequency),
 real world entities that the system needs to track,
 real world activities
 data sources or sinks
Category List for Associations
 A is a physical part of B. Memory is part of a CPU.

 A is a logical part of B. The p tag is grouped by a div tag.
 A is contained in B. A card is in a deck.
 A is a description of B. A house plan describes a house.
 A is a line item of B. A part in a part list.
 A is reported in B. An error event is reported in a log.
 A is a member of B. A faculty member is a member of a department.
 A used B. Tax rules are used to calculate the total in a point of sales terminal.
 A communicates with B. A computer communicates with a printer.
Heuristics for Identifying Associations

Some heuristics for identifying associations are:
 examine verb phrases,

 ensure that the roles and association names are clear,
 only add an association if it impoves the understanding of the domain,
 wait until the list of associations are stable before considering the multipicity,
Identifying Attributes
An attribute is a logical data (property) of an object (e.g., my eyes are hazel). Most
attributes can be represented by simple data types (which are?).
Some heuristics for identifying attributes:
 an attribute is part of the state of an object (a car's speed is 100 km/h, weight
of a work item)
 attributes are required by the use case (i.e., ignore irrelevant attributes).
Judgment is required to separate attributes from associated classes.

Making a domain model
1. Identify conceptual classes

2. Draw the class diagram
3. Add any associations between classes
4. Add attributes (properties) to the classes
Larman suggest that domain modeling should be similar to map making.
 use existing names (do not invent your own)

 exclude irrelevant features (that is the basis of modeling)
 do not add things that are not there.

*********************************************************
Topic 4 Finding Conceptual Classes and Description Classes in

OOAD
Conceptual Model
Once we’ve some use cases or user stories, the next thing we can do is create a
conceptual model of our system. It simply means you’re identifying the most
important objects.
You shouldn’t be worried about software object right now, but more generically what
are the things in the application that we need to be aware of.
Things like product, item, shopping cart, order, invoice, paycheck, spaceship,
asteroid, level, that’s what we’re identifying here. Some of them will become actual
classes and software object, but not all of them.
First time through it will be incomplete, and that’s absolutely normal to miss out
even important objects, things that you will discover later on during programming.
1. Identifying Objects
2. Refining Objects
3. Drawing Objects
3. Identifying Object Relationships
4. Identifying Object Behaviors
Finding Conceptual Class
 A conceptual model captures the important concepts and relationships in some

domain.
 Concepts are represented by classes, while relationships are represented by
associations.
 Packages represent groups of related classes and associations.
 Objects represent specific instances of classes.
For example a business might organize its concepts and relationships into three
packages:
Classes
 In the hr package we might find the Position and Person classes. Typical
attributes of persons and positions can be listed in the attribute compartments
of the respective class icons. Typical operations performed by persons and
positions can be listed in their operation compartments:
 In this example, an object representing a position, vice president for example,
has a title attribute of type String and an execute operation that takes a task,
t, as an input, and outputs a result.
 An object representing a person has four attributes: last name, first name, and
Social Security number, all of type String, and a salary of type Money and with
initial value $0.0. The person class has no operations specified at this point.
 It is often the case that operations correspond to responsibilities and are not
assigned to classes until the design phase. For this reason operation
compartments are often suppressed in domain models. Attribute
compartments can also be suppressed if they are not needed.
Note that the "-" sign indicates that the scope of an attribute or association endpoint
is private, visible only inside of the class. Other possible scopes are:
+ = public = system-wide scope
~ = package scope
# = protected = subclass scope
Generally speaking, the default for an attribute or association endpoint is private,
while the default for an operation is public.
Associations
 The relationship "Position X is filled by person Y" can be represented by an

association connecting Position and Person:
 Note that the name of an association can be decorated by a tiny arrow showing
which way the association is read. This helps distinguish a relationship from
its inverse.
 Note that the endpoints of an association can be decorated by:
 name = the name used by objects on one end to refer to objects on the other
end. For example, an employee refers to his position as his "role" while a
position refers to the employees filling it as its "actors."
 multiplicity = the number of objects that can be related to a given object. For
example, a given position, vice president, say, can be filled by by 0 or more
persons (indicated by "*"), while a given person, Joe Smith, say, can fill one
position.
Objects
Specific persons and positions can be represented using objects. Specific instances of
the filledBy relationship can be represented by links connecting the participating
objects:
Strategies to Find Conceptual Classes

1.Reuse or modify existing models
2.Identify noun phrases; linguistic analysis
3.Use a category list

Topic 5 Associations and Attributes in OOAD
Derived associations and derived attributes can be calculated from other

associations and attributes, respectively, on a class diagram. For example, an age
attribute of a Person can be derived if you know that Person's date of birth.
Each perspective brings its own interpretation of derived features on class diagrams.
The most critical of these has to do with the specification perspective. From this
angle, it is important to realize that derived features indicate a constraint between
values, not a statement of what is calculated and what is stored.
Properties of associations on UML class diagrams

 In a UML class diagram, you can draw associations between any pair of types.
A type is a class, interface, or enumeration.
 An association indicates that the system you are developing stores links of
some kind between the instances of the associated types. Generally, it does not
imply anything about the implementation of the links.
 For example, they might be pointers, rows in a table, cross-referenced names
in XML, and so on.
 An association is a diagrammatic method of showing an attribute or pair of
attributes.
 For example, if you have defined a class Restaurant to have an attribute of type
Menu, you can state the same definition by drawing an association between
Restaurant and Menu.
To draw an association, click Association in the toolbox, click the first type, then the
second. You can click the same type two times to show that instances can be linked
with other instances of the same type.
Properties
These are the properties of an association on a UML Class Diagram.
To see the properties of an association, right-click the association and then
click Properties. The properties will appear in the Properties window.Some of the
properties are also visible on the diagram, as shown in the following illustration.
Property Description
Name (1) Identifies the association. Also appears on the diagram near the mid-point of the
association.
Qualified Identifies the association uniquely. Prefixed with the qualified name of the package that
Name contains the association's first role.
Work Items The number of work items linked to this association. To link work items, see Link
model elements and work items.
Color The color of the connector. Unlike the other properties, this is a property of this view of
the association, not a property of the underlying relationship in the model.
First Role Each end of the association is called a role. Each role describes the properties of the
Second equivalent attribute on the class at the opposite end of the association.
Role In the example diagram, the association between Menu and Menu Item has roles called
Menu and Contents.
Contents is the name of an attribute on the Menu class.

Topic 6 Domain Model Refinement in OOAD

A domain model is a system of abstractions that describes selected aspects of a
sphere of knowledge, influence or activity .The model can then be used to solve
problems related to that domain. The domain model is a representation of
meaningful real-world concepts pertinent to the domain that need to be modeled in
software. The concepts include the data involved in the business and rules the
business uses in relation to that data.
A domain model generally uses the vocabulary of the domain, thus allowing a
representation of the model to be communicated to non-technical stakeholders. It
should not refer to any technical implementations such as databases or software
components that are being designed.
Business Object Model (BOM)

The UP defines the Domain Model as one of the artifacts that may be created in the
Business Modeling discipline. More precisely, the UP Domain Model is a
specialization of the UP Business Object Model (BOM) "focusing on explaining
'things' and products important to a business domain" [RUP]. That is, a Domain
Model focuses on one domain, such as POS related things.
The more broad BOM, not covered in this introductory text and not something I
encourage creating (because it can lead to too much up - front modeling), is an
expanded, often very large and difficult to create, multi - domain model that covers
the entire business and all its sub - domains.
Applying UML notation, a domain model is illustrated with a set of class diagrams in
which no operations (method signatures) are defined. It provides a conceptual
perspective. lt may show:
 domain objects or conceptual classes

 associations between conceptual classes
 attributes of conceptual classes
Therefore, the following elements are not suitable in a domain model:
 Software artifacts, such as a window or a database, unless the domain being

modeled is of software concepts, such as a model of graphical user interfaces.
 Responsibilities or methods.
A domain model shows real - situation conceptual classes, not software

classes
A domain model does not show software artifacts or classes

The domain model illustrates conceptual classes or vocabulary in the domain.
Informally, a conceptual classis an idea, thing, or object. More formally, a
conceptual class may be considered in terms of its symbol, intension, and extension
[M095].
 Symbol - words or images representing a conceptual class.
 Intension - the definition of a conceptual class.
 Extension - the set of examples to which the conceptual class applies.
For example, consider the conceptual class for the event of a purchase transaction. I
may choose to name it by the (English) symbol Sale. The intension of a Salemay
state that it "represents the event of a purchase transaction, and has a date and
time." The extension of Sale is all the examples of sales; in other words, the set of all
sale instances in the universe.
A conceptual class has a symbol, intension, and extension
Topic 7 Finding Conceptual Class Hierarchies in OOAD

class hierarchy
A class hierarchy or inheritance tree in computer science is a classification of
object types, denoting objects as the instantiations of classes (class is like a
blueprint, the object is what is built from that blueprint) inter-relating the various
classes by relationships such as "inherits", "extends", "is an abstraction of", "an
interface definition".
In object-oriented programming, a class is a template that defines the state and

behavior common to objects of a certain kind. A class can be defined in terms of
other classes.
The concept of class hierarchy in computer science is very similar to taxonomy, the
classifications of species.
The relationships are specified in the science of object-oriented design and object
interface standards defined by popular use, language designers
(Java, C++, Smalltalk, Visual Prolog) and standards committees for software design
like the Object Management Group.
Upcasting
 The class hierarchy can be as deep as needed. The Instance variables and
methods are inherited down through the levels and can be redefined according
to the requirement in a subclass. In general, the further down in the hierarchy
a class appears, the more specialized its behavior.
 When a message is sent to an object, it is passed up the inheritance tree
starting from the class of the receiving object until a definition is found for the
method. This process is called upcasting.
For example
consider the superclass Paymentand its subclasses (CashPayment, and so on).
Assume the definition of Payment is that it represents the transaction of transferring
money (not necessarily cash) for a purchase from one party to another, and that all
payments have an amount of money transferred.
Generalization and Class Sets

Conceptual subclasses and superclasses are related in terms of set membership.
Definition : All members of a conceptual subclass set are members of their superclass
set.
For example
in terms of set membership, all instances of the set CreditPayment are also members
of the set Payment.Most of the inheritence relationships are realized by template
parameterization! Therefore some of the inheritance links are not documented in a
inheritance graph in the reference. This picture shows the overall concept.
Topic 8 Aggregation and Composition in OOAD
Association
Association is a relationship between two objects. In other words, association defines
the multiplicity between objects. You may be aware of one-to-one, one-to-many,
many-to-one, many-to-many all these words define an association between objects.
Aggregation is a special form of association. Composition is a special form of
aggregation.
Example: A Student and a Faculty are having an association.
Aggregation
Aggregation is a special case of association. A directional association between
objects. When an object ‘has-a’ another object, then you have got an aggregation
between them. Direction between them specified which object contains the other
object. Aggregation is also called a “Has-a” relationship.
Composition
Composition is a special case of aggregation. In a more specific manner, a restricted
aggregation is called composition. When an object contains the other object, if the
contained object cannot exist without the existence of container object, then it is
called composition.
Example: A class contains students. A student cannot exist without a class. There
exists composition between class and students.
Aggregation and Composition

Aggregation or composition is a relationship among classes by which a class can be
made up of any combination of objects of other classes. It allows objects to be placed
directly within the body of other classes. Aggregation is referred as a “part–of” or
“has–a” relationship, with the ability to navigate from the whole to its parts. An
aggregate object is an object that is composed of one or more other objects.
Example
In the relationship, “a car has–a motor”, car is the whole object or the aggregate, and
the motor is a “part–of” the car. Aggregation may denote −
 Physical containment − Example, a computer is composed of monitor, CPU,

mouse, keyboard, and so on.
 Conceptual containment − Example, shareholder has–a share.
Comparison Chart
BASIS FOR AGGREGATION COMPOSITION
COMPARISON
Basic In aggregation there exhibit a In composition the cannot exist
relationship where a child can exist independently of the parent.
independently of the parent.
Type of "has a" "part of"
relationship
Association type Weak association Strong association
UML design Represented by a hollow diamond Represented by a solid diamond
symbol next to assembly class. next to assembly class.
Function The deletion of assembly doesn't If the owning class object is
affect its parts. deleted, it could significantly affect
the containing class object.
Key Differences Between Aggregation and Composition
1. Aggregation indicates a relationship where a child and parent entities can exist
independently. As against, in composition, the child entity is dependent on the
parent.
2. In aggregation there exist a “has a” relationship whereas in composition there
is a “part of” relationship between the assembly and constituent class objects.
3. Aggregation is weak association while the composition is a strong association
because it has more constraints.
4. In UML design the aggregation is described by a hollow diamond. In contrast,
the composition is pictured by a solid diamond.

TOPIC 9:Relationship Between Sequence and Use Cases in OOAD

Sequence diagram
Sequence diagrams are used to model the flow of logic within a system by showing
the information (also known as stimuli, or message) that is passed between the
objects during the execution of a scenario. It is a type of interaction diagram as it
describes how and in what order a group of objects (interface components or software
components) interact with one another. Sequence diagrams are also known as event
diagrams.
However, it does not show how the objects are related to each other.
Notation:
Objects are represented as boxes from left to right. Messages sent are represented as
horizontal arrows with name on top. Particular instances of each object are shown
with a lifeline below to indicate when the object is created and destroyed.
Earlier events are depicted at the top of the lifeline, with the later events shown
further down. Arrival of a stimulus at an object is called an event.
Sequence diagrams only specify the ordering of events and not the exact timings of
events. An activation box represents the period during which an operation is
executed.
Strengths
 Shows interactions between objects in visual and chronological (time) order.

 Refines use cases with more details.
Limitations
 Creating sequence diagram for every use case can be a waste of time and effort.
 Fairly technical.
Use case diagram
Use case diagram depicts how actors (a person or a system) interacts with a solution
to accomplish one or more of the person’s or systems goals. It visually depicts the
scope of the solution, the actors involved, and the use cases.
Notations:
Associations: Shows relationships between actors and use cases:
2 commonly used relationships are:
Extend: Allows for insertion of additional behavior into a use case. Here, base use
case gets extended by the extended use case. Extending use case is optional and its
execution ALWAYS depends on a condition. The point at which extension occurs is
called extension point.
The base use case (extended use case) is complete without the extending use case
where as the extending use case is incomplete without the base use case.
Include: Allows base use case to make use of the functionality present in another
use case. Included use case is ALWAYS executed. The base use case is incomplete
without the included use case.
Common function is represented by include relationship and is mandatory.
Additional function is represented by extend relationship and is non-mandatory.
Strengths
 Good at clarifying scope, and providing a high-level understanding of

requirements.
 Use case specifications make it easy to understand functional behavior of a
system.
Limitations
 Written at higher-level of abstraction (low level of detail).

 Lack of standardized formats.
 Need analysis to identify include use cases.

TOPIC 10: When to Use Class Diagrams in OOAD
When to Use Class Diagrams
Class diagrams are the backbone of nearly all OO methods, so you will find yourself
using them all the time. This chapter covers the basic concepts; Chapter 6 discusses
many of the advanced concepts.
The trouble with class diagrams is that they are so rich, they can be overwhelming to
use. Here are a few tips.
 Don't try to use all the notations available to you. Start with the simple stuff in
this chapter: classes, associations, attributes, generalization, and constraints.
Introduce other notations from Chapter 6 only when you need them.
 Fit the perspective from which you are drawing the models to the stage of the
project.
o If you are in analysis, draw conceptual models.
o When working with software, concentrate on specification models.
o Draw implementation models only when you are illustrating a particular
implementation technique.
 Don't draw models for everything; instead, concentrate on the key areas. It is
better to have a few diagrams that you use and keep up to date than to have
many forgotten, obsolete models.

UNIT III DYNAMIC AND IMPLEMENTATION UML DIAGRAMS
Dynamic Diagrams – UML interaction diagrams – System sequence diagram –

Collaboration diagram – When to use Communication Diagrams – State machine
diagram and Modelling –When to use State Diagrams – Activity diagram – When to
use activity diagrams Implementation Diagrams – UML package diagram – When to
use package diagrams – Component and Deployment Diagrams – When to use
Component and Deployment diagrams
TOPIC 1: Dynamic and Interaction Diagram in OOAD
There are two kinds of object models:
 Dynamic
 Static.
Dynamic models
such as UML interaction diagrams (sequence diagrams or communication
diagrams), help design the logic, the behavior of the code or the method bodies.
They tend to be the more interesting, difficult, important diagrams to create.
Static models
such as UML class diagrams, help design the definition of packages, class names,
attributes, and method signatures .
Static and dynamic UML diagrams for object modeling
There's a relationship between static and dynamic modeling and the agile modeling
practice of create models in parallel: Spend a short period of time on interaction
diagrams (dynamics), then switch to a wall of related class diagrams (statics).
UML - Interaction Diagrams
 From the term Interaction, it is clear that the diagram is used to describe some
type of interactions among the different elements in the model. 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. The basic purpose of both
the diagrams are similar.
The purpose of interaction diagram is −
 To capture the dynamic behaviour of a system.

 To describe the message flow in the system.
 To describe the structural organization of the objects.
 To describe the interaction among objects.
Interaction diagrams come in two forms, both present in the UML. The first form is
the sequence diagram. In this form objects are shown as vertical lines with the
messages as horizontal lines between them.
This form was first popularized by Jacobson. The diagram below shows this form in
its UML notation. The sequence of messages is indicated by reading down the page.
Figure 1: A sequence diagram.
The second form of the interaction diagram is the collaboration diagram. Here the
example objects are shown as icons. Again arrows indicate the messages sent in the
use case.
When to Use Them

Interaction diagrams should be used when you want to look at the behavior of
several objects within a single use case. They are good at showing the collaborations
between the objects, they are not so good at precise definition of the behavior.
TOPIC2: System Sequence and Collaboration Diagram in OOAD
Sequence diagram and Collaboration diagram
A Sequence diagram is an interaction diagram that details about the operation that
is carried out. Sequence diagram captures the interaction between the objects in the
context of collaboration. Sequence diagrams are time focused and they show the
order of the interaction visually by using the vertical axis of the diagram to represent
time.
Example:
Collaboration Diagram represents the interaction of the objects to perform the
behavior of a particular use case or a part of use case. The designers use the
Sequence diagram and Collaboration Diagrams to define and clarify the roles of the
objects that perform a particular flow of events of a use case.
Example:
Similarities Between Sequence and Collaboration Diagram
1. In Unified Modelling Language both the sequence diagram and collaboration
diagram are used as interaction diagrams.
2. Both the diagrams details about the behavioral aspects of the system.
Differences Between Sequence and Collaboration diagram:
SEQUENCE DIAGRAMS COLLABORATION DIAGRAMS

The sequence diagram represents the The collaboration diagram also comes
UML, which is used to visualize the under the UML representation which is
sequence of calls in a system that is used to visualize the organization of the
used to perform a specific objects and their interaction.
functionality.
The sequence diagram are used to The collaboration diagram are used to
represent the sequence of messages represent the structural organization of
that are flowing from one object to the system and the messages that are
another. sent and received.
The sequence diagram is used when The collaboration dagram is used when
time sequence is main focus. object organization is main focus.
The sequence diagrams are better The collaboration diagrams are better
suited of analysis activities. suited for depicting simpler interactions
of the smaller number of objects.
Topic 3 When to use Communication Diagrams
UML communication diagrams, like the sequence diagrams - a kind of interaction

diagram, shows how objects interact. A communication diagram is an extension of
object diagram that shows the objects along with the messages that travel from one
to another. In addition to the associations among objects, communication diagram
shows the messages the objects send each other.
Purpose of Communication Diagram
 Model message passing between objects or roles that deliver the functionalities
of use cases and operations
 Model mechanisms within the architectural design of the system
 Capture interactions that show the passed messages between objects and roles
within the collaboration scenario
 Model alternative scenarios within use cases or operations that involve the
collaboration of different objects and interactions
 Support the identification of objects (hence classes), and their attributes
(parameters of message) and operations (messages) that participate in use
cases
Communication Diagram at a Glance
In the example of the notation for a communication diagram, objects (actors in use
cases) are represented by rectangles. In the example (generic communication
diagram):
 The objects are Object1, Object2, Object..., ObjectN-1 ..., and ObjectN.
 Messages passed between objects are represented by labeled arrows that start
with the sending object (actor) and end with the receiving object.
 The sample messages passed between objects are labeled 1: message1, 2:
message2, 3: message3, etc., where the numerical prefix to the message name
indicates its order in the sequence.
 Object1 first sends Object2 the message message1, Object2 in turn sends
ObjectN-1 the message message2, and so on.
 Messages that objects send to themselves are indicated as loops (e.g., message
message5).
Communication Example - Hotel Reservation
 Each message in a communication diagram has a sequence number.

 The top-level message is numbered 1.
 Messages sent during the same call have the same decimal prefix, but suffixes
of 1, 2, etc. according to when they occur.
For example, in the communication diagram in the figure below, you can follow the
sequence numbers to determine the order of messages between objects:
TOPIC 4:State Machine Diagram and Modeling
State machine diagrams are also called as state chart diagrams. State machine
diagrams are used to capture the behavior of a software system. UML State machine
diagrams can be used to model the behavior of a class, a subsystem, a package, or
even an entire system. It is also called a Statechart or State Transition diagram.
Statechart diagrams provide us an efficient way to model the interactions or

communication that occur within the external entities and a system. These diagrams
are used to model the event-based system. A state of an object is controlled with the
help of an event.
Statechart diagrams are used to describe various states of an entity within the
application system.
There are a total of two types of state machine diagrams:
1. Behavioral state machine
 It captures the behavior of an entity present in the system.

 It is used to represent the specific implementation of an element.
 The behavior of a system can be modelled using behavioral state machine
diagrams.
2. Protocol state machine
 These diagrams are used to capture the behavior of a protocol.

 It represents how the state of protocol changes concerning the event. It also
represents corresponding changes in the system.
 They do not represent the specific implementation of an element.
Why State Machine Diagram?
Statechart diagram is used to capture the dynamic aspect of a system. State machine
diagrams are used to represent the behavior of an application. An object goes
through various states during its lifespan. The lifespan of an object remains until the
program is terminated. The object goes from multiple states depending upon the
event that occurs within the object. Each state represents some unique information
about the object.
Notation and Symbol for State Machine
Following are the various notations that are used throughout the state chart
diagram. All these notations, when combined, make up a single diagram.
UML state diagram notations
Initial state
The initial state symbol is used to indicate the beginning of a state machine diagram.
Final state
This symbol is used to indicate the end of a state machine diagram.
Decision box
It contains a condition. Depending upon the result of an evaluated guard condition, a

new path is taken for program execution.
Transition
A transition is a change in one state into another state which is occurred because of
some event. A transition causes a change in the state of an object.
State box
It is a specific moment in the lifespan of an object. It is defined using some condition

or a statement within the classifier body. It is used to represent any static as well as
dynamic situations.
Types of State
Unified Modeling Language defines three types of states:
 Simple state
o They do not have any substrate.
 Composite state
o These types of states can have one or more than one substrate.
o A composite state with two or more substates is called an orthogonal
state.
 Submachine state
o These states are semantically equal to the composite states.
o Unlike the composite state, we can reuse the submachine states.
How to draw a Statechart diagram?
Following rules must be considered while drawing a state chart diagram:
1. The name of a state transaction must be unique.

2. The name of a state must be easily understandable and describe the behavior
of a state.
3. If there are multiple objects, then only essential objects should be
implemented.
4. Proper names for each transition and an event must be given.
When to use State Diagrams?

State char diagrams are used,
1. To model objects of a system.

2. To model and implement interactive systems.
3. To display events that trigger changes within the states.
Example of State Machine

Following state chart diagram represents the user authentication process.
TOPIC5: When to Use State Diagrams in OOAD
From the above discussion, we can define the practical applications of a Statechart
diagram. Statechart diagrams are used to model the dynamic aspect of a system like
other four diagrams discussed in this tutorial. However, it has some distinguishing
characteristics for modeling the dynamic nature.
Statechart diagram defines the states of a component and these state changes are
dynamic in nature. Its specific purpose is to define the state changes triggered by
events. Events are internal or external factors influencing the system.
Statechart diagrams are used to model the states and also the events operating on
the system. When implementing a system, it is very important to clarify different
states of an object during its life time and Statechart diagrams are used for this
purpose. When these states and events are identified, they are used to model it and
these models are used during the implementation of the system.
If we look into the practical implementation of Statechart diagram, then it is mainly

used to analyze the object states influenced by events. This analysis is helpful to
understand the system behavior during its execution.
The main usage can be described as −
 To model the object states of a system.

 To model the reactive system. Reactive system consists of reactive objects.
 To identify the events responsible for state changes.
 Forward and reverse engineering.

TOPIC 6: Activity Diagram and When to Use in OOAD
What is an Activity Diagram?

An activity diagram visually presents a series of actions or flow of control in a system
similar to a flowchart or a data flow diagram. Activity diagrams are often used in
business process modeling. They can also describe the steps in a use case diagram.
Activities modeled can be sequential and concurrent. In both cases an activity
diagram will have a beginning (an initial state) and an end (a final state).
Basic Activity Diagram Notations and Symbols
Initial State or Start Point

A small filled circle followed by an arrow represents the initial action state or the
start point for any activity diagram. For activity diagram using swimlanes, make sure
the start point is placed in the top left corner of the first column.
Activity or Action State

An action state represents the non-interruptible action of objects. You can draw an
action state in SmartDraw using a rectangle with rounded corners.
Action Flow
Action flows, also called edges and paths, illustrate the transitions from one action
state to another. They are usually drawn with an arrowed line.
Object Flow
Object flow refers to the creation and modification of objects by activities. An object
flow arrow from an action to an object means that the action creates or influences
the object. An object flow arrow from an object to an action indicates that the action
state uses the object.
Decisions and Branching

A diamond represents a decision with alternate paths. When an activity requires a
decision prior to moving on to the next activity, add a diamond between the two
activities. The outgoing alternates should be labeled with a condition or guard
expression. You can also label one of the paths "else."
Guards
In UML, guards are a statement written next to a decision diamond that must be true
before moving next to the next activity. These are not essential, but are useful when
a specific answer, such as "Yes, three labels are printed," is needed before moving
forward.
Synchronization
A fork node is used to split a single incoming flow into multiple concurrent flows. It is
represented as a straight, slightly thicker line in an activity diagram.
A join node joins multiple concurrent flows back into a single outgoing flow.
A fork and join mode used together are often referred to as synchronization.
Time Event
This refers to an event that stops the flow for a time; an hourglass depicts it.
Merge Event
A merge event brings together multiple flows that are not concurrent.
Sent and Received Signals
Signals represent how activities can be modified from outside the system. They
usually appear in pairs of sent and received signals, because the state can't change
until a response is received, much like synchronous messages in a sequence
diagram. For example, an authorization of payment is needed before an order can be
completed.
Interrupting Edge
An event, such as a cancellation, that interrupts the flow denoted with a lightning
bolt.
Swimlanes
Swimlanes group related activities into one column.
Final State or End Point
An arrow pointing to a filled circle nested inside another circle represents the final action state.
When to Use Activity Diagram
We use Activity Diagrams to illustrate the flow of control in a system and refer to
the steps involved in the execution of a use case. We model sequential and
concurrent activities using activity diagrams. So, we basically depict workflows
visually using an activity diagram. An activity diagram focuses on condition of flow
and the sequence in which it happens. We describe or depict what causes a
particular event using an activity diagram.
Activity diagram is suitable for modeling the activity flow of the system. An
application can have multiple systems. Activity diagram also captures these systems
and describes the flow from one system to another. This specific usage is not
available in other diagrams. These systems can be database, external queues, or any
other system.
Activity diagram can be used for −
 Modeling work flow by using activities.

 Modeling business requirements.
 High level understanding of the system's functionalities.
 Investigating business requirements at a later stage.

TOPIC 7 :UML Package Diagram and When to Use it
Package diagram, a kind of structural diagram, shows the arrangement and

organization of model elements in middle to large scale project. Package diagram can
show both structure and dependencies between sub-systems or modules, showing
different views of a system, for example, as multi-layered (aka multi-tiered)
application - multi-layered application model.
some major elements of the package diagram are shown on the drawing below. Web
Shopping, Mobile Shopping, Phone Shopping, and Mail Shopping
packages merge Shopping Cart package. The same 4 packages use Payment package.
Both Payment and Shopping Cart packages import other packages.
Purpose of Package Diagrams
Package diagrams are used to structure high level system elements. Packages are
used for organizing large system which contains diagrams, documents and other key
deliverables.
 Package Diagram can be used to simplify complex class diagrams, it can group
classes into packages.
 A package is a collection of logically related UML elements.
 Packages are depicted as file folders and can be used on any of the UML
diagrams.
Package Diagram at a Glance

Package diagram is used to simplify complex class diagrams, you can group classes
into packages. A package is a collection of logically related UML elements.
The diagram below is a business model in which the classes are grouped into
packages:
 Packages appear as rectangles with small tabs at the top.

 The package name is on the tab or inside the rectangle.
 The dotted arrows are dependencies.
 One package depends on another if changes in the other could possibly force
changes in the first.
[embedyt] https://www.youtube.com/watch?v=BgvwzJnUt4A[/embedyt]
Key Elements of Package Diagram
Packages are used to organize a large set of model elements:
 Visibility
 Import
 Access
When to Use Packages?
To create an overview of a large set of model elements
 To organize a large model

 To group related elements
 To separate namespaces
Visibility of Packages
Each contained element has a visibility relative to the containing package.
 A public element is visible to elements outside the package, denoted by ‘+’

 A protected element is visible only to elements within inheriting packages,
denoted by ‘#’
 A private element is not visible at all to elements outside the package, denoted
by ‘-’
 Same syntax for visibility of attributes and operations in classes
Package Diagram Example - Order Subsystem

TOPIC 8: Component Diagrams in OOAD

What is Component Diagram
A component diagram, also known as a UML component diagram, describes the
organization and wiring of the physical components in a system. Component
diagrams are often drawn to help model implementation details and double-check
that every aspect of the system's required functions is covered by planned
development.
In the first version of UML, components included in these diagrams were physical:
documents, database table, files, and executables, all physical elements with a
location.
In the world of UML 2, these components are less physical and more conceptual
stand-alone design elements such as a business process that provides or requires
interfaces to interact with other constructs in the system. The physical elements
described in UML 1, like files and documents, are now referred to as artifacts. A UML
2 component may contain multiple physical artifacts if they naturally belong
together.
Basic Component Diagram Symbols and Notations

Component
A component is a logical unit block of the system, a slightly higher abstraction than
classes. It is represented as a rectangle with a smaller rectangle in the upper right
corner with tabs or the word written above the name of the component to help
distinguish it from a class.
Interface
An interface (small circle or semi-circle on a stick) describes a group of operations
used (required) or created (provided) by components. A full circle represents an
interface created or provided by the component. A semi-circle represents a required
interface, like a person's input.
Dependencies
Draw dependencies among components using dashed arrows.
Port
Ports are represented using a square along the edge of the system or a component. A
port is often used to help expose required and provided interfaces of a component.
Purpose of Component Diagrams
 Component diagram is a special kind of diagram in UML. The purpose is also

different from all other diagrams discussed so far. It does not describe the
functionality of the system but it describes the components used to make those
functionalities.
 Thus from that point of view, component diagrams are used to visualize the
physical components in a system. These components are libraries, packages,
files, etc.
 Component diagrams can also be described as a static implementation view of
a system. Static implementation represents the organization of the components
at a particular moment.
 A single component diagram cannot represent the entire system but a
collection of diagrams is used to represent the whole.
The purpose of the component diagram can be summarized as −
 Visualize the components of a system.

 Construct executables by using forward and reverse engineering.
 Describe the organization and relationships of the components.
Example of a component diagram

TOPIC 9:Deployment Diagrams in OOAD
A UML deployment diagram is a diagram that shows the configuration of run time
processing nodes and the components that live on them. Deployment diagrams is a
kind of structure diagram used in modeling the physical aspects of an object-oriented
system. They are often be used to model the static deployment view of a system
(topology of the hardware).
Purpose of a deployment diagram

Deployment diagrams are used with the sole purpose of describing how software is
deployed into the hardware system. It visualizes how software interacts with the
hardware to execute the complete functionality. It is used to describe software to
hardware interaction and vice versa.
 They show the structure of the run-time system

 They capture the hardware that will be used to implement the system and the
links between different items of hardware.
 They model physical hardware elements and the communication paths
between them
 They can be used to plan the architecture of a system.
 They are also useful for Document the deployment of software components or
nodes
Deployment Diagram Symbol and notations
Deployment Diagram Notations

A deployment diagram consists of the following notations:
1. A node
2. A component
3. An artifact
4. An interface
Other Notations
 Dependency
 Association relationships.
 May also contain notes and constraints.
Example of a Deployment diagram
Following deployment diagram represents the working of HTML5 video player in the
browser:
When to use a deployment diagram?

Deployment diagrams are mostly used by system administrators, network engineers,
etc. These diagrams are used with the sole purpose of describing how software is
deployed into the hardware system. It visualizes how software interacts with the
hardware to execute the complete functionality.
To make the software work efficiently and at a faster rate, the hardware also must be
of good quality. It must be designed efficiently to make software work properly and
produce accurate results in quick time.
Deployment diagrams can be used for,
1. Modeling the network topology of a system.

2. Modeling distributed systems and networks.
3. Forward and reverse engineering processes.

UNIT IV 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 –Applying GoF
design patterns – Mapping design to code
TOPIC 1: General Responsibility Assignment Software
Patterns(GRASP)
General Responsibility Assignment Software Patterns (or Principles),

abbreviated GRASP, consist of guidelines for assigning responsibility to classes and
objects in object-oriented design.
 As a tool for software developers, GRASP provides a means to solve
Organizational problems and offers a common way to speak about abstract
concepts. The design pattern sets responsibilities
for objects and classes in object-oriented program design.
 GRASP with object-oriented programming classifies problems and their
solutions together as patterns. With these problems and solutions well defined,
they can be applied in other similar instances.
GRASP assigns seven types of roles to classes and objects in order to make for clear
delineation of responsibilities. These roles are:
 Controller
 Information Expert
 Creator
 High Cohesion
 Low Coupling
 Polymorphism
 Protected Classes
All these patterns answer some software problems, and 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.
Understanding the GRASP Design Patterns
Design Patterns are incredibly important tools for software developers. Above solving
common problems, they give people a standard vernacular to communicate with, and
offer conceptual abstractions that are valuable in a wide set of circumstances.
The GRASP design patterns are a set of design patterns that came after the original
Gang of Four book that many of you might be familiar with. GRASP stands
for General Responsibility Assignment Software Patterns.
The Controller
The Controller is responsible for handling the requests of actors. The Controller
is the middle-man between your user clicking “Send” and your back-end making that
happen. The Controller knows how to interpret the actions of user-interfaces, and
how to connect those actions to behaviours in your system.
This pattern allows user-interfaces to be separated cleanly from “business objects”,

and have both change independently of one another. Implicit in this is that a system
can also support many different user-interfaces at once, which is very groovy.
We can imagine a controller as the steering wheel in a car, it connects the intentions
of a driver to the actions of the vehicle. Changing the engine of the car does not need
to change how the car is used at a high level. And likewise replacing a steering wheel
does not require any internal components to be modified. Some cars even have
multiple steering wheels.
The Controller is also an important idiom in modern web development frameworks,

in forming a pillar of the Model-View-Controller architectural pattern.
Controllers are used in
 AngularJS,
 Ruby on Rails,
 Sails and more.
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 the use cases
 Create User
 Delete User
one can have a single class called UserController, instead of two separate use case
controllers.
 The controller 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.
The Creator
The Creator takes the responsibility of creating certain other objects. This
pattern is probably the easiest to understand conceptually. There are a number of
reasons why a class may take the responsibility of creating another. The Creator
might have information on how to create said object, or it might be the class that
uses the object most closely. These decisions will be largely established in the initial
design of the system, and other documents such as UML diagrams will guide and
inform the Creator pattern.
EXAMPLE
An example of this is a printing-press. A printing-press creates printed pages

because it has the information (in the form of the type-set) to create these pages. It
would be silly to expect printed pages to come out of a microwave.
 The Creator Pattern allows for a lot of other best-practices to fall into place,
such as dependency injection and low-coupling. The Creator Pattern can be
used to enforce the logical design of a system.
 The Creator Pattern is of course a parent to a whole family of patterns in the
Gang of Four book, including the very
useful Factory, Prototype and Singleton patterns.
 Creation of objects is one of the most common activities in an object-oriented
system. Which class is responsible for creating objects is a fundamental
property of the relationship between objects of particular classes.
In general, a class B should be responsible for creating instances of class A if one, or

preferably more, of the following apply:
 Instances of B contain or compositely aggregate instances of A

 Instances of B record instances of A
 Instances of B closely use instances of A
 Instances of B have the initializing information for instances of A and pass it
on creation.
The Expert
As our systems grow, we might find that we are putting too much logic into our
controllers. This results in what we call “bloated controllers”. Bloated controllers
imply tight coupling in our system, which is bad.
The Expert Pattern solves this by encapsulating information about a task into a
distinct class. This may sound a bit abstract, but let’s work through a simple
example. User-authentication is a common problem. We can have a user that is
logging in to have their username and password validated within our system. With
just a controller, this might look this:
User Login →Controller →Database
This transaction requires a lot of work on the part of the Controller. Authentication
may entail hashing, database look-ups and perhaps other application-specific tasks.
We therefore introduce an expert: Authentication Module. This module knows
precisely how to authenticate a user, and the Controller need only delegate the
authentication request to this module to know that authentication will be handled
correctly.
Login Request → Controller → Authentication Module → Database

In this way, the Expert pattern is very much like an expert in the real world. When
we wish to build a house, we might enlist the help of an architect. It is within
feasibility for a person to design their own house (and many people do), but most of
the time we would rather out-source this task. People have enough to manage when
building a house already, and an architect is certainly better equipped to design
houses.
Information expert
also expert or the expert principle) is a principle used to determine where to
delegate responsibilities such as 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.
This will lead to placing the responsibility on the class with the most information
required to fulfill it.
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, reuse, maintain and change.
Low coupling
Coupling is a measure of how strongly one element is connected to, has knowledge
of, or relies on other elements. Low coupling is an evaluative pattern that dictates
how to assign responsibilities to support
 lower dependency between the classes,

 change in one class having lower impact on other classes,
 higher reuse potential.
Polymorphism
According to the polymorphism principle, responsibility for defining the variation of
behaviors based on type is assigned to the type for which this variation happens.
This is achieved using polymorphic operations. The user of the type should use
polymorphic operations instead of explicit branching based on type.
Protected variations
The protected variations pattern protects elements from the variations on other
elements (objects, systems, subsystems) by wrapping the focus of instability with
an interface and using polymorphism to create various implementations of this
interface.
Pure fabrication
A pure fabrication is a class that does not represent a concept in the problem
domain, specially made up to achieve low coupling, high cohesion, and the reuse
potential thereof derived (when a solution presented by the information expert pattern
does not). This kind of class is called a "service" in domain-driven design.
Topic 2 Design Patterns in OOAD
A design pattern provides a general reusable solution for the common problems
occurs in software design. The patterns typically show relationships and interactions
between classes or objects. The idea is to speed up the development process by
providing well tested, proven development/design paradigm.
Design patterns are programming language independent strategies for solving a

common problem. That means a design pattern represents an idea, not a particular
implementation. By using the design patterns you can make your code more flexible,
reusable and maintainable.
By using the design patterns you can make your code more flexible, reusable and
maintainable. It is the most important part because java internally follows design
patterns.
Advantage of design pattern:
1. They are reusable in multiple projects.

2. They provide the solutions that help to define the system architecture.
3. They capture the software engineering experiences.
4. They provide transparency to the design of an application.
5. They are well-proved and testified solutions since they have been built upon
the knowledge and experience of expert software developers.
6. Design patterns don?t guarantee an absolute solution to a problem. They
provide clarity to the system architecture and the possibility of building a
better system.
When should we use the design patterns?

We must use the design patterns during the analysis and requirement phase of
SDLC(Software Development Life Cycle).
Design patterns ease the analysis and requirement phase of SDLC by providing
information based on prior hands-on experiences.
Types of Design Pattern

S.N. Pattern & Description
Creational Patterns
These design patterns provides way to create objects while hiding the creation
1 logic, rather than instantiating objects directly using new operator. This gives
program more flexibility in deciding which objects need to be created for a given
use case.
Structural Patterns
These design patterns concern class and object composition. Concept of
2
inheritance is used to compose interfaces and define ways to compose objects to
obtain new functionalities.
Behavioral Patterns
3 These design patterns are specifically concerned with communication between
objects.
J2EE Patterns
4 These design patterns are specifically concerned with the presentation tier.
These patterns are identified by Sun Java Center.
As per the design pattern reference book Design Patterns - Elements of Reusable
Object-Oriented Software , there are 23 design patterns. These patterns can be
classified in three categories: Creational, Structural and behavioral patterns. We'll
also discuss another category of design patterns: J2EE design patterns.
Core Java Design Patterns
In core java, there are mainly three types of design patterns, which are further
divided into their sub-parts:
1. Creational Design Pattern
1. Factory Pattern
2. Abstract Factory Pattern
3. Singleton Pattern
4. Prototype Pattern
5. Builder Pattern.
2. Structural Design Pattern
1. Adapter Pattern
2. Bridge Pattern
3. Composite Pattern
4. Decorator Pattern
5. Facade Pattern
6. Flyweight Pattern
7. Proxy Pattern
3. Behavioral Design Pattern

1. Chain Of Responsibility Pattern
2. Command Pattern
3. Interpreter Pattern
4. Iterator Pattern
5. Mediator Pattern
6. Memento Pattern
7. Observer Pattern
8. State Pattern
9. Strategy Pattern
10. Template Pattern
11. Visitor Pattern
TOPIC 3Applying GoF Design Patterns
What is Gang of Four (GOF)?
In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson und John
Vlissides published a book titled Design Patterns - Elements of Reusable Object-
Oriented Software which initiated the concept of Design Pattern in Software
development.
These authors are collectively known as Gang of Four (GOF). According to these
authors design patterns are primarily based on the following principles of object
orientated design.
 Program to an interface not an implementation

 Favor object composition over inheritance
Usage of Design Pattern
Design Patterns have two main usages in software development.
Common platform for developers
Design patterns provide a standard terminology and are specific to particular

scenario. For example, a singleton design pattern signifies use of single object so all
developers familiar with single design pattern will make use of single object and they
can tell each other that program is following a singleton pattern.
Best Practices
Design patterns have been evolved over a long period of time and they provide best
solutions to certain problems faced during software development. Learning these
patterns helps un-experienced developers to learn software design in an easy and
faster way.

Types of Design Pattern

S.N. Pattern & Description
Creational Patterns
These design patterns provides way to create objects while hiding the creation
1 logic, rather than instantiating objects directly using new operator. This gives
program more flexibility in deciding which objects need to be created for a given
use case.
Structural Patterns
These design patterns concern class and object composition. Concept of
2
inheritance is used to compose interfaces and define ways to compose objects to
obtain new functionalities.
Behavioral Patterns
3 These design patterns are specifically concerned with communication between
objects.
J2EE Patterns
4 These design patterns are specifically concerned with the presentation tier.
These patterns are identified by Sun Java Center.
As per the design pattern reference book Design Patterns - Elements of Reusable
Object-Oriented Software , there are 23 design patterns. These patterns can be
classified in three categories: Creational, Structural and behavioral patterns. We'll
also discuss another category of design patterns: J2EE design patterns.
Core Java Design Patterns
In core java, there are mainly three types of design patterns, which are further
divided into their sub-parts:
1. Creational Design Pattern
1. Factory Pattern
2. Abstract Factory Pattern
3. Singleton Pattern
4. Prototype Pattern
5. Builder Pattern.
2. Structural Design Pattern
1. Adapter Pattern
2. Bridge Pattern
3. Composite Pattern
4. Decorator Pattern
5. Facade Pattern
6. Flyweight Pattern
7. Proxy Pattern
3. Behavioral Design Pattern
1. Chain Of Responsibility Pattern

2. Command Pattern
4. Iterator Pattern
5. Mediator Pattern
6. Memento Pattern
7. Observer Pattern
8. State Pattern
9. Strategy Pattern
11. Visitor Pattern
Creation Design Patterns

Creational Design Patterns are concerned with the way in which objects are
created. They reduce complexities and instability by creating objects in a controlled
manner.
The new operator is often considered harmful as it scatters objects all over the
application. Over time it can become challenging to change an implementation
because classes become tightly coupled.
Creational Design Patterns address this issue by decoupling the client entirely from
the actual initialization process.
In this article, we'll discuss four types of Creational Design Pattern:
1. Singleton – Ensures that at most only one instance of an object exists

throughout application
2. Factory Method – Creates objects of several related classes without
specifying the exact object to be created
3. Abstract Factory – Creates families of related dependent objects
4. Builder – Constructs complex objects using step-by-step approach
Factory Pattern
 Factory pattern is one of the most used 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.
 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
We're going to create a Shape interface and concrete classes implementing
the Shape interface. A factory class ShapeFactory is defined as a next step.
FactoryPatternDemo, our demo 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.
Shape.java
public interface Shape {
void draw();
}
Step 2
Create concrete classes implementing the same interface.
Rectangle.java
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Inside Rectangle::draw() method.");
}
}
Square.java
public class Square implements Shape {
@Override
System.out.println("Inside Square::draw() method.");
}
}
Circle.java
public class Circle implements Shape {
@Override
System.out.println("Inside Circle::draw() method.");
}
}
Step 3
Create a Factory to generate object of concrete class based on given information.
ShapeFactory.java
public class ShapeFactory {
//use getShape method to get object of type shape

public Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
}
Step 4
Use the Factory to get object of concrete class by passing an information such as
type.
FactoryPatternDemo.java
public class FactoryPatternDemo {
public static void main(String[] args) {

ShapeFactory shapeFactory = new ShapeFactory();
//get an object of Circle and call its draw method.

Shape shape1 = shapeFactory.getShape("CIRCLE");
//call draw method of Circle

shape1.draw();
//get an object of Rectangle and call its draw method.

Shape shape2 = shapeFactory.getShape("RECTANGLE");
//call draw method of Rectangle

shape2.draw();
//get an object of Square and call its draw method.

Shape shape3 = shapeFactory.getShape("SQUARE");
//call draw method of square
shape3.draw();
}
}
Step 5
Verify the output.
Inside Circle::draw() method.
Inside Rectangle::draw() method.
Inside Square::draw() method.
Structural design patterns

Structural design patterns are concerned with how classes and objects can be
composed, to form larger structures.
The structural design patterns simplify the structure by identifying the
relationships.
These patterns focus on, how the classes inherit from each other and how they are
composed from other classes.
Types of structural design patterns

There are following 7 types of structural design patterns.
1. Adapter PatternAdapting an interface into another according to client

expectation.
2. Bridge PatternSeparating abstraction (interface) from implementation.
3. Composite PatternAllowing clients to operate on hierarchy of objects.
4. Decorator PatternAdding functionality to an object dynamically.
5. Facade PatternProviding an interface to a set of interfaces.
6. Flyweight PatternReusing an object by sharing it.
7. proxy PatternRepresenting another object.
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. A real life example could be a case
of card reader which acts as an adapter between memory card and a laptop.
You plugins the memory card into card reader and card reader into the laptop
so that memory card can be read via laptop.
 We are 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
 We've an interface MediaPlayer interface and a concrete

class AudioPlayer implementing the MediaPlayer interface. AudioPlayer can
play mp3 format audio files by default.
 We're 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've created an adapter class MediaAdapter which implements
the MediaPlayer interface and uses AdvancedMediaPlayer 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.
MediaPlayer.java
public interface MediaPlayer {
public void play(String audioType, String fileName);
}
AdvancedMediaPlayer.java
public interface AdvancedMediaPlayer {
public void playVlc(String fileName);
public void playMp4(String fileName);
}
Step 2
Create concrete classes implementing the AdvancedMediaPlayer interface.
VlcPlayer.java
public class VlcPlayer implements AdvancedMediaPlayer{
@Override
public void playVlc(String fileName) {
System.out.println("Playing vlc file. Name: "+ fileName);
}
@Override
public void playMp4(String fileName) {
//do nothing
}
}
Mp4Player.java
public class Mp4Player implements AdvancedMediaPlayer{
@Override
public void playVlc(String fileName) {
//do nothing
}
@Override
public void playMp4(String fileName) {
System.out.println("Playing mp4 file. Name: "+ fileName);
}
}
Step 3
Create adapter class implementing the MediaPlayer interface.
MediaAdapter.java
public class MediaAdapter implements MediaPlayer {
AdvancedMediaPlayer advancedMusicPlayer;
public MediaAdapter(String audioType){

if(audioType.equalsIgnoreCase("vlc") ){
advancedMusicPlayer = new VlcPlayer();
} else if (audioType.equalsIgnoreCase("mp4")){
advancedMusicPlayer = new Mp4Player();
}
}
@Override
public void play(String audioType, String fileName) {
if(audioType.equalsIgnoreCase("vlc")){
advancedMusicPlayer.playVlc(fileName);
}else if(audioType.equalsIgnoreCase("mp4")){
advancedMusicPlayer.playMp4(fileName);
}
}
}
Step 4
Create concrete class implementing the MediaPlayer interface.
AudioPlayer.java
public class AudioPlayer implements MediaPlayer {
MediaAdapter mediaAdapter;
@Override
public void play(String audioType, String fileName) {
//inbuilt support to play mp3 music files

if(audioType.equalsIgnoreCase("mp3")){
System.out.println("Playing mp3 file. Name: "+ fileName);
}
//mediaAdapter is providing support to play other file formats
else if(audioType.equalsIgnoreCase("vlc")
|| audioType.equalsIgnoreCase("mp4")){
mediaAdapter = new MediaAdapter(audioType);
mediaAdapter.play(audioType, fileName);
}
else{
System.out.println("Invalid media. "+
audioType + " format not supported");
}
}
}
Step 5
Use the AudioPlayer to play different types of audio formats.
AdapterPatternDemo.java
public class AdapterPatternDemo {
AudioPlayer audioPlayer = new AudioPlayer();
audioPlayer.play("mp3", "beyond the horizon.mp3");

audioPlayer.play("mp4", "alone.mp4");
audioPlayer.play("vlc", "far far away.vlc");
audioPlayer.play("avi", "mind me.avi");
}
}
Step 6
Verify the output.
Playing mp3 file. Name: beyond the horizon.mp3
Playing mp4 file. Name: alone.mp4
Playing vlc file. Name: far far away.vlc
Invalid media. avi format not supported
Bridge Pattern
Bridge is used where 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.
We are 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.

Implementation
We've an interface DrawAPI interface which is acting as a bridge implementer and
concrete classes RedCircle, 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.
DrawAPI.java
public interface DrawAPI {
public void drawCircle(int radius, int x, int y);
}
Step 2
Create concrete bridge implementer classes implementing the DrawAPI interface.
RedCircle.java
public class RedCircle implements DrawAPI {
@Override
public void drawCircle(int radius, int x, int y) {
System.out.println("Drawing Circle[ color: red, radius: "
+ radius +", x: " +x+", "+ y +"]");
}
}
GreenCircle.java
public class GreenCircle implements DrawAPI {
@Override
public void drawCircle(int radius, int x, int y) {
System.out.println("Drawing Circle[ color: green, radius: "
+ radius +", x: " +x+", "+ y +"]");
}
}
Step 3
Create an abstract class Shape using the DrawAPI interface.
Shape.java
public abstract class Shape {
protected DrawAPI drawAPI;
protected Shape(DrawAPI drawAPI){
this.drawAPI = drawAPI;
}
public abstract void draw();
}
Step 4
Create concrete class implementing the Shape interface.
Circle.java
public class Circle extends Shape {
private int x, y, radius;
public Circle(int x, int y, int radius, DrawAPI drawAPI) {

super(drawAPI);
this.x = x;
this.y = y;
this.radius = radius;
}

drawAPI.drawCircle(radius,x,y);
}
}
Step 5
Use the Shape and DrawAPI classes to draw different colored circles.
BridgePatternDemo.java
public class BridgePatternDemo {
Shape redCircle = new Circle(100,100, 10, new RedCircle());
Shape greenCircle = new Circle(100,100, 10, new GreenCircle());
redCircle.draw();
greenCircle.draw();
}
}
Step 6
Verify the output.
Drawing Circle[ color: red, radius: 10, x: 100, 100]
Drawing Circle[ color: green, radius: 10, x: 100, 100]
Behavioral Design Patterns
Behavioral design patterns are concerned with the interaction and responsibility
of objects.
In these design patterns,the interaction between the objects should be in such a
way that they can easily talk to each other and still should be loosely coupled.
That means the implementation and the client should be loosely coupled in order to
avoid hard coding and dependencies.
There are 12 types of structural design patterns:
1. Chain of Responsibility Pattern

2. Command Pattern
4. Iterator Pattern
5. Mediator Pattern
6. Memento Pattern
7. Observer Pattern
8. State Pattern
9. Strategy Pattern
11. Visitor Pattern
12. Null Object
Strategy Pattern
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.
Implementation
We are going to create a Strategy interface defining an action and concrete strategy
classes implementing the Strategy interface. Context is a class which uses a Strategy.

StrategyPatternDemo, our demo class, will use Context and strategy objects to
demonstrate change in Context behaviour based on strategy it deploys or uses.
Step 1
Create an interface.
Strategy.java
public interface Strategy {
public int doOperation(int num1, int num2);
}
Step 2
Create concrete classes implementing the same interface.
OperationAdd.java
public class OperationAdd implements Strategy{
@Override
public int doOperation(int num1, int num2) {
return num1 + num2;
}
}
OperationSubstract.java
public class OperationSubstract implements Strategy{
@Override
return num1 - num2;
}
}
OperationMultiply.java
public class OperationMultiply implements Strategy{
@Override
return num1 * num2;
}
}
Step 3
Create Context Class.
Context.java
public class Context {
private Strategy strategy;
public Context(Strategy strategy){

this.strategy = strategy;
}
public int executeStrategy(int num1, int num2){

return strategy.doOperation(num1, num2);
}
}
Step 4
Use the Context to see change in behaviour when it changes its Strategy.
StrategyPatternDemo.java
public class StrategyPatternDemo {
Context context = new Context(new OperationAdd());
System.out.println("10 + 5 = " + context.executeStrategy(10, 5));
context = new Context(new OperationSubstract());

System.out.println("10 - 5 = " + context.executeStrategy(10, 5));
context = new Context(new OperationMultiply());

System.out.println("10 * 5 = " + context.executeStrategy(10, 5));
}
}
Step 5
Verify the output.
10 + 5 = 15
10 - 5 = 5
10 * 5 = 50
Observer Pattern
Observer pattern is used when there is one-to-many relationship between objects
such as if one object is modified, its depenedent 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, our demo class, will use Subject and concrete class object to
show observer pattern in action.
Step 1
Create Subject class.
Subject.java
import java.util.ArrayList;
import java.util.List;
public class Subject {

private List<Observer> observers = new ArrayList<Observer>();
private int state;
public int getState() {

return state;
}
public void setState(int state) {

this.state = state;
notifyAllObservers();
}
public void attach(Observer observer){

observers.add(observer);
}
public void notifyAllObservers(){

for (Observer observer : observers) {
observer.update();
}
}
}
Step 2
Create Observer class.
Observer.java
public abstract class Observer {
protected Subject subject;
public abstract void update();
}
Step 3
Create concrete observer classes
BinaryObserver.java
public class BinaryObserver extends Observer{
public BinaryObserver(Subject subject){

this.subject = subject;
this.subject.attach(this);
}
@Override
public void update() {
System.out.println( "Binary String: " + Integer.toBinaryString( subject.getState() )
);
}
}
OctalObserver.java
public class OctalObserver extends Observer{
public OctalObserver(Subject subject){

}
@Override
System.out.println( "Octal String: " + Integer.toOctalString( subject.getState() ) );
}
}
HexaObserver.java
public class HexaObserver extends Observer{
public HexaObserver(Subject subject){

}
@Override
System.out.println( "Hex String: " + Integer.toHexString( subject.getState()
).toUpperCase() );
}
}
Step 4
Use Subject and concrete observer objects.

ObserverPatternDemo.java
public class ObserverPatternDemo {
Subject subject = new Subject();
new HexaObserver(subject);
new OctalObserver(subject);
new BinaryObserver(subject);
System.out.println("First state change: 15");

subject.setState(15);
System.out.println("Second state change: 10");
subject.setState(10);
}
}
Step 5
Verify the output.

First state change: 15
Hex String: F
Octal String: 17
Binary String: 1111
Second state change: 10
Hex String: A
Octal String: 12
Binary String: 1010
UNIT V TESTING
Object Oriented Methodologies – Software Quality Assurance – Impact of object

orientation on Testing – Develop Test Cases and Test Plans
TOPIC 1:Object Oriented Methodologies in OOAD
What are benefits of OO Methodology? Give overview of different OO

Methodologies in brief.
What is Object Oriented Methodology?
 It is a new system development approach, encouraging and facilitating re-use
of software components.
 It employs international standard Unified Modeling Language (UML) from the
Object Management Group (OMG).
 Using this methodology, a system can be developed on a component basis,
which enables the effective re-use of existing components, it facilitates the
sharing of its other system components.
 Object Oriented Methodology asks the analyst to determine what the objects of
the system are?, What responsibilities and relationships an object has to do
with the other objects? and How they behave over time?
There are three types of Object Oriented Methodologies

1. Object Modeling Techniques (OMT)
2. Object Process Methodology (OPM)
3. Rational Unified Process (RUP)
1. Object Modeling Techniques (OMT)
 It was one of the first object oriented methodologies and was introduced by
Rumbaugh in 1991.
 OMT uses three different models that are combined in a way that is analogous
to the older structured methodologies.
a. Analysis
 The main goal of the analysis is to build models of the world.

 The requirements of the users, developers and managers provide the
information needed to develop the initial problem statement.
b. OMT Models
I. Object Model
 It depicts the object classes and their relationships as a class diagram, which
represents the static structure of the system.
 It observes all the objects as static and does not pay any attention to their
dynamic nature.
II. Dynamic Model

 It captures the behavior of the system over time and the flow control and
events in the Event-Trace Diagrams and State Transition Diagrams.
 It portrays the changes occurring in the states of various objects with the
events that might occur in the system.
III. Functional Model
 It describes the data transformations of the system.

 It describes the flow of data and the changes that occur to the data throughout
the system.
c. Design
 It specifies all of the details needed to describe how the system will be
implemented.
 In this phase, the details of the system analysis and system design are
implemented.
 The objects identified in the system design phase are designed.
2. Object Process Methodology (OPM)
 It is also called as second generation methodology.

 It was first introduced in 1995.
 It has only one diagram that is the Object Process Diagram (OPD) which is
used for modeling the structure, function and behavior of the system.
 It has a strong emphasis on modeling but has a weaker emphasis on process.
 It consists of three main processes:
I. Initiating: It determines high level requirements, the scope of the system and the
resources that will be required.
II. Developing: It involves the detailed analysis, design and implementation of the
system.
III. Deploying: It introduces the system to the user and subsequent maintenance of
the system.
3. Rational Unified Process (RUP)
 It was developed in Rational Corporation in 1998.

 It consists of four phases which can be broken down into iterations.
I. Inception
II. Elaboration
III. Construction
IV. Transition
 Each iteration consists of nine work areas called disciplines.
 A discipline depends on the phase in which the iteration is taking place.
 For each discipline, RUP defines a set of artefacts (work products), activities
(work undertaken on the artefacts) and roles (the responsibilities of the
members of the development team).
Objectives of Object Oriented Methodologies

 To encourage greater re-use.
 To produce a more detailed specification of system constraints.
 To have fewer problems with validation (Are we building the right product?).
Benefits of Object Oriented Methodologies

1. It represents the problem domain, because it is easier to produce and understand
designs.
2. It allows changes more easily.
3. It provides nice structures for thinking, abstracting and leads to modular design.
4. Simplicity:
 The software object's model complexity is reduced and the program structure is
very clear.
5. Reusability:
 It is a desired goal of all development process.

 It contains both data and functions which act on data.
 It makes easy to reuse the code in a new system.
 Messages provide a predefined interface to an object's data and functionality.
6. Increased Quality:
 This feature increases in quality is largely a by-product of this program reuse.
7. Maintainable:
 The OOP method makes code more maintainable.
 The objects can be maintained separately, making locating and fixing problems
easier.
8. Scalable:
 The object oriented applications are more scalable than structured approach.
 It makes easy to replace the old and aging code with faster algorithms and
newer technology.
9. Modularity:
 The OOD systems are easier to modify.
 It can be altered in fundamental ways without ever breaking up since changes
are neatly encapsulated.
10. Modifiability:
 It is easy to make minor changes in the data representation or the procedures
in an object oriented program.
11. Client/Server Architecture:
 It involves the transmission of messages back and forth over a network.

TOPIC2: Software Quality Assurance in OOAD
SOFTWARE QUALITY ASSURANCE (SQA) is a set of activities for ensuring quality in

software engineering processes that ultimately results, or at least gives confidence, in
the quality of software products.
SQA Activities
SQA includes the following activities:
 Process definition
 Process training
 Process implementation
 Process audit
SQA Processes
SQA includes the following processes:
 Project Management
 Project Estimation
 Configuration Management
 Requirements Management
 Software Design
 Software Development
 Software Testing
 Software Deployment
 Software Maintenance
How to perform testing & Quality Assurance in OOAD ?
Once a program code is composed, it must be tried to test hence handle all blunders
in it. Various plans are utilized for testing purposes.
Another vital viewpoint is the wellness of motivation behind a program that finds out
whether the program fills the need which it goes for. The wellness characterizes the
product quality.
Testing Object-Oriented Systems
Testing is a constant action amid programming advancement. In object arranged

systems, testing incorporates three levels, specifically, unit testing, subsystem
testing, and system testing.
Unit Testing
In unit testing, the individual classes are tried. It is seen whether the class
characteristics are executed according to outline and whether the strategies and the
interfaces are sans blunder. Unit testing is the duty of the application design who
actualizes the structure.
Subsystem Testing
This includes testing a specific module or a subsystem and is the duty of the
subsystem lead. It includes testing the relationship internal the subsystem and also
the Interaction of the subsystem with the external. Subsystem tests can be utilized
as relapse tests for each recently discharged form of the subsystem.
System Testing
System testing includes testing the system overall and is the obligation of the quality-
confirmation group. The group regularly utilizes system tests as relapse tests when
collecting new discharges.
Object Oriented Testing Techniques
Grey Box Testing
The diverse sorts of experiments that can be intended for testing object-situated
projects are called dark box test cases. A portion of the essential kinds of dark box
testing are −
 State model based testing − This encompasses state coverage, state transition
coverage, and state transition path coverage.
 Use case based testing − Each scenario in each use case is tested.
 Class diagram based testing − Each class, derived class, associations, and
aggregations are tested.
 Sequence diagram based testing − The methods in the messages in the
sequence diagrams are tested.
Techniques for Subsystem Testing
 The two fundamental methodologies of subsystem testing are −

 Thread based testing − All classes that are expected to understand a solitary
utilize case in a subsystem are coordinated and tried.
 Use based testing − The interfaces and administrations of the modules at each
level of progressive system are tried. Testing begins from the individual classes
to the little modules including classes, slowly to bigger modules, lastly all the
significant subsystems.
Categories of System Testing
 Alpha testing − This is completed by the testing group internal the Interaction
that creates programming.
 Beta testing − This is completed by select gathering of co-working clients.
 Acceptance testing − This is completed by the client before tolerating the
expectations.
Software Quality Assurance
Software Quality
Schulmeyer and McManus have characterized programming quality as "the wellness

for utilization of the aggregate programming item". A decent quality programming
does precisely what it should do and is translated as far as fulfillment of the
necessity particular set around the client.
Quality Assurance
Programming quality confirmation is a procedure that decides the degree to which a

product item is fit for utilize. The exercises that are incorporated for deciding
programming quality are −
 Auditing
 Development of standards and guidelines
 Production of reports
 Review of quality system
Quality Factors
 Correctness − Correctness determines whether the software requirements are

appropriately met.
 Usability − Usability determines whether the software can be used by different
categories of users (beginners, non-technical, and experts).
 Portability − Portability determines whether the software can operate in
different platforms with different hardware devices.
 Maintainability − Maintainability determines the ease at which errors can be
corrected and modules can be updated.
 Reusability − Reusability determines whether the modules and classes can be
reused for developing other software products.
Object-Oriented Metrics
Measurements can be extensively arranged into three classifications: venture

measurements, item measurements, and process measurements.
Project Metrics
Undertaking Metrics empower a product venture administrator to evaluate the status

and execution of a progressing venture. The following measurements are proper for
protest situated programming ventures −
 Number of scenario scripts

 Number of key classes
 Number of support classes
 Number of subsystems
Product Metrics
Item measurements measure the attributes of the product item that has been
created. The item measurements appropriate for object arranged systems are −
 Methods per Class − It decides the many-sided quality of a class. In the event
that every one of the techniques for a class are thought to be similarly
unpredictable, at that point a class with more strategies is more perplexing
and along these lines more vulnerable to blunders.
 Inheritance Structure− Systems with a few little legacy grids are more well–
organized than systems with a solitary expansive legacy cross section. As a
thumb lead, a legacy tree ought not have more than 7 (± 2) number of levels
and the tree ought to be adjusted.
 Coupling and Cohesion− Modules having low coupling and high union are
thought to be better outlined, as they allow more prominent reusability and
viability.
 Response for a Class− It gauges the productivity of the strategies that are
called by the occurrences of the class.
Process Metrics
Process measurements help in estimating how a procedure is performing. They are

gathered over all undertakings over drawn out stretches of time. They are utilized as
pointers for long haul programming process enhancements. Some procedure
measurements are −
 Number of KLOC (Kilo Lines of Code)
 Defect removal efficiency
 Average number of failures detected during testing
 Number of latent defects per KLOC

TOPIC3: Impact of Object Orientation on Testing
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,
 extendibility.
OO Paradigm
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 Levels
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.
Structural Testing Methods
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 inter
class 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.
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.
1. It should be explicitly specified with each test case which class it should test.
2. Purpose of each test case should be mentioned.
3. External conditions that should exist while conducting a test should be clearly
stated with each test case.
4. All the states of object that is to be tested should be specified.
5. Instructions to understand and conduct the test cases should be provided with
each test case.
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.
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.
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.
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 some segments of the software.
Generally, the structure of a scenario includes the following points.
1. A condition under which the scenario runs.

2. A goal to achieve, which can also be a name of the scenario.
3. A set of steps of actions.
4. An end condition at which the goal is achieved.
5. A possible set of extensions written as scenario fragments.
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 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.

TOPIC4: Develop Test Cases and Test Plans in OOAD
A TEST CASE is a set of conditions or variables under which a tester will determine
whether a system under test satisfies requirements or works correctly.The process of
developing test cases can also help find problems in the requirements or design of an
application.
Test Case Template

A test case can have the following elements. Note, however, that a test management
tool is normally used by companies and the format is determined by the tool used.
Test Suite ID The ID of the test suite to which this test case belongs.
Test Case ID The ID of the test case.
Test Case
The summary / objective of the test case.
Summary
Related
The ID of the requirement this test case relates/traces to.
Requirement
Any prerequisites or preconditions that must be fulfilled prior to
Prerequisites
executing the test.
Test Procedure Step-by-step procedure to execute the test.
The test data, or links to the test data, that are to be used while
Test Data
conducting the test.
Expected Result The expected result of the test.
Actual Result The actual result of the test; to be filled after executing the test.
Pass or Fail. Other statuses can be ‘Not Executed’ if testing is not
Status
performed and ‘Blocked’ if testing is blocked.
Remarks Any comments on the test case or test execution.
Created By The name of the author of the test case.
Date of Creation The date of creation of the test case.
Executed By The name of the person who executed the test.
Date of
The date of execution of the test.
Execution
Test The environment (Hardware/Software/Network) in which the test
Environment was executed.
Writing Good Test Cases
 As far as possible, write test cases in such a way that you test only one thing
at a time. Do not overlap or complicate test cases. Attempt to make your test
cases ‘atomic’.
 Ensure that all positive scenarios AND negative scenarios are covered.
 Language:
o Write in simple and easy-to-understand language.
o Use active voice instead of passive voice: Do this, do that.
o Use exact and consistent names (of forms, fields, etc).
 Characteristics of a good test case:
o Accurate: Exacts the purpose.
o Economical: No unnecessary steps or words.
o Traceable: Capable of being traced to requirements.
o Repeatable: Can be used to perform the test over and over.
o Reusable: Can be reused if necessary.
What is a Test Plan?
 A test plan is a detailed document that outlines the test

strategy, Testing objectives, resources (manpower, software, hardware)
required for testing, test schedule, Test Estimation and test deliverables.
 The test plan serves as a blueprint to conduct software testing activities as a
defined process which is minutely monitored and controlled by the test
manager.
 Let’s start with following scenario
 In a meeting, you want to discuss the Test Plan with the team members, but
they are not interested
Importance of Test Plan

Making Test Plan has multiple benefits
 Test Plan helps us determine the effort needed to validate the quality of the
application under test
 Help people outside the test team such as developers, business managers,
customers understand the details of testing.
 Test Plan guides our thinking. It is like a rule book, which needs to be
followed.
 Important aspects like test estimation, test scope, Test
Strategy are documented in Test Plan, so it can be reviewed by Management
Team and re-used for other projects.
How to write a Test Plan

You already know that making a Test Plan is the most important task of Test
Management Process. Follow the seven steps below to create a test plan as per IEEE
829
1. Analyze the product

2. Design the Test Strategy
3. Define the Test Objectives
4. Define Test Criteria
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables

CS8592-OBJECT ORIENTED ANALYSIS AND DESIGN
Two Marks Question with Answers
Unit-I Introduction to OOAD

1.What is Object-Oriented Analysis? Nov/Dec 2016
During object-oriented analysis there is an emphasis on finding and

describing the objects or concepts in the problem domain. For example, in
the case of the flight information system, some of the concepts include
Plane, Flight, and Pilot.
2.What is Object-Oriented Design?
During object-oriented design (or simply, object design) there is an emphasis

on defining software objects and how they collaborate to fulfill the
requirements. The combination of these two concepts shortly known as
object oriented analysis and design.
3.What is Object-Oriented Analysis and Design? APRIL/MAY-2011
During object-oriented analysis there is an emphasis on finding and

describing the objects or concepts in the problem domain. For example, in
the case of the flight information system, some of the concepts include
Plane, Flight, and Pilot.
During object-oriented design (or simply, object design) there is an

emphasis on defining software objects and how they collaborate to fulfill the
requirements. The combination of these two concepts shortly known as
object oriented analysis and design.
4.What is Analysis and Design?
Analysis emphasizes an investigation of the problem and requirements,

rather than a solution. Design emphasizes a conceptual solution (in
software and hardware) that fulfills the requirements, rather than its
implementation. For example, a description of a database schema and
software objects.
5.Define Design Class Diagrams April/May 2016
A static view of the class definitions is usefully shown with a design class
diagram. This illustrates the attributes and methods of the classes.
6. What is the UML? MAY/JUNE 2012
The Unified Modeling Language is a visual language for specifying,

constructing and documenting the artifacts of systems.
7.What are the three ways and perspectives to Apply UML?
Ways - UML as sketch, UML as blueprint, UML as programming language
Perspectives-Conceptual perspective, Specification (software) perspective,

Implementation (Software) perspective.
8.What is Inception? APIRAL/MAY-2011
Inception is the initial short step to establish a common vision and basic
scope for the Project. It will include analysis of perhaps 10% of the use
cases, analysis of the critical non-Functional requirement, creation of a
business case, and preparation of the development Environment so that
programming can start in the elaboration phase. Inception in one
Sentence: Envision the product scope, vision, and business case.
9.What Artifacts May Start in Inception?
Some sample artifacts are Vision and Business Case, Use-Case Model,
Supplementary Specification, Glossary, Risk List & Risk Management Plan,
Prototypes and proof-of- concepts etc.
10. Define Requirements and mention its types.
Requirements are capabilities and conditions to which the system and more
broadly, the project must conform.
1. Functional
2. Reliability
3. Performance
4. Supportability
11. What are Actors?

An actor is something with behavior, such as a person (identified by role),
computer system, or organization; for example, a cashier.
12. What is a scenario?

A scenario is a specific sequence of actions and interactions between actors and
the system; it is
also called a use case instance. It is one particular story of using a system, or
one path through the use case; for example, the scenario of successfully
purchasing items with cash, or the scenario of failing to purchase items
because of a credit payment denial.
13. Define Use case.

A use case is a collection of related success and failure scenarios that
describe an actor using a system to support a goal. Use cases are text
documents, not diagrams, and use-case modeling is primarily an act of
writing text, not drawing diagrams.
14. What are Three Kinds of Actors?
Primary actor, Supporting actor, offstage actor.
15. What Tests Can Help Find Useful Use Cases?

1. The Boss Test
2. The EBP Test
3. The Size Test

16. What are UseCase Diagrams?
A use case diagram is an excellent picture of the system context; it makes a

good context diagram that is, showing the boundary of a system, what lies
outside of it, and how it gets used. It serves as a communication tool that
summarizes the behavior of a system and its actors.
17. What are Activity Diagrams?
A diagram which is useful to visualize workflows and business processes.

These can be a useful alternative or adjunct to writing the use case text,
especially for business use cases that describe complex workflows involving
many parties and concurrent actions.
18. List the relationships used in use cases? MAY/JUNE 2012

1.Include
2.Extend
3.Generali
19. List out the steps for finding use cases.NOV/DEC 2012
Identifify the actor
Name the use cases
Describe the usecse by using terminologies.
20. What is an object?
An object is a combination of data and logic; the representation of some real-

world entity.
21. What is the main advantage of object-oriented development?
• High level of abstraction
• Seamless transition among different phases of software development
• Encouragement of good programming techniques.
• Promotion of reusability.
22. What is Object Oriented System development methodology?
Object oriented system development methodology is a way to develop software by

building self-contained modules or objects that can be easily replaced, modified and
reused.
23. Distinguish between method and message in object.
Method Message
i) Methods are similar to functions, procedures or subroutines in more

traditional programming languages. Message essentially is non-specific function
calls.
ii) Method is the implementation. Message is the instruction.
iii) In an object oriented system, a method is invoked by sending an object a

message. An object understands a message when it can match the message to a
method that has the same name as the message.
UNIT-II
Elaboration
PART- A
1.What is Elaboration?
Elaboration is the initial series of iterations during which the team does
serious investigation, implements (programs and tests) the core architecture,
clarifies most requirements, and tackles the high-risk issues. In the UP, "risk"
includes business value. Therefore, early work may include implementing
scenarios that are deemed important, but are not especially technically risky.
2. What are the tasks performed in elaboration?
 the core, risky software architecture is programmed and tested

 the majority of requirements are discovered and stabilized
 the major risks are mitigated or retired
3. What are the key ideas and best practices that will manifest in
elaboration?
 do short time boxed risk-driven iterations

 start programming early
 adaptively design, implement, and test the core and risky parts of the
architecture
 test early, often, realistically
 adapt based on feedback from tests, users, developers
• write most of the use cases and other requirements in detail,
through a series of workshops, once per elaboration iteration
4. What Artifacts May Start in Elaboration?
Domain Model This is a visualization of the domain concepts; it is similar to

a static
information model of the domain entities.
Design Model This is the set of diagrams that describes the logical design.
This includes
software class diagrams, object interaction diagrams,
package diagrams,
and so forth.
Software A learning aid that summarizes the key architectural issues
and their
Architecture resolution in the design. It is a summary of the outstanding
design ideas
Document and their motivation in the system.
Data Model This includes the database schemas, and the mapping
strategies between
object and non-object representations.
Use-Case Descriptions of the user interface, paths of navigation,
usability models,
Storyboards, UI and so forth.
Prototypes
5.What are the key ideas for Planning the Next Iteration?
Organize requirements and iterations by risk, coverage, and criticality.
6. What is a Domain Model? APIRAL/MAY-2011
A domain model is a visual representation of conceptual classes or real-

situation objects in a domain. The term "Domain Model" means a
representation of real-situation conceptual classes, not of software objects.
The term does not mean a set of diagrams describing software classes, the
domain layer of a software architecture, or software objects with
responsibilities.
7. How the domain model is illustrated?
Applying UML notation, a domain model is illustrated with a set of class

diagrams in which no operations (method signatures) are defined. It
provides a conceptual perspective. It may show:
 domain objects or conceptual classes
 associations between conceptual classes
 attributes of conceptual classes
8. Why Call a Domain Model a "Visual Dictionary"?
The information it illustrates could alternatively have been expressed in plain

text. But it's easy to understand the terms and especially their relationships
in a visual language, since our brains are good at understanding visual
elements and line connections. Therefore, the domain model is a visual
dictionary of the noteworthy abstractions, domain vocabulary, and
information content of the domain.
9. What are the elements not suitable in a domain model?
The following elements are not suitable in a domain model
 Software artifacts, such as a window or a database, unless the

domain being modeled is of software concepts, such as a model of
graphical user interfaces.
 Responsibilities or methods
10. What are Conceptual Classes?
The domain model illustrates conceptual classes or vocabulary in the

domain. Informally, a conceptual class is an idea, thing, or object. More
formally, a conceptual class may be considered in terms of its symbol,
intension, and extension
 Symbol words or images representing a conceptual class.

 Intension the definition of a conceptual class.
 Extension the set of examples to which the conceptual class applies
11. How to Create a Domain Model?
The current iteration requirements under design:
1. Find the conceptual classes (see a following guideline).

2. Draw them as classes in a UML class diagram.
3. Add associations and attributes.
12. How to Find Conceptual Classes?
1. Reuse or modify existing models. This is the first, best, and usually
easiest approach, and where I will start if I can. There are published,
well-crafted domain models and data models (which can be modified
into domain models) for many common domains, such as inventory,
finance, health, and so forth. Example books that I'll turn to include
Analysis Patterns by Martin Fowler, Data Model Patterns by David
Hay, and the Data Model Resource Book (volumes 1 and 2) by Len
Silverton.
2. Use a category list.
3. Identify noun phrases.
13. Mention some Conceptual Class Category.
Conceptual Class Category Exampl

es
business transactions Sale, Payment
Reservation
transaction line items Sales Line Item
product or service related to a transaction Item

or
transaction line item
Flight, Seat, Meal
where is the transaction recorded? Register, Ledger

Flight Manifest
roles of people or organizations related to Cashier, Customer, Store

the Monopoly
transaction; actors in the use case Player Passenger, Airline
place of transaction; place of service Store

Airport, Plane, Seat
14. Define Association.
An association is a relationship between classes (more precisely, instances

of those classes) that indicates some meaningful and interesting connection.
15. Why Should We Avoid Adding Many Associations?
We need to avoid adding too many associations to a domain model. Digging

back into our discrete mathematics studies, you may recall that in a graph
with n nodes, there can be associations to other nodes a potentially very
large number. A domain model with 20 classes could have 190 associations’
lines! Many lines on the diagram will obscure it with "visual noise."
Therefore, be parsimonious about adding association lines. Use the criterion
guidelines suggested in this chapter, and focus on "need-to-remember"
associations.
16. How to Name an Association in UML?

Name an association based on a Class Name-Verb Phrase-Class Name format
where the verb phrase creates a sequence that is readable and meaningful.
17. What is Aggregation? APRIL/MAY-2011
Aggregation is a vague kind of association in the UML that loosely suggests

whole-part relationships (as do many ordinary associations). It has no
meaningful distinct semantics in the UML versus a plain association, but
the term is defined in the UML.
18. What is composition? APRIL/MAY-2011
Composition, also known as composite aggregation, is a strong kind of

whole-part aggregation and is useful to show in some models. A composition
relationship implies that 1) an instance of the part (such as a Square) belongs
to only one composite instance (such as one Board) at a time, 2) the part must
always belong to a composite (no free-floating Fingers), and 3) the composite
is responsible for the creation and deletion of its parts either by itself
creating/deleting the parts, or by collaborating with other objects.
19. Mention the guidelines that suggest when to show aggregation.
 The lifetime of the part is bound within the lifetime of the composite
there is a create-delete dependency of the part on the whole.
 There is an obvious whole-part physical or logical assembly.
 Some properties of the composite propagate to the parts, such as the
location.
 Operations applied to the composite propagate to the parts,
such as destruction, movement, and recording.
20. What is an activity diagram?
A UML activity diagram shows sequential and parallel activities in a process.

They are useful for modeling business processes, workflows, data flows, and
complex algorithms. Basic UML activity diagram notation illustrates an action,
partition, fork, join, and object node. In essence, this diagram shows a
sequence of actions, some of which may be parallel. Most of the notation is
self-explanatory; two subtle points:
 once an action is finished, there is an automatic outgoing transition

 the diagram can show both control flow and data flow
UNIT-III
System Sequence Diagrams
PART- A
1. What is meant by System Sequence Diagrams? APRIL/MAY-2011

A system sequence diagram (SSD) is a picture that shows, for a particular
scenario of a use case, the events that external actors generate their order,
and inter-system events. All systems are treated as a black box; the emphasis
of the diagram is events that cross the system boundary from actors to
systems.
2. What is meant by System Behavior?
System behavior is a description of what a system does, without explaining

how it does it. One Part of that description is a system sequence diagram.
Other parts include the Use cases,
and system contracts(tobediscussedlater).
3. What is meant by Inter-System SSDs?
SSDs can also be used to illustrate collaborations between systems, such as

between the Next Gen POS and the external credit payment authorizer.
However, this is deferred until a later iteration in the case study, since this
iteration does not include remote systems collaboration.
4. Define System Events and the System Boundary.
To identify system events, it is necessary to be clear on the choice of

system boundary, as discussed in the prior chapter on use cases. For the
purposes of software development, the system boundary is usually
chosen to be the software system itself; in this context, a system event is
an external event that directly stimulates the software.
5. How to Naming System Events and Operations?
System events (and their associated system operations) should be expressed at

the level of intent rather than in terms of the physical input medium or
interface widget level.
It also improves clarity to start the name of a system event with a verb Thus
"enter item" is better than "scan" (that is, laser scan) because it captures the
intent of the operation while remaining abstract and noncommittal with
respect to design choices about what interface is used to capture the system
event.
6. What is meant by interaction diagram?
The term interaction diagram is a generalization of two more specialized UML

diagram types; both can be used to express similar message interactions:
. Collaboration diagrams
. Sequence diagrams
7. What is meant by link?
A link is a connection path between two objects; it indicates some form of
navigation And visibility between the objects is possible . More formally, a
link is an instance of an association. For example, there is a link or path of
navigation from a Register to a Sale, along which messages may flow, such as
the make 2 Payment message.
8. What is meant by Messages?
Each message between objects is represented with a message expression

and small arrow indicating the direction of the message. Many messages
may flow along this link. A sequence number is added to show the
sequential order of messages in the current thread of control.
9. How to create an instance?
Any message can be used to create an instance, but there is a convention in

the UML to use a message named create for this purpose. If another (perhaps
less obvious) message name is used, the message may be annotated with a
special feature called a UML stereotype, like so: «create».
The create message may include parameters, indicating the passing of
initial values. This indicates, for example, a constructor call with
parameters in Java.
10. What is meant by Low Coupling?
Coupling is a measure of how strongly one element is connected to, has

knowledge of, or relies on other elements. An element with low (or weak)
coupling is not dependent on too many other elements; "too many" is
context-dependent, but will be examined. These elements include classes,
subsystems, systems, and so on.
11. What is meant by High COHESION?
Cohesion (or more specifically, functional cohesion) is a measure of how

strongly related and focused the responsibilities of an element are. An element
with highly related responsibilities, and which does not do a tremendous
amount of work, has high cohesion. These elements include classes,
subsystems, and so on.
12. Define Controller.
Assign the responsibility for receiving or handling a system event

message to a class representing one of the following choices:
- Represents the overall system, device, or subsystem (facade controller).
- Represents a use case scenario within which the system event
occurs, often named <UseCaseName>Handler,
<UseCaseName>Coordinator, or <Use- CaseName>Session (use-
case or session controller).
- Use the same controller class for all system events in the same
use case scenario. -Informally, a session is an instance of a
conversation with an actor.
-Sessions can be of any length, but are often organized in terms of use cases (use
case sessions).
13. What is meant by CRC card?
CRC cards are index cards, one for each class, upon which the
responsibilities of the class are briefly written, and a list of collaborator
objects to fulfill those responsibilities. They are usually developed in a small
group session. The GRASP patterns may be applied when considering the
design while using CRC cards.
14. What is meant by Pure Fabrication?
This is another GRASP pattern. A Pure Fabrication is an arbitrary creation of

the designer, not a software class whose name is inspired by the Domain
Model. A use-case controller is a kind of Pure Fabrication.
15. List the relationships used in class diagram? APRIL/MAY-2011
Generalization(class to class)
Association (object to object) Aggregation(objecttoobject)
Composition (object to object)
Unit-IV
GRASP
PART- A
1. How to Choosing the Initial Domain Object?
Choose as an initial domain object a class at or near the root of the

containment or aggregation hierarchy of domain objects. This may be a
facade controller, such as Register, or some other object considered to
contain all or most other objects, such as a Store.
2. How to Connecting the UI Layer to the Domain Layer?
• An initializing routine (for example, a Java main method) creates both a

UI and a domain object, and passes the domain object to the UI.
• A UI object retrieves the domain object from a well-known source, such as a
factory object that is responsible for creating domain objects.
3. Mention the Interface and Domain Layer Responsibilities.
The UI layer should not have any domain logic responsibilities. It should only
be responsible for user interface tasks, such as updating widgets. The UI layer
should forward requests for all domain-oriented tasks on to the domain layer,
which is responsible for handling them.
5. Define patterns.
A pattern is a named problem/solution pair that can be applied in new
context, with advice on how to apply it in novel situations and discussion of
its trade-offs.
6. How to Apply the GRASP Patterns?
The following sections present the first five GRASP patterns:

. Information Expert
. Creator
. High Cohesion
. Low Coupling
. Controller
7. Define Responsibilities and Methods.
The UML defines a responsibility as "a contract or obligation of a classifier"

[OMG01]. Responsibilities are related to the obligations of an object in
terms of its behavior. Basically, these responsibilities are of the following
two types:
Doing responsibilities of an object include:

- doing something itself, such as creating an object or doing a calculation
- initiating action in other objects
-controlling and coordinating activities in
other objects Knowing responsibilities of an
object include:
- knowing about private encapsulated data
- knowing about related objects
- knowing about things it can derive or calculate
8. Who is creator?
Solution Assign class B the responsibility to create an instance of class
A if one or more of the following is true:
. B aggregates an object.
. B contains an object.
. B records instances of objects.
. B closely uses objects.
. B has the initializing data that will be passed to A when it is created (thus B
is an Expert with respect to creating A).
B is a creator of an object.
If more than one option applies, prefer a class B which aggregates or contains
class A.
9. List out some scenarios that illustrate varying degrees of functional

cohesion.
-Very low
cohesion -low
cohesion -High
cohesion -
Moderate cohesion
10. Define Modular Design.

Coupling and cohesion are old principles in software design; designing with
objects does not imply ignoring well-established fundamentals. Another of
these. Which is strongly related to coupling and cohesion? is to promote
modular design.
11. What are the advantages of Factory objects?
• Separate the responsibility of complex creation into cohesive helper objects.

• Hide potentially complex creation logic.
• Allow introduction of performance-enhancing memory management
strategies, such as object caching or recycling.
12. Designing for Non-Functional or Quality Requirements.
Interestingly—and this a key point in software architecture—it is common

that the large-scale themes, patterns, and structures of the software
architecture are shaped by the designs to resolve the non-functional or
quality requirements, rather than the basic business logic.
13. Abstract for Factory (GoF) for Families of Related Objects.
The Java POS implementations will be purchased from

manufacturers. For example5:
// IBM's drivers
com.ibm.pos.jpos.CashDrawer (implements
jpos.CashDrawer) com.ibm.pos.jpos.CoinDispenser
(implemen
ts jpos.CoinDispenser) // NCR's drivers
com.ncr.posdrivers.CashDrawer
(implements
jpos.CashDrawer)
com.ncr.posdrivers.CoinDis
penser (implements jpos.CoinDispenser)
14. What is meant by Abstract Class Abstract Factory?
A common variation on Abstract Factory is to create an abstract class factory

that is accessed using the Singleton pattern, reads from a system property to
decide which of its subclass factories to create, and then returns the
appropriate subclass instance. This is used, for example, in the Java libraries
with the java.awt.Toolkit class, which is an abstract class abstract factory for
creating families of GUI widgets for different operating system and GUI
subsystems.
15. What is meant by Fine-Grained Classes?
Consider the creation of the Credit Card, Drivers License, and Check software
objects. Our first impulse might be to record the data they hold simply in their
related payment classes, and eliminate such fine-grained classes. However, it
is usually a more profitable strategy to use them; they often end up providing
useful behavior and being reusable. For example, the Credit Card is a natural
Expert on telling you its credit company type (Visa, MasterCard, and so on).
This behavior will turn out to be necessary for our application.
16. Define coupling. APIRAL/MAY-2011

The degree to which components depend on one another. There are two types
of coupling, "tight" and "loose". Loose coupling is desirable for good software
engineering but tight coupling may be necessary for maximum performance.
Coupling is increased when the data exchanged between components becomes
larger or more complex.
Unit-V
UML state diagrams and modeling
PART- A
1. Define post condition.

The post conditions describe changes in the state of objects in the Domain
Model. Domain Model state changes include instances created,
associations formed or broken, and attributes changed.
2. Define Attributes.
An attribute is a logical data value of an object.
3. When Are Contracts Useful?
The use cases are the main repository of requirements for the project. They
may provide most or all of the detail necessary to know what to do in the
design, in which case, contracts are not helpful. However, there are situations
where the details and complexity of required state changes are awkward to
capture in use cases.
4. Mention the Guidelines for Contracts.
To make contracts:
1. Identify system operations from the SSDs.
2. For system operations that are complex and perhaps subtle in their
results, or which are not clear in the use case, construct a contract.
3. To describe the post conditions, use the following categories:
- Instance creation and deletion
- attribute modification
- Associations formed and broken
5. What are Steps for Mapping Designs to Code?
Implementation in an object-oriented programming language requires

writing source code for:
• Class and interface definitions
• Method definitions
6. Creating Class Definitions from DCDs.
At the very least, DCDs depict the class or interface name, super classes,
method signatures, and simple attributes of a class. This is sufficient to create
a basic class definition in an object- oriented programming language. Later
discussion will explore the addition of interface and namespace (or package)
information, among other details.
7. What are the Benefits of Iterative Development?
• Early rather than late mitigation of high risks (technical, requirements,

objectives, usability, and so forth)
• Early visible progress
• Early feedback, user engagement, and adaptation, leading to a refined
system that more closely meets the real needs of the stakeholders
• managed complexity; the team is not overwhelmed by "analysis paralysis"
or very long and complex steps
• The learning within iteration can be methodically used to improve the
development process itself, iteration by iteration
8. Define Events, States, and Transitions. APRIL/MAY-2011
An event is a significant or noteworthy

occurrence. For example:
A telephone receiver is taken off the hook.
A state is the condition of an object at a moment in time—the time
between events. For example:
• A telephone is in the state of being "idle" after the receiver is placed on the
hook and until it Is taken off the hook.
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.
For example:
• When the event "off hook" occurs, transition the telephone from the "idle" to
"active" state.
9. What is meant by State chart Diagrams?
A UML state chart diagram, illustrates the interesting events and states of an
object, and the behavior of an object in reaction to an event. Transitions are
shown as arrows, labeled with their event. States are shown in rounded
rectangles. It is common to include an initial pseudo-state, which
automatically transitions to another state when the instance is created.
10. State chart Diagrams in the UP?
There is not one model in the UP called the "state model." Rather, any
element in any model (Design Model, Domain Model, and so forth) may have
a state chart to better understand or communicate its dynamic behavior in
response to events. For example, a state chart associated with the Sale
design class of the Design Model is itself part of the Design Model.
11. Utility of Use Case State chart Diagrams.
- Hard-coded conditional tests for out-of-order events

- Use of the State pattern (discussed in a subsequent chapter)
- disabling widgets in active windows to disallow illegal events (a desirable
approach)
- A state machine interpreter that runs a state table
representing a use case State chart diagram.
12. List out the types of Events.
-External
event -
Internal event
- Temporal
event
13. Define External event.
External event—also known as a system event, is caused by something (for

example, an actor) outside our system boundary. SSDs illustrate external
events. Noteworthy external events precipitate the invocation of system
operations to respond to them.
- When a cashier presses the "enter item" button on a POS terminal, an

external event has occurred.
14. Define internal event.
Internal event—caused by something inside our system boundary. In terms

of software, an internal event arises when a method is invoked via a
message or signal that was sent from another internal object. Messages in
interaction diagrams suggest internal events.
- When a Sale receives a make Line item message, an internal event has occurred.
15. Define temporal event.
Temporal event—caused by the occurrence of a specific date and time or

passage of time. In terms of software, a temporal event is driven by a real time
or simulated-time clock.
-Suppose that after an end Sale operation occurs, a make Payment operation
must occur within five minutes, otherwise the current sale is automatically
purged.
UNIT 1-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 (2 Marks)
Q.NO QUESTIONS COMPETENCE LEVEL
1 What is Object Oriented analysis & Design? Remembering BTL1
2 List the 4 phases in UP. Remembering BTL1
3 Compose your views on iterative Development and
write it benefits. Creating BTL6
4 Define UML and list out its perspectives. Remembering BTL1
5 Define design Class Diagram. When to use Class
Diagrams? Remembering BTL1
6 Define Use Case. Point out the test that can help to
find useful use cases. Analysing BTL4
7 Illustrate the relationship used in Use case. Applying BTL3
8 Discover the major Difference between Component and
Deployment Diagram. Applying BTL3
9 Classify the 3 kinds of actors in use case.
Examine the purpose of using usecases to
describe requirements. Analysing BTL4
10 Define State Chart Diagram. When to use State Remembering BTL1
Diagram?
11 Compare Activity and state chart diagram. Evaluating BTL5
Mention the Elements of an Activity Diagram.
12 Define Aggregation and Composition. Remembering BTL1
13 Distinguish between method and message in
Understanding BTL2
object.
14 Formulate the purpose of Interaction Diagram. Creating BTL6
15 What is package diagram? Classify the three layers of
Analysing BTL4
package Diagram.
16 Discuss the Strength and Weakness of the Use case Understanding BTL2
Diagram.
17 Interpret the meaning of event, state and Understanding BTL2
Transition.
18 Define an Object. Illustrate the probable
attributes that will be modeled in a library Applying BTL3
database for the object BOOK.
19 Compare and Contrast Sequence and Collaboration
Evaluating BTL5
diagram.
20 Describe the Primary goals in the Design of Understanding BTL2
UML.
PART – B (13 Marks)
1 i) Explain in detail about the Unified process in object
oriented Analysis and Design? Explain the phases
with neat diagrams. (6)
ii) What is UML activity Diagram? Using an example Analysing BTL4
explain the features of basic UML activity diagram
notation. (7)
2 Distinguish between the Concepts of component and
Deployment Diagram with an example of Book bank Understanding BTL2
system. (13)
3 Apply Interactive modeling for a Payroll system in
UML. (13) Applying BTL3
4 (i)Describe in detail about the Class Diagram. (4)

(ii)Define use case Diagram. (2)
(iii)Model a use case diagram for a Banking System.
Explain the business rules you are
considering.Consider the following use Cases that
play a role in the Banking System you have
modeled: Remembering BTL1
1. Deposit (4)
2. Withdraw Model sequence diagrams for the
above two use cases. (3)
5 Write a problem statement for Library Management
System. Design the UML Use Case diagram, Activity
diagram, Class diagram, Sequence diagram, State chart
diagram, Package diagram, and Component and Creating BTL6
Deployment
diagram. (13)
6 i) Describe an outline of object oriented analysis and
object oriented design. (6)
ii) Why the unified process has emerged as a Remembering BTL1
popular and effective software development
process? (7)
7 i)Describe the UML notation for Class diagram with
an example. Explain the concept of link, association
and inheritance. (6) Remembering BTL1
ii)Identify the major difference between sequence and
collaboration diagram. (7)
8 i) Summarize with an example, how interaction
Diagram are used to model the dynamic aspects of a
system. (5)
ii) Discuss the topic on Understanding BTL2
(i) Aggregation and Composition. (3)
(ii)Generalization and Specialization. (3)
(iii) Attributes and Association. (2)
9 i) Explain the UML state machine diagram and
Modeling. (5)
ii) A Library lends books and magazines to
member, who is registered in the system. It also
maintains the purchase of new books and
magazines for the Library. A member can reserve a
book or magazine that is not currently available in the
library, so that when it is returned or
purchased by the library, that person is notified. The
library can easily create, replace and delete
information about the books, members, and reservation Analysing BTL4
in the system. Book’s transactions are stored
in the database. The fine list while the member
returns the book after the due date must be generated.
Analyze and discover the users and actors of this
system, and the interactions
between them must be depicted.(8)
10 i)Describe in detail about Sequence Diagram. (5)
ii)Draw and discuss the Sequence and collaboration
diagram for an Online Purchase System. (5)
iii)Give the three ways to apply Unified Modeling Understanding BTL2
Language (UML). (3)
11 Explain about usecase model for a case study of your

Analysing BTL4
choice. (13)
12 i)Explain with an example, how use case modeling
is used to describe functional
requirements, Identify the actors, scenario and use
Evaluating BTL5
cases for the example. (6)
ii)Comparison between Activity and State chart
Diagram. (7)
13 i) Describe UML Package diagram with example.
(7)
Remembering BTL1
ii) When to use Activity and State chart diagram?
(6)
14 Illustrate about UML Deployment and Component
diagram. Draw the Diagrams for banking applications. Applying BTL3
(13)
PART – C(15 Marks)
1 A University conducts examinations and the results are
announced. Prepare a report for the following:
• Print the marks in the register number order
semester wise for each department
• Print the Arrear list semester wise.
• Prepare a Rank list for each
department.
• Prepare the final aggregate mark list for
final year students. Creating BTL6
Identify the problem statement and Design and
Explain the classes for each sequence. Draw a detailed
flow chart using state chart diagrams. Design this
system using Rational Rose. Design all the UML
diagrams for designing this system. (15)
2 Write a problem statement for Quiz System. Design

the UML Use Case diagram, Activity diagram, Class
diagram, Sequence diagram, State chart Creating BTL6
diagram,Package diagram, and
Component and Deployment diagram. (15)
3 Evaluate and Model a state transition diagram for Evaluating BTL5
the following scenario.
Here is what happens in a microwave oven :
• The oven is initially in an idle state with door
open, where the light is turned ON.
• When the door is closed it is now in idle but the
light is turned OFF.
• If a button is pressed, then it moves to initial
cooking stage, where the timer is set and lights
are ON and heating starts
• At any moment the door may be opened, the
cooking is interrupted, the timer is cleared and
heating stops.
• Also while cooking, another button can be
pushed and extended cooking state starts, where the
timer gets more minutes.at any moment door can be
opened here also. (15)
(i) Analyze and Model a usecase diagram for the
following scenario:
Deepthi super market wants a subsystem to process
supply orders via the web .the user will supply via a
from their name ,passwords ,account no and list of
supplies along with an indication of the quantities
desired .the subsystems will validate the order
number, expected shift date and the total cost of the
order. If the validation step fails, the subsyste3m will Analysing BTL4
generate an error message describing the cause of the
failure.
(ii) ”A component represents a modular
,deployable and replaceable part of a system that
encapsulates implementation and expose a set of
interfaces”.Elucidate with an example. (15)
UNIT II-DESIGN
PATTERNS
GRASP: Designing objects with responsibilities – Creator – Information
expert – Low Coupling– HighCohesion – Controller - Design Patterns –
creational - factory method - structural – Bridge – Adapter -behavioral –
Strategy – observer.
PART – A(2 Marks)

1 Define Patterns and Design Patterns. When to use Remembering BTL1
pattern?
2 Define responsibility. What are the various types Remembering BTL1
of responsibilities?
3 List out the categories of Design patterns. State the Remembering BTL1
use of design pattern.
4 Define GRASP. How to apply the GRASP Remembering BTL1
patterns?
5 When does a pattern is said to be a good Remembering BTL1
pattern?
6 Define modular design. Remembering BTL1
7 Interpret the need of Information Expert. Understanding BTL2
8 Distinguish between coupling and cohesion. Understanding BTL2
9 Express the benefits of low coupling. Understanding BTL2
10 Analyze about coupling. Analysing BTL4
11 ‘A system must be loosely coupled and highly Evaluating BTL5
cohesive’. Justify.
12 Compose your views on High Cohesion. Creating BTL6
13 Examine the benefits of controller. Applying BTL3
14 Discuss the benefits and the types of adapter Understanding BTL2
pattern.
15 Summarize the list of structural patterns used Evaluating BTL5
during.
16 Analyze the situation to use Factory method

pattern. Analysing BTL4
17 Classify GoF design patterns in groups. Applying BTL3
18 Discover the Limitations of Factory Pattern. Applying BTL3
19 Generalize your view on creator. Creating BTL6
20 Point out the interface and domain layer

responsibilities.
Analysing BTL4
PART – B (13 Marks)

1 (i) Explain the design principles in object modeling.
(6)
(ii) Explain in detail the GRASP method for Analysing
BTL4
designing objects with example. (7)
2 What is GRASP? Describe the design patterns and

principles used in it. (13) Remembering BTL1
3 Examine the following GRASP patterns: (i)Creator

(3)
(ii)Information Expert (3)
(iii) Lo Remembering BTL1
w coupling (2)
(iv) High cohesion (2)
(v) Controller (3)
4 Explain about Creator and controller design patterns Analysing BTL4
with example. (13)
5 (i) Compare cohesion and coupling with suitable
example. (6) BTL5
Evaluating
(ii) Summarize and state the role and patterns while
developing system design. (7)
6 (i) Design creator and information expert GRASP

patterns. (6)
Creating BTL6
(ii) Generalize the concepts of Façade, session and
bloated controller. (7)
7 i) Discuss about Low Coupling and High Cohesion

with example. (6)
ii) Describe the different scenarios of functional Understanding BTL2
cohesion. (7)
8 i)Discuss with an example the Factory method design Understanding

pattern. (6)
BTL2
ii)Discuss about coupling and mention its types.
(7)
9 i)Differentiate Adapter and Bridge pattern. (6)
ii)Analyze how will you design the behavioral pattern. Analysing
(7) BTL4
10 Discuss the topic on :

(i) Adapter Pattern (5) Understanding
(ii) Observer Pattern (5) BTL2
(ii)Factory Pattern (3)
11 (i) Describe about Strategy pattern. (6)
(ii) List out the applications of Factory pattern and Remembering BTL1
mention its Limitations. (7)
12 (i) Examine in detail about Behavioral pattern. (6)

Remembering BTL1
(ii) Describe the concepts of Singleton Pattern.(7)
13 Demonstrate in detail about the various categories Applying BTL3

of Design pattern. (13)
14 (i) Illustrate your views about Structural patterns.
(6)
Applying BTL3
(ii)What is Visibility? Classify the ways of visibility
and explain it. (7)
PART – C(15 Marks)
1 Create the observer pattern by using your own BTL6

application and explain the sections of the design Creating
pattern. (15)
2 Generalize the design issues in implementation of BTL6

Singleton pattern. (15) Creating
3 Explain the GRASP pattern(Creator,Infromation

Expert,Low coupling) by using Monopoly game. Evaluating BTL5
(15)
4 i) Analyze and categories of Design pattern. (8)
ii) Analyze the creational pattern by using Maze game. Analysing BTL4
(7)
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(2 Marks)
1 What is a POS system? List the components of POS Remembering BTL1
system.
2 List out the advantages of Use case Modeling. Remembering BTL1
3 Define Domain Model and list out its Components. Remembering BTL1
4 Compare abstract use case and concrete Use Case. Analysing BTL4
5 Express the meaning of Elaboration and What are the Understanding BTL2
tasks performed in elaboration?
6 Differentiate Include and Extend use case Analysing BTL4
relationships.
7 What is the relationship of a conceptual super Remembering BTL1
class to a subclass?
8 Demonstrate how to create a Domain model. Applying BTL3
9 Express why we call domain model
Understanding BTL2
a “VisualDictionary".
10 When to create a subclass of a superclass? Remembering BTL1
11 Compare Aggregation and Composition. Evaluating BTL5
12 Illustrate the usage of Description class. Applying BTL3
13 Generalize the purpose of association relationship. Creating BTL6
14 Show the important deals in Inception of the POS Applying BTL3
system? Mention the requirements of Inception
phase of the POS system.
15 Define attribute? List out the types of attributes. Remembering BTL1
16 Interpret the meaning of Generalization and
Understanding BTL2
Specialization.
17 Differentiate Conceptual class and abstract conceptual Understanding BTL2
class.
18 How to create an inception? Creating BTL6
19 Compare qualified association and reflexive
association. Evaluating
BTL5
20 Point out the main goals of Establishing Analysing BTL4

conceptual class Hierarchies.
PART-B (13 Marks)
1 (i) What is a POS system? Briefly explain about Analysing BTL4
Inception Phase. (8)
(ii) Compare between Association and attributes.
(5)
2 Constructs the design for Library information system

which comprises and following notations.
(i) Aggregation and Composition. (6)
Creating BTL6
(ii)Generalization and Specialization. (2)
(iii)Associations (5)
3 (i) Summarize the Elaboration phase. Discuss the
differences between elaboration and inception with
suitable diagram for university domain. (8)
Understanding BTL2
(ii) Describe a suitable example showing the various
relationships used in Use Case and also give a short
note on each relationship. (5)
4 (i) Describe the strategies used to identify the
conceptual classes. (6)

Understanding BTL2
(ii)Describe the steps to create a domain model used
for representing the conceptual classes. (7)
5 (i) Illustrate the concepts of Domain model with
example. (8)
Applying BTL3
(ii) Show when to model with Description classes with
example. (5)
6 (i) Explain the purpose of use case model? Identify the

actors, scenarios, and use cases for a library
Management system. (8)
Evaluating BTL5
(ii) Rank the three kinds of actors and explain the 3
common Use Case formats. (5)
7 (i) Describe briefly about association and formulate the

guidelines to be followed with UML with suitable
example. (7) Remembering BTL1
(ii) Describe the concepts of Derived attribute. (6)
8 (i) Discuss about attributes with example. (6)

(ii)Discuss the topic on:
a) Conceptual subclass. (2)
Understanding BTL2
b) Conceptual super class. (2)
c) Multiplicity. (3)
9 (i) Explain in detail about domain Model refinement.
(8)
(ii) What is use cases and explain in detail about the Analysing BTL4
sample Unified process Artifacts Relationships.
(5)
10 (i) Analyze the guidelines to define a conceptual

Classes and subclass with suitable example and Analysing BTL4
diagram. (8)
(ii) Analyze the guidelines to define a conceptual
super class with suitable example. (5)
11 (i) What are the guidelines used to partition the classes
in the domain model to be organized into packages?
Explain with suitable examples. (8) Remembering BTL1
(ii) Describe the benefits of composition. (5)
12 (i) Examine the various sections in the Use Case

template with example. (6)
Remembering BTL1
(ii) List the guidelines to be followed when writing Use
Case. (7)
13 (i) Describe in detail about Finding Conceptual class

Hierarchies. (8)
(ii)Describe briefly about association classes and Remembering BTL1
association role. (5)
14 (i) Illustrate about aggregation and composition with

example. Mention the guidelines to be followed. (6)
(ii) Illustrate the topic on
a) Generalization (3)
b) Specialization (2) Applying BTL3
c) Conceptual class hierarchies. (2)
PART-C(15 Marks)
1 With a suitable example explain how to design a class.
Give all possible representation in a class(such
Creating BTL6
as:name,attribute,visibility,methods,and
responsibilities). (15)
2 For the NextGen POS system design the
following conceptual class hierarchies:
(i) Conceptual super class (4)
Creating BTL6
(ii) Conceptual subclass (4)
(iii)Authorization Transaction classes. (4)
(iv)Abstract Conceptual classes. (3)
3 Explain the concepts of Finding Description classes BTL5
with the example of Airline and mobile phone Evaluating
company. (15)
4 Explain the benefits and concepts of use case and use
case model and analyze the use cases for the Library Analysing BTL4
management system. (15)
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- UMLinteraction diagrams - Applying GoF
design patterns.
PART – A(2 Marks)
1 Express the use of Sequence Diagram. Understanding BTL2
2 Distinguish sequence diagram and communication
diagram.What are their strengths and weaknesses? Understanding BTL2
3 Demonstrate what do you mean by sequence Applying BTL3

number in UML? Where and for what it is used?
4 What is meant by System Behavior? How will you Remembering BTL1
name system events and operations?
5 Define Package. Draw UML notation for Package. Remembering BTL1
6 Analyze the key reason for modeling a package Analysing BTL4
diagram.
7 Define Logical architecture. How is it different Remembering BTL1
from layers ?.
8 Formulate the guideline to be followed when Creating BTL6
designing with layers.
9 Name the different types of architectural layers. Remembering BTL1
10 Differentiate strict layered and relaxed layered
Understanding BTL2
architecture.
11 Summarize the Model-View separation principle. Evaluating BTL5
12 List the two types of UML Interaction diagrams Remembering BTL1
13 Name the layers in the 3 tier architecture. Remembering BTL1
14 Show the way you will define system Events and Applying BTL3
system boundary.
15 Express the meaning of Facade. Understanding BTL2
16 Differentiate Class diagram and Interaction Analysing BTL4
diagram.
17 Illustrate the term Classifier. Applying BTL3
18 Create SSD for Borrow book scenario. Creating BTL6
19 Summarize the benefits of using layers. Evaluating BTL5
20 Compare and Contrast asynchronous and Analysing BTL4
synchronous message.
PART-B (13 Marks)

1 (i) Illustrate the relationship between sequence
diagram and Use Case with example. (5)
Applying BTL3
(ii) Demonstrate the Interaction Diagram notations and
explain it? (8)
2 (i) Describe briefly about the logical architecture and

UML package diagram. (6) BTL1
Remembering
(ii) Identify the relationship between Domain layer and
Domain model. (7)
3 What is Model View separation principle? Examine

the motivation for Model View separation. (13) Remembering BTL1
4 (i) What are the benefits of using layers? Provide the

relationship between Domain layer and Domain
model. (8)
Remembering BTL1
(ii) Describe the concepts of Relaxed layer coupling.
(5)
5 Draw a neat sketch of logical layered architecture Understanding BTL2

of Next Gen application and discuss the
components in detail. (13)
6 (i) What do you mean by system sequence diagram?
(5)
Understanding BTL2
(ii) Differentiate the relationship between SSDs and
use cases? Explain with an Example. (8)
7 Describe the UML notation for class diagram with an

example. Explain the concept of Link, association and Understanding BTL2
Inheritance. (13)
8 (i) Examine the UML Class, Sequence and
Interaction diagrams for Library Management
system. (8)
Applying BTL3
(ii) Illustrate how interaction diagram are used to
model the dynamic aspects of the system. (5)
9 (i)Explain about Interaction diagram notation for

Inventory Management System. (8)
Analysing BTL4
(ii)Explain in detail about UML package Diagram.
(5)
10 (i) Compare sequence diagram and communication
diagram with suitable example.
(8) Evaluating BTL5
(ii) Explain the Concepts of frames in UML. (5)
11 (i) How to add New SSDs and contracts to the design

diagram? Explain it. (8)
Analysing BTL4
(ii) What are the concepts involved in domain model
refinement? (5)
12 i)What is design pattern? Describe the GOF design

patterns. (6) Remembering BTL1
ii) Writ
e a short note on CRC card. (7)
13 Generalize your views and write notes on Structural Creating BTL6
and Behavioral Pattern. (13)
14 With an example explain notations used in Analysing BTL4
sequence diagram for the following:
(i) Object destruction. (3)
(ii) Frames. (3)
(iii) Conditional message. (3)
(iv) Mutually exclusive conditional message. (2)
(v)Iterations over a collection. (2)
PART-C (15 Marks)

1 For the Course Registration system design
the following UML diagrams.
(i) Conceptual Class Diagram (Over all system).
(8) Creating BTL6

(ii) Sequence and collaboration diagram
(Login process, maintaining the course details.)
(7)
2 Design the logical layer architecture for Next Creating BTL6
Generation application. (15)
3 Consider the following use case that plays a role in a
banking system:
i) Deposit (8)
Evaluating BTL5
ii) Withdraw(minimum balance has to be
checked)model sequence diagram for the above use
cases. Explain. (7)
4 Compare sequence and communication diagram by Analysing BTL4
using the Ticket Reservation system. (15)
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(2 Marks)
1 What are the steps for mapping design to Remembering BTL1
code?
2 What is TDD? Remembering BTL1
3 Give the advantages of test driven Understanding BTL2
development.
4 Define refactoring. Remembering BTL1
5 List the activities and goals of refactoring. Remembering BTL1
6 Summarize the issues in OO testing. Understanding BTL2
7 Summarize class testing. Evaluating BTL5
8 Conclude on the need of OO Integration Evaluating BTL5
testing.
9 Generalize the need of GUI testing. Creating BTL6
10 Analyze the need for OO system testing and Analysing BTL4
regression testing.
11 Differentiate OO integration testing and OO Understanding BTL2
system testing.
12 Pointout the meaning of a test case. Give eg. Analysing BTL4
13 List the 2 levels of Integration testing. Remembering BTL1
14 Examine on static view, compile time view and Applying BTL3
execution time view on classes.
15 Illustrate about Unit testing. Applying BTL3
16 Point out the use of atomic system function Analysing BTL4
(ASF).
17 Interpret the use of method/message path Understanding BTL2
(MM-path).
18 Design the 4 controls commonly used in GUI Creating BTL6
design.
19 List the 3 types of system function. Remembering BTL1
20 Point out the 4 levels with coverage metrics for Applying BTL3
GUI application.
PART-B(13 Marks)
1 Explain in detail about mapping design to code Analysing BTL4
concepts in detail. (13)
2 (i).Describe in detail about coding and testing in
OOAD. (8) Remembering BTL1
ii)Write short notes on system testing. (5)
3 (i) Discuss in detail about the different types of
testing in OOAD. (8)
(ii) Describe the two views of OO unit testing. Understanding BTL2
(5)
4 (i) Discuss briefly about the issues in OO testing. (8)
(ii)Describe the two levels of integration in OO Understanding BTL2

integration testing. (5)
5 (i) What is OO testing? (5)

(ii) Examine in detail about the concepts of OO Remembering BTL1
testing in OOAD. (8)
6 (i) How is class testing different from conventional

testing? Explain with an example.
(5) Evaluating BTL5
(ii) Explain the implications of Encapsulation and
polymorphism. (8)
7 (i) Illustrate about OO Integration testing with
example. (8)
Applying BTL3
(ii) Illustrate the Unit testing concepts by using
Currency Conversion program. (5)
8 Demonstrate the need for GUI testing. (13) Applying BTL3

9 (i) Describe about OO system testing. (8)
(ii)Describe the concepts of Event and Message Remembering BTL1
Driven petri Nets(EMDPNs) (5)
10 (i) Compare and contrast OO integration testing

and OO system testing. (8) Analysing BTL4
(ii) Explain the implication of inheritance. (5)
CS8592 OOAD QR Code Based Video Lecturer Notes
11 (i).Differentiate GUI testing and class testing.

(8)
Analysing BTL4
(ii)Explain the three types of system functions in
OO system testing. (5)
12 (i) Examine the framework for OO data flow
integration testing. (8)
Remembering BTL1
(ii)Describe the concepts of UML based system
testing. (5)
13 i) Summarize on how is class testing different

from conventional testing? Explain with an
example. (8) Understanding BTL2
ii) Write a note on system testing. (5)
14 (i) Use currency converter application as example

and generalize the steps in OO system testing. (8)
(ii) Generalize the concepts of implications in Creating BTL6
Polymorphism. (5)
PART-C(15 Marks)
1 Prepare the implementation model (Mapping
design to code) and give the NextGen POS program Creating BTL6
(15)
2 Develop the foundation code for Monopoly game Creating BTL6
System. (15)
3 Explain in detail about the implication of
Composition and Encapsulation with the example of Evaluating BTL5
Winder shield wiper system. (15)
4 Analyze the Unit, Integration, and system testing for Analysing BTL4
currency converter application. (15)
CS8592 OOAD Vijayanand Shanmugam Facultytalkies.com

Question Bank
UNIT-1
1. Explain the important & principles of modeling.

2. Explain the Soft ware development life cycle.
3. Describe the structural things of UML.
4. Explain the Architecture of the UML.
5. Explain the different Types of UML diagrams.
6. What are the static diagrams of UML.
7. What are the dynamic diagrams of UML.
8. Write common modeling techniques of classes.
9. Explain four types of Relations with examples.
10. What is Packages? Explain terms and concepts of package.
11. Write common modeling techniques of package.
12. Write and explain four Common mechanisms in the UML.
13. What are the advanced relationships in UML.
14. Explain interface in the UML.
15. What are the advanced classes in UML?
UNIT-2
1. Explain Class diagrams with one example diagram.
2. Write common modeling techniques of class diagrams.
3. Explain Object diagrams with one example diagram.
4. Write common modeling techniques of object diagrams.
5. Draw the class diagram for library management system.
6. Draw the object diagram for ATM Applications.
7. Explain interactions and terms and concepts of interactions.
8. Differences between collaborations diagram and sequence diagrams.
9. Explain the sequence diagram with example.
10. Explain the collaboration diagram with example.
11. Write common modeling techniques of collaboration diagrams.
12. Write common modeling techniques of sequence diagrams.
13. Draw the sequence diagram for Quiz Applications.
14. Draw the collaboration diagram for Hospital Management System.
UNIT-3
1. Explain use case and terms and concepts of use case.
2. Explain the use case diagram with example.
3. Explain the Activity diagram with example.
4. Explain use case and terms and concepts of Activity diagram.
5. Write common modeling techniques of use case diagrams.

6. Write common modeling techniques of Activity diagrams.

7. Draw the Activity diagram for ATM Applications.
8. Draw the use case diagram for Hospital Management System.
9. Explain Events and signals in the UML.
10. What is state machine and terms and concepts of state machine.
11. Explain process and threads in UML.
12. Explain state chart diagrams and terms and concepts.
13. Write common modeling techniques of state chart diagrams.
14. Write common modeling techniques of process and threads
diagrams.
15. Draw the state chart diagram for ATM Applications.
16. Draw the state chart diagram for Quiz Applications.
UNIT-4
1. What is component and terms and concepts of component.

2. Explain the component diagram with example.
1. Difference between class and component.
2. Explain the Deployment diagram with example.
3. What is Deployment and terms and concepts of Deployment.
4. Difference between deployment and component.
5. Write common modeling techniques of component diagrams.
6. Write common modeling techniques of Deployment diagrams.
7. Draw the component diagram for ATM Applications.
8. Draw the deployment diagram for Hospital Management System.
UNIT-5
1. Case study of the Unified Library application.

2. Case study of the ATM application.
3. Case study of the Quiz application.
4. Case study of the online course registration.
5. Case study of the Hospital management system.

Previous Year Question Papers







Assignment Questions
Unit 1
1. Explain the important of modeling & principles of modeling.
2. Explain the s/w development life cycle.
3. Describe the structural things of UML modeling.
4. Draw and explain the Architecture of UML.
5. Describe the various types of UML diagrams.
6. What is Class? Enumerate the steps involved in modeling techniques.
7. Write the various Relations with examples.
Unit 2
1. What is Package? Write the steps involved in common modeling
techniques.
2. What are the Common mechanisms in the UML model?
3. Explain the Advanced relationships in UML model.
4. What is Class diagram? Draw the class diagram for Library management
system.
5. What are the common modeling techniques of class diagram?
6. What is Object diagram? Draw the object diagram for ATM Applications.
Unit 3
1. What are the common modeling techniques for Object diagram?

2. What is interaction diagram? Write the terms and concepts of
interactions.
3. Differences between collaborations and sequence diagrams.
4. Draw the sequence and collaboration diagrams for Hospital Management
System.
Unit 4
6. 16. Explain process and threads in UML.
Unit 5


19. Unit-wise objective type questions
UNIT 1
Objective type questions:
1. Which one of the following is not principal of modeling?

1. Choose your models well
2. Every model may not be expressed at different at different levels of
decision.
3. The best models are connected to reality.
4. No single model is sufficient.
2. Which one of the following view express the requirements of the system?
1. Usecase
2. Design
3. Process
4. Implementation.
3. UML is a _ _ _ _ _ _ _ _ _ modeling language.

1. general - purpose.
2. object-purpose.
3. architecture-purpose.
4. code-purpose.
4. We build models so that we can better _ _ _ _ _ the system we are developing.

[01M02]
1. misunderstand
2. understand
3. guide
4. misguide.
5. _ _ _ _ _ _ _ is a central past of all the activities that lead up to the deployment

of good software. [01S01]
1. Modeling

2. Coding
3. Testing
4. Analysis
6. What is a model? [01S02]

1. A model is a modification of reality
2. A model is a justification of reality
3. A model is a simplification of reality
4. A model is a construction of reality
7. UML stands for [01S03]

1. Uniform Modeling Language
2. Unified Modeling Language
3. United Modeling Language
4. Unique Modeling Language
8. Models tell us to _ _ _ _ _ _ _ _ a system as it is (or) as we want it to be.

[01S04]
1. visualize
2. specify.
3. constructing.
4. document.
9. Models permit us to _ _ _ _ _ _ _ _ the structure or behavior of a system.

[01S05]
1. visualize
2. specify.
3. constructing.
4. document.
10.Models give us a template that guides us in _ _ _ _ _ _ _ _ _ system. [01S06]

1. visualize
2. specify.
3. constructing.
4. document.
11.Models _ _ _ _ _ _ _ _ the decisions we have made. [01S07]

1. visualize
2. specify.
3. constructing.
4. document.
12.The best models are connected to _ _ _ _ _ _ _ _ _ _ _ _. [01S08]

1. reality.
2. functionality.
3. casuality

4. visualityl
13.A _ _ _ _ _ _ _ _ is a generic template for objects. [02D01]

1. program
2. class.
3. procedure.
4. method.
14.A _ _ _ _ _ _ _ _ method of an object cannot be accessed by other objects.

[02D02]
1. private
15.In an object-oriented approach the main building block of all software is the _
_ _ _ _ _. [02M01]
1. class
2. function.
3. procedure.
4. module.
16.The _ _ _ _ _ _ _ _ _ _ _ _ _ approach to software development is decidedly a

part of the mainstream. [02M02]
1. algorithmic.
2. object-oriented.
3. procedural.
4. modeled
17.In an algorithmic approach the main building block of all software is the _ _
_ _ _ _ _ . [02S01]
1. class.
2. abstract class.
3. object.
4. module.
18.Visualizing,specifying,constructing, & documenting object-oriented systems

is exactly the purpose of the _ _ _ _ _ _ _ _ _ _ _. [02S02]
1. C language.
2. C++ language.
3. pascal language .
4. Unified modeling language.
19.In _ _ _ _ _ _ _ _ , any program can call any other program. [02S03]

1. modular.
2. object.
3. procedural.
4. component.
20.An object contains _ _ _ _ _ _ _ _ _ _ _ _ _ _ _. [02S04]

1. attributes & methods.

2. only attributes.
3. only methods.
4. classes.
Objective Type Questions: UNIT 2
1._ _ _ _ _ _ _ _ _ is a special kind of association, representing a structural

relationship between a whole and its parts. [04M01]
1. dependency.
2. Aggregation.
3. Generalization.
4. Realization.
2.A _ _ _ _ _ _ _ _ _ _ relationship is rendered as a solid line with a hollow

arrowhead pointing to the parent. [04M02]
1. dependency.
2. Aggregation.
3. Generalization.
4. Realization.
3.A _ _ _ diagram shows the configuration of runtime processing nodes and the
components that live on them. [04M03]
1. usecase.
2. activity.
3. deployment.
4. component.
4.A _ _ _ _ _ _ _ _ _ is a semantic relationship between two things in which a

change to one thing may affect the semantics of the their thing. [04S01]
1. dependency.
2. generalization.
3. realization.
4. message.
5.An _ _ _ _ _ _ _ _ is a structural relationship that describes a set of links, a link

being a connection Among objects. [04S02]
1. interaction.
2. association.
3. interface.
4. dependency.
6.A _ _ _ _ _ _ _ _ _ is a specialization relationship in which objects of the

specified element are substitutable for objects of the generalized element.
[04S03]
1. dependency.

2. generalization.
3. realization.
4. message.
7.A _ _ _ _ _ _ is a semantic relationship between classifiers where in one

classifier specifies a contract that another classifier guarantees to carry out.
[04S04]
1. dependency.
2. generalization.
3. realization.
4. message.
8.UML includes _ _ _ _ diagrams. [04S05]

1. seven.
2. eight.
3. nine.
4. ten.
9.Which one of the following diagram address the dynamic view of a system?
[04S06]
1. class.
2. object.
3. component.
4. state chart.
10.Which one the following diagram address the static view of a system? [04S07]
1. interaction.
2. activity.
3. statechart.
4. component.
11.A _ _ _ _ _ _ _ extends the properties of a UML building block, allowing you to

create new information in that element's specification. [04S08]
1. tagged value.
2. stereotype.
3. Constraint
4. Adornmrnts.
12.A _ _ _ _ _ _ _ _ extends the semantics of a UML building block ,allowing you

to add new rules or modify existing ones. [04S09]
Ans:Constraint
13.A _ _ _ _ _ _ _ _ extends the vocabulary to the UML ,allowing you to create

new kinds of building block that are derived from existing ones out that are
specific to your problem. [04S10]
1. tagged value.

2. stereotype.
3. Constraint
4. Adornmrnts.
14._ _ _ _ _ _ _ _ _ is the fourth phase of the process when the software is turned
into the hands of the user community.
1. Inception.
2. Elaboration.
3. Construction.
4. Transition.
15.The coding phase roughly maps to the _ _ _ _ phase. [05D02]

1. inception.
2. elaboration.
3. construction.
4. trasition.
16.An _ _ _ _ _ _ _ _ _ is one that involves managing a streams of executable

releases. [05M01]
1. use case-driven.
2. iterative process.
3. incremental process.
4. architecture-centric.
17.The architecture model baseline is usually ready in the _ _ _ _ _ _ _ _ phase.

[05M02]
1. inception.
2. elaboration.
3. construction.
4. trasition.
18.The users get a chance to test the system in the _ _ _ _ _ _ _ _ phase. [05M03]
1. inception.
2. elaboration.
3. construction.
4. transition.
19.The _ _ _ _ _ view of a system encompasses the use cases that describe the
behavior of the system as seen by its end users, analysis and testers. [05S01]
1. design
2. use case
3. process
4. deployment.
20.The _ _ _ _ _ _ _ view of a system encompasses the classes, interfaces ,and

collaborations that form the vocabulary of the problem and its solution. [05S02]

1. design
2. usecase
3. process
4. deployment
Objective Type Questions: UNIT 3
1.The _ _ _ _ _ _ _ _ view of a system encompasses the threads and processes

that form the system's concurrency and synchronization mechanisms. [05S03]
1. design
2. use case
3. process
4. deployment
2.The _ _ _ _ _ view of a system encompasses the nodes that form the system's
hardware topology on which system executes. [05S04]
1. design
2. use case
3. process
4. deployment
3.The _ _ _ _ _ _ _ _ view of a system encompasses the components and files that

are used to assemble an release the physical system. [05S05]
1. implementation.
2. usecase
3. process
4. deployment
4.The analysis phase roughly maps to the _ _ _ _ _ _ _ _ _ phase. [05S06]

1. Inception.
2. Elaboration.
3. Construction.
4. Transition.
5.The design phase roughly maps to the _ _ _ _ _ _ _ _ _ _ phase. [05S07]

1. Inception.
2. Elaboration.
3. Construction.
4. Transitions.
6.Aggregation is a _ _ _ _ _ _ _ _ _ kind of relationship . [06D01]

1. is-a.
2. to-a.
3. was-a

4. has-a.
7.Use _ _ _ _ _ _ _ _ _ only when you have an is a- kind-of relationship. [06D02]

1. dependency.
2. association.
3. aggregation.
4. generalization.
8.Use _ _ _ _ _ _ _ _ only when the relationship you are modeling is not

structural. [06D03]
1. dependencies.
2. associations.
3. aggregations.
4. generalizations.
9._ _ _ _ _ _ _ _ _ _ _ can be drawn in a separate comportment at the bottom of

the class icon. [06M01]
1. usability.
2. responsibility
3. package.
4. state.
10.An association that connects exactly two classes is called a _ _ _ _ _ _ _ _ _ _.

[06M02]
1. binary association.
2. Terihy association.
3. normal association.
4. single association.
11.You can explicitly specify that there are more attributes or properties than
shown by ending each list with an _ _ _ _ _ _ _ _ _ _ _ _. [06M03]
1. circles.
2. sequeres.
3. ellipsis.
4. stereotypes.
12.A _ _ _ _ _ _ _ _ _ is a description of a set of objects that store the same

attributes, operations, relationships & semantics. [06S01]
1. class.
2. Entity.
3. Function.
4. Procedure.
13.An _ _ _ _ _ _ _ _ _ _ _ is a named property of a class that describes a range of

values that instance of the
property may held. [06S02]

1. item.
2. Attribute.
3. Operation.
4. Entity.
14.An _ _ _ _ _ _ _ _ _ _ _ _ is the implementation of a service that can be

requested from any object of the class to affect behavior. [06S03]
1. item.
2. attribute.
3. operation.
4. entity.
15.A _ _ _ _ _ _ _ _ is a contract or an obligation of a class. [06S04]

1. usability.
2. responsibility
3. package.
4. state.
16.A _ _ _ _ _ _ _ is just the face the class at the neor end of the association
presents to the other end of the association. [06S05]
1. name.
2. role.
3. multiplicity.
4. aggregation.
Objective Type Questions UNIT 4
1._ _ _ _ _ _ _ _ _ _ _ _ diagrams are especially important in modeling the

function of system. [07D01]
1. state chart.
2. Deployment.
3. Activity.
4. Sequence.
2.You use _ _ _ _ _ _ _ diagrams to illustrate data structures, the static

snapshots of instances of the things found in class diagrams.
[07D02]
1. Use case.
2. Object.
3. Collaboration.
4. Sequence.
3. Implementation view consists of _ _ _ _ _ _ _ _ diagrams. [07D03]

1. Class
2. Interaction

3. Component
4. Deployment
4. The UML specifies one standard stereotype that applies to notes is . [07M01]
1. Requirement.
2. meta class.
3. Exception.
4. power type.
5. From the following diagrams you can convert from one to the other without
loss of information. [07M02]
1. Sequence & collaboration.
2. Sequences & class .
3. Collaboration & use case.
4. Deployment and use case.
6._ _ _ _ _ _ _ _ _ diagrams emphasize the event-ordered behavior of an object,

which is especially usefull in modeling reactive system. [07M03]
1. State chart.
2. Sequence.
3. Component.
4. Deployment.
7. Notes may be attached to more than one element by using _ _ _ _ _ _ _ _ _ _.

[07S01]
1. Associations.
2. Dependences.
3. Generalizations.
4. Aggregations.
8._ _ _ _ _ _ _ _ _ _ _ are textual or graphical items that are added to an element's

basic notation and are used to visualize details from the element's specification.
[07S02]
1. Notes.
2. Stereo types.
3. Tagged values.
4. Adornments.
9.A tagged value is rendered as a _ _ _ _ _ _ _ _ _ enclosed by brackets and

placed below the name of another element. [07S03]
Ans: String
10.A _ _ _ _ _ _ _ _ _ _ is rendered as a string enclosed by brackets and placed

near the associated element. [07S04]
1. note.
2. Stereo type.

3. tagged value.
4. constraint.
11.which one of the following standard stereotype specifies that the classifier is
a Stereo types, that may be applied to other elements? [07S05]
1. Stereo type
2. Documentation
3. Exception
4. Metaclass
12.A _ _ _ _ _ _ _ _ _ _ _ _ is a semantically classed abstraction of a system,

meaning that it represents a complete and self-consistent simplification of
reality ,created in order to better understand the system. [07S06]
1. diagram.
2. View.
3. Model.
4. Sub system.
13.Which one of the following diagram is a structural diagram? [07S07]
1. Use case.
2. Activity.
3. component.
4. state chart.
14.Which one of the following diagram is a behavioral diagram? [07S08]

1. class.
2. objects.
3. component.
4. sequence.
15.Wich one of the following attribute declaration is legal of name, multiplication

& type? [08D01]
1. name : string.
2. + orgin.
3. head:*item.
4. name[0.1] : string.
16.A _ _ _ _ _ _ _ _ _ _ _ is a parameterized element. [08M02]

Ans: template
17.A _ _ _ _ _ _ _ _ _ is a mechanism that describes structural and behavioral

features. [08S01]
1. class.
2. Classifier.
3. Object.
4. Entity

18.The visibility of public is [08S02]

1. +
2. #
3. -
4. @
19.The visibility of protected is . [08S03]

1. +
2. #
3. -
4. @
20.Which one of the following stereotype specifies a classifier whose objects are
all classes? [08S04]
1. metaclass.
2. power type.
3. stereotype.
4. utility.
21._ _ _ _ _ _ _ _ _ _ _ _ is a physical and replacable part of a system that

conforms and provides the realization of a set of interfaces. [08S05]
1. signal.
2. Component.
3. Node
4. Subsystem.
22._ _ _ _ _ _ _ _ _ _ _ is specification of an asynchronous stimulus

communicated between instances. [08S06]
1. Signal.
2. Component.
3. Node
4. Subsystem
23._ _ _ _ _ _ _ _ _ _ _ is a description of a set of sequence of actions, including

variants,that a system performs that yields an observable result of value to a
particular actor. [08S07]
1. Signal.
2. Component
3. Node.
4. Usecase
24._ _ _ _ _ _ _ _ _ _ _ _ _ stereotype specifies a classifier whose objects are the

children of a given parent. [08S08]
1. Signal.
2. Component
3. Node.

4. Usecase
25._ _ _ _ _ _ _ _ _ stereotype specifies a class whose attributes and operations

are all class scoped. [08S09]
1. Signal.
2. Component
3. Node.
4. Usecase
26.Which one of the following stereotype is used to apply to dependency

relationships among packages? [09D01]
1. extend.
2. access.
3. include.
4. become.
27.Which one of the following constraint in generalization relationships,apply

only in the context of multiple inheritance. [09D02]
1. overlapping.
2. Complete.
3. Incomplete.
4. Implementation.
28._ _ _ _ _ _ _ _ _ _ stereotype specifies that the source is given special visibility

into the target. [09D03]
Ans: Friend
29._ _ _ _ _ _ _ _ _ _ _ _ stereotype specifies that the target is an historical

ancestor of the source. [09M01]
1. send.
2. copy.
3. trace.
4. extand.
30._ _ _ _ _ _ _ _ _ _ standard constrint specifies that objects of the parent may

have no more than one of the children as a type [09M02]
1. complete.
2. Incomplete.
3. Disjoint.
4. Overlapping.
31.Which one of the following constraint that relate to changeablity of the

instances of an association? [09M03]
1. implicit.
2. frozen.
3. ordered.

4. become.
32._ _ _ _ _ _ _ _ _ _ _ _ stereotype specifies that the source instantiates the

target template using the given actual parameters [09S01]
1. bind.
2. derive.
3. friennd.
4. powertype.
33.Which one of the following stereotype specifies that the source is at a finer
degree of abstraction than the target? [09S02]
1. bind
2. friend
3. derive,
4. refine.
34.A semantic variation of generation in which a child may have more than one
parent is called. [09S03]
1. single inheritance.
2. multiple inheritance.
3. inheritance.
4. double inheritance.
35.Which one of the following stereotype is used in generalization relationships?

[09S04]
1. send.
2. trace.
3. implementation
UNIT 5
1.A _ _ _ _ _ _ _ _ is a semantic relationship between classifiers in which one

classifiers a contract that another classifier guarantees to carry out. [09S05]
1. association.
2. Generalization.
3. Composition.
4. Realization.
2._ _ _ _ _ _ _ _ _ _ _ _ _ is really just a special kind of association is specified by

adorning a plain association with a field diamond at the whole end. [09S06]
1. Composition.
2. Interface specifier.
3. Association class.
4. Realization class.

3._ _ _ _ _ _ _ _ _ _ _ is an association attitude whose values partition the set of

objects related to an object across an association. [09S07]
1. Navigation
2. Visibility.
3. Qualification.
4. Composition.
4._ _ _ _ _ _ _ _ _ _ To constraint specifies that the relationship is not manifest

but,rather,is only conceptual. [09S08]
1. implicit.
2. frozen.
3. ordered.
4. become.
5._ _ _ _ _ _ _ _ _ stereotype specifies that the source operation invokes the target
operation.
Ans: call
6.A _ _ _ _ _ _ relationship is rendered as a dashed directed line with a large

open arrowhead pointing to the relationship [10D01]
1. generalization.
2. Realization.
3. Aggregation.
4. Dependency
7._ _ _ _ _ _ _ _ stereotype specifies a package that serves as a proxy for the

public contents of another package [10D02]
1. facade
2. frame work
3. stub
4. system
8.Which one of the following stereotype specifies that the source package has
access to the contents of the target? [10M01]
1. import
2. export
3. frame work
4. stub
9._ _ _ _ _ _ _ _ may also be used to specify a contact for a use case or

subsystem. [10M02]
1. classes
2. objects
3. interfaces
4. names

10.An _ _ _ _ _ _ is a collection of operations that are used to specify a service of

a class or a component. [10S01]
1. item
2. interface
3. integrity
4. iterative
11._ _ _ _ _ _ _ _ _ _ stereo type specifies a package that is only a view on some

other package
[10S02]
1. facade
2. frame work
3. stub
4. system
12.A _ _ _ _ _ _ is the behavior of an entry participating in a particular context.

[10S03]
1. type
2. component
3. Name
4. Role
13.Stereotype specifies a package consisting mainly of patterns [10S04]

1. facade
2. frame work
3. stub
4. system
14.A _ _ _ _ _ _ is a general purpose mechanism for organization elements into

groups. [10S05]
1. type.
2. Role.
3. Package.
4. Class.
15.A _ _ _ _ _ _ is rendered as a tabbed folder. [10S06]

1. class
2. component
3. node
4. package
16.A _ _ _ _ _ _ _ _ _ _ _ is a parameterized element. [11D01]

1. class.
2. object.
3. template.

4. active class.
17.which diagrams are similar to class diagrams ? [11M01]

Ans: component and Deployment
18.Which one of the following attribute declaration is legal of name,

multiplication & type? [11M02]
1. name : string.
2. + orgin.
3. head:*item.
4. name[0.1] : string.
19._ _ _ _ _ _ is the process of transforming a model into code through a

mapping to an implementation language. [11S01]
1. forward engineering
2. reverse engineering
3. revise engineering
4. refine engineering
20._ _ _ _ _ is the process of transforming code into a model through a mapping

from a specific implementation language. [11S02]
1. forward engineering
2. reverse engineering
3. revise engineering
4. refine engineering
21.Class diagrams are not useful [11S03]

1. to model the vocabulary of a system
2. to model simple collaborations
3. to model a logical database schema
4. to model simple interactions
22.common use of class diagrams is [11S04]

1. to model simple interactions
2. to model object diagram
3. to model the vocabulary of a system
4. to model the life cycle of a system.
23.You can explicitly specify that there are more attributes or properties than
shown by ending each list with an _ _ _ _ _ _ _ _. [11S05]
1. circles.
2. squares.
3. ellipsis.
4. stereotypes.

24.Aggregation is a _ _ _ _ _ _ _ _ _ kind of relationship . [11S06]

1. is-a.
2. to-a.
3. was-a.
4. has-a.
25.A _ _ _ _ _ _ _ is a mechanism that describes structural and behavioral

features. [11S07]
1. class.
2. classifier.
3. object.
4. entity.
26.The static part of an interaction diagram is [12D01]

1. class diagram
2. deployment diagram
3. component diagram
4. object diagram
27.Anonymous object is declared as [12D02]

1. p:person
2. p:
3. :person
4. p:q:person
28.A link in object diagrams is rendered as [12M01]

1. dashed line
2. solid line
3. direction triangle
4. filled diamond
29.Object diagrams are used to model [12M02]
1. class structures
2. solid structures
3. object structures
4. activity structures
30.An _ _ _ _ _ _ _ diagram is essentially an instance of a class diagram [12S01]

1. interaction
2. object
31.An _ _ _ _ _ _ diagram represents one static frame in the dynamic story
board represented by an interaction diagram [12S02]
1. interaction
2. object
3. use case
4. activity

32.An object diagram is essentially the static port of an _ _ _ _ _ _ _ diagram

[12S03]
1. interaction
2. object
3. use case
4. activity
33._ _ _ _ _ _ _ _ is a concrete manifestation of an abstraction [12S04]

1. object
2. class
3. state
4. component
34._ _ _ _ _ _ _ diagrams let you model static data structures [12S05]

1. object
2. class
3. state
4. component
35._ _ _ _ _ _ _ is an instance of a class [12S06]

1. interaction
2. use case
3. activity
4. object
36._ _ _ _ _ _ _ _ _ _ _ can be drawn in a separate comportment at the bottom of

the class icon. [13D01]
1. usability.
2. responsibility.
3. package.
4. state.
37.Which one of the following diagram is used to model a logical database

schema ? [13G01]
1. a code into a model
2. a model into test
3. a code into design
4. a model into a code
38.To model a schema [13M01]
1. create a class diagram that contains these classes & mark them as
persistent
2. create a class diagram that contains these classes & mark them as database
3. create a class diagram that contains these classes & mark them as java
4. create a class diagram that contains these classes & mark them as schema
39.A _ _ _ _ _ _ _ _ _ is a contract or an obligation of a class. [13M02]

1. usability.
2. responsibility.
3. package.
4. state.
40.Which one of the following diagrams is used to model simple collaborations ?

[13S01]
1. object
2. class
3. use case
4. activity
20. tutorial QUESTIONS

Unit 1:
1. Explain the important of modeling & principles of modeling
2. Explain the s/w development life cycle.
3. Describe the structural things of UML modeling.
4. Draw and explain the Architecture of UML.
5. Describe the various types of UML diagrams.
6. What is Class? Enumerate the steps involved in modeling techniques.
7. Write the various Relations with examples.
8. What is Package? Write the steps involved in common modeling
techniques.
9. What are the Common mechanisms in the UML model?
10. Explain the Advanced relationships in UML model.
Unit 2:
1. What is Class diagram? Draw the class diagram for Library management
system.
2. What are the common modeling techniques of class diagram?
3. What is Object diagram? Draw the object diagram for ATM Applications.
4. What are the common modeling techniques for Object diagram?
5. What is interaction diagram? Write the terms and concepts of
interactions.
6. Differences between collaborations and sequence diagrams.
7. Draw the sequence and collaboration diagrams for Hospital Management
System.
8. What are the equivalences between collaborations and sequence
diagrams?
UNIT-3


6. Write common modeling techniques of Activity diagrams.
7. Draw the Activity diagram for ATM Applications.
8. Draw the use case diagram for Hospital Management System.
UNIT-4

3. Explain process and threads in UML.
5. Write common modeling techniques of state chart diagrams.
6. Write common modeling techniques of process and threads diagrams.
7. Draw the state chart diagram for ATM Applications.
8. Draw the state chart diagram for Quiz Applications.
UNIT-5

6. Difference between deployment and component.
7. Write common modeling techniques of component diagrams.
8. Write common modeling techniques of Deployment diagrams.
9. Draw the component diagram for ATM Applications.
10. 10.Draw the deployment diagram for Hospital Management
System.
Case study:
4. Case study of the online course registration.
5. Case study of the Hospital management system.


cs8592 Ooad PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

cs8592 Ooad PDF

Uploaded by

Copyright:

Available Formats

WHO WE ARE

“Facultytalkies-An Innovative Engineering Professors Hub”

Faculty Talkies began as an imitative experiment in online teaching, when

 Increase access to high-quality of innovative engineering knowledge for every

 Teach courses in a wide variety of subjects, such as all engineering courses

S.No Topic Page. No.

WHAT YOU WILL LEARN

UNIT II STATIC UML DIAGRAMS

UNIT III DYNAMIC AND IMPLEMENTATION UML

UNIT IV DESIGN PATTERNS

INTENDED AUDIENCE : UG, PG Course, BCA, MCA, B.Tech., M.Tech.

 Express software design with UML diagrams

6. Course Objectives & Outcomes

COA60524.3) Be able to analyze and design the classes, relationships and

COA60524.4) Be able to analyze and compare advanced classes and

COA60524.8) Be able to draw Component Diagram and the Deployment

Learning Outcomes/Instructional Outcomes

S.No Unit Contents Outcomes

I Introduction to UML:  Students Can able to explain the

 Students Can able to identify

 Students Can able to Analyze

 Students Can able to compare

 Students Can able to analyze

 Students Can able to

 Students Can able to model the

 Students Can able to model an

 Students Can able to model a

 Students can analyze how to

 Students can prepare how to

 Students can identify what the

 Students can analyze how to

 Students can design an Activity

 Students can evaluate how to

 Students can plan how to model

 Students Can able to explain the

 Students Can able to design and

 Students Can able to analyze and

 Students Can able to explain how

 Students Can able to discuss how

5 V Case Study: The Unified  Students Can able to analyze and

 Students Can able to analyze and

 Students Can able to prepare

 Students Can able to create how

UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Definition of OOP Concepts in Java

List of OOP Concepts in Java

 Abstraction. Abstraction means using simple things to represent complexity.

 Restructuring the class data (if necessary),

 Bottom–up approach in program design

Do You Want Video Lecture for this Topic

Topic 2:Unified Process in Object Oriented Analysis and Design

 during this phase the project team is expected to capture a majority of

The disciplines described by Unified Process are as follows

 Business modeling—domain object modeling and dynamic modeling of

Topic 3 UML diagrams in OOAD

What is the use of UML?

Types of UML Diagrams

Structural UML Diagram

 Functional requirements – represented as use cases; a verb describing an

 Interaction Overview Diagram

 Lifeline – individual participant

Sequence UML Diagram