OOSE BVICAM

Question 1: Answer all the following questions briefly

a) Contrast error to a fault.

• Error: An error is a human action that produces an incorrect result. It is the
discrepancy between a computed, observed, or measured value or condition and the
true, specified, or theoretically correct value or condition.
• Fault: A fault, also known as a defect or bug, is an incorrect step, process, or data
definition in a computer program. Faults occur because of errors and lead to the
execution of incorrect steps or processing of incorrect data.

b) Describe the purpose of a UML activity diagram. Provide an example scenario where
an activity diagram would be used in software development.
• Purpose: UML activity diagrams are used to represent workflows of stepwise
activities and actions, with support for choice, iteration, and concurrency. They help
in modeling the dynamic aspects of the system.
• Example Scenario: An activity diagram can be used in modeling the process of
online shopping, where the activities include browsing items, adding items to the cart,
checking out, and making payments.

c) Explain the difference between a UML class diagram and a UML object diagram.
Provide a brief example for each to illustrate their use.
• Class Diagram: A class diagram describes the structure of a system by showing the
system's classes, their attributes, methods, and the relationships among objects.
o Example: A class diagram for an online shopping system showing classes like
Customer, ShoppingCart, Product, and Order.
• Object Diagram: An object diagram shows a complete or partial view of the
structure of a modeled system at a specific time. It instantiates the classes from a class
diagram.
o Example: An object diagram for an online shopping system might show
instances of objects like customer1:Customer, cart1:ShoppingCart with
specific products added.

d) Provide an example of a stereotype and explain how it can be used to extend the
standard UML elements.
In UML (Unified Modeling Language), a "stereotype" is an extension mechanism that allows
you to create new types of modeling elements. Stereotypes enable you to customize and
extend the standard UML metamodel by adding additional semantics to UML models.

• Example: A stereotype in UML can be <<interface>> which is used to indicate that

a class is an interface.
 • Usage: Stereotypes are used to create new model elements, derived from existing
ones, but that have specific properties suitable to a particular context. They extend the
vocabulary of the UML to include domain-specific elements.

Example Usage
• Domain-Specific Modeling:
o In a banking application, you might define stereotypes like «account»,
«transaction», and «customer» to represent different elements of the banking
domain.
• System Architecture:
o In software architecture, you might use stereotypes like «controller»,
«boundary», and «entity» to represent different layers of the application
architecture.
• Model Driven Development:
o Stereotypes can be used to mark elements that need to be treated in a specific
way during code generation or other model-driven development activities.

e) Discuss the use of packages in UML diagrams. How do packages help in organizing
and managing the complexity of large systems?
• Use of Packages: Packages are used in UML to group related classes, interfaces, and
other elements. They help to organize models into manageable parts.
• Managing Complexity:
o Packages help organize large models by breaking them down into smaller,
more manageable units.
o They promote modularity by encapsulating related elements within a single
package, making the system easier to navigate and understand.

f) Differentiate between a scenario and a use case.

• Scenario: A scenario is a specific sequence of actions and interactions between actors
and the system, illustrating a particular behavior. It is a single path through the use
case.
• Use Case: A use case describes a set of scenarios. It represents a complete
functionality that the system provides and includes all possible paths through the
function.

g) Explain the concept of multiplicity in UML. How is multiplicity represented in a class

diagram, and why is it important in modeling relationships between classes?
• Concept: Multiplicity defines the number of instances of one class that can be
associated with one instance of another class.
• Representation: It is represented by numbers at the association end, e.g., 1, 0..*, *.
 • Importance: Multiplicity clearly defines how many instances of a class can or must
be associated with instances of another class.This helps in understanding the nature of
the relationship, such as one-to-one, one-to-many, or many-to-many.
• For system designers and developers, multiplicity provides a clear understanding of
how different parts of the system interact.

h) Contrast between the different interaction diagrams.

• Sequence Diagram: Shows how objects interact in a particular sequence of time.
• Collaboration Diagram: Focuses on the structural organization of objects that send
and receive messages.
• Timing Diagram: Represents the behavior of objects over time, focusing on time
constraints.
• Communication Diagram: Similar to sequence diagrams but emphasizes the
organization of the objects rather than the time sequence.

i) Discuss the importance of pair programming.

• Importance: Pair programming involves two programmers working together at one
workstation. One writes code while the other reviews each line of code as it is typed
in. This improves code quality, facilitates knowledge transfer, and enhances team
collaboration.

j) List the principles of agile software development.

1. Customer satisfaction through early and continuous software delivery.

2. Welcome changing requirements, even late in development.
3. Deliver working software frequently.
4. Close, daily cooperation between business people and developers.
5. Projects are built around motivated individuals.
 6. Face-to-face conversation is the best form of communication.
