Please read this disclaimer before proceeding:

This document is confidential and intended solely for the educational purpose of
RMK Group of Educational Institutions. If you have received this document
through email in error, please notify the system manager. This document
contains proprietary information and is intended only to the respective group /
learning community as intended. If you are not the addressee you should not
disseminate, distribute or copy through e-mail. Please notify the sender
immediately by e-mail if you have received this document by mistake and delete
this document from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in reliance on
the contents of this information is strictly prohibited.
21CS931-OBJECT ORIENTED ANALYSIS AND
DESIGN
Department: Computer Science & Engineering
Batch/Year:2021-2025/III Year
Created by: Dr.M.Vedaraj & Mr.Shanker
January 2024
1. CONTENTS

S. No. Contents

1 Contents

2 Course Objectives

3 Pre Requisites

4 Syllabus

5 Course outcomes

6 CO- PO/PSO Mapping

7 Lecture Plan

8 Activity based learning

9 Lecture Notes

10 Assignments

11 Part A Questions & Answers

12 Part B Questions

13 Supportive online Certification courses

14 Real time Applications

15 Contents beyond the Syllabus

16 Assessment Schedule

17 Prescribed Text Books & Reference Books

18 Mini Project Suggestions

2. Course Objectives
1. To learn the basics of OOAD and various UML diagrams.
2. To understand how to create design patterns.
3. To understand the various stages of the design process using a case study.
4. To learn how to apply design patterns using various UML diagrams.
5. To know how to map design to code and learn different testing techniques.
3. Pre Requisites
Course Name: Object Oriented Analysis and Design

Course Code: 21CS931

Pre Requisites

1. Understand object-oriented Programming concepts and methodology

2. Experience of Programming Projects would help; but is not mandatory
3. General understanding of programming, preferably using the Java programming
language
4. Understand the fundamentals of the systems development process
4. Syllabus
21CS931 OBJECT ORIENTED ANALYSIS AND DESIGN LTPC

3003
OBJECTIVES:
 To learn the basics of OOAD and various UML diagrams.
 To understand how to create design patterns.
 To understand the various stages of the design process using a case study.
 To learn how to apply design patterns using various UML diagrams.
 To know how to map design to code and learn different testing techniques.

UNIT I UML DIAGRAMS 6+6

Introduction to OOAD with OO Basics - Unified Process – UML diagrams – Use Case
– Class Diagrams– Interaction Diagrams – State Diagrams – Activity Diagrams
– Package, component, and Deployment Diagrams.

UNIT II DESIGN PATTERNS 6+6

GRASP: Designing objects with responsibilities – Creator – Information expert – Low

Coupling –High Cohesion – Controller Design Patterns – creational – factory
method– structural – Bridge – Adapter – behavioural – Strategy – observer.

UNIT III CASE STUDY 6+6

Case study – the Next Gen POS system, Inception -Use case Modelling - Relating
Use cases – include, extend and generalization - Elaboration - Domain Models -
Finding conceptual classes and description classes – Associations – Attributes –
Domain model refinement – Finding conceptual class Hierarchies - Aggregation and
Composition.
UNIT IV APPLYING DESIGN PATTERNS 6+6
System sequence diagrams - Relationship between sequence diagrams and use
cases Logical architecture and UML package diagram – Logical architecture
refinement - UML class diagrams - UML interaction diagrams - Applying GoF design
patterns.

UNIT V CODING AND TESTING, METRICS 6+6

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

Integration Testing – GUI Testing – OO System Testing-Metrics for Object Oriented
Design- ClassOriented Metrics
TOTAL: 60 PERIODS
TEXT BOOKS:

1. Craig Larman, ―Applying UML and Patterns: An Introduction to Object-Oriented

Analysis and Design and Iterative Development‖, Third Edition, Pearson Education,
2005.

REFERENCES:

1.Roger.S.Pressman and Bruce R. Maxim, “Software Engineering: A Practitioner's

Approach” , Eighth Edition, Mc-Graw Hill Education, 2015.

2.Simon Bennett, Steve Mc Robb and Ray Farmer, “Object Oriented Systems
Analysis and Design Using UML”, Fourth Edition, Mc-Graw Hill Education, 2010.

3.Erich Gamma, and Richard Helm, Ralph Johnson, John Vlissides, “Design
patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley,
1995.

4.Martin Fowler, “UML Distilled: A Brief Guide to the Standard Object Modeling
Language”, Third edition, Addison Wesley, 2003.

5.Paul C. Jorgensen, “Software Testing:- A Craftsman‟s Approach”, Third Edition,

