MUTHAYAMMAL ENGINEERING COLLEGE

(An Autonomous Institution)

(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS
L-1

CSE III / VI
Course Code & Name : 21CSE17&VIRTUAL REALITY

Name of the Faculty:

Year / Semester/Section : VI/VII/

Unit : I- INTRODUCTION Date of Lecture:

Topic of Lecture: Virtual Reality & Virtual Environment

Introduction :
 Virtual Reality (VR) is an immersive technology that creates a simulated environment, allowing users to
experience and interact with a 3D world as if they were physically present in it. This technology typically
involves the use of VR headsets, which display the virtual environment and track the user's head and hand
movements, providing a sense of depth and presence.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Basic Computer Science Principles
 3D Graphics and Mathematics
 Computer Graphics
 VR Hardware and Software

Detailed content of the Lecture:

Virtual Reality (VR) is an immersive technology that creates a simulated environment, allowing users to experience
and interact with a 3D world as if they were physically present in it. This technology typically involves the use of VR
headsets, which display the virtual environment and track the user's head and hand movements, providing a sense of
depth and presence.

1. Basic Computing and Programming

 Programming Languages: Knowledge of languages like C#, C++, or Python is crucial, as these are often used
for VR development.
 Basic Programming Concepts: Understanding fundamental concepts such as variables, loops, conditionals, and
functions.

2. 3D Graphics Fundamentals

 Mathematics for 3D Graphics:

o Linear Algebra: Vectors, matrices, and transformations (translation, rotation, scaling) are essential for
manipulating 3D objects.
o Geometry: Basic concepts of shapes, space, and coordinate systems.
 Rendering Techniques: Basics of how 3D graphics are rendered, including shaders, lighting, and texturing.
 3. VR Hardware Knowledge

 Head-Mounted Displays (HMDs): Understanding different types of VR headsets, their specifications, and how
they work.
 Motion Controllers: Knowledge about how VR controllers track user input and interact with the virtual
environment.
 Tracking Systems: Familiarity with how tracking systems capture and translate user movements into the VR
world.

4. VR Development Tools and Software

 Game Engines: Proficiency with game engines like Unity or Unreal Engine, which are commonly used for
creating VR applications.
 VR SDKs and APIs: Knowledge of VR Software Development Kits (SDKs) and Application Programming
Interfaces (APIs) such as Oculus SDK, SteamVR, or OpenXR.

Applications: VR has a wide range of applications across different fields:

 Gaming: Offers highly immersive gaming experiences where players can explore virtual worlds and
interact with them in real-time.
 Education and Training: Provides simulations for training in fields such as medicine, aviation, and
military, allowing users to practice skills in a safe and controlled environment.
 Healthcare: Used for therapy and rehabilitation, helping patients with conditions like PTSD, phobias,
or motor impairments through tailored virtual experiences.
 Design and Architecture: Allows designers and architects to visualize and interact with their projects
before they are built, facilitating better planning and decision-making.
 Social Interaction: Platforms like VR chat rooms enable people to meet and interact in virtual spaces,
bridging distances and creating new forms of social engagement.

Video Content / Details of website for further learning (if any):

https://www.uml-diagrams.org/uml-object-oriented-concepts.html

Important Books/Journals for further learning including the page nos.:

Martin Fowler, UML Distilled, PHI/Pearson Education,2007[1-16]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS L -2

CSE III / VI
Course Code & Name 21CSE17&VIRTUAL REALITY

Name of the Faculty:

Year / Semester/Section : III/VI/

Unit I- INTRODUCTION Date of Lecture:

Topic of Lecture: Introduction –Computer grapics-Real time computer-graphics-Flight simulation-virtual

Environments
Introduction :
 Computer graphics in Virtual Reality (VR) is a crucial component that creates the visual elements of immersive
virtual environments. The field combines principles of computer graphics with VR technology to produce
realistic, interactive, and engaging experiences.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Real time computer
 Graphics
 Flight simulation
 Environment virtual
Detailed content of the Lecture:

Real-time computer graphics in Virtual Reality (VR) refers to the process of generating and rendering images
at a speed that matches or exceeds the frame rate of the VR headset, providing a smooth and immersive
experience.

1. Real-Time Rendering

Real-time rendering involves generating images from 3D models and scenes at a rate that maintains fluid
motion. This is critical for VR because any lag or stutter can break immersion and potentially cause motion
sickness. Key considerations include:

 Frame Rate: VR typically requires high frame rates (e.g., 90Hz or higher) to ensure smooth visuals
and reduce the risk of motion sickness. Each frame must be rendered quickly to keep up with user
movements and interactions.
 Latency: Low latency is essential in VR. The system needs to respond to user inputs and movements
with minimal delay to maintain a natural and immersive experience.
2.VR-Specific Rendering Techniques

 Stereoscopic Rendering: In VR, two images are rendered simultaneously, one for each eye, to create a
sense of depth. This requires rendering the scene from slightly different viewpoints and ensuring
synchronization.
 Foveated Rendering: This technique improves performance by rendering high detail only in the area
where the user is looking (the foveal region) and lower detail in peripheral vision. This approach
reduces the rendering workload and improves frame rates.
 Asynchronous Reprojection: This technique helps maintain a stable frame rate by compensating for
minor drops in performance. It allows the VR system to use the most recent frame data to interpolate
missing frames, reducing perceived latency.

3. Performance Optimization

Optimizing performance is critical for maintaining high frame rates and low latency:

 Level of Detail (LOD): Adjusting the complexity of 3D models based on their distance from the
viewer. Objects further away can be rendered with less detail, reducing computational load.
 Culling: Techniques to avoid rendering objects that are not visible to the user. Frustum culling, for
instance, removes objects outside the camera’s view frustum, while occlusion culling ignores objects
blocked by other objects.
 Asset Optimization: Reducing the complexity and size of textures and models to ensure faster
rendering. This can include techniques like texture atlasing, where multiple textures are combined into
a single image

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=nFoumijTcUg
Important Books/Journals for further learning including the page nos.:
Martin Fowler, UML Distilled, PHI/Pearson Education,2007[25-25]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu L-3

LECTURE HANDOUTS

CSE III/VI
Course Code & Name : 21CSE17&VIRTUAL REALITY
Name of the Faculty:

Year / Semester/Section : III/VI/

Unit : I- INTRODUCTION Date of Lecture:

Topic of Lecture: Requirement for Virtually- benefits of virtual reality-Historical development of VR

Introduction :
 To create and experience Virtual Reality (VR), several requirements must be met, spanning hardware, software,
and human factors.
Prerequisite knowledge for Complete understanding and learning of Topic:

 Hardware Requirements
 Software Requirements

Detailed content of the Lecture:

Hardware Requirements

 Head-Mounted Display (HMD): The primary device for VR, which provides the visual and often
auditory components of the experience. Popular models include the Oculus Quest, HTC Vive, and
Meta Quest.
 Motion Controllers: Handheld devices that track user movements and allow interaction within the
virtual environment. Examples include the Oculus Touch controllers and HTC Vive controllers.
 Tracking Sensors: Devices that track the user’s movements within the VR space. This may include
external sensors (like those used with the HTC Vive) or internal tracking systems within the HMD (as
with the Oculus Quest).
 Powerful PC or Console: High-performance computers or consoles may be required for VR systems
that are not standalone. These systems need to meet the specifications for processing power, graphics
capabilities, and memory. Examples include a gaming PC with a powerful GPU or consoles like
PlayStation VR.
 Connectivity: For VR systems that require external hardware, such as sensors or PCs, a reliable
connection (USB, HDMI, or DisplayPort) is necessary.

Software Requirements

 VR Platforms and SDKs: Software Development Kits (SDKs) and platforms that facilitate the
creation and integration of VR content. Examples include Unity and Unreal Engine for
development, and SDKs like Oculus SDK and SteamVR for interfacing with VR hardware.
  Content and Applications: VR requires specific applications and content designed for VR
environments, such as games, simulations, or educational programs.
 Drivers and Firmware: Up-to-date drivers and firmware for VR hardware to ensure
compatibility and performance.

Video Content / Details of website for further learning (if any):

https://www.smartdraw.com/uml-diagram/

Important Books/Journals for further learning including the page nos.:

Martin Fowler, UML Distilled, PHI/Pearson Education,2007[10-19]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu L-4

LECTURE HANDOUTS

CSE III/VI
Course Code & Name : 21CSE17&VIRTUAL REALITY

Name of the Faculty:

Year / Semester/Section : III/VI/

Unit : I- INTRODUCTION Date of Lecture:

Topic of Lecture: Introduction- Scientific landmark-3D Computer graphics

Introduction :
 3D computer graphics involve creating and manipulating visual content that appears to have three dimensions
—depth, width, and height. Unlike 2D graphics, which are flat and lack depth, 3D graphics provide a sense of
realism and spatial awareness, making them essential in various fields, including video games, movies,
simulations, and virtual reality.

Prerequisite knowledge for Complete understanding and learning of Topic

 Modeling
 Rendering
 Texturing
 Shading
Detailed content of the Lecture:

 Modeling: The process of creating 3D objects using geometric shapes. Techniques include polygonal
modeling, NURBS (Non-Uniform Rational B-Splines), and procedural generation.

 Rendering: The process of generating an image from a 3D model. This involves converting 3D data into
2D images through techniques like rasterization and ray tracing.

 Texturing: Applying textures to 3D models to add detail and realism. This includes creating and mapping
2D images onto 3D surfaces.

 Shading: Calculating the color and brightness of surfaces based on lighting conditions. Techniques
include flat shading, Gouraud shading, and Phong shading.

 Lighting: Simulating light sources within a scene to illuminate 3D objects. Types of lighting include
ambient, directional, point, and spotlights.
 Animation: Creating movement in 3D models by defining keyframes and using techniques such as
rigging and inverse kinematics.
  Simulation: The process of mimicking real-world physical phenomena in 3D environments, such as fluid
dynamics, cloth simulation, and particle systems.

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=UI6lqHOVHic
Important Books/Journals for further learning including the page nos.:
Martin Fowler, UML Distilled, PHI/Pearson Education,2007[35-50]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu L-5

LECTURE HANDOUTS

CSE III/VI
Course Code & Name : 21CSE17&VIRTUAL REALITY

Name of the Faculty:

Year / Semester/Section : III/VI/

Unit : I- INTRODUCTION Date of Lecture:

Topic of Lecture: - Introduction-The Virtual World Space-Positioning the virtual of Server

Introduction :
 Virtual world space refers to the conceptual and technical environment where digital simulations, games,
and applications occur. It’s an artificial space created and managed by computer systems where users
interact with three-dimensional objects, environments, and other users. This virtual space is defined and
manipulated using various technologies and methodologies to create a believable and functional simulated
experience.
Prerequisite knowledge for Complete understanding and learning of Topic:
 Virtual Coordinates
 Scale and Units
 World Boundaries and Limits
 Navigation and Movement
Detailed content of the Lecture:
Virtual world space refers to the conceptual and technical environment where digital simulations, games, and
applications occur. It’s an artificial space created and managed by computer systems where users interact with
three-dimensional objects, environments, and other users. This virtual space is defined and manipulated using
various technologies and methodologies to create a believable and functional simulated experience.

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=Ba7SyM78cUM
Important Books/Journals for further learning including the page nos.:
Martin Fowler, UML Distilled, PHI/Pearson Education,2007

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu L-6

LECTURE HANDOUTS

CSE III/VI
Course Code & Name : 21CSE17&VIRTUAL REALITY

Name of the Faculty:

Year / Semester/Section : III/VI/

Unit : I- INTRODUCTION Date of Lecture:

Topic of Lecture: - The Perspective projection-Human vision –Stereo perspective projection.

Introduction :
 Perspective projection is a technique in computer graphics used to create a sense of depth and realism in 3D
environments by mimicking how the human eye perceives the world. This projection method transforms 3D points
in space onto a 2D plane (such as a computer screen) in a way that reflects how objects appear smaller as they get
further away, converging towards a point in the distance.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Vanishing Points
 Depth Perception
 Field of View (FOV)
 Camera Model
Detailed content of the Lecture: Models:

Principles of Perspective Projection

 Vanishing Points: Lines parallel in 3D space converge towards one or more vanishing points on the 2D
plane. For example, railway tracks appear to meet at a single point on the horizon as they extend into the
distance.
 Depth Perception: Objects appear smaller as they move further from the viewer, creating a realistic sense
of depth. This is achieved by mapping objects based on their distance from the viewer.
 Field of View (FOV): The angle of the viewable area in the projection, typically controlled by the camera’s
lens. A wider FOV allows for more of the scene to be visible, while a narrower FOV focuses on a smaller
portion of the scene.
 Camera Model: In computer graphics, the perspective projection can be represented by a pinhole camera
model, where light rays pass through a single point (the pinhole) and project onto a flat surface (the image
plane).

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=KBNSZp2Ysdg

Important Books/Journals for further learning including the page nos.:

Martin Fowler, UML Distilled, PHI/Pearson Education,2007[107-115]

Course Faculty Verified by HOD

 LECTURE HANDOUTS

CSE III / VI
MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-7
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

Course Code & Name : 21CSE17&VIRTUAL REALITY

Name of the Faculty:

Year / Semester/Section : III/VI/

Unit : I- INTRODUCTION Date of Lecture:

Topic of Lecture: 3D clipping-colour theory-simple 3D modeling

Introduction :
3D clipping is a process in computer graphics used to manage and render only the visible parts of 3D
objects, which helps in optimizing performance and ensuring that the rendering process is efficient. The
primary goal of clipping is to eliminate parts of objects that are outside the viewable area of the scene or
are not visible to the camera.
Prerequisite knowledge for Complete understanding and learning of Topic:
 View Frustum Clipping
 Back-Face Culling
 Occlusion Culling
 Frustum Culling
Detailed content of the Lecture:
Types of 3D Clipping

 View Frustum Clipping:

o Definition: The view frustum is the pyramid-shaped volume that defines the visible space of the
camera. Clipping involves removing parts of objects that fall outside this pyramid.
o Process: Objects are tested against the six planes of the frustum (left, right, top, bottom, near, and
far). Portions of the object outside these planes are clipped or discarded.

 Back-Face Culling:
o Definition: This technique involves removing faces of objects that are facing away from the
camera, as they are not visible.
o Process: The orientation of each face is checked, and those with normals pointing away from the
camera are omitted from the rendering process.

 Occlusion Culling:
 o Definition: This technique eliminates objects that are blocked by other objects from being
rendered.
o Process: Visibility algorithms determine which objects are hidden behind others and only render
the visible ones.

 Frustum Culling:
o Definition: This is a form of view frustum clipping that specifically involves determining which
objects or parts of objects are within the view frustum.
o Process: Objects are tested against the view frustum to determine if they are within the visible
region.
Colour Theory

Colour theory in computer graphics is the study of how colors interact and how they can be used
effectively to create visual effects, convey information, and enhance realism in 3D environments.

1. Color Models

 RGB (Red, Green, Blue):

o Definition: The RGB color model is based on combining red, green, and blue light in various
intensities to produce a broad spectrum of colors.
o Application: It’s commonly used in digital displays and 3D graphics. Colors are represented as
combinations of these three primary colors.
 CMYK (Cyan, Magenta, Yellow, Black):

o Definition: The CMYK color model is used in color printing and is based on the subtractive
color mixing of cyan, magenta, yellow, and black inks.
o Application: It’s not typically used for screen-based displays but is crucial for printing
processes.

 HSV (Hue, Saturation, Value):

o Definition: The HSV model represents color in terms of hue (color type), saturation (color
intensity), and value (brightness).
o Application: Useful for designing color schemes and adjusting colors intuitively based on their
perceptual characteristics.

Video Content / Details of website for further learning (if any):

https://www.geeksforgeeks.org/cpu-scheduling-in-operating-systems/

Important Books/Journals for further learning including the page nos.:

Operating System Concepts, Abraham Silberschatz, Peter Baer Galvin and Greg Gagne, Prentice Hall of
India, 3rd Edition 2015[117-130]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-8
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Code & Name : 21CSE17&VIRTUAL REALITY

Name of the Faculty:

Year / Semester/Section : III/VI/

Unit : I- INTRODUCTION Date of Lecture:

Topic of Lecture: Illuminiation models- reflection models-shading algorithms

Introduction :
Illumination models describe how light interacts with surfaces in a 3D environment. They are crucial for
creating realistic and visually appealing graphics in VR and other applications. These models help
simulate how light is reflected, absorbed, and transmitted by objects, influencing their appearance and
how they are perceived by the viewer.
Prerequisite knowledge for Complete understanding and learning of Topic
 Basic Illumination Models
 Advanced Illumination Models
 Detailed content of the Lecture:

Basic Illumination Models

 Ambient Lighting:
o Definition: Represents the constant, uniform light that is scattered in all directions and affects all
surfaces equally, regardless of their orientation.
o Application: Provides a base level of illumination to ensure no part of the scene is completely
dark.

 Diffuse Lighting:
o Definition: Simulates light that is scattered uniformly across a surface, with intensity depending
on the angle between the light source and the surface normal.
o Calculation: Often modeled using Lambert’s cosine law, where the intensity is proportional to the
cosine of the angle between the light direction and the surface normal.
o Application: Adds depth and texture to surfaces, making them look more realistic by simulating
how light is scattered when hitting rough surfaces.

 Specular Lighting:
o Definition: Simulates the bright spots or highlights on surfaces that occur when light reflects
directly into the viewer’s eye.
o Calculation: Often modeled using the Phong reflection model, which calculates specular
reflection based on the angle between the viewer’s direction and the reflection of the light
direction on the surface.
o Application: Adds realism to shiny or glossy surfaces by creating highlights and reflections.

2. Advanced Illumination Models

 Phong Illumination Model:

o Components: Combines ambient, diffuse, and specular components to create a complete
illumination model.
o Formula: I=Ia⋅Ka. I=Ia⋅Ka+Id⋅Kd⋅max(0,L⋅N)+Is⋅Ks⋅max(0,R⋅V)n.

where III is the total illumination, IaI_aIa is the ambient light intensity, IdI_dId is the diffuse light
intensity, IsI_sIs is the specular light intensity, KaK_aKa, KdK_dKd, and KsK_sKs are the material
properties, L\mathbf{L}L is the light direction, N\mathbf{N}N is the surface normal, R\mathbf{R}R is
the reflection direction, V\mathbf{V}V is the viewer direction, and nnn is the shininess exponent.

 Application: Widely used for its balance of simplicity and realism in simulating surface illumination.

Reflection Models

Reflection models describe how light bounces off surfaces and contributes to the appearance of materials
in a 3D scene. They are essential for creating realistic reflections and surface properties.

1. Reflection Types

 Diffuse Reflection:
o Definition: Light is scattered equally in all directions from a rough surface.
o Model: Often modeled using Lambert's cosine law, which is already included in basic illumination
models like Phong.

 Specular Reflection:
o Definition: Light reflects in a specific direction, creating highlights on shiny surfaces.
o Model: Simulated using the Phong or Blinn-Phong models, which calculate the intensity based on
the reflection direction and viewer angle.
 Mirror Reflection:
o Definition: Light reflects off smooth, shiny surfaces in a predictable manner, like a mirror.
o Model: Implemented using reflection techniques that simulate the exact angle of incidence equals
the angle of reflection.

 Environment Mapping:
o Definition: Simulates reflections of the surrounding environment on reflective surfaces.
o Techniques:
 Cubemaps: Use a cube map texture to provide environment reflections. Each face of the
cube map represents a different direction in the environment.
 Sphere Mapping: Uses a spherical texture to simulate reflections on curved surfaces.
Video Content / Details of website for further learning (if any):
https://www.youtube.com/watch?v=3bfJ5AORAjQ
Important Books/Journals for further learning including the page nos.:
Martin Fowler, UML Distilled, PHI/Pearson Education,2007[89-95]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -9
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Code & Name : 21CSE17&VIRTUAL REALITY

Name of the Faculty:

Year / Semester/Section : III/VI/

Unit : I- INTRODUCTION Date of Lecture:

Topic of Lecture: - Hidden-Surface removal-realism-steregraphic usages.

Introduction :
 Hidden-surface removal is a critical process in computer graphics used to determine which surfaces of 3D
objects are visible in a rendered scene and which are obscured by other objects. This process ensures that only
the surfaces that are visible to the viewer are displayed, enhancing realism and efficiency. .

Prerequisite knowledge for Complete understanding and learning of Topic

 Techniques for Hidden-Surface Removal
 Realism in VR
 Detailed content of the Lecture:

Techniques for Hidden-Surface Removal

 Depth Buffering (Z-Buffering):

o Definition: Depth buffering is a technique used to track the distance of each pixel from the camera. It
involves maintaining a depth buffer (or Z-buffer) where the depth values of pixels are stored.
o Process: As each pixel is processed, its depth value is compared to the value stored in the depth buffer.
If the new pixel is closer to the camera, it updates the depth buffer and the color buffer; otherwise, it is
discarded.
o Advantages: Simple and effective for most scenes. It handles overlapping objects well and is widely
used in modern graphics pipelines.

 Painter’s Algorithm:
o Definition: The painter’s algorithm renders objects in the order of their distance from the camera, with
farthest objects drawn first.
o Process: Objects are sorted based on their depth, and then drawn from back to front. Overlapping
objects are managed by drawing the farther objects first, allowing nearer objects to obscure them.
o Challenges: Requires sorting of objects and may struggle with complex scenes or intersecting
geometries.

 Scanline Algorithm:
o Definition: This technique processes the image one horizontal scanline at a time, determining visible
surfaces for each scanline.
o Process: For each scanline, the algorithm determines which surfaces are visible by comparing depth
values and then updates the frame buffer accordingly.
o Advantages: Can be efficient for scenes with many horizontal surfaces but may be complex for scenes
with varying object shapes and intersections.

 Ray Casting:
o Definition: Ray casting involves shooting rays from the camera into the scene and determining the
closest intersection point of each ray with objects in the scene.
o Process: Each pixel corresponds to a ray, and the closest object intersected by the ray determines the
color of the pixel.
o Advantages: Useful for rendering complex scenes and handling transparency. Forms the basis for more
advanced techniques like ray tracing.

Realism in VR

Realism in VR involves creating immersive and believable experiences that closely mimic real-world physics,
lighting, and interactions. Achieving realism is essential for enhancing user engagement and providing a
convincing virtual environment.

1. Key Aspects of Realism

 Visual Realism:
o Lighting and Shading: Accurate lighting and shading models (e.g., Phong, Cook-Torrance) simulate
how light interacts with surfaces, creating realistic textures and highlights.
o Textures and Materials: Detailed textures and physically-based materials replicate real-world surface
properties, such as roughness and reflectivity.

 Physical Realism:
o Physics Simulations: Accurate simulations of physical behaviors, such as gravity, collisions, and
object interactions, enhance the realism of movement and object behavior in the virtual environment.
o Environmental Effects: Simulating environmental effects, such as fog, rain, or reflections, adds to the
realism of the scene.

 Interactive Realism:
o User Interaction: Natural and intuitive interactions, such as hand tracking and realistic object
manipulation, contribute to the immersive experience.
 o Feedback and Response: Providing haptic feedback and responsive controls helps users feel more
connected to the virtual environment.

2. Techniques for Enhancing Realism

 High-Resolution Textures: Use of high-resolution textures and detailed normal maps to create realistic surface
details.
 Dynamic Lighting: Implementing dynamic lighting that changes based on time of day, user interactions, and
environmental conditions.
 Advanced Shading Models: Utilizing advanced shading models that account for complex light interactions,
such as subsurface scattering and reflections.

Stereographic Usages

Stereography refers to techniques used to create the illusion of depth and three-dimensionality in visual
displays. In VR, stereographic methods are crucial for enhancing immersion and providing a convincing sense
of space.

1. Stereographic Techniques

 Stereo Vision:
o Definition: Involves presenting two slightly different images to each eye to simulate the perception of
depth, similar to how human vision works.
o Process: Two cameras are positioned to mimic the distance between human eyes (interocular distance).
Each camera renders a separate image, which is then displayed to each eye through VR headsets.

 Anaglyphic Stereo:
o Definition: Uses colored filters (typically red and cyan) to create a 3D effect on a 2D image. Each eye
sees a different color filter, creating a perception of depth.
o Application: Often used in legacy 3D glasses and images, but less common in modern VR due to color
and quality limitations.

 Polarized Stereo:
o Definition: Uses polarized glasses and displays with different polarization angles for each eye to
achieve 3D effects.
o Application: Provides better color fidelity and is used in some 3D cinema and VR systems.

 Active Shutter Stereo:

o Definition: Uses shutter glasses that alternate between left and right eye views in sync with the
display’s refresh rate.
o Application: Offers high-quality 3D effects with minimal color distortion, commonly used in VR
headsets and high-end 3D displays.

2. Stereoscopic Rendering Techniques

 Dual Rendering: Rendering two images from slightly different viewpoints (one for each eye) to
create a stereoscopic effect. Each eye’s viewpoint is adjusted based on its position to simulate depth.
 Depth Perception Adjustment: Adjusting the depth and convergence settings to match the user’s
natural vision and ensure comfort in VR experiences.
Video Content / Details of website for further learning (if any):
https://www.youtube.com/watch?v=3bfJ5AORAjQ

Important Books/Journals for further learning including the page nos.:

Martin Fowler, UML Distilled, PHI/Pearson Education,2007[97-98]

Course Faculty

Verified by

HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-10
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : II- OBJECT ORIENTED ANALYSIS Date of Lecture:

Topic of Lecture: GRASP: Designing objects with responsibilities

Introduction :
 GRASP - General Responsibility Assignment Software Patterns or Principles, abbreviated GRASP,
consist of guidelines for assigning responsibility to classes and objects in object-oriented design.
 It is not related to the SOLID design principle.
Prerequisite knowledge for Complete understanding and learning of Topic:
 Assigning responsibilities
 Aspects of object design
Detailed content of the Lecture:
Five GRASP patterns:
 Creator
 Information Expert
 Low Coupling
 Controller
Creator
 The concept of composition (Composite aggregates Part, Container contains Content, and Recorder
records)
 Expert pattern: initializing data is passed in during creation via some kind of initialization method, such
as a java constructor that has parameters.
 Assume that a payment instance, when created, needs to be initialized with the sale total. Since sale
knows the total, sale is a candidate creator of the payment.

Information Expert

 Assign a responsibility to the information expert the class that has the information necessary to fulfill the
responsibility.
 To create the interaction diagrams in order to assign responsibilities to objects.
 To fulfill the responsibility of knowing and answering the sale's total.
 Assign three responsibilities to three design classes of objects in the interaction diagram.
 Summarize the methods in the method section of a class diagram

Low Coupling

 Assign a responsibility so that coupling remains low. Use this principle to evaluate alternatives –
Coupling
  An element with low coupling is not dependent on too many other classes, subsystems,
systems. High coupling problems:
 Forced local changes because of changes in related classes.
 Harder to understand in isolation.
 Harder to reuse because its use requires the additional presence of the classes on which it is dependent.

Controller

 A controller is the first object beyond the UI layer that is responsible for receiving or handling a system
operation message.
 System

Video Content / Details of website for further learning (if any):

https://slideplayer.com/slide/9445997/
Important Books/Journals for further learning including the page nos.:
James Rumbaugh Ivar Jacobson Grady Booch, The Unified Modelling Language Reference Manual, Addison
Wesley,2005[39-47]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)

(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to L -11

Anna University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu
LECTURE HANDOUTS

CSE III / VI
Course Name with Code: 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III /VI/B

Unit : II- OBJECT ORIENTED ANALYSIS Date of Lecture:

Topic of Lecture : Creator

Introduction :
 Design patterns represent the best practices used by experienced object-oriented software
developers.
 Design patterns are solutions to general problems that software developers faced during software
development.
 These solutions were obtained by trial and error by numerous software developers over quite a
substantial period of time.
Prerequisite knowledge for Complete understanding and learning of Topic:
 Creational
 Factory
 Behavioral
Detailed content of the Lecture:
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

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.

S.N. Pattern & Description

1 Creational Patterns
These design patterns provides way to create objects while hiding the creation 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.

2 Structural Patterns
These design patterns concern class and object composition. Concept of inheritance is used to
compose interfaces and define ways to compose objects to obtain new functionalities.

3 Behavioral Patterns
These design patterns are specifically concerned with communication between objects.

4 J2EE Patterns
These design patterns are specifically concerned with the presentation tier. These patterns are
identified by Sun Java Center.
Video Content / Details of website for further learning (if any):
https://www.journaldev.com/1392/factory-design-pattern-in-java
Important Books/Journals for further learning including the page nos.:
James Rumbaugh Ivar Jacobson Grady Booch, The Unified Modelling Language Reference Manual,
Addison Wesley,2005.[23-28]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(Autonomous )

(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to L -12

Anna University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu
LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : II - OBJECT ORIENTED ANALYSIS Date of Lecture:

Topic of Lecture : Information expert

Introduction :
 Information Expert is a principle used to determine where to delegate responsibilities.
 These responsibilities include methods, computed fields and so on.
 Using the principle of Information Expert a general approach to assigning responsibilities is to look
at a given responsibility, determine the information needed to fulfil it, and then determine where
that information is stored.
Prerequisite knowledge for Complete understanding and learning of Topic:
 Creational
 Factory
 Behavioral
Detailed content of the Lecture:
Problem definition

 Information Expert is a principle used to determine where to delegate responsibilities.

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

 Using the principle of Information Expert a general approach to assigning responsibilities is to look
at a given responsibility, determine the information needed to fulfil it, and then determine where
that information is stored.

 Information Expert will lead to placing the responsibility on the class with the most information
required to fulfil it.

Analysis

 Information Expert is a basic principle of delegating responsibilities in object oriented development.

 Main idea is very simple and intuitive – objects do only those operations which are connected with
contained by them informations.
  Result of using this principle are solutions in which objects do those operations which in real world
normally do somebody on representing by them real objects.

 This pattern is also analogy to the real world – it’s quite natural that responsibilities are delegated
to the peoples who have appropriate knowledge.

Contraindication

 In some situations the solution resulting from Information Expert principle is not the best one
because of problems with coupling and cohesion.

 What is more, we have to be careful about not breaking layer separation principle.

 What object should write class A to the database? The most of information contains class A itself so
Information Expert says us that the class A should be responsible for writing itself to database.

 But this new responsibilities would decrease cohesion and break layer separation rule.

Advantages

 The rule of encapsulation is fulfilled – the objects do operations on the basis of contained
information’s.

 This usually will follow to the decreasing the number of connections between objects and
decreasing of coupling.

 What is more, different behaviors of the system are assigned to the different classes.

Video Content / Details of website for further learning (if any):

https://www.journaldev.com/1392/factory-design-pattern-in-java

Important Books/Journals for further learning including the page nos.:

James Rumbaugh Ivar Jacobson Grady Booch, The Unified Modelling Language Reference Manual,
Addison Wesley,2005.[56-59]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)

(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to L -13

Anna University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III /VI/B

Unit : II- OBJECT ORIENTED ANALYSIS Date of Lecture:

Topic of Lecture : Information expert

Introduction :
 Information Expert is a principle used to determine where to delegate responsibilities.
 These responsibilities include methods, computed fields and so on.
 Using the principle of Information Expert a general approach to assigning responsibilities is to look
at a given responsibility, determine the information needed to fulfil it, and then determine where
that information is stored.
Prerequisite knowledge for Complete understanding and learning of Topic:
 Creational
 Factory
 Behavioral
Detailed content of the Lecture:
Problem definition

 Information Expert is a principle used to determine where to delegate responsibilities.

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

 Using the principle of Information Expert a general approach to assigning responsibilities is to look
at a given responsibility, determine the information needed to fulfil it, and then determine where
that information is stored.

 Information Expert will lead to placing the responsibility on the class with the most information
required to fulfil it.

Analysis

 Information Expert is a basic principle of delegating responsibilities in object oriented development.

 Main idea is very simple and intuitive – objects do only those operations which are connected with
contained by them informations.
  Result of using this principle are solutions in which objects do those operations which in real world
normally do somebody on representing by them real objects.

 This pattern is also analogy to the real world – it’s quite natural that responsibilities are delegated
to the peoples who have appropriate knowledge.

Contraindication

 In some situations the solution resulting from Information Expert principle is not the best one
because of problems with coupling and cohesion.

 What is more, we have to be careful about not breaking layer separation principle.

 What object should write class A to the database? The most of information contains class A itself so
Information Expert says us that the class A should be responsible for writing itself to database.

 But this new responsibilities would decrease cohesion and break layer separation rule.

Advantages

 The rule of encapsulation is fulfilled – the objects do operations on the basis of contained
information’s.

 This usually will follow to the decreasing the number of connections between objects and
decreasing of coupling.

 What is more, different behaviors of the system are assigned to the different classes.

Video Content / Details of website for further learning (if any):

https://www.journaldev.com/1392/factory-design-pattern-in-java

Important Books/Journals for further learning including the page nos.:

James Rumbaugh Ivar Jacobson Grady Booch, The Unified Modelling Language Reference Manual,
Addison Wesley,2005.[33-35]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)

(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to L-14

Anna University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu
LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : II- OBJECT ORIENTED ANALYSIS Date of Lecture:

Topic of Lecture : Controller-Design Patterns

Introduction :
 Design patterns represent the best practices used by experienced object-oriented software developers.
 Design patterns are solutions to general problems that software developers faced during software
development.
 These solutions were obtained by trial and error by numerous software developers over quite a
substantial period of time.
Prerequisite knowledge for Complete understanding and learning of Topic:
 Creational
 Factory
 Behavioral
Detailed content of the Lecture:
 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
 Design patterns represent the best practices used by experienced object-oriented software developers.

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.
CONTROLLER
 The controller pattern assigns the responsibility of dealing with system events to a non-UI class that
represents the overall system or a use case scenario.
 The controller is defined as the first object beyond the UI layer that receives and coordinates ("controls")
a system operation.
 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.

Video Content / Details of website for further learning (if any):

https://www.journaldev.com/1392/factory-design-pattern-in-java
Important Books/Journals for further learning including the page nos.:
James Rumbaugh Ivar Jacobson Grady Booch, The Unified Modelling Language Reference Manual, Addison
Wesley,2005.

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)

(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to L-15

Anna University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu
LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : II- OBJECT ORIENTED ANALYSIS Date of Lecture:

Topic of Lecture : Creational -factory method

Introduction :
 Creational design patterns are design patterns that deal with object creation mechanisms, trying to create
objects in a manner suitable to the situation.
 The basic form of object creation could result in design problems or in added complexity to the design.
 Factory Method is a creational design pattern that provides an interface for creating objects in a
superclass, but allows subclasses to alter the type of objects that will be created.
Prerequisite knowledge for Complete understanding and learning of Topic:
 Creational
 Factory
 Behavioral
Detailed content of the Lecture:
 Creational design patterns are design patterns that deal with object creation mechanisms, trying to create
objects in a manner suitable to the situation.
 The basic form of object creation could result in design problems or in added complexity to the design.
Creational design patterns
 Creational design patterns are concerned with the way of creating objects.
 These design patterns are used when a decision must be made at the time of instantiation of a class (i.e.
creating an object of a class).
 But everyone knows an object is created by using new keyword in java. For example:

1. StudentRecord s1=new StudentRecord();

 Hard-Coded code is not the good programming approach.

 Here, we are creating the instance by using the new keyword.
 Sometimes, the nature of the object must be changed according to the nature of the program.
 In such cases, we must get the help of creational design patterns to provide more general and flexibl
approach
 .

Types of creational design patterns

There are following 6 types of creational design patterns.

 1. Factory Method Pattern
2. Abstract Factory Pattern
3. Singleton Pattern
4. Prototype Pattern
5. Builder Pattern
6. Object Pool Pattern

FACTORY METHOD

 Factory Method is a creational design pattern that provides an interface for creating objects in a
superclass, but allows subclasses to alter the type of objects that will be created.

FACTORY METHOD PATTERN

 A Factory Pattern or Factory Method Pattern says that just define an interface or abstract class
for creating an object but let the subclasses decide which class to instantiate.
 In other words, subclasses are responsible to create the instance of the class.

The Factory Method Pattern is also known as Virtual Constructor.

ADVANTAGE OF FACTORY DESIGN PATTERN

o Factory Method Pattern allows the sub-classes to choose the type of objects to create.
o It promotes the loose-coupling by eliminating the need to bind application-specific classes into the
code. That means the code interacts solely with the resultant interface or abstract class, so that it will
work with any classes that implement that interface or that extends that abstract class.
USAGE OF FACTORY DESIGN PATTERN
o When a class doesn't know what sub-classes will be required to create
o When a class wants that its sub-classes specify the objects to be created.
o When the parent classes choose the creation of objects to its sub-classes.
Video Content / Details of website for further learning (if any):
https://www.journaldev.com/1392/factory-design-pattern-in-java

Important Books/Journals for further learning including the page nos.:

James Rumbaugh Ivar Jacobson Grady Booch, The Unified Modelling Language Reference Manual, Addison
Wesley,2005.[78-81]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-16
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : II- OBJECT ORIENTED ANALYSIS Date of Lecture:

Topic of Lecture: GRASP-Structural, Bridge

Introduction :
 Bridge pattern decouple an abstraction from its implementation so that the two can vary independently.
 Introduce a class to convert the interface of one component into another interface is called adapter.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Software system blueprint

 Depict structures and relationship in complex object
Detailed content of the Lecture:
Bridge pattern
 The bridge pattern is a design pattern used in software engineering that is meant to decouple
an abstraction from its implementation so that the two can vary independently, introduced by the Gang
of Four. The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities
into different classes.
 When a class varies often, the features of object-oriented programming become very useful because
changes to a program's code can be made easily with minimal prior knowledge about the program.
 The bridge pattern is useful when both the class and what it does very often.
 The class itself can be thought of as the abstraction and what the class can do as the implementation.
 The bridge pattern can also be thought of as two layers of abstraction.
 When there is only one fixed implementation, this pattern is known as the Pimpl idiom in the C++ world.
 The bridge pattern is often confused with the adapter pattern, and is often implemented using the object
adapter pattern, e.g. in the Java code below.
 Variant: The implementation can be decoupled even more by deferring the presence of the
implementation to the point where the abstraction is utilized.
Structure

Sample UML class and sequence diagram for the Bridge design pattern

 The above Unified Modeling Language class diagram, an abstraction isn't implemented as usual in a
single inheritance hierarchy.
 Instead, there is one hierarchy for an abstraction and a separate hierarchy for its implementation ,
which makes the two independent from each other.
 The operation() interface is implemented in terms of by delegating to the interface
(impOperationImp()).
The UML sequence diagram shows the run-time interactions: The implementation1 object delegates
implementation to the implementor1 object by calling operationImp() on Implementor1, which performs
the operation and returns to abstraction1.

Video Content / Details of website for further learning (if any):

https://practice.geeksforgeeks.org/courses/design-patterns

Important Books/Journals for further learning including the page nos.:

James Rumbaugh Ivar Jacobson Grady Booch, The Unified Modelling Language Reference Manual, Addison
Wesley,2005.[45-49]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-17
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : II- OBJECT ORIENTED ANALYSIS Date of Lecture:

Topic of Lecture: Adapter, Behavioral

Introduction :
 Introduce a class to convert the interface of one component into another interface is called adapter.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Software system blueprint

 Depict structures and relationship in complex object
Detailed content of the Lecture:
ADAPTER
 In software engineering, the adapter pattern is a software design pattern also known as wrapper, an
alternative naming shared with the decorator pattern that allows the interface of an existing class to be
used as another interface.
 It is often used to make existing classes work with others without modifying their source code.

 An adapter allows two incompatible interfaces to work together.

 This is the real-world definition for an adapter.

 Interfaces may be incompatible, but the inner functionality should suit the need.

 The adapter design pattern allows otherwise incompatible classes to work together by converting the
interface of one class into an interface expected by the clients.
 An adapter can be used when the wrapper must respect a particular interface and must
support polymorphic behavior.
 Alternatively, a decorator makes it possible to add or alter behavior of an interface at run-time, and
a facade is used when an easier or simpler interface to an underlying object is desired.
BEHAVIORAL

 UML behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a system.
  The behavioral diagrams are categorized as follows:
 use case diagrams,
 interaction diagrams
 state–chart diagrams
 activity diagrams
1. Interactions Terms and Concepts Modeling Techniques
2. Interaction Diagrams Terms and Concepts Modeling Techniques

USE CASE DIAGRAMS

 Use case diagrams present an outside view of the manner the elements in a system behave and how they
can be used in the context.
 Use case diagrams comprise of −
 Use cases
 Actors
 Relationships like dependency, generalization, and association

Video Content / Details of website for further learning (if any):

https://practice.geeksforgeeks.org/courses/design-patterns

Important Books/Journals for further learning including the page nos.:

James Rumbaugh Ivar Jacobson Grady Booch, The Unified Modelling Language Reference Manual,
Addison Wesley,2005.[39-47]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)

(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to L-18

Anna University)
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu
LECTURE HANDOUTS

CSE III / VI

Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : II- OBJECT ORIENTED ANALYSIS Date of Lecture:

Topic of Lecture: Grasp- Strategy- observer

Introduction :
 Strategy lets the algorithm vary independently from clients that use it.
 Observer defines a one-to-many dependency between objects so that when one object
changes state, all its dependents are notified and updated automatically.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Observer pattern
 Strategy pattern
Detailed content of the Lecture:
Observer Pattern

 The observer pattern is a software design pattern in which an object, called the subject, maintains a list of
its dependents, called observers, and notifies them automatically of any state changes, usually by calling
one of their methods.
 It is mainly used to implement distributed event handling systems, in "event driven" software. In those
systems, the subject is usually called a "stream of events" or "stream source of events", while the
observers are called "sink of events".
 The stream nomenclature simulates or adapts to a physical setup where the observers are physically
separated and have no control over the emitted events of the subject/stream-source.
 This pattern then perfectly suits any process where data arrives through I/O, that is, where data is not
available to the CPU at startup, but can arrive "randomly" (HTTP requests, GPIO data, user input from
keyboard or mouse, distributed databases and blockchains .
 Most modern languages have built-in "event" constructs which implement the observer pattern
components.
 While not mandatory most 'observers' implementations will use background threads listening for subject
events and other support mechanism from the kernel Linux epoll.
 It addresses following problems:

 A one-to-many dependency between objects should be defined without making the objects tightly
coupled.
  It should be ensured that when one object changes state an open-ended number of dependent objects are
updated automatically.
 It should be possible that one object can notify an open-ended number of other objects.
 The Observer design pattern is one of the twenty-three well-known "Gang of Four" design patterns that
describe how to solve recurring design problems to design flexible and reusable object-oriented software,
that is, objects that are easier to implement, change, test, and reuse.

Strategy Pattern

 The strategy pattern (also known as the policy pattern) is a behavioral software design pattern that
enables selecting an algorithm at runtime.
 Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a
family of algorithms to use.
 For instance, a class that performs validation on incoming data may use the strategy pattern to select a
validation algorithm depending on the type of data, the source of the data, user choice, or other
discriminating factors.
 These factors are not known until run-time and may require radically different validation to be
performed.
 The validation algorithms (strategies), encapsulated separately from the validating object, may be used
by other validating objects in different areas of the system (or even different systems) without code
duplication.
 This is compatible with the open/closed principle (OCP), which proposes that classes should be open for
extension but closed for modification.

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=_BpmfnqjgzQ

Important Books/Journals for further learning including the page nos.:

James Rumbaugh Ivar Jacobson Grady Booch, The Unified Modelling Language Reference Manual, Addison
Wesley,2005.[75-87]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -19
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : III - CASE STUDY Date of Lecture:

Topic of Lecture: Case study – the Next Gen POS system

Introduction :
 A POS system is a computerized application used (in part) to record sales and handle payments; it
is typically used in a retail store.
Prerequisite knowledge for Complete understanding and learning of Topic:

 Next Gen POS System

Detailed content of the Lecture:

Case Study: Next POS System
 In this apparently straightforward problem domain, we shall see that there are very interesting
requirement and design problems to solve. In addition, it is a realistic problem; organizations
really do write POS systems using object technologies.
 A POS system is a computerized application used (in part) to record sales and handle payments; it
is typically used in a retail store.
 It includes hardware components such as a computer and bar code scanner, and software to run
the system.
 It interfaces to various service applications, such as a third-party tax calculator and inventory
control.
User-Level Goals
The users (and external systems) need a system to fulfill these goals:
 Cashier: process sales, handle returns, cash in, cash out
 System administrator: manage users, manage security, manage system tables
 Manager: start up, shut down
 Sales activity system: analyze sales data
Architectural Layers and Case Study Emphasis
A typical object-oriented information system is designed in terms of several architectural layers or
subsystems.
 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
 OOA/D is generally most relevant for modeling the application logic and technical
service layers.
 The Next Gen 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.
Video Content / Details of website for further learning (if any):
https://facultytalkies.com/courses/cs8592-object-oriented-analysis-and-design-notes/lessons/case-studythe-
next-gen-pos-system/

Important Books/Journals for further learning including the page nos.:

1. UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
2. Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath,
Springer, 2015[45-51]

Course Faculty

Verified by

HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-20
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : III - CASE STUDY Date of Lecture:

Topic of Lecture: Inception -Use case Modeling

Introduction :
 Inception is about understanding the project scope and objectives and getting enough information to
confirm that the project should proceed - or to convince you that it should not.
Prerequisite knowledge for Complete understanding and learning of Topic:

 Phases of application workflow

Detailed content of the Lecture:

Objectives:
 Understand what to build: Determine an overall vision, including the scope of the system and its
boundaries. Identify the stakeholders: who is interested in this system and what their success criteria
are.
 Identify key system functionality: Decide which requirements are most critical.
 Determine at least one possible solution: Assess whether the vision is technically feasible. This
may involve identifying a candidate high-level architecture or doing technical prototypes, or
both.
 Understand the high-level estimate for cost, schedule, and risks associated with the project.
Key considerations:
Projects may have one or more iterations in the Inception phase. These are among the reasons for multiple
iterations:
 Project is large, and it is hard to define its scope
 Unprecedented system
 Too many stakeholders with competing needs and complex relationships
 Major technical risks demand the creation of a prototype or proof of concept
Goals:
 To describe the initial requirements
 To develop and justify the business case for the system
 To determine the scope of your system
 To identify the people, organizations, and external systems that will interact with your system
 To develop an initial risk assessment, schedule, and estimate for your system
  To develop an initial tailoring of the Unified Process to meet your exact needs

The essential activities of the inception phase are:

 Formulating the scope of the project. This involves capturing the context and the most important
requirements and constraints to such an extent that you can derive acceptance criteria for the
end product.
 Planning and preparing a business case. Evaluating alternatives for risk management,
staffing, project plan, and cost/schedule/profitability trade-offs.
 Synthesizing a candidate architecture, evaluating trade-offs in design, and in make/buy/reuse,
so that cost, schedule and resources can be estimated.

The outcome of the inception phase is:

 A vision document: a general vision of the core project's requirements, key features,
main constraints.
 The use-case model survey (identifying all use cases that can be identified at this early stage).
 An initial glossary.
 An initial business case, which includes:.
 Success criteria (revenue projection, market recognition, and so on).
 Financial forecast.
 Business context
 An initial risk assessment.
 A project plan, showing phases, and iterations.
Video Content / Details of website for further learning (if any):
https://www.inceptiondesigns.com/CASE_HD_FOAM_p/gcl-005-cf.htm

Important Books/Journals for further learning including the page nos.:

 UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007

 Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath
Ramnath, Springer, 2015[45-49]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-21
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : III - CASE STUDY Date of Lecture:

Topic of Lecture: Relating Use cases

Introduction :
 An extend dependency, formerly called an extends relationship in UML v1. 2 and earlier, is a
generalization relationship where an extending use case continues the behavior of a base use case.
Prerequisite knowledge for Complete understanding and learning of Topic:

 Phases of application workflow

 Include
 Extend
 Generalization
Detailed content of the Lecture:
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.
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.

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.
 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.
Video Content / Details of website for further learning (if any):
https://facultytalkies.com/courses/cs8592-object-oriented-analysis-and-design-notes/lessons/relating-use-cases-
include-extend-and-generalization/
Important Books/Journals for further learning including the page nos.:
 UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
 Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath,
Springer, 2015[74-79]

Course Faculty

Verified by HOD
.
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -22
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : III - CASE STUDY Date of Lecture:

Topic of Lecture: Include, Extend and Generalization

Introduction :
 An extend dependency, formerly called an extends relationship in UML v1. 2 and earlier, is a
generalization relationship where an extending use case continues the behavior of a base use
case.
Prerequisite knowledge for Complete understanding and learning of Topic:

 Relating Use cases

 Include
 Extend
 Generalization
Detailed content of the Lecture:
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.
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.

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.
 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.
Video Content / Details of website for further learning (if any):
https://facultytalkies.com/courses/cs8592-object-oriented-analysis-and-design-notes/lessons/relating-
use-cases-include-extend-and-generalization/

Important Books/Journals for further learning including the page nos.:

 UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007[55-65]
 Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath,
Springer, 2015

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -23
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : III - CASE STUDY Date of Lecture:

Topic of Lecture: Elaboration Domain Models- Finding conceptual classes and description classes

Introduction :

 Conceptual class hierarchies are often inspiration for software class hierarchies that exploits inheritance
and reduce duplication of code.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Domain Model

Detailed content of the Lecture:

Uses of defining conceptual super classes and subclasses

 Defining is valuable to identify conceptual super and subclasses, it is useful to clearly and precisely
understand generalization, super classes, and subclasses in terms of class definition and class sets.

Role of conceptual subclass and super classes in set membership

 Conceptual subclasses and super classes are related in terms of set membership.
 By definition, all members of a conceptual subclass set are members of their super class set.
 For example, in terms of set membership, all instances of the set Credit Payment are also members of the
set Payment.
100% rule
100% of the conceptual Super class’s definition should be applicable to the subclass. The subclass must conform
to 100% of the Super class’s attributes and associations.

Guidelines followed in defining a super class

Create a super class in a generalization relationship to subclasses when :

 The potential conceptual subclasses represent variations of a similar concept
 The subclasses will confirm to the 100% and Is-A rules
 All subclasses have the same attribute that can be factored out and expressed in the super class
 All subclasses have the same association that can be factored out and related to the super class
Strong motivations to partition a conceptual class with subclasses

Create a conceptual subclass of a super class when :

 The subclass has additional attributes of interest
 The subclass has additional associations of interest
 The subclass concept is operated on, handled, reacted-to, or manipulated differently than the super class or
other subclasses
Video Content / Details of website for further learning (if any):
https://facultytalkies.com/courses/cs8592-object-oriented-analysis-and-design-notes/lessons/finding-conceptual-
class-hierarchies-in-ooad/
Important Books/Journals for further learning including the page nos.:
UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer, 2015[78-
89]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -24
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : III - CASE STUDY Date of Lecture:

Topic of Lecture: Associations – Attributes

Introduction :
 An association indicates that the system you are developing stores links of some kind between the
instances of the associated types.
Prerequisite knowledge for Complete understanding and learning of Topic:

 Domain Model
 Associations
 Attributes
Detailed content of the Lecture:
Association
 Association is a group of links having common structure and common behavior. Association depicts the
relationship between objects of one or more classes.
 A link can be defined as an instance of an association.
Degree of an Association
Degree of an association denotes the number of classes involved in a connection. Degree may be unary, binary, or
ternary.
 A unary relationship connects objects of the same class.
 A binary relationship connects objects of two classes.
 A ternary relationship connects objects of three or more classes.
Cardinality Ratios of Associations
 One–to–One − A single object of class A is associated with a single object of class B.
 One–to–Many − A single object of class A is associated with many objects of class B.
 Many–to–Many − an object of class A may be associated with many objects of class B and conversely an
object of class B may be associated with many objects of class A.
Attributes
 A set of attributes for the objects that are to be instantiated from the class. Generally, different objects of
a class have some difference in the values of the attributes. Attributes are often referred as class data.
 A set of operations that portray the behavior of the objects of the class. Operations are also referred as
functions or methods.
Domain Model Refinement
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".

Generalization
Generalization is the process of extracting shared characteristics from two or more classes, and combining them
into a generalized super class. Shared characteristics can be attributes, associations, or methods.

Specialization
Specialization means creating new subclasses from an existing class. If it turns out that certain attributes,
associations, or methods only apply to some of the objects of the class, a subclass can be created. The most
inclusive class in a generalization/specialization is called the super class and is generally located at the top of the
diagram. The more specific classes are called subclasses and are generally placed below the super class.

Video Content / Details of website for further learning (if any):

https://facultytalkies.com/courses/cs8592-object-oriented-analysis-and-design-notes/lessons/finding-conceptual-
classes-and-description-classes-in-ooad/

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer, 2015[81-
86]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -25
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : III - CASE STUDY Date of Lecture:

Topic of Lecture: Domain model refinement

Introduction :
 A domain model is illustrated with a set of class diagrams in which no operations (method signatures)
are defined
Prerequisite knowledge for Complete understanding and learning of Topic:

 Associations
 Attributes
 Domain Model
Detailed content of the Lecture:
 A domain model is illustrated with a set of class diagrams in which no operations (method signatures)
are defined
Association
 Association is a group of links having common structure and common behavior. Association depicts the
relationship between objects of one or more classes.
 A link can be defined as an instance of an association.
Degree of an Association
Degree of an association denotes the number of classes involved in a connection. Degree may be unary, binary,
or ternary.
 A unary relationship connects objects of the same class.
 A binary relationship connects objects of two classes.
 A ternary relationship connects objects of three or more classes.
Cardinality Ratios of Associations
 One–to–One − A single object of class A is associated with a single object of class B.
 One–to–Many − A single object of class A is associated with many objects of class B.
 Many–to–Many − an object of class A may be associated with many objects of class B and conversely
an object of class B may be associated with many objects of class A.
Attributes
 A set of attributes for the objects that are to be instantiated from the class.
 Generally, different objects of a class have some difference in the values of the attributes.
 Attributes are often referred as class data.
 A set of operations that portray the behavior of the objects of the class.
  Operations are also referred as functions or methods.
Domain Model Refinement
 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".

Generalization
 Generalization is the process of extracting shared characteristics from two or more classes, and
combining them into a generalized super class.
 Shared characteristics can be attributes, associations, or methods.

Specialization
 Specialization means creating new subclasses from an existing class.
 If it turns out that certain attributes, associations, or methods only apply to some of the objects of the
class, a subclass can be created.
 The most inclusive class in a generalization/specialization is called the super class and is generally
located at the top of the diagram.
 The more specific classes are called subclasses and are generally placed below the super class.

Video Content / Details of website for further learning (if any):

https://facultytalkies.com/courses/cs8592-object-oriented-analysis-and-design-notes/lessons/finding-conceptual-
classes-and-description-classes-in-ooad/

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007

Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[89-95]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -26
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : III - CASE STUDY Date of Lecture:

Topic of Lecture: Finding conceptual classes and description classes

Introduction :

 Conceptual class hierarchies are often inspiration for software class hierarchies that exploits inheritance
and reduce duplication of code.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Domain Model

Detailed content of the Lecture:

Uses of defining conceptual super classes and subclasses

 Defining is valuable to identify conceptual super and subclasses, it is useful to clearly and precisely
understand generalization, super classes, and subclasses in terms of class definition and class sets.

Role of conceptual subclass and super classes in set membership

 Conceptual subclasses and super classes are related in terms of set membership.
 By definition, all members of a conceptual subclass set are members of their super class set.
 For example, in terms of set membership, all instances of the set Credit Payment are also members of the
set Payment.
100% rule
100% of the conceptual Super class’s definition should be applicable to the subclass. The subclass must conform
to 100% of the Super class’s attributes and associations.

Guidelines followed in defining a super class

Create a super class in a generalization relationship to subclasses when :

 The potential conceptual subclasses represent variations of a similar concept
 The subclasses will confirm to the 100% and Is-A rules
 All subclasses have the same attribute that can be factored out and expressed in the super class
 All subclasses have the same association that can be factored out and related to the super class
Strong motivations to partition a conceptual class with subclasses

Create a conceptual subclass of a super class when :

 The subclass has additional attributes of interest
 The subclass has additional associations of interest
 The subclass concept is operated on, handled, reacted-to, or manipulated differently than the super class
or other subclasses
Video Content / Details of website for further learning (if any):
https://facultytalkies.com/courses/cs8592-object-oriented-analysis-and-design-notes/lessons/finding-conceptual-
class-hierarchies-in-ooad/
Important Books/Journals for further learning including the page nos.:
UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[145-145]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -27
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : III - CASE STUDY Date of Lecture:

Topic of Lecture: Aggregation and Composition

Introduction :

 Aggregation implies a relationship where the child can exist independently of the parent. Example: Class
(parent) and Student (child). Delete the Class and the Students still exist.
 Composition implies a relationship where the child cannot exist independent of the parent. Example:
House (parent) and Room (child).

Prerequisite knowledge for Complete understanding and learning of Topic:

 Conceptual class hierarchy

Detailed content of the Lecture:
Aggregation (Shared Association)
 In cases where there’s a part-of relationship between Class A (whole) and Class B (part), we can be more
specific and use the aggregation link instead of the association link, taking special notice that Class B
can also be aggregated by other classes in the application (therefore aggregation is also known as shared
association).

 So basically, the aggregation link doesn’t state in any way that Class A owns Class B nor that there is
a parent-child relationship (when parent deleted all its child’s are being deleted as a result) between
the two.
 Actually, quite the opposite! The aggregation link usually used to stress the point that Class A is not
the exclusive container of Class B, as in fact Class B has another container.
Composition (Not-Shared Association)
 In cases where in addition to the part-of relationship between Class A and Class B - there’s a strong life
cycle dependency between the two, meaning that when Class A is deleted then Class B is also deleted
as a result, we should be more specific and use the composition link instead of the aggregation link or
the association link.
 The composition link shows that a class (container, whole) has exclusive ownership over other
class/s (parts), meaning that the containers object and its parts constitute a parent-child/s relationship.
 Unlike association and aggregation, in the composition relationship, the composed class cannot appear
as a return type or parameter type of the composite class, thus changes in the composed class cannot be
propagated to the rest of the system.
 Consequently, usage of composition limits complexity growth as the system grows.

Significance:

 Provides standard for software development.

 Reducing of costs to develop diagrams of UML using supporting tools.
 Development time is reduced.
 The past faced issues by the developers are no longer exists.
 Has large visual elements to construct and easy to follow.
Video Content / Details of website for further learning (if any):
https://www.infoworld.com/article/3029325/exploring-association-aggregation-and-composition-in-oop.html

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[119-127]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -28
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : IV- APPLYING DESIGN PATTERNS Date of Lecture:

Topic of Lecture: System sequence diagrams

Introduction :

 System sequence diagram (SSD) is a sequence diagram that shows, for a particular scenario of a use case,
the events that external actors generate, their order, and possible inter-system events.

Prerequisite knowledge for Complete understanding and learning of Topic:

 UML Diagrams

Detailed content of the Lecture:

Definition
 System sequence diagrams, also known as SSD, are actually a sub-type of sequence diagrams, whose
style and notation is dictated by the Unified Modeling Language.
 This language provides a toolkit for diagram creators to make and read diagrams that are comprehensible
regardless of location or industry.
 Standard sequence diagrams show the progression of events over a certain amount of time, while system
sequence diagrams go step further and present sequences for specific use cases.

Most elements we cover in use case diagrams remain in use throughout a system sequence diagram, including:
 Objects - this box shape with an underlined title represents a class, or object, in UML. Within a SSD, this
shape models the system as a black box (a system with inner workings that are not immediately visible).
 Actors - shown by stick figures, actors are entities that interact with the system, and yet are external to it.
 Events - the system events that the actors generate in the sequence. A dashed line, known as a lifeline,
represents events in an SSD. Lifelines may begin with a labeled rectangle shape or an actor symbol.
Benefits of system sequence diagrams
SSDs are ideal for demonstrating when and how tasks are completed in a system, especially as those tasks relate
to use cases. Here are a few specific examples of when to use SSDs:
 In a step-wise fashion, modeling operations of the system in response to events.
 Building a blueprint for the main success scenario of a given use case, then creating alternative paths.
  Identifying major system events and operations in order to come up with realistic estimates of resources
needed.

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=3VX3QpUuvfs
Important Books/Journals for further learning including the page nos.:
UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[178-187]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -29
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : IV- APPLYING DESIGN PATTERNS Date of Lecture:

Topic of Lecture: Relationship between sequence diagrams

Introduction :

 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.
 Shows interactions between objects in visual and chronological (time) order.

Prerequisite knowledge for Complete understanding and learning of Topic:

 UML Diagrams
Detailed content of the Lecture:
Use case relate to a sequence diagram
 A use-case model is built and the actors are connected to use cases.
 Each use case represents a task in which the actor participates.
 For each use case, a sequence diagram is built.
 Each sequence diagram specifies the main interaction steps to be achieved for each task (i.e. use case).
Describing Use Cases By Means of Sequence Diagrams
 Regarding the model-driven development, we also show a discussion on how the development process
and, in general, the developer decisions affect both use-case modeling and sequence-diagram modeling,
in particular, the identification of use-case relationships.
Our technique can be summarized as follows.
 A use-case model is built and the actors are connected to use cases. Each use case represents a task in
which the actor participates.
 For each use case, a sequence diagram is built. Each sequence diagram specifies the main interaction
steps to be achieved for each task (i.e. use case).
 From the sequence diagrams, use-case relationships are identified. Sequence sub diagrams are identified
with new use cases.
 The sequence diagrams are refined: some interaction steps are added as extensions to the original
sequence diagrams. These extensions are represented as new sequence (sub)diagrams.
  These new sub diagrams are identified with new use cases.

 From the refined sequence diagrams, new use-case relationships are discovered: new generalization/
specialization and extension relationships.

 Generalization/ specialization relationships between abstract and particular use cases are identified.
 Some of the previous steps might be applied incrementally in the development process.

Combined Fragments

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=3VX3QpUuvfs
Important Books/Journals for further learning including the page nos.:
UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[110-115]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-30
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : IV- APPLYING DESIGN PATTERNS Date of Lecture:

Topic of Lecture: Use cases

Introduction :
 To model a system, the most important aspect is to capture the dynamic behavior. Dynamic behavior
means the behavior of the system when it is running/operating.
 In UML, there are five diagrams available to model the dynamic nature and use case diagram is one of
them.
 Now as we have to discuss that the use case diagram is dynamic in nature, there should be some internal
or external factors for making the interaction.
Prerequisite knowledge for Complete understanding and learning of Topic:
 UML Diagrams
 Use cases
Detailed content of the Lecture:
 These internal and external agents are known as actors. Use case diagrams consists of actors, use cases
and their relationships.
 The diagram is used to model the system/subsystem of an application.
 A single use case diagram captures a particular functionality of a system.
 Hence to model the entire system, a number of use case diagrams are
used. 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. When the initial task is complete, use case diagrams are modelled to present the outside
view.
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.

HOW TO DRAW A USE CASE DIAGRAM:

 Actors can be a human user, some internal applications, or may be some external applications. When we
are planning to draw a use case diagram, we should have the following items identified.
 Functionalities to be represented as use case
 Actors
 Relationships among the use cases and actors.
 Use case diagrams are drawn to capture the functional requirements of a system. After identifying the
above items, we have to use the following guidelines to draw an efficient use case diagram
 The name of a use case is very important. The name should be chosen in such a way so that it can
identify the functionalities performed.
 Give a suitable name for actors.
 Show relationships and dependencies clearly in the
diagram.

Use case diagrams can be used for −

 Requirement analysis and high level design.
 Model the context of a system.
 Reverse engineering.
 Forward engineering.

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=3VX3QpUuvfs
Important Books/Journals for further learning including the page nos.:
UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[143-147]

Course Faculty

Verified by HOD
.
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-31
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : IV -APPLYING DESIGN PATTERNS Date of Lecture:

Topic of Lecture: Logical architecture

Introduction :

 Logical architecture is the large-scale organization of the software classes into packages (or namespaces),
subsystems, and layers.
 Logical - because there's no decision about how these elements are deployed across different operating
system processes or across physical computers in a network (deployment architecture).

Prerequisite knowledge for Complete understanding and learning of Topic:

 UML Diagrams
 Logical architecture

Detailed content of the Lecture:

 Any real-world system is used by different users. The users can be developers, testers, business people,
analysts, and many more.
 Hence, before designing a system, the architecture is made with different perspectives in mind.
 The most important part is to visualize the system from the perspective of different viewers. The better
we understand the better we can build the system.
UML plays an important role in defining different perspectives of a system. These perspectives are −

 Design
 Implementation
 Process
 Deployment
The center is the Use Case view which connects all these four.
A Use Case represents the functionality of the system. Hence, other perspectives are connected with use case.
Design of a system consists of classes, interfaces, and collaboration.
UML provides class diagram, object diagram to support this.
Implementation defines the components assembled together to make a complete physical system. UML
component diagram is used to support the implementation perspective.
Process defines the flow of the system. Hence, the same elements as used in Design are also used to support this
perspective.
Deployment represents the physical nodes of the system that forms the hardware. UML deployment diagram is
used to support this perspective.
It is very important to distinguish between the UML model. Different diagrams are used for different types of
UML modeling. There are three important types of UML modeling.

STRUCTURAL MODELING
Structural modeling captures the static features of a system. They consist of the following −

 Classes diagrams
 Objects diagrams
 Deployment diagrams
 Package diagrams
 Composite structure diagram
 Component diagram
Structural model represents the framework for the system and this framework is the place where all other
components exist. Hence, the class diagram, component diagram and deployment diagrams are part of structural
modeling. They all represent the elements and the mechanism to assemble them.
The structural model never describes the dynamic behavior of the system. Class diagram is the most widely used
structural diagram.

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

 Activity diagrams
 Interaction diagrams
 Use case diagrams
All the above show the dynamic sequence of flow in a system.

ARCHITECTURAL MODELING
Architectural model represents the overall framework of the system. It contains both structural and behavioral
elements of the system. Architectural model can be defined as the blueprint of the entire system. Package
diagram comes under architectural modeling.
Video Content / Details of website for further learning (if any):
https://www.youtube.com/watch?v=3VX3QpUuvfs

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer, 2015[158-
158]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-32
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : IV- APPLYING DESIGN PATTERNS Date of Lecture:

Topic of Lecture: UML package diagram

Introduction :

 Package diagram is UML structure diagram which shows structure of the designed system at the
level of packages. The following elements are typically drawn in a package diagram: package,
packageable element, dependency, element import, package import, package merge.

Prerequisite knowledge for Complete understanding and learning of Topic:

 UML Diagrams

Detailed content of the Lecture:

Package
 Package is a namespace used to group together elements that are semantically related and might
change together.
 It is a general purpose mechanism to organize elements into groups to provide better structure for
system model.
 Owned members of a package should all be packageable elements.
 If a package is removed from a model, so are all the elements owned by the package.
 Package by itself is packageable element, so any package could be also a member of other
packages.

Package Template
Logical Architecture And Layers
 Logical architecture is the large-scale organization of the software classes into packages (or
namespaces), subsystems, and layers.
 Logical - because there's no decision about how these elements are deployed across different
operating system processes or across physical computers in a network (deployment architecture).
Layering Pattern
 A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive
responsibility for a major aspect of the system.
 Also, layers are organized such that "higher" layers (such as the UI layer) call upon services of
"lower" layers, but not normally vice versa.
 Strict layered architecture VS Relaxed Layered Architecture.
 A logical architecture doesn't have to be organized in layers.
 But it's very common, and hence, introduced at this time.
Typical Layers Typically layers in an OO system
 User Interface.
 Application Logic and Domain Objects software objects representing domain concepts (for
example, a software class Sale) that fulfill application requirements, such as calculating a sale total.
.

Video Content / Details of website for further learning (if any):

https://medium.com/@warren2lynch/uml-what-is-package-diagram-how-to-use-it-dbd317c07d5d

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath,
Springer, 2015[144-147]

Course Faculty

Verified by

HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -33
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : IV- APPLYING DESIGN PATTERNS Date of Lecture:

Topic of Lecture: Logical architecture refinement

Introduction :

 Package diagram is UML structure diagram which shows structure of the designed system at the level of
packages.
 The following elements are typically drawn in a package diagram: package, packageable element,
dependency, element import, package import, package merge.

Prerequisite knowledge for Complete understanding and learning of Topic:

 UML Diagrams
 UML package diagram
Detailed content of the Lecture:
Package
 Package is a namespace used to group together elements that are semantically related and might change
together.
 It is a general purpose mechanism to organize elements into groups to provide better structure for system
model.
 Owned members of a package should all be packageable elements.
 If a package is removed from a model, so are all the elements owned by the package.
 Package by itself is packageable element, so any package could be also a member of other packages.
Package Template

Logical Architecture And Layers

 Logical architecture is the large-scale organization of the software classes into packages (or namespaces),
subsystems, and layers.
 Logical - because there's no decision about how these elements are deployed across different operating
system processes or across physical computers in a network (deployment architecture).
Layering Pattern
 A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive
responsibility for a major aspect of the system.
 Also, layers are organized such that "higher" layers (such as the UI layer) call upon services of "lower"
layers, but not normally vice versa.
 Strict layered architecture VS Relaxed Layered Architecture.
 A logical architecture doesn't have to be organized in layers.
 But it's very common, and hence, introduced at this time.
Typical Layers Typically layers in an OO system
 User Interface.
 Application Logic and Domain Objects software objects representing domain concepts (for example, a
software class Sale) that fulfill application requirements, such as calculating a sale total. .

Video Content / Details of website for further learning (if any):

https://medium.com/@warren2lynch/uml-what-is-package-diagram-how-to-use-it-dbd317c07d5d
Important Books/Journals for further learning including the page nos.:
UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer, 2015[141-
148]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -34
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : IV -APPLYING DESIGN PATTERNS Date of Lecture:

Topic of Lecture: UML class diagrams

Introduction :

 Class diagram in the Unified Modeling Language is a type of static structure diagram that describes the
structure of a system by showing the system's classes, their attributes, operations, and the relationships
among objects.

Prerequisite knowledge for Complete understanding and learning of Topic:

 UML Diagrams

Detailed content of the Lecture:

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.
Where to Use Class Diagrams
Class diagrams are used for −
 Describing the static view of the system.
 Showing the collaboration among the elements of the static view.
 Describing the functionalities performed by the system.
 Construction of software applications using object oriented languages.
Draw a Class Diagram
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.

Video Content / Details of website for further learning (if any):

https://www.edx.org/course/uml-class-diagrams-for-software-engineering

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[119-125]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-35
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : IV- APPLYING DESIGN PATTERNS Date of Lecture:

Topic of Lecture: UML interaction diagrams

Introduction :

 Interaction Overview Diagram is one of the fourteen types of diagrams of the Unified Modeling
Language, which can picture a control flow with nodes that can contain interaction diagrams.
 The interaction overview diagram is similar to the activity diagram, in that both visualize a sequence of
activities.

Prerequisite knowledge for Complete understanding and learning of Topic:

 UML Diagrams

Detailed content of the Lecture:

Purpose of Interaction Diagrams
 The purpose of interaction diagrams is to visualize the interactive behavior of the system. Visualizing
the interaction is a difficult task.
 Hence, the solution is to use different types of models to capture the different aspects of the interaction.
The purpose of interaction diagram is −
 To capture the dynamic behavior 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.
Where to Use Interaction Diagrams
Interaction diagrams can be used −
 To model the flow of control by time sequence.
 To model the flow of control by structural organizations.
 For forward engineering.
 For reverse engineering.
Draw an Interaction Diagram
Following things are to be identified clearly before drawing the interaction diagram
 Objects taking part in the interaction.
  Message flows among the objects.
 The sequence in which the messages are flowing.
 Object organization.
The Sequence Diagram
The sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder).

The Collaboration Diagram

 In the collaboration diagram, the method call sequence is indicated by some numbering technique.
 The number indicates how the methods are called one after another. We have taken the same
order management system to describe the collaboration diagram.

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=Ba7SyM78cUM

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[155-159]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -36
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : IV- APPLYING DESIGN PATTERNS Date of Lecture:

Topic of Lecture: UML interaction diagrams

Introduction :

 Interaction Overview Diagram is one of the fourteen types of diagrams of the Unified Modeling
Language, which can picture a control flow with nodes that can contain interaction diagrams.
 The interaction overview diagram is similar to the activity diagram, in that both visualize a sequence of
activities.

Prerequisite knowledge for Complete understanding and learning of Topic:

 UML Diagrams
Detailed content of the Lecture:

INTERACTION DIAGRAMS
 The main purpose of both the diagrams are similar as they are used to capture the dynamic behavior of a
system.
 However, the specific purpose is more important to clarify and understand.
 Sequence diagrams are used to capture the order of messages flowing from one object to another.
 Collaboration diagrams are used to describe the structural organization of the objects taking part in the
interaction.
 A single diagram is not sufficient to describe the dynamic aspect of an entire system, so a set of
diagrams are used to capture it as a whole.
 Interaction diagrams are used when we want to understand the message flow and the structural
organization.
 Message flow means the sequence of control flow from one object to another. Structural organization
means the visual organization of the elements in a system.
Interaction diagrams can be used −
 To model the flow of control by time sequence.
  To model the flow of control by structural organizations.
 For forward engineering.
 For reverse
engineering. The Sequence
Diagram
The sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder).

STATECHART DIAGRAM
Statechart diagrams are very important for describing the states.
Before drawing a Statechart diagram we should clarify the following points −
 Identify the important objects to be analyzed.
 Identify the states.
 Identify the events.

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=Ba7SyM78cUM
Important Books/Journals for further learning including the page nos.:
UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[112-119]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-37
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : V- TESTING Date of Lecture:

Topic of Lecture: Applying GoF

Introduction :
 Design patterns represent the best practices used by experienced object-oriented software developers.
 Program to an interface not an implementation
 Favor object composition over inheritance
Prerequisite knowledge for Complete understanding and learning of Topic:
 Design patterns
 UML Diagrams

Detailed content of the Lecture:

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 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.
 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 Creational
Patterns-
 These design patterns provides way to create objects while hiding the creation 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 inheritance is used to compose
interfaces and define ways to compose objects to obtain new functionalities.
Behavioral Patterns-
 These design patterns are specifically concerned with communication between objects.
J2EE Patterns-
 These design patterns are specifically concerned with the presentation tier. These patterns are identified
by Sun Java Center.

Video Content / Details of website for further learning (if any):

https://www.linkedin.com/learning/java-ee-design-patterns-and-architecture/classic-gof-software-design-patterns
Important Books/Journals for further learning including the page nos.:
UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[138-142]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-38
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : V- TESTING Date of Lecture:

Topic of Lecture: Design patterns

Introduction :

 Design patterns represent the best practices used by experienced object-oriented software developers.
 Design patterns are solutions to general problems that software developers faced during software
development.
 These solutions were obtained by trial and error by numerous software developers over quite a substantial
period of time.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Design patterns
 UML Diagrams
Detailed content of the Lecture:
Usage of Design Pattern
Design patterns provide a standard terminology and are specific to particular scenario.
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 Creational
Patterns-
 These design patterns provides way to create objects while hiding the creation 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 inheritance is used to compose interfaces and define ways to compose objects to obtain new
functionalities.
Behavioral Patterns-
 These design patterns are specifically concerned with communication between objects.
J2EE Patterns-
  These design patterns are specifically concerned with the presentation tier.
 These patterns are identified by Sun Java Center.
 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

Video Content / Details of website for further learning (if any):

https://www.linkedin.com/learning/java-ee-design-patterns-and-architecture/classic-gof-software-design-patterns
Important Books/Journals for further learning including the page nos.:
UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[140-143]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-39
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : V- TESTING Date of Lecture:

Topic of Lecture: Mapping design to code

Introduction :

 Mapping from Design to Code. Each class in design is implemented by coding it in a programming
language or by using a pre-existing component

Prerequisite knowledge for Complete understanding and learning of Topic:

 GoF Patterns
 UML Diagrams
Detailed content of the Lecture:
Programming and Iterative, Evolutionary Development
 The creation of code in an OO programming language is not a part of OOAD, is an end goal
 The artifacts created in the UP Design Model provide some of the information necessary to generate
the code
 Roadmap to software development
 OOAD - logical solution, blueprints
 OOP - running applications
 Use case - requirements

Creativity and Change During Implementation

 OOAD produces a base for the
application Scales up with elegances
Robustness
 Code Changes are inevitable
CASE Tools, and Reverse-Engineering
Rational ROSE, or Borland Together

Mapping Designs to Code

Implementation in an OO programming language requires writing source code for
 Classes and interface definitions
 methods definition

Creating Class Definitions from DCDs

 This is sufficient to create a basic class definition in a OO language.
 If the DCD was drawn in a UML tool, it can generate the basic class definition from the diagrams.
DCDs depict some of the basic elements of a class or interface
 Name
 Superclass
 Operation signatures
 attributes
Defining a Class with Methods and Attributes
From the DCD, a mapping to the attributes (Java fields) and method signatures is straightforward.

Video Content / Details of website for further learning (if any):

https://study.com/academy/lesson/mapping-code-using-outlines-and-flow-charts.html

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[158-161]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L -40
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : V- TESTING Date of Lecture:

Topic of Lecture: Mapping design to code

Introduction :

 Mapping from Design to Code. Each class in design is implemented by coding it in a programming
language or by using a pre-existing component

Prerequisite knowledge for Complete understanding and learning of Topic:

 GoF Patterns
 UML Diagrams
Detailed content of the Lecture:

Programming and Iterative, Evolutionary Development

 The creation of code in an OO programming language is not a part of OOAD, is an end goal
 The artifacts created in the UP Design Model provide some of the information necessary to generate
the code
 Roadmap to software development
 OOAD - logical solution, blueprints
 OOP - running applications
 Use case - requirements

Creativity and Change During Implementation

 OOAD produces a base for the
application Scales up with elegances
Robustness
 Code Changes are inevitable
CASE Tools, and Reverse-Engineering
Rational ROSE, or Borland Together

Mapping Designs to Code

Implementation in an OO programming language requires writing source code for
 Classes and interface definitions
 methods definition

Creating Class Definitions from DCDs

 This is sufficient to create a basic class definition in a OO language.
 If the DCD was drawn in a UML tool, it can generate the basic class definition from the diagrams.
DCDs depict some of the basic elements of a class or interface
 Name
 Superclass
 Operation signatures
 attributes
Defining a Class with Methods and Attributes
From the DCD, a mapping to the attributes (Java fields) and method signatures is straightforward.

Video Content / Details of website for further learning (if any):

https://study.com/academy/lesson/mapping-code-using-outlines-and-flow-charts.html

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[185-189]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-41
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : V- TESTING Date of Lecture:

Topic of Lecture: Testing: Issues in OO Testing

Introduction :

 Issues in Object oriented testing: 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

Prerequisite knowledge for Complete understanding and learning of Topic:

 Mapping Design to Code

Detailed content of the Lecture:

Definition
 Software typically undergoes many levels of testing, from unit testing to system or acceptance testing.
 Typically, in-unit testing, small “units”, or modules of the software, are tested separately with focus on
testing the code of that module.
 In higher, order testing (e.g., acceptance testing), the entire system (or a subsystem) is tested with the
focus on testing the functionality or external behavior of the system.
Issues in Testing Classes:
 In object-oriented programs, control flow is characterized by message passing among objects, and the
control flow switches from one object to another by inter-object communication.
 Consequently, there is no control flow within a class like functions.
 This lack of sequential control flow within a class requires different approaches for testing.

Techniques of object-oriented testing

 Fault Based Testing:

This type of checking permits for coming up with test cases supported the consumer specification
or the code or both.
It tries to identify possible faults (areas of design or code that may lead to errors.). For all of these
faults, a test case is developed to “flush” the errors out.
These tests also force each time of code to be
executed. This method of testing does not find all
types of errors.
  Class Testing Based on Method Testing:
This approach is the simplest approach to test classes.
Each method of the class performs a well defined cohesive function and can, therefore, be related to
unit testing of the traditional testing techniques.
Therefore all the methods of a class can be involved at least once to test the class.
 Random Testing:
It is supported by developing a random test sequence that tries the minimum variety of operations
typical to the behavior of the categories
 Partition Testing:
This methodology categorizes the inputs and outputs of a category so as to check them severely.
This minimizes the number of cases that have to be designed.
 Scenario-based Testing:
It primarily involves capturing the user actions then stimulating them to similar actions throughout
the test.
These tests tend to search out interaction form of error.
Video Content / Details of website for further learning (if any):
https://slideplayer.com/slide/7780236/

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[241-243]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-42
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : V- TESTING Date of Lecture:

Topic of Lecture: Class Testing

Introduction :

 Class testing is the base of object-oriented software testing. It involves three aspects: testing each
method, testing the relations among class methods and testing the inheriting relation between class and
subclass.

Prerequisite knowledge for Complete understanding and learning of Topic:

 Issues in OO Testing

Detailed content of the Lecture:

Unit
 The smallest chunk that can be compiled by itself
 A single method that does not call use other methods
 Something small enough to be developed by one person
When units are methods
 Simplistic view reduces to traditional procedural unit
testing Apply functional and structural test methods
Require drivers and stubs
 Encapsulation
advantage Methods
are simple
 Encapsulation disadvantage
Interface complexity is high
Intense message sending
Lots of work building stubs and drivers
 Burden of testing moves to integration
level Intraclass
Interclass

When units are classes

 Solves intraclass integration problem

  Different views
Static view – class text
Ignores inheritance
Good only for reading
Compile-time view
When inheritance
occurs Execution view
Behavioral view – class are instantiated
This is where testing occurs
 Cannot test abstract classes
 Cannot be instantiated
 Choices
Classes flattened for testing
Need to unflatten when testing is
completed Use inherited classes
Configuration management nightmare
 Make most sense when
Little inheritance
occurs
Intraclass control complexity
Interesting statechart
Video Content / Details of website for further learning (if any):
https://slideplayer.com/slide/7780236/

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[248-251]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-43
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : V- TESTING Date of Lecture:

Topic of Lecture: OO Integration Testing

Introduction :

 Integration Testing: This involves testing a particular module or a subsystem and is the responsibility of
the subsystem lead.

Prerequisite knowledge for Complete understanding and learning of Topic:

 OO Testing

Detailed content of the Lecture:

Integration Testing
 It is defined as a type of testing where software modules are integrated logically and tested as a group.
 A typical software project consists of multiple software modules, coded by different programmers.
 The purpose of this level of testing is to expose defects in the interaction between these software modules
when they are integrated

Approaches, Strategies, Methodologies of Integration Testing

Software Engineering defines variety of strategies to execute Integration testing, viz.
 Big Bang Approach :
 Incremental Approach: which is further divided into the
following Top Down Approach
Bottom Up Approach
Sandwich Approach - Combination of Top Down and Bottom Up
Big Bang Approach:
Here all component are integrated together at once and then tested.
Advantages:
Convenient for small systems.
Incremental Approach
 In this approach, testing is done by joining two or more modules that are logically related.
 Then the other related modules are added and tested for the proper functioning.
 The process continues until all of the modules are joined and tested successfully.
Stub: Is called by the Module under Test.
Driver: Calls the Module to be tested.
Bottom-up Integration
 In the bottom-up strategy, each module at lower levels is tested with higher modules until all modules are
tested. It takes help of Drivers for testing.
Top-down Integration:
 In Top to down approach, testing takes place from top to down following the control flow of the software
system.
 Takes help of stubs for testing.
Hybrid/ Sandwich Integration
 In the sandwich/hybrid strategy is a combination of Top Down and Bottom up approaches.
Guidelines for Integration Testing
 First, determine the Integration Test Strategy that could be adopted and later prepare the test cases and
test data accordingly.
 Study the Architecture design of the Application and identify the Critical Modules.
 These need to be tested on priority.
 Obtain the interface designs from the Architectural team and create test cases to verify all of the
interfaces in detail.
 Interface to database/external hardware/software application must be tested in detail.
 After the test cases, it's the test data which plays the critical role.
 Always have the mock data prepared, prior to executing.
 Do not select test data while executing the test cases.
Video Content / Details of website for further learning (if any):
https://www.guru99.com/integration-testing.html

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[295-297]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-44
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu
LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : V- TESTING Date of Lecture:

Topic of Lecture: GUI Testing- OO System Testing

Introduction :

 GUI testing is defined as the process of testing the system's Graphical User Interface of the Application
Under Test.
 GUI testing involves checking the screens with the controls like menus, buttons, icons, and all types of
bars - toolbar, menu bar, dialog boxes, and windows, etc.

Prerequisite knowledge for Complete understanding and learning of Topic:

 OO Testing
 Testing
 GUI
Detailed content of the Lecture:

Graphical User Interface Testing (GUI) Testing

 Graphical User Interface Testing (GUI) Testing is the process for ensuring proper functionality of the
graphical user interface (GUI) for a specific application.
 GUI testing generally evaluates a design of elements such as layout, colors and also fonts, font sizes,
labels, text boxes, text formatting, captions, buttons, lists, icons, links and content.

Feature of Graphical User Interface Testing (GUI):

 It is provide customizable test report.
 It is run tests in parallel or distribute on a Selenium Grid with built-in Selenium Web
 driver.
 It allows you to test the functionality from a user’s perspective.
 Sometimes the internal functions of the system work correctly but the user interface doesn’t then GUI
testing is good to have in addition to the other types.
 It provide reliable object identification, even for web elements with dynamic IDs.
Types of Graphical User Interface Testing (GUI) Testing:
 Analog Recording
 Object based Recording
Challenges with Graphical User Interface Testing (GUI) Testing:
 Technology Support
 Stability of Objects
 Instrumentation
  GUI testing is a testing technique in which the application's user interface is tested whether the
application performs as expected with respect to user interface behaviour.
 GUI Testing includes the application behaviour towards keyboard and mouse movements and how
different GUI objects such as toolbars, buttons, menubars, dialog boxes, edit fields, lists, behavior to the
user input.

GUI TESTING GUIDELINES

 Check Screen Validations
 Verify All Navigations
 Check usability Conditions
 Verify Data Integrity
 Verify the object states
 Verify the date Field and Numeric Field Formats
CHALLENGES WITH GRAPHICAL USER INTERFACE TESTING (GUI) TESTING:

There is some challenge which is occurring during Graphical user interface testing.
These are given below.
 Technology Support
 Stability of Objects
 Instrumentation

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=1R3vsu_7n0E

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer, 2015[332-
335]

Course Faculty

Verified by HOD
 MUTHAYAMMAL ENGINEERING
COLLEGE
(An Autonomous Institution)
(Approved by AICTE, New Delhi, Accredited by NAAC & Affiliated to Anna
University) L-45
Rasipuram - 637 408, Namakkal Dist., Tamil Nadu

LECTURE HANDOUTS

CSE III / VI
Course Name with Code : 21CSF23&OBJECT ORIENTED ANALYSIS AND DESIGN

Course Faculty :

Year / Semester/Section : III/VI/ B

Unit : V- TESTING Date of Lecture:

Topic of Lecture: GUI Testing- OO System Testing

Introduction :

 GUI testing is defined as the process of testing the system's Graphical User Interface of the Application
Under Test.
 GUI testing involves checking the screens with the controls like menus, buttons, icons, and all types of
bars - toolbar, menu bar, dialog boxes, and windows, etc.

Prerequisite knowledge for Complete understanding and learning of Topic:

 OO Testing
 Testing
 GUI
Detailed content of the Lecture:
System Testing
 System testing is a level of testing that validates the complete and fully integrated software product.
 The purpose of a system test is to evaluate the end-to-end system specifications.
 Usually, the software is only one element of a larger computer-based system.
System Testing is Blackbox
 Two Category of Software
Testing Black Box Testing
White Box Testing
 System test falls under the black box testing category of software testing.
 White box testing is the testing of the internal workings or code of a software application.
Different Types of System Testing
 Usability Testing- mainly focuses on the user's ease to use the application, flexibility in handling
controls and ability of the system to meet its objectives
 Load Testing- is necessary to know that a software solution will perform under real-life loads.
 Regression Testing- involves testing done to make sure none of the changes made over the course of the
development process have caused new bugs.
 It also makes sure no old bugs appear from the addition of new software modules over time.
 Recovery testing - is done to demonstrate a software solution is reliable, trustworthy and can
successfully recoup from possible crashes.
 Migration testing- is done to ensure that the software can be moved from older system infrastructures to
current system infrastructures without any issues.
 Functional Testing - Also known as functional completeness testing, Functional Testing involves trying
to think of any possible missing functions.
 Testers might make a list of additional functionalities that a product could have to improve it during
 functional testing.
 Hardware/Software Testing - IBM refers to Hardware/Software testing as "HW/SW Testing".
 This is when the tester focuses his/her attention on the interactions between the hardware and software
during system testing.
 System Testing (ST) is a black box testing technique performed to evaluate the complete system the
system's compliance against specified requirements.
 In System testing, the functionalities of the system are tested from an end-to-end perspective.
 System Testing is usually carried out by a team that is independent of the development team in order to
measure the quality of the system unbiased.
 It includes both functional and Non-Functional
testing. Types of System Tests:

Video Content / Details of website for further learning (if any):

https://www.youtube.com/watch?v=1R3vsu_7n0E

Important Books/Journals for further learning including the page nos.:

UML Distilled, Abraham Martin Fowler, PHI/Pearson Education, 2007
Object-Oriented Analysis, Design and Implementation, Brahma Dathan, Sarnath Ramnath, Springer,
2015[342-345]

Course Faculty

Verified by HOD