1. List the diagrams used in Booch method.

Draw OMT DFD of the

ATM System.
The Booch method, developed by Grady Booch, primarily focuses on object-oriented design and
analysis. While it doesn't prescribe a specific set of diagrams like the Unified Modeling Language
(UML), it often utilizes various diagrams to represent different aspects of a system. Some of the
common diagrams used in the Booch method include:

1. Class Diagrams: Represent the static structure of a system, showing classes, their attributes,
methods, and relationships between classes.

2. Object Diagrams: Depict instances of classes and their relationships at a specific point in
time.

3. State Diagrams: Illustrate the states of objects and the transitions between these states.

4. Interaction Diagrams: Such as sequence diagrams and collaboration diagrams, which show
how objects interact over time.

5. Use Case Diagrams: Describe the interactions between a system and its external actors,
focusing on the functionality provided by the system.

6. Package Diagrams: Organize the elements of a system into cohesive groups.

the Object Modeling Technique (OMT) Data Flow Diagram (DFD) for an ATM
systems
This DFD illustrates the flow of data in a basic ATM system:
 The "User Interface" interacts with the user, accepting inputs such as
account information and transaction requests.
 The "Transaction Logic" processes the user's requests, checking for valid
transactions, deducting or adding funds from/to the account, and
updating the database accordingly.
 The "Database" stores information about user accounts, balances,
transaction logs, etc.

2. Compare the merits and demerits of Software Development

models in table form. (write the below answer in tabular form in
exam)

1. Waterfall Model:
Merits:
 Simple and Sequential: The linear and sequential nature of the waterfall
model makes it easy to understand and implement.
 Clear Milestones: Each phase has well-defined deliverables and
milestones, aiding in project tracking and management.
 Documentation: Emphasizes documentation at each stage, ensuring
clear documentation of requirements, design, and implementation.
 Prevents Scope Creep: Requirements are finalized upfront, reducing the
likelihood of scope creep during development.
 Easy Management: Due to its structured approach, the waterfall model
is relatively easy to manage, especially for smaller projects with stable
requirements.
Demerits:
 Rigidity: Lack of flexibility makes it difficult to accommodate changes
once the project moves to the next phase.
  Late Testing: Testing occurs at the end of the development lifecycle,
which may lead to issues being discovered late, increasing the cost of
fixing defects.
 Limited Customer Feedback: Customer feedback is limited until the later
stages of development, which may result in mismatches between the
final product and customer expectations.
 High Risk: The risk of project failure is high if requirements are not well
understood or change significantly during development.
 No Working Software Until Late: Working software is only produced
towards the end of the project, leading to potential delays in delivering
value to the customer.
2. Agile Model:
Merits:
 Customer Satisfaction: Agile prioritizes customer satisfaction by
delivering working software iteratively and frequently, incorporating
customer feedback throughout the development process.
 Adaptability: Highly adaptable to changes, allowing for flexibility in
responding to evolving requirements.
 Early Detection of Issues: Early and continuous testing and integration
help in early detection and resolution of issues.
 Collaboration: Promotes collaboration and communication among team
members and stakeholders, enhancing transparency and shared
understanding.
 Reduced Risk: Incremental and iterative development reduces the risk of
project failure by delivering value early and frequently.
Demerits:
 Active Customer Involvement Required: Agile requires active
involvement and commitment from customers throughout the
development process, which may not always be feasible.
 Scope Creep: Continuous changes and iterations may lead to scope creep
if requirements are not managed effectively.
  Documentation: Agile prioritizes working software over comprehensive
documentation, which may lead to a lack of documentation, especially in
fast-paced environments.
 Skill Dependency: Requires skilled and experienced team members for
effective collaboration, communication, and decision-making.
 Not Suitable for Fixed Requirements: Not suitable for projects with fixed
requirements or tight deadlines, as the iterative nature may lead to
uncertainty in project timelines and costs.
3. Spiral Model:
Merits:
 Risk Management: Incorporates risk analysis and mitigation from the
early stages, allowing for proactive management of risks throughout the
development lifecycle.
 Adaptability: Highly adaptable and flexible, making it suitable for
projects with changing or evolving requirements.
 Early Prototyping: Allows for early prototyping and user feedback,
reducing the risk of building the wrong product.
 Iterative Development: Provides opportunities for incremental
development and refinement, allowing for continuous improvement.
 Large and Complex Projects: Suitable for large, complex projects where
requirements are not well understood initially.
Demerits:
 Complexity: The spiral model can be complex and may require extensive
resources, making it less suitable for smaller projects.
 Risk Analysis Overhead: Risk management can become time-consuming
and costly, especially for projects with high uncertainty.
 Difficulty in Estimation: Difficult to estimate project timelines and costs
accurately, especially in the early stages.
 Skill Dependency: Requires highly skilled team members for effective
risk assessment, management, and decision-making.
  Documentation Challenges: Documentation can be challenging to
maintain due to the iterative nature of the model, leading to potential
gaps in documentation.
4. V-Model:
Merits:
 Early Emphasis on Testing: Testing activities are integrated into each
phase of development, leading to early detection and resolution of
defects.
 Clear Correspondence: Each development phase has a corresponding
testing phase, ensuring that all requirements are validated and verified.
 Well-Structured: Provides a systematic and structured approach to
development, making it easier to manage and track progress.
 Reduced Risk: Ensures that requirements are properly validated and
verified, reducing the risk of building the wrong product.
 Documentation: Emphasizes documentation at each stage, ensuring
clear documentation of requirements, design, and testing activities.
Demerits:
 Rigidity: Similar to the waterfall model, the V-model can be rigid and
inflexible, making it difficult to accommodate changes once the project is
underway.
 Late Feedback: Customer feedback is limited until later stages of
development, which may lead to mismatches between the final product
and customer expectations.
 Limited Adaptability: Less adaptable to changes compared to agile
methodologies, making it less suitable for projects with evolving
requirements.
 Complexity: Requires careful planning and coordination of development
and testing activities, which can be complex and time-consuming.
 Documentation Overhead: Emphasizes documentation at each stage,
which may lead to documentation overhead, especially for smaller
projects.
5. Incremental Model:
Merits:
 Early Delivery of Basic Functionality: Allows for early delivery of partial
functionality, providing value to customers sooner.
 Reduced Risk: Incremental delivery reduces the risk of project failure by
delivering working software early and frequently.
 Flexibility: Each increment builds on the previous one, providing
opportunities for feedback and adaptation.
 Customer Involvement: Encourages customer involvement and feedback
throughout the development process, ensuring alignment with customer
needs.
 Clear Progression: Each increment provides a clear progression towards
the final product, enhancing transparency and stakeholder satisfaction.
Demerits:
 Careful Planning Required: Requires careful planning and design of
increments to ensure that each increment adds value and aligns with
project goals.
 Integration Challenges: May lead to integration issues if not planned
properly, especially as the number of increments increases.
 Increased Complexity: Managing multiple increments simultaneously
can increase complexity, especially for larger projects.
 Estimation Challenges: Difficulty in estimating overall project timeline
and cost, especially in the early stages when requirements are not fully
understood.
 Not Suitable for Fixed Deadlines: May not be suitable for projects with
fixed deadlines or requirements, as the iterative nature may lead to
uncertainty in project timelines and costs.
4. Write detailed notes on UML class diagram.

Class diagrams are a type of UML (Unified Modeling Language) diagram used in
software engineering to visually represent the structure and relationships of
classes in a system. UML is a standardized modeling language that helps in
designing and documenting software systems. They are an integral part of the
software development process, helping in both the design and documentation
phases.
Class diagrams provide a high-level overview of a system’s design, helping to
communicate and document the structure of the software. They are a
fundamental tool in object-oriented design and play a crucial role in the
software development lifecycle.

What is a class
In object-oriented programming (OOP), a class is a blueprint or template for
creating objects. Objects are instances of classes, and each class defines a set of
attributes (data members) and methods (functions or procedures) that the objects
created from that class will possess. The attributes represent the characteristics or
properties of the object, while the methods define the behaviors or actions that the
object can perform.
UML Class Notation
class notation is a graphical representation used to depict classes and their
relationships in object-oriented modeling.

1. Class Name:
 The name of the class is typically written in the top compartment
of the class box and is centered and bold.
2. Attributes:
 Attributes, also known as properties or fields, represent the data
members of the class. They are listed in the second compartment
of the class box and often include the visibility (e.g., public,
private) and the data type of each attribute.
3. Methods:
 Methods, also known as functions or operations, represent the
behavior or functionality of the class. They are listed in the third
compartment of the class box and include the visibility (e.g.,
public, private), return type, and parameters of each method.
Relationships between classes
In class diagrams, relationships between classes describe how classes are
connected or interact with each other within a system. There are several types
of relationships in object-oriented modeling, each serving a specific purpose.
Here are some common types of relationships in class diagrams:

1. Association
An association represents a bi-directional relationship between two classes. It
indicates that instances of one class are connected to instances of another
class. Associations are typically depicted as a solid line connecting the classes,
with optional arrows indicating the direction of the relationship.

2. Directed Association
A directed association in a UML class diagram represents a relationship
between two classes where the association has a direction, indicating that one
class is associated with another in a specific way.
 In a directed association, an arrowhead is added to the association line
to indicate the direction of the relationship. The arrow points from the
class that initiates the association to the class that is being targeted or
affected by the association.
  Directed associations are used when the association has a specific flow
or directionality, such as indicating which class is responsible for
initiating the association or which class has a dependency on another.

3. Aggregation
Aggregation is a specialized form of association that represents a “whole-part”
relationship. It denotes a stronger relationship where one class (the whole)
contains or is composed of another class (the part). Aggregation is represented
by a diamond shape on the side of the whole class. In this kind of relationship,
the child class can exist independently of its parent class.

4. Composition
Composition is a stronger form of aggregation, indicating a more significant
ownership or dependency relationship. In composition, the part class cannot
exist independently of the whole class. Composition is represented by a filled
diamond shape on the side of the whole class.

5. Generalization(Inheritance)
Inheritance represents an “is-a” relationship between classes, where one class
(the subclass or child) inherits the properties and behaviors of another class
(the superclass or parent). Inheritance is depicted by a solid line with a closed,
hollow arrowhead pointing from the subclass to the superclass.

6. Realization (Interface Implementation)

Realization indicates that a class implements the features of an interface. It is
often used in cases where a class realizes the operations defined by an
interface. Realization is depicted by a dashed line with an open arrowhead
pointing from the implementing class to the interface.

7. Dependency Relationship
A dependency exists between two classes when one class relies on another,
but the relationship is not as strong as association or inheritance. It represents
a more loosely coupled connection between classes. Dependencies are often
depicted as a dashed arrow.

8. Usage(Dependency) Relationship
A usage dependency relationship in a UML class diagram indicates that one
class (the client) utilizes or depends on another class (the supplier) to perform
certain tasks or access certain functionality. The client class relies on the
services provided by the supplier class but does not own or create instances of
it.

How to draw Class Diagrams

Drawing class diagrams involves visualizing the structure of a system, including
classes, their attributes, methods, and relationships. Here are the steps to draw
class diagrams:
1. Identify Classes:
 Start by identifying the classes in your system. A class represents a
blueprint for objects and should encapsulate related attributes
and methods.
2. List Attributes and Methods:
 For each class, list its attributes (properties, fields) and methods
(functions, operations). Include information such as data types and
visibility (public, private, protected).
3. Identify Relationships:
 Determine the relationships between classes. Common
relationships include associations, aggregations, compositions,
inheritance, and dependencies. Understand the nature and
multiplicity of these relationships.
4. Create Class Boxes:
  Draw a rectangle (class box) for each class identified. Place the
class name in the top compartment of the box. Divide the box into
compartments for attributes and methods.
5. Add Attributes and Methods:
 Inside each class box, list the attributes and methods in their
respective compartments. Use visibility notations (+ for public, –
for private, # for protected, ~ for package/default).
6. Draw Relationships:
 Draw lines to represent relationships between classes. Use arrows
to indicate the direction of associations or dependencies. Different
line types or notations may be used for various relationships.
7. Label Relationships:
 Label the relationships with multiplicity and role names if needed.
Multiplicity indicates the number of instances involved in the
relationship, and role names clarify the role of each class in the
relationship.
8. Review and Refine:
 Review your class diagram to ensure it accurately represents the
system’s structure and relationships. Refine the diagram as needed
based on feedback and requirements.
9. Use Tools for Digital Drawing:
 While you can draw class diagrams on paper, using digital tools can
provide more flexibility and ease of modification. UML modeling
tools, drawing software, or even specialized diagramming tools
can be helpful.
1
Benefits of Class Diagrams
 Modeling Class Structure:
 Class diagrams help in modeling the structure of a system by
representing classes and their attributes, methods, and
relationships.
  This provides a clear and organized view of the system’s
architecture.
 Understanding Relationships:
 Class diagrams depict relationships between classes, such as
associations, aggregations, compositions, inheritance, and
dependencies.
 This helps stakeholders, including developers, designers, and
business analysts, understand how different components of the
system are connected.
 Communication:
 Class diagrams serve as a communication tool among team
members and stakeholders. They provide a visual and
standardized representation that can be easily understood by both
technical and non-technical audiences.
 Blueprint for Implementation:
 Class diagrams serve as a blueprint for software implementation.
They guide developers in writing code by illustrating the classes,
their attributes, methods, and the relationships between them.
 This can help ensure consistency between the design and the
actual implementation.
 Code Generation:
 Some software development tools and frameworks support code
generation from class diagrams.
 Developers can generate a significant portion of the code from the
visual representation, reducing the chances of manual errors and
saving development time.
 Identifying Abstractions and Encapsulation:
 Class diagrams encourage the identification of abstractions and
the encapsulation of data and behavior within classes.
 This supports the principles of object-oriented design, such as
modularity and information hiding.
8. Write detailed notes on test driven development.

Test Driven Development is the process in which test cases are written before
the code that validates those cases. It depends on repetition of a very short
development cycle. Test driven Development is a technique in which
automated Unit test are used to drive the design and free decoupling of
dependencies.
The following sequence of steps is generally followed:
1. Add a test – Write a test case that describe the function completely. In
order to make the test cases the developer must understand the features
and requirements using user stories and use cases.
2. Run all the test cases and make sure that the new test case fails.
3. Write the code that passes the test case
4. Run the test cases
5. Refactor code – This is done to remove duplication of code.
6. Repeat the above mentioned steps again and again

Process of tdd
 1. Red – Create a test case and make it fail
2. Green – Make the test case pass by any means.
3. Refactor – Change the code to remove duplicate/redundancy.

1. Write a Failing Test (Red):

 Identify the Requirement: Start by identifying a specific requirement or
functionality that needs to be implemented in the software.
 Write a Test Case: Write an automated test case that defines the desired
behavior or functionality. This test case should initially fail because the
corresponding code has not been implemented yet.
 Run the Test: Execute the test case to ensure that it fails. This step
confirms that the test accurately captures the desired behavior and
verifies that the required functionality is not yet implemented.
2. Write the Minimum Code to Pass the Test (Green):
 Write the Implementation Code: Write the minimum amount of code
necessary to make the failing test pass. Focus on implementing the
simplest solution that satisfies the requirements of the test case.
 Run the Test: Execute the test case again to verify that the newly written
code passes the test. The test should now pass because the
implementation code has been written to meet the requirements of the
test case.
3. Refactor the Code (Refactor):
 Improve the Code: Refactor the implementation code to improve its
design, readability, and maintainability. Ensure that the code adheres to
coding standards, follows best practices, and is well-structured.
 Run the Tests: After refactoring the code, run all existing tests to ensure
that they continue to pass. Refactoring should not change the external
behavior of the code, so all tests should pass without any modifications.
4. Repeat the Cycle:
 Write More Tests: Once the current test passes and the code is
refactored, identify the next requirement or functionality to implement
and write another failing test for it.
 Write Implementation Code: Write the minimum code necessary to pass
the new test, ensuring that all existing tests continue to pass as well.
 Refactor: Refactor the code as needed to maintain its quality and
readability while ensuring that all tests continue to pass.
 Continue Iterating: Repeat the cycle iteratively for each new
requirement or functionality, writing tests, implementing code, and
refactoring as necessary.

Benefits:
 Unit test provides constant feedback about the functions.
 Quality of design increases which further helps in proper maintenance.
 Test driven development act as a safety net against the bugs.
 TDD ensures that your application actually meets requirements defined
for it.
 TDD have very short development lifecycle.

9. Write in detail about Risk management.

10. Write in detail about Configuration management.

Configuration management (CM) is concerned with the policies, processes and

tools for managing changing software systems. You need CM because it is easy
to lose track of what changes and component versions have been incorporated
into each system version. CM is essential for team projects to control changes
made by different developers.

Configuration management activities

1. Version Management: Version management, also known as version control

or revision control, is the process of keeping track of the different versions of
system components, such as source code files, documents, and other artifacts,
throughout the software development lifecycle. The primary goals of version
management are to maintain a history of changes, facilitate collaboration
among developers, and ensure that changes made by different developers do
not interfere with each other.
Key Activities in Version Management:
 Version Identification: Assigning unique identifiers (e.g., version
numbers, revision numbers, or tags) to each version of a system
component.
 Version Control: Storing and managing different versions of system
components in a version control system (VCS), which allows developers
 to track changes, revert to previous versions, and merge changes made
by multiple developers.
 Branching and Merging: Creating branches in the version control system
to isolate development work on specific features or bug fixes, and
merging changes from one branch to another once they are completed
and tested.
 Conflict Resolution: Resolving conflicts that may arise when multiple
developers make conflicting changes to the same system component.
2. System Building: System building, also known as build management or
compilation, is the process of assembling program components, data, libraries,
and other resources, and then compiling these components to create an
executable system or software application. The system building process
typically involves various tasks such as compiling source code, linking object
files, packaging binaries, and generating documentation.
Key Activities in System Building:
 Compilation: Translating source code files written in high-level
programming languages (e.g., Java, C++) into machine-readable object
code using a compiler.
 Linking: Combining object files and libraries into a single executable or
library file, resolving external references and dependencies in the
process.
 Packaging: Bundling executable files, configuration files, libraries, and
other resources into a distributable package or installer.
 Automated Builds: Automating the system building process using build
automation tools (e.g., Apache Maven, Gradle, Make) to ensure
consistency and repeatability in the build process.
3. Change Management: Change management is the process of systematically
managing requests for changes to the software from customers, stakeholders,
and developers. The primary goal of change management is to assess the
impact of proposed changes, prioritize them based on their importance and
feasibility, and implement approved changes in a controlled and coordinated
manner.
Key Activities in Change Management:
  Change Request Management: Recording and tracking requests for
changes to the software, including bug fixes, feature enhancements, and
other modifications.
 Change Impact Analysis: Assessing the potential impact of proposed
changes on the software's functionality, performance, cost, schedule,
and other factors.
 Change Prioritization: Prioritizing change requests based on their
urgency, impact, and alignment with project objectives and priorities.
 Change Approval: Reviewing and approving proposed changes by
relevant stakeholders, such as project managers, product owners, and
customers, before implementation.
 Change Implementation: Implementing approved changes in a
controlled and coordinated manner, ensuring that they are properly
tested, documented, and deployed.
4. Release Management: Release management is the process of preparing
software for external release and managing the distribution of system versions
to customers or end-users. The primary goal of release management is to
ensure that software releases are delivered on time, with high quality, and
meet the needs and expectations of customers.
Key Activities in Release Management:
 Release Planning: Planning and scheduling software releases based on
project timelines, development milestones, and customer requirements.
 Release Packaging: Packaging software releases into distributable
packages or installers, including documentation, release notes, and other
relevant artifacts.
 Release Testing: Conducting comprehensive testing of software releases
to ensure that they meet quality standards and perform as expected in
different environments.
 Release Deployment: Deploying software releases to production or
staging environments, ensuring smooth and seamless deployment with
minimal disruption to users.
  Release Monitoring: Monitoring and tracking software releases in
production, collecting feedback from users, and addressing any issues or
defects that arise post-release.

SCM Process
It uses the tools which keep that the necessary change has been implemented
adequately to the appropriate component. The SCM process defines a number
of tasks:

o Identification of objects in the software configuration

o Version Control
o Change Control
o Configuration Audit
o Status Reporting

1. Identification of Objects in the Software Configuration:

 Description: This involves identifying and naming the various
components or artifacts that make up the software configuration. These
 components could include source code files, documentation, libraries,
configuration files, and other resources.
 SCM Process Perspective:
 Planning: Determine the scope of the software configuration and
identify the components that need to be managed.
 Identification: Assign unique identifiers (e.g., names, numbers) to
each component to facilitate tracking and management.
 Documentation: Document each identified object, including its
purpose, dependencies, and relationships with other objects.
2. Version Control:
 Description: Version control manages changes to software artifacts over
time. It involves tracking different versions of objects, recording changes
made to them, and enabling collaboration among multiple developers.
 SCM Process Perspective:
 Version Identification: Assign unique version numbers or tags to
each version of an object.
 Version Control: Record changes made to objects and store them
in a version control system (VCS).
 Branching and Merging: Use branching mechanisms to isolate
development work on specific features or bug fixes, and merge
changes from different branches.
3. Change Control:
 Description: Change control manages requests for changes to the
software configuration. It involves evaluating, approving, implementing,
and documenting changes while minimizing disruption and maintaining
stability.
 SCM Process Perspective:
 Change Request Management: Record and track requests for
changes, including bug fixes, feature enhancements, and
modifications.
  Change Impact Analysis: Assess the potential impact of proposed
changes on the software configuration.
 Change Approval: Review and approve changes before
implementation to ensure alignment with project objectives.
 Change Implementation: Implement approved changes in a
controlled manner, ensuring proper testing and documentation.
4. Configuration Audit:
 Description: Configuration audit ensures that the software configuration
complies with specifications and standards. It involves reviewing all
components and configurations to verify correctness and completeness.
 SCM Process Perspective:
 Regular Audits: Conduct regular audits to verify that the software
configuration matches the expected state.
 Documentation Review: Review documentation to ensure it
accurately reflects the current configuration.
 Corrective Actions: Take corrective actions to address any
discrepancies or non-compliance identified during the audit.
5. Status Reporting:
 Description: Status reporting provides updates on the state of the
software configuration, including changes made, current versions, and
any issues or progress.
 SCM Process Perspective:
 Regular Updates: Provide regular updates to stakeholders on
changes made to the software configuration.
 Issue Tracking: Report any issues or problems encountered during
configuration management activities.
 Progress Tracking: Track progress on configuration management
tasks and milestones, such as audits and releases.