Auerbach Publications, Taylor and Francis Group, 2008.
5. Course outcomes
At the end of this course, the students will be able to:
CO1: To learn the basics of OOAD and various UML diagrams.
CO2: To understand how to create design patterns.
CO3:To understand the various stages of the design process using a case study.
CO4:To learn how to apply design patterns using various UML diagrams.
CO5:To know how to map design to code and learn different testing techniques.
 6. CO - PO / PSO MAPPING

PROGRAM OUTCOMES PSO

K3,
CO HKL K3 K4 K5 K5
K A3 A2 A3 A3 A3 A3 A2

PSO3
PSO2
PSO1
4,K
5
PO- PO- PO- PO- PO- PO- PO- PO- PO- PO- PO- PO-
1 2 3 4 5 6 7 8 9 10 11 12

CO1 K3 2 1 1 - - - - - - - - - 2 2 2

CO2
K3 3 3 3 - - - - - - - - - 2 2 2

CO3
K3 3 3 3 - - - - - - - - - 2 2 2

CO4
K3 3 3 3 - - - - - - - - - 2 2 2

CO5
K3 3 3 3 - - - - - - - - - 2 2 2

Correlation Level:
1. Slight (Low)
2. Moderate (Medium)
3. Substantial (High)
If there is no correlation, put “-
“.
 7. LECTURE PLAN

Number Proposed Actual Taxono Mode of

Sl. of Lecture
Topic Date CO my Delivery
No. Periods Date
Level
Introduction to
OOAD with OO Chalk &
1 Basics - Unified 1 CO1 K1 talk
Process

UML diagrams – Chalk &

2 Use Case 1 CO1 K2 talk
Class Diagrams Chalk &
3 1 CO1 K2 talk
Interaction
Diagrams PPT/
4 1 CO1 K2
Demo

State Diagrams – PPT/

5 Activity 1 CO1 K2
Demo
Diagrams
Package,
component, PPT/
6 1 CO1 K3
and Demo
Deployment
Diagrams
8. Activity based learning
Construct a class Diagram using ArgoUML for Exam management system.
8. Activity based learning
Develop a UseCase Diagram using ArgoUML for Learning Mangement
Systems
9. Links to Videos, e-book reference, PPTs
Links to Videos
https://fccdl.in/9DFiMFQULX

E-book reference
1. Clean Code: A Handbook of Agile Software Craftsmanship
2. The Clean Coder: A Code of Conduct for Professional Programmers
3. Agile Software Development, Principles, Patterns, and Practices
4. UML for Java Programmers
5. Design Patterns: Elements of Reusable Object-Oriented Software
6. Object-Oriented Analysis and Design with Applications (3rd Edition)
7. Test Driven Development: By Example (Kent Beck)
8. Refactoring: Improving the Design of Existing Code: Martin Fowler also have a
Ruby version
9. Applying UML and Patterns: Craig Larman
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Introduction

Object Oriented analysis and design skills are essential for the creation of
well-designed, robust, and maintainable software using OO technologies and
languages such as Java or C#.

Requirements analysis and OOA/D needs to be presented and practiced in

the context of some development process. In this case, an agile (light ,flexible)
approach to the well-known Unified Process (UP) is used as the sample
iterative development process are taken . It includes

Apply principles and patterns to create better object designs.

Iteratively follow a set of common activities in analysis and design, based

on an agile approach to the UP as an example.

Create frequently used diagrams in the UML notation.

What is Analysis and Design?

Analysis (do the right thing )emphasizes an investigation of the

problem and requirements, rather than a solution. For example, if a new online
trading system is desired, how will it be used? What are its functions?

Design (do the thing right ) 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. Design ideas often exclude low-level or "obvious" detail.

What is Object-Oriented Analysis and Design?

Object-Oriented Analysis : It 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.
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Object-Oriented Design : It emphasis on defining software objects

and how they collaborate to fulfill the requirements. For example, a Plane
software object may have a tail Number attribute and a get Flight History method.

During implementation or object-oriented programming, design objects are

implemented, such as a Plane class in Java.

Figure1.Object-orientation emphasizes representation of

objects.
 Define Use Cases : Requirements analysis may include stories or scenarios
of how people use the application; these can be written as use cases. They are a
popular tool in requirements analysis. For example, the Play a Dice Game use case:

Play a Dice Game: Player requests to roll the dice. System presents results:
If the dice face value totals seven, player wins; otherwise, player loses.

Define a Domain Model

There is an identification of the concepts, attributes, and associations that

are considered important. The result can be expressed in a domain model that
shows the important. domain concepts or objects.

Figure 2. Partial domain model of the dice game.