7. Working software is the primary measure of progress.
8. Sustainable development, able to maintain a constant pace.
9. Continuous attention to technical excellence and good design.
10. Simplicity is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. Regular adaptation to changing circumstances.

UNIT - I

Question 2 (a): Maintaining traceability during requirements and subsequent activities

is expensive, because of the additional information that must be captured and
maintained. What are the benefits of traceability that outweigh this overhead?
• Benefits:
a. Requirement Validation: Ensures all requirements are met and validated.
b. Impact Analysis: Helps in understanding the impact of changes.
c. Compliance: Assists in regulatory and standards compliance.
d. Project Tracking: Improves tracking of project progress and deliverables.
e. Maintenance: Eases the maintenance and updating of the system by providing
a clear map of requirements and their implementations.

Question 2 (b): Explain the role of UML in software architecture. How does UML help
in designing and visualizing the architecture of a software system?
• Role of UML: UML provides a standardized way to visualize the design of a system.
It helps in documenting and designing the architecture, providing a blueprint that
guides the development process.
• Designing and Visualizing:
o Class Diagrams: Define the static structure.
o Sequence and Activity Diagrams: Describe the dynamic behavior.
o Component Diagrams: Show the organization and dependencies among a set
of components.
o Deployment Diagrams: Describe the physical deployment of artifacts on
nodes.

Question 3 (a): Elaborate is-a relationship in detail with a suitable example.

• Is-a Relationship: Represents inheritance in object-oriented design. It indicates that a
subclass is a type of its superclass.
o Example: Consider a class Vehicle and a subclass Car. The relationship Car
is a Vehicle represents the is-a relationship. This allows Car to inherit
attributes and methods from Vehicle.

Question 3 (b): Describe the various architectural views that can be represented using
UML.
• Views:
 f. Logical View: Represents the functional requirements of the system.
g. Development View: Focuses on the software's static organization in the
development environment.
h. Process View: Captures the system’s dynamic aspects, explaining the system
processes and how they communicate.
i. Physical View: Describes the physical deployment of the system on hardware.
j. Scenarios (Use Case View): Represents the system’s functionality as
perceived by external actors.

How do these views help in understanding and communicating the software

architecture?
• Understanding and Communicating:
o Clear Structure: Provides a clear and organized structure of the system.
o Stakeholder Communication: Each view addresses concerns of different
stakeholders (developers, architects, users).
o Comprehensive Understanding: Offers a comprehensive understanding of
the system from different perspectives.
o Documentation: Ensures thorough documentation, aiding in maintenance and
future development.

UNIT - II

Question 4 (a): Analyze the relationship between a class and object diagram with an
appropriate example.
• Relationship: A class diagram represents the blueprint of the system, showing classes
and their relationships. An object diagram represents instances of classes at a
particular moment in time.
o Example: In a class diagram, you may have a class Person with attributes like
name and age. An object diagram may show an instance of this class like
john:Person with name=John Doe and age=30.
Question 4(b) Case study: Online ShoppingParagraphs Corporation sells books and
CDs using through online shopping. The customer adds items to her shopping cart.
Shemay remove items or go tothe check-out to make her purchases at any time. The
customer reviews her purchases, chooses a payment method and pays. A sales
employeeat Paragraphs Corporation gets the order and purchase confirmation from the
system, andsends the electronic order to the warehouse. The warehouse
employeeupdates the order status. The customer may check the order status. Model the
above scenarios through a Use case Diagram
Question 5 (a):A company wants to develop a new software system to manage its
inventory. They need a system that can track items, suppliers, purchase orders, and
sales orders. Create a UML class diagram that represents the main entities and their
relationships in this system. Include attributes and relationships between the classes.

Question 5 (b):An Online Public Access Catalog (OPAC)is an e-Library website which
is part of Integrated Library Systenm (ILS), also known as a Library Management
System (LMS), and managed by a library or group of libraries. Patrons of the library
can search library catalog online to locate various resources - books, periodicals, audio
and visual materials, or other items under control of the library. Patrons may reserve or
renew item, provide feedback, and manage their account. Model the abovescenarios
through a Use case Diagram
 UNIT - III

Question 6 (a): With an appropriate example, justify the purpose of the construction
phase in the object-oriented analysis model.
• Purpose: The construction phase involves the actual coding and development of the
system. It translates design into an executable system.
o Example: In developing a banking application, during the construction phase,
the developers write code to implement classes like Account, Transaction,
and their interactions as per the design models.