iii) Assign Object Responsibilities and Draw Interaction Diagrams

Object-oriented design is concerned with defining software objects their

responsibilities and collaborations. It shows the flow of messages between
software objects, and thus the invocation of methods.
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

For example, the sequence diagram in Figure 3 illustrates an OO software

design, by sending messages to instances of the DiceGame and Die classes.

Notice that although in the real world a player rolls the dice, in the
software design the DiceGame object "rolls" the dice (that is, sends messages to
Die objects). Software object designs and programs do take some inspiration from
real-world domains, but they are not direct models or simulations of the real
world.

Figure 3 Sequence diagram illustrating messages between software

objects.

iv) Define Design Class Diagrams: a static view of the class definitions
is usefully shown with a design class diagram. This illustrates the attributes and
methods of the classes.

For example, in the dice game, an inspection of the sequence diagram

leads to the partial design class diagram shown in Figure 4. Since a play message
is sent to a DiceGame object, the DiceGame class requires a play method, while
class Die requires a roll and get FaceValue method.
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Figure 4. Partial design class diagram.

What is the UML?

The Unified Modeling Language is a visual language for specifying,

constructing and documenting the artifacts of systems. The word visual in the
definition is a key point the UML is the de facto standard diagramming notation
for drawing or presenting pictures. The standard is managed, and was created, by
the Object Management Group. It was first added to the list of OMG adopted
technologies in 1997.

UML is composed of 9 graphical diagrams:

1.Class Diagram-describes the structure of a system by showing the system’s

classes ,their attributes, and the relationships among the classes.

2.Use Case Diagram-describes the functionality provided by a system in terms

of actors, their goals represented as use cases, and any dependencies among
those use cases.

3. Behaviour Diagram

a. Interaction Diagram

i. Sequence Diagram-shows how objects communicate with each other in

terms of a sequence of messages .Also indicates the lifespan of objects relative to
those messages.
 UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

ii. Communication diagram: how the interactions between objects or

parts in terms of sequenced messages

b. State Chart Diagram –describes the states and state transitions of the
system.

c. Activity Diagram-describes the business and operational step-by step –

workflows of components in a system.an activity diagram shows he overall flow of
control.

4. Implementation Diagram

a. Component Diagram-describes how a software system is split up into

components and shows the dependencies among these components.

b. Deployment Diagram-describes the hardware used in system

implementations and the execution environments and artifacts deployed on the
hardware.

Three Ways to Apply UML

UML as sketch : Informal and incomplete diagrams created to explore

difficult parts of the problem or solution space, exploiting the power of visual
languages.

UML as blueprint : Relatively detailed design diagrams used either for

1) Reverse Engineering : UML tool reads the source or binaries and

generates UML package, class, and sequence diagrams to visualize and
better understanding of existing code in UML diagrams .

2) Forward Engineering : code generation . Before programming, some

detailed diagrams can provide guidance for code generation (e.g., in
Java), either manually or automatically with a tool. It's common that the
diagrams are used for some code, and other code is filled in by a
developer while coding

UML as programming language : Complete executable specification of a

software system in UML. Executable code will be automatically generated
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Three Perspectives to Apply UML

The same UML class diagram notation can be used to draw pictures of
concepts in the real world or software classes in Java.

1.Conceptual perspective - the diagrams are interpreted as describing

things in a situation of the real world or domain of interest.

2.Specification (software) perspective - the diagrams (using the same

notation as in the conceptual perspective) describe software abstractions or
components with specifications and interfaces, but no commitment to a
particular implementation (for example, not specifically a class in C# or Java).

3.Implementation (software) perspective - the diagrams describe

software implementations in a particular technology (such as Java).

Figure 5:Conceptual Perspective and Software Perspective.

UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

The Meaning of "Class" in Different Perspectives

Conceptual class real-world concept or thing. A conceptual or essential

perspective. The UP Domain Model contains conceptual classes.

Software class a class representing a specification or implementation

perspective of a software component, regardless of the process or method.

Implementation class a class implemented in a specific OO language such as

Java.

What is the UP?

A software development process describes an approach to building, deploying,

and possibly maintaining software. The Unified Process has emerged as a popular
iterative software development process for building object-oriented systems. In
particular, the Rational Unified Process or RUP a detailed refinement of the Unified
Process, has been widely adopted.

The UP combines commonly accepted best practices, such as an iterative

lifecycle and risk-driven development, into a cohesive and well-
documented process description.

UP for three reasons:

1. The UP is an iterative process.

2.UP practices provide an example structure for how to do and thus how to
explain OOA/D.

3.The UP is flexible, and can be applied in a lightweight and agile approach that
includes practices from other agile methods
 UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Iterative and Evolutionary Development : A key practice in both the UP

and most other modern methods is iterative development.

In this lifecycle approach, development is organized into a series of short,

fixed-length (for example, three-week) mini-projects called iterations; the
outcome of each is a tested, integrated, and executable partial system. Each
iteration includes its own requirements analysis, design, implementation, and
testing activities.

The system grows incrementally over time, iteration by iteration, and thus
this approach is also known as iterative and incremental development (see
Figure 6). Because feedback and adaptation evolve the specifications and
design, it is also known as iterative and evolutionary development.

Figure 6.Iterative and evolutionary development

 UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Notice in this example that there is neither a rush to code, nor a long drawn-out
design step that attempts to perfect all details of the design before programming. The
system may not be eligible for production deployment until after many iterations; for
example, 10 or 15 iterations.

To Handle Change on an Iterative Project

• Each iteration involves choosing a small subset of the requirements, and quickly
designing, implementing, and testing

• In addition to requirements clarification, activities such as load testing will prove if

the partial design and implementation are on the right path, or if in the next
iteration, a change in the core architecture is required.

• Work proceeds through a series of structured build-feedback-adapt cycles. in early

iterations the deviation from the "true path" of the system (in terms of its final
requirements and design) will be larger than in later iterations. Over time, the
system converges towards this path, as illustrated in Figure 7.

Figure 7. Iterative feedback and evolution leads towards the desired

system. The requirements and design instability lowers over time.
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Benefits of Iterative Development

• less project failure, better productivity, and lower defect rates; shown by
research into iterative and evolutionary methods

• 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 an iteration can be methodically used to improve the

development process itself, iteration by iteration

What is Iteration Time boxing?

• Most iterative methods recommend an iteration length between two and six
weeks.

• Small steps, rapid feedback, and adaptation are central ideas in iterative
development; long iterations subvert the core motivation for iterative
development and increase project risk.

• A very long time-boxed iteration misses the point of iterative development.

Short is good.

Iterations are time-boxed, or fixed in length. For example, if the next

iteration is chosen to be three weeks long, then the partial system must be
integrated, tested, and stabilized by the scheduled date-date slippage is illegal. If
it seems that it will be difficult to meet the deadline, the recommended response
is to de-scope-remove tasks or requirements from the iteration, and include them
in a future iteration, rather than slip the completion date.
 UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

The Waterfall Lifecycle

In a waterfall lifecycle process there is an attempt to define all or most of the
requirements before programming. It is strongly associated with
 high rates of failure
 lower productivity
 higher defect rates
Figure 8 Percentage of change on software projects of varying sizes.

The Need for Feedback and Adaptation

In complex, changing systems feedback and adaptation are key ingredients for
success.

• Feedback from early development, programmers trying to read

specifications, and client demos to refine the requirements.
• Feedback from tests and developers to refine the design or models.

• Feedback from the progress of the team tackling early features to refine the
schedule and estimates.

• Feedback from the client and marketplace to re-prioritize the features to

tackle in the next iteration.
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

What is Risk-Driven and Client-Driven Iterative Planning?

The UP encourages a combination of risk-driven and client-driven iterative

planning. This means that the goals of the early iterations are chosen to 1)
identify and drive down the highest risks, and 2) build visible features that the
client cares most about.

Risk-driven iterative development includes more specifically the practice of

architecture-centric iterative development, i.e early iterations focus on building,
testing, and stabilizing the core architecture

What are Agile Methods and Attitudes?

Agile development methods usually apply time boxed iterative and

evolutionary development, employ adaptive planning, promote incremental
delivery, and include other values and practices that encourage agility rapid and
flexible response to change.

The Agile Manifesto and Principles

The Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

The Agile Principles

1. Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile

processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter time scale.

4. Business people and developers must work together daily throughout

the project

5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and

within a development team is face-to-face conversation

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development.

9.The sponsors, developers, and users should be able to maintain a

constant pace indefinitely

10. Continuous attention to technical excellence and good design enhances

agility

11. Simplicity the art of maximizing the amount of work not done is essential
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

12. The best architectures, requirements, and designs emerge from self-
organizing teams.

13. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.

This example assumes there will ultimately be 20 iterations on the project before
delivery

Figure 9 Evolutionary analysis and design the majority in early iterations.

UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

UP Phases

A UP project organizes the work and iterations across four major phases:

Inception - approximate vision, business case, scope, vague estimates.

Elaboration - refined vision, iterative implementation of the core architecture,

resolution of high risks, identification of most requirements and scope, more
realistic estimates.

Construction - iterative implementation of the remaining lower risk and easier

elements, and preparation for deployment.

Transition - beta tests, deployment.

This is not the old "waterfall" or sequential lifecycle of first defining all the
requirements, and then doing all or most of the design. Inception is not a
requirements phase; rather, it is a feasibility phase, where investigation is
done to support a decision to continue or stop.

Similarly, elaboration is a phase where the core architecture is iteratively

implemented, and high-risk issues are mitigated.

Figure 10 : Schedule-oriented terms in the UP.

UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

The UP Disciplines
Disciplines a set of activities(and related artifacts)in one subject area,such
as the activities within requirements analysis.In the UP, an artifact is the general
term for any work product:code,web graphics,database schema,text
documents,diagrams,models,and so on. There are several disciplines in the UP:

Figure 11: The UP Disciplines

 UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Definition: the Development Case: The choice of practices and UP

artifacts for a project may be written up in a short document called the Development
Case (an artifact in the Environment discipline).

Table 1. Sample Development Case. s - start; r - refine

Discipline Practice Artifact Incep. Elab. Const. Trans.

I1 E1..En C1..Cn T1..T2
Iteration
Business agile Domain Model
s
Modeli modeling
ng req.
workshop
Requirements req. Use-
s r
workshop Case
vision box Model
exercise dot
Vision s r
voting
Supplementary
s r
Specification

Glossary s r
Design agile Design Model s r
modeling
SW
test-driven dev.
Architect s
ure
Document

Data Model s r
Implement test-driven dev. …
ati on pair programming
continuous
integration
coding
standards

Project agile PM …
Managem daily Scrum
ent meeting
…
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

Business Modeling - The Domain Model artifact, to visualize

noteworthy concepts in the application domain.

Requirements - The Use-Case Model and Supplementary Specification

artifacts to capture functional and non-functional requirements

• Design - The Design Model artifact, to design the software objects

Figure 12:What is the Relationship Between the Disciplines and Phases?

 UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

UML Diagrams

The UML defines nine graphical diagrams

1. Class diagram (static)

2. Use-case diagram

3. Behavior diagrams (dynamic):

– 3.1. Interaction diagram:

• 3.1.1. Sequence diagram

• 3.1.2. Collaboration diagram

– 3.2. State chart diagram

– 3.3. Activity diagram

4. Implementation diagram:

Component diagram

Deployment diagram
Diagrams Are Views of a Model

Use Case Diagram

Use case diagrams are created to visualize the relationships between actors and
use cases
• An actor is someone or some thing that must interact with the system
under development
• A use case is a pattern of behavior the system exhibits
• Use cases are written from an actor point of view Details what the
system must provide to the actor when the use cases is executed

Class Diagrams

A class diagram describes the types of objects in the system and the various kinds of
static relationships that exist among them.
A graphical representation of a static view on declarative static elements.
 A central modeling technique that runs through nearly all object-oriented
methods.
The richest notation in UML.
A class diagram shows the existence of classes and their relationships in the
logical view of a system
Essential Elements of a UML Class Diagram

– Class
– Attributes
– Operations
– Relationships
 Associations
 Generalization
– Dependency
– Realization

Constraint Rules and Notes

A class is the description of a set of objects having similar attributes,

operations, relationships and behavior.

Attributes

 Classes have attributes that describe the characteristics of their objects.

 Attributes are atomic entities with no responsibilities.
 Attribute syntax (partial):
 o [visibility] name [ : type ] [ = defaultValue ]
 Class scope attributes are underlined
 Example (Java implementation):

Visibility

• Visibility describes whether an attribute or operation is visible and can be referenced

from classes other than the one in which they are defined.
• language dependent
o Means different things in different languages
UML provides four visibility abbreviations:
+ (public) – (private) # (protected) ~ (package)

UML modeling elements in class diagrams

Classes and their structure, association, aggregation, dependency, and inheritance

relationships
Multiplicity and navigation indicators, etc.
Associations

• A semantic relationship between two or more classes that specifies

connections among their instances.
• A structural relationship, specifying that objects of one class are connected
to objects of a second (possibly the same) class.
• Example: ―An Employee works for a Company‖
• An association between two classes indicates that objects at one end of an
association ―recognize‖ objects at the other end and may send messages
to them.
• This property will help us discover less trivial associations using
interaction diagrams
Aggregation

A special form of association that models a whole-part relationship between an aggregate

(the whole) and its parts.

Generalization

A sub-class inherits from its super-class. A generalization relationship may not be used
to model interface implementation.

Dependency

A dependency is a relation between two classes in which a change in one may force
changes in the other although there is no explicit association between them.
A stereotype may be used to denote the type of the dependency.

Realization

A realization relationship indicates that one class implements a behavior specified by

another class (an interface or protocol). An interface can be realized by many
classes. A class may realize many interfaces.
Interactive Diagrams

Interaction diagrams describe how groups of objects collaborate to get the job
done. Interaction diagrams capture the behavior of a single use case, showing
the pattern of interaction among objectsThe purpose of Interaction diagrams is
to:
Model interactions between objects
Assist in understanding how a system (a use case) actually works
Verify that a use case description can be supported by the existing
classes Identify responsibilities/operations and assign them to
classes
Interaction diagrams:
Sequence diagrams
Collaboration
diagrams

Packages

A package is a general purpose grouping mechanism. Can be used to group any

UML element (e.g. use case, actors, classes, components and other packages.
Commonly used for specifying the logical distribution of classes. A package does
not necessarily translate into a physical sub-system.

Packages and Class Diagrams

• Emphasize the logical structure of the system (High level view)

 Emphasize the interface between packages by showing relations and
dependencies between public classes,Add package information to class
diagrams

Collaboration Diagrams

UML provides two sorts of interaction diagram,

• sequence and
• collaboration diagrams.

Collectively, the objects which interact to perform some task, together with the links
between them, are known as a collaboration

• Objects
o Each object is shown as rectangle, which is labelled objectName: className
• Links
o Links between objects are shown like associations in the class model.
• Actors
o Actors can be shown as on a use case diagram
 A collaboration diagram represents a set of objects related in a particular context, and
the exchange of their messages to achieve a desired outcome.

 Used for design of: components, object, subsystems

 Diagrams show entity event responses
 Event receiving a message

State Diagram

A statechart diagram (also called a state diagram) shows the sequence

of states that an object goes through during its life in response to outside stimuli and
messages. A statechart diagram is a view of a state machine that models the
changing behavior of a state. Statechart diagrams show the various states that an
object goes through, as well as the events that cause a transition from one state to
another.

State chart diagram model elements

The common model elements that state chart diagrams contain are:

 States
 Start and end states
 Transitions
 Entry, do, and exit actions

A state represents a condition during the life of an object during which it satisfies
some condition or waits for some event. Start and end states represent the
beginning or ending of a process. A state transition is a relationship between two
states that indicates when an object can move the focus of control on to another
state once certain conditions are met.

Actions in a Statechart diagram

 Each state on a state chart diagram can contain multiple internal actions.
 An action is best described as a task that takes place within a state.
 There are four possible actions within a state:
 On entry
 On exit
 Do
 On event

Idle
lift receiver and get dial
tone

State

Dialing
Dialing

Start Dial number.siValid(

entry aSntdarsttart Dial number.siValid(
entry and
diaelongtreyxaitn/dstsotpart entry and
dialog exit/ stop

digit(n
digit(n

Substates
 Activity Diagram

• Activity Diagram – a special kind of Statechart diagram, but showing the flow from
activity to activity (not from state to state).

• Activity – an ongoing non-atomic execution within a state machine. Activities

ultimately result in some action.

– A real world process or execution of a software routine

• Action – made up of executable atomic computations that results in a change in

state of the system or the return of a value (i.e., calling another operation, sending
a signal, creating or destroying an object, or some pure computation).

Activity diagrams commonly contain:

• Activity states and action states

• Transitions
• Objects

Action states - executable, atomic computations (states of the system, each representing
the execution of an action) – cannot be decomposed. Activity states – non-atomic; can be
further decomposed; can be represented by other activity diagrams – a composite whose
flow of control is made up of other activity states and action states
 Deployment Diagram

Shows the configuration of run-time processing elements and the software

processes living on them. The deployment diagram visualizes the distribution of
components across the enterprise
10. Assignments ( For higher level learning and Evaluation - Examples: Case
study, Comprehensive design, etc.,)

Assignments Questions

Category I:
Consider the following scenario: 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 in the system. The books transactions are stored in the database. The Penalty list
while the member returns the book after the due date must be generated. Analyze the users
and actors of this system, and the interactions between them must be depicted. Draw a Use
case diagram. (CO1, K4)

Category II:
Online examination system has become popular for competitive examinations because of its
unique features such as auto-evaluation, speed and accuracy. Moreover, it also helps
environments by reducing the use of paper. In such a system, students are asked to select
answers from multiple options given for a single question. Likewise, there are several
questions which appear in the students’ systems. The questions and multiple options are
saved in a database along with desired answers. Typically, a student can edit an answer after
saving it, however, editing cannot be done after submitting the answer. Another user is also
there – Teacher. The Teacher can create, modify and delete questions and accordingly, the
question is updated in the system. Draw the UML Use Case and class diagram for above
scenario. (CO1,K4)

Category III:
Blood Bank Management System is an online portal where donor can register himself with his
blood group information and other details like his age, address and gender. The users who
are in need of blood can search for donors based on blood group, age and location. The
administrator should be able to generate reports based on dates and donors. Draw the UML
Use Case, and , Class diagram for above scenario. (CO1,k4)

Category IV:
Write a problem statement for Passport automation system. Draw the UML Class
diagram.(CO1,K4)

Category V:
Write a problem statement for banking system. Draw the UML use case diagram and class
diagram.(CO1,K4)
11. Part A Q & A (with K level and CO)
S.No Questions
K Level CO Level

1 What is Object Oriented Analysis & Design? K3 C01

It is a method of analysis and design during software
development process.
OOAD considers a problem domain and logical solution
from the prescriptive of object.
2 Distinguish between OOA and OOD. K2 C01
OOA: Object Oriented Analysis is
the process of identifying and
describing the object for given problem
instance.
OOD: Object oriented design is the process of defining
the objects and their collaboration with other objects in
order to fulfill the requirements.
3 Define an object. Identify the probable attributes that K2 C01
will be modelled in a Library database for the object
BOOK.
An object is a real-world element in an object oriented
environment that may have a physical or a conceptual
existence. It is a software bundle of variables and
related methods.

Attributes for the object BOOK: Book ID, Book Title,

Author, Publisher, Edition and Year of Publication.
4 What is Activity Diagram? K2 C01
Activity diagram is basically a flowchart to represent the
flow from one activity to another activity.
Activity diagram is used to describe the dynamic aspects
of the system.
5 What are the three ways and perspectives to apply UML K2 C01
Three ways to apply UML
UML as sketch UML as blueprint
UML as programming language Three perspectives to
apply UML Conceptual perspective Specification
perspective Implementation perspective
6 What is Elaboration? K2 C01
Elaboration is the phase where the core architecture is
iteratively implemented.
Elaboration includes
Refined vision.
Iterative implementation of the core architecture. Resolution of
high risks.
Identification of most requirements and scope. More realistic
estimates.
7 What is actor? List its types. K2 C01
The use cases are the text stories that are designed in order
to understand the functionality of the system.
•Primary Actor
•Supporting Actor
•Offstage Actor

8 What is scenario? K2 C01

A scenario is a specific sequence of actions or interactions
between actors and the system.
It is also called a use case instance.
9 Define Use Case. K2 C01
The use cases are the text stories that are designed in order to
understand the functionality of the system.

10 List the relationships used in use cases K3 C01

Use case relationships is divided into three types
1.Include relationship
2.Extend relationship
3.Generalization

11 Define Inception. K2 C01

Inception is the smallest phase in the project. The following
are typical goals for the Inception phase.
Approximate vision Business case
Establish the Project scope vague estimates.
12 Define Sequence Diagram. K2 C01
A Sequence diagram simply depicts interaction between objects
in a sequential order i.e the order in which these interactions
take place.

13 Distinguish between Method and Message in object. K2 C01

Method Message
Each (typical synchronous) A method is the
message between objects is implementation of an
represented with a message operation. It specifies
expression on a filled-arrowed the algorithm or
solid line between the vertical procedure associated
lifelines. The time ordering is with an operation.
organized from top to bottom of
lifelines.

There are two ways to show the A set of operations that

return result from a message portray the behavior of
Using the message the objects of the class.
syntax return Var= Operations are also
message(parameter) referred as functions or
Using a reply (or return) methods.
message line at the end of an
activation bar.

14 What are the Phases of Unified Process? The Unified Process has 4 K2 C01
phases:
–Inception: Requirements capture and analysis
–Elaboration: System and class-level design
–Construction: Implementation and testing
–Transition: Deployment

15 What is extend relationship in use case? K2 C01

An Extend is a relationship from an extending UseCase (the
extension) to an extended UseCase (the extendedCase) that
specifies how and when the behavior defined in the extending
UseCase can be inserted into the behavior defined in the
extended UseCase.
12. Part B Qs (with K level and CO)
S.No Questions
K Level CO Level

1 (i).What is UP? (3) (ii).Explain briefly about the Four

K2 CO1
Major phases of Unified Process? (10)

2 By considering the Library management system,

K2 CO1
Perform the object oriented System Development and
give the use case model for the same(use include,
extend and generalization) (13)

3 List the Various UML diagrams and explain the purpose

K3 CO1
of each diagram. (13)

4 (i).What artifacts may start in Inception? How much

K3 CO1
UML is required during Inception? (7) (ii). Identify the
major difference between Evolutionary and water fall
requirements.(6)

5 (i).Give one Success scenario for ATM system. (7)

K2 CO1
(ii). Give the steps to find actors and goals. (6)
6 Explain the following terms (i). UP Disciplines (5)
K3 CO1
(ii).OOA and OOD (4)
(iii). Abstract and Base Use case(4)

7 A Library lends books and magazines to member, who is

K3 CO1
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 in the
system. The books transactions are stored in the
database. The fine list while the member returns the
book after the due date must be generated. Design the
use case diagram and discover the users and actors of
this system, and the interactions between them must be
depicted.(15)

8 Describe a suitable example showing the various

K3 CO1
relationships used in Use Case and also give a short
note on each relationship. (13)
13. Supportive online Certification courses
(NPTEL, Swayam, Coursera, Udemy, etc.,)
Online Repository:
1. Google Drive 2. GitHub 3. Code Guru

2 NPTEL Swayam
https://onlinecourses.nptel.ac.in/noc16_cs19
http://engineeringvideolectures.com/video/1237
www.uml-diagrams.org/uml-object-oriented-concepts.html
14. Real time Applications in day to day life
and to Industry
Joint Requirements Planning
Workshops (JRP)
The workshop approach pulls together a group of
people interested in the system being developed
(the stakeholders).
Everyone in the group is invited to give their view
of what the system needs to do. Key to the success
of these workshops is the facilitator. They lead the
group by ensuring that the discussion sticks to the
point, and that all the stakeholders are encouraged
to put their views across, and that those views are
captured.
Good facilitators are priceless! A scribe will also be
present, who will ensure that everything is
documented. The scribe might work from paper,
but a better method is to connect a CASE tool or
drawing tool to a projector and capture the
diagrams live.
A simple method of attacking the workshop is:
1) Brainstorm all of the possible actors first
2) Next, brainstorm all of the possible Use Cases
3)Once brainstorming is complete, as a group, justify
each Use Case through by producing a simple, one
line/paragraph description
4) Capture them on the model
Steps 1) and 2) can be reversed if desired. Some
good advice on the workshop:
•don’t work too hard trying to find every single
Use Case and Actor! It is natural that some more
use cases will emerge later on in the process.
•If you canít justify the Use Case at step 3), it
might not be a use case.
15. Contents beyond the Syllabus ( COE related Value
added courses)

S.No. Name of the Topic

1. Use case Relationship

16. Assessment Schedule ( Proposed Date & Actual
Date)

S.No Assessment Proposed Actual

Date Date

10.02.24
1 Internal Assessment to
Test I
16.02.24

01.04.24
2 Internal Assessment
to
Test II
06.04.24

20.04.24
3 Model Examination to
30.04.24
17. Prescribed Text Books & Reference Books

TEXT BOOKS:
Craig Larman, ―Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development‖, Third Edition, Pearson Education,
2005.
Ali Bahrami – Object Oriented Systems Development – McGraw Hill International
Edition – 1999.

REFERENCES:
Erich Gamma, a n d Richard Helm, Ralph Johnson, John Vlissides, ―Design
patterns: Elements of Reusable Object-Oriented Software‖, Addison-Wesley, 1995.
Martin Fowler, ―UML Distilled: A Brief Guide to the Standard Object Modeling
Language, Third edition, Addison Wesley, 2003.
Simon Bennett, Steve Mc Robb and Ray Farmer, “Object Oriented Systems Analysis
and Design Using UML”, Fourth Edition, Mc-Graw Hill Education, 2010.
Paul C. Jorgensen, “Software Testing:- A Craftsman‟s Approach”, Third Edition,
Auerbach Publications, Taylor and Francis Group, 2008.
18. Mini Project suggestions

1. Passport automation system.

2. Book bank
3. Exam Registration
4. Stock maintenance system.
5. Online course reservation system
6. E-ticketing
7. Software personnel management system
8. Credit card processing
9. e-book management system
10. Recruitment system
11. Foreign trading system
12. Conference Management System
13. BPO Management System
 Thank you

Disclaimer:

This document is confidential and intended solely for the educational purpose of RMK Group of
Educational Institutions. If you have received this document through email in error, please notify the
system manager. This document contains proprietary information and is intended only to the
respective group / learning community as intended. If you are not the addressee you should not
disseminate, distribute or copy through e-mail. Please notify the sender immediately by e-mail if you
have received this document by mistake and delete this document from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.