Question 6 (b): Evaluate the Iterator design pattern with an appropriate example.
o The Iterator design pattern is a behavioral pattern that provides a way to
access the elements of an aggregate object (such as a collection) sequentially
without exposing its underlying representation. It allows clients to traverse the
elements of a collection without needing to know its internal structure, thus
promoting encapsulation and decoupling between the client and the collection.
o Example: Consider a collection of Book objects in a library system. An
iterator can be used to traverse this collection and access each Book object
sequentially without needing to know the underlying data structure (e.g., array,
list).

Question 7 (a): Explain the concept of design patterns and their importance in software
development.
Basic Design Patterns:
Singleton Pattern:
o Ensures that a class has only one instance and provides a global point of access to that
instance.
o Useful when exactly one instance of a class is needed throughout the system, such as a
configuration manager or a logging service.
Multiton Pattern:
o A variation of the Singleton pattern where there can be multiple named instances of a class,
each identified by a key.
o Useful when there's a need for multiple instances of a class, each with a unique identifier,
such as connection pools or resource managers.
Iterator Pattern:
o Provides a way to access the elements of an aggregate object sequentially without exposing
its underlying representation.
o Useful for iterating over collections or sequences of objects without exposing the internal
structure of the collection.
Adapter Pattern:
o Allows objects with incompatible interfaces to work together by providing a wrapper that
translates one interface into another.
o Useful for integrating legacy or third-party code with new systems or for providing a
consistent interface to clients.
Observer Pattern:
o Defines a one-to-many dependency between objects so that when one object changes state,
all its dependents are notified and updated automatically.
o Useful for implementing event handling, pub-sub systems, or implementing the Model-
View-Controller (MVC) architectural pattern

Question 7 (b):Elaborate the need of various design patterns through appropriate

examples.

1. Singleton Pattern:
Example - Configuration Manager: Imagine a Configuration Manager class that is
responsible for managing application configuration settings throughout the application's
lifecycle. It's crucial to ensure that there's only one instance of the Configuration Manager
throughout the application to maintain consistency in configuration settings.

2. Multiton Pattern:
Example - Database Connection Pool: Consider a Database Connection Pool that manages
multiple database connections based on different connection names. Each connection pool is
identified by a unique name, and clients can request connections from the pool based on their
specific needs.

3. Iterator Pattern:
Example - Music Playlist: Suppose you have a music playlist containing multiple songs.
You want to iterate over the playlist to play each song in sequence. The Iterator pattern
provides a way to traverse the playlist without exposing its internal structure, allowing you to
iterate over the songs one by one.

4. Adapter Pattern:
Example - Voltage Adapter: In the context of electronics, imagine you have a device that
requires a specific voltage input, but the available power source provides a different voltage
level. A Voltage Adapter acts as an intermediary between the device and the power source,
converting the voltage to match the device's requirements.
5. Observer Pattern:
Example - Weather Station: Consider a Weather Station that collects weather data
(temperature, humidity, etc.) and broadcasts updates to various display devices (e.g., weather
dashboard, mobile app). The Observer pattern allows the display devices to register as
observers and receive real-time updates whenever there's a change in weather conditions.

UNIT- IV

Question 8 (a): Elaborate the XP practices that embody the basic practices of Extreme
Programming (XP)?
Extreme Programming (XP) is an agile software development methodology that emphasizes
flexibility, communication, and high-quality code. The basic practices of XP embody its core
principles and include:

• Planning Game: Collaborative planning sessions where the team and stakeholders
prioritize and estimate user stories or features for the next iteration.
• Small Releases: Delivering working software in small, frequent releases to obtain
feedback and adapt to changing requirements quickly.
• Simple Design: Emphasizing simplicity in design by continuously improving the
codebase through refactoring and removing unnecessary complexity.
• Pair Programming: Two developers working together at one workstation, where one
writes code while the other reviews it in real-time. This practice fosters collaboration,
improves code quality, and spreads knowledge across the team.
• Test-Driven Development (TDD): Writing automated tests before writing code, and
then writing only enough code to make the tests pass. This ensures code correctness,
promotes a better understanding of requirements, and supports continuous integration.
• Refactoring: Restructuring existing code without changing its external behavior to
improve readability, maintainability, and extensibility.
• Continuous Integration: Integrating code changes into the mainline frequently,
ideally multiple times per day, to detect and resolve integration issues early.
• Collective Code Ownership: All team members are responsible for the codebase,
allowing anyone to modify or refactor any part of the code.
• On-Site Customer: Ensuring constant availability of a customer representative to
provide real-time feedback and clarify requirements.
• Coding Standards: Establishing and following coding standards and conventions to
maintain consistency and improve readability.
Question 8 (b): Contrast the various types of black box testing strategies?

Types of Black Box Testing

1.Functional Testing(same as above)
2.Non-Functional Testing

Types of Functional Testing

Unit testing: It a level of the software testing process where individual units/components
of a software/system are tested. The purpose is to validate that each unit of the software
performs as designed.
Integration testing: It is a level of the software testing process where individual units are
combined and tested as a group. The purpose of this level of testing is to expose faults in
the interaction between integrated units.
 System testing: It is a level of the software testing process where a complete, integrated
system/software is tested. The purpose of this test is to evaluate the system’s compliance
with the specified requirements.

Types of Integration Testing

1.Incremental Testing

There are 2 Types of Incremental Testing

1.Top-down Integration Testing

2.Bottom-up Integration Testing

1. Top-down Integration Testing

Top-down testing is a type of incremental integration testing approach in which testing is

done by integrating or joining two or more modules by moving down from top to bottom
through the control flow of the architecture structure. In these, high-level modules are tested
first, and then low-level modules are tested.

2. Bottom-up Integration Testing

Bottom-up Testing is a type of incremental integration testing approach in which testing is

done by integrating or joining two or more modules by moving upward from bottom to top
through the control flow of the architecture structure. In these, low-level modules are tested
first, and then high-level modules are tested.

2.Non-Incremental Testing

Types of Non-functional Testing

Performance Testing
Usability Testing
Compatibility Testing

1. Performance Testing

Performance Testing is a type of software testing that ensures software applications perform
properly under their expected workload. It is a testing technique carried out to determine
system performance in terms of sensitivity, reactivity, and stability under a particular
workload.
There are 4 Types of Performance Testing

1. Load Testing

Load testing determines the behavior of the application when multiple users use it at the same
time.
2. Stress Testing
In Stress Testing, we give unfavorable conditions to the system and check how it perform in
those conditions.

3. Scalability Testing

Scalability Testing is defined as the ability of a network, system, application, product or a

process to perform the function correctly when changes are made in the size or volume of the
system to meet a growing need.

4. Stability Testing

Stability Testing is a type of Software Testing to checks the quality and behavior of the
software under different environmental parameters. It is defined as the ability of the product
to continue to function over time without failure.

2. Usability Testing

You design a product (say a refrigerator) and when it becomes completely ready, you need a
potential customer to test it to check it working. To understand whether the machine is ready
to come on the market, potential customers test the machines.

3. Compatibility Testing

Compatibility testing is software testing that comes under the non functional testing category,
and it is performed on an application to check its compatibility (running capability) on
different platforms/environments.

Question 9 (a): Analyze the stakeholders that affect a Scrum project?

Stakeholders in a Scrum project are individuals or groups who have an interest or stake in the
project's success. They include:
 • Product Owner: Represents the stakeholders and is responsible for defining the
product vision, prioritizing the product backlog, and ensuring the team delivers value
to the customers.
• Scrum Master: Facilitates the Scrum process, removes impediments, and helps the
team adhere to Scrum principles and practices.
• Development Team: Self-organizing cross-functional team responsible for delivering
potentially shippable increments of the product at the end of each sprint.
• Customers/Users: End-users or customers who will ultimately use the product and
provide feedback to ensure it meets their needs and expectations.
• Management: Executives, project managers, or other organizational leaders who
provide resources, support, and strategic direction to the project.
• Quality Assurance/Testers: Responsible for ensuring the quality of the product
through testing and validation activities.
• External Stakeholders: Suppliers, vendors, regulatory bodies, or other external
entities who may have a vested interest in the project's outcome.

Question 9 (b): Evaluate the testing process lifecycle?

The testing process lifecycle typically includes the following phases:

• Test Planning: Defining the testing objectives, scope, resources, and timelines. It
involves identifying test requirements, creating test plans, and allocating resources for
testing activities.
• Test Design: Developing test cases and test scenarios based on requirements,
specifications, and other relevant documents. Test design involves defining test
inputs, expected outcomes, and test execution conditions.
• Test Execution: Running test cases and executing test scenarios to validate the
behavior of the system under test. It involves running automated tests, manual tests, or
a combination of both, and recording test results for analysis.
• Test Reporting: Documenting and communicating test results, including defects,
issues, and observations. Test reports provide stakeholders with insights into the
quality of the software and help make informed decisions about its release.
• Defect Management: Identifying, recording, prioritizing, and tracking defects found
during testing. Defect management involves triaging defects, assigning them to
appropriate stakeholders, and ensuring timely resolution.
• Test Closure: Evaluating the completion criteria defined in the test plan and assessing
whether the testing objectives have been met. Test closure involves reviewing test
documentation, conducting post-mortem meetings, and preparing test summary
reports.