Mixed

# Reason of studying SWE

Career opportunities: SWE is a highly in-demand field, and studying it can open up a wide range
of job opportunities. Many industries require software engineers, from tech companies to
healthcare, finance, and more.

Solving problems: Software engineering provides a structured approach to problem-solving.

Studying SWE gives you the tools to design and build complex software systems to solve real-
world problems.

Innovating: SWE is a constantly evolving field, with new technologies and techniques emerging
all the time. Studying SWE allows you to stay up to date with the latest developments and
contribute to innovation.

Collaboration: SWE involves working in teams to develop software systems. Studying SWE
equips you with the skills to work collaboratively with others, including communication, project
management, and leadership skills.

Personal growth: Studying SWE challenges you to think critically and creatively, and to develop
problem-solving and analytical skills. It can also provide a sense of accomplishment and
satisfaction when you successfully design and implement software systems.

# Principles in SWE
There are several key principles in software engineering (SWE) that guide the design and
development of software systems. Some of the most important principles include:

Modularity: This principle involves breaking a software system down into smaller, independent
components, or modules. Each module should have a specific responsibility, and be able to
function independently of other modules.

Abstraction: Abstraction involves hiding unnecessary details of a system from the user, and
providing a simplified, high-level view of the system. This makes it easier for users to interact
with the system, and reduces the complexity of the underlying code.

Encapsulation: This principle involves grouping related data and functionality together, and
restricting access to that functionality to specific parts of the system. Encapsulation helps to
ensure that data is used and manipulated correctly, and can make code more modular and
easier to maintain.

Separation of Concerns: This principle involves dividing a software system into different parts,
each of which handles a specific concern or responsibility. This can make code easier to
understand and maintain, and can also make it easier to develop and test specific parts of the
system in isolation.

Open/Closed Principle: This principle states that software components should be open for
extension, but closed for modification. This means that existing code should not be modified to
add new functionality, but rather new functionality should be added through extension.
Single Responsibility Principle: This principle states that each module or component should
have a single, well-defined responsibility. This makes it easier to understand and maintain code,
and can also improve modularity and reusability.

By following these principles and others, software engineers can design and develop software
systems that are reliable, maintainable, and scalable, and that meet the needs of users and
stakeholders.

# SDLC: components, brief explanation

SDLC stands for Software Development Life Cycle. It is a process followed by software
development teams to design, develop, test, and deploy high-quality software products. SDLC is
a structured approach to software development, which involves several stages or phases. The
components of SDLC include:

Planning: In this phase, the project goals and requirements are defined, and the scope of the
project is established. The project team creates a plan and determines the resources, timeline,
and budget required for the project.

Analysis: In this phase, the project team analyzes the requirements and identifies any potential
issues or challenges. They also gather information about the users and stakeholders, and
develop a detailed understanding of the system requirements.

Design: In this phase, the project team designs the system architecture and develops a detailed
plan for the software product. This includes creating a design specification document, which
outlines the software system's components, interfaces, and functionality.
Implementation: In this phase, the project team develops the software code and implements the
design. They also conduct unit tests to ensure that each component of the system works as
intended.

Testing: In this phase, the project team tests the software product to ensure that it meets the
requirements and functions as intended. This includes conducting integration testing,
performance testing, and user acceptance testing.

Deployment: In this phase, the software product is deployed or released to users. The project
team ensures that the software is installed correctly and that users are able to access and use it
effectively.

Maintenance: In this phase, the software product is maintained and updated as needed. This
includes fixing bugs, updating features, and addressing any issues that arise over time.

By following the SDLC process, software development teams can ensure that the software
products they develop are high-quality, reliable, and meet the needs of users and stakeholders.

# Conflicts which arise during requirement engineering. Solution, advantages of solve.

Requirement engineering is a critical phase in the software development life cycle that involves
gathering, analyzing, and documenting requirements for a software system. During this process,
conflicts may arise due to differences in stakeholder expectations, priorities, and constraints.
Some common conflicts that can arise during requirement engineering include:

Conflicts between stakeholders: Different stakeholders may have conflicting requirements or

priorities, which can create tension and disagreements.

Conflicts between functionality and feasibility: Stakeholders may request functionality that is
not feasible or practical given technical constraints, resource limitations, or other factors.

Conflicts between requirements and cost: Stakeholders may request requirements that are
not financially feasible, given the available budget or resources.

To address these conflicts, the requirement engineering team may need to engage in
negotiation, compromise, and trade-offs. Some strategies that can help resolve conflicts include:

Prioritization: Stakeholders can prioritize their requirements based on their importance,

urgency, or impact on the system.

Requirements trade-off: Teams can negotiate and make trade-offs between conflicting
requirements to find a balance between different stakeholder needs.

Requiring more information: Teams can gather additional information and data to help
stakeholders understand the potential implications of their requirements.

The advantages of resolving conflicts during requirement engineering include:

Improved stakeholder satisfaction: By addressing conflicts and finding a satisfactory

resolution, stakeholders are more likely to be satisfied with the final product.
Better project outcomes: Resolving conflicts helps ensure that the final software system
meets stakeholder needs and expectations, leading to better outcomes.

Reduced rework: By addressing conflicts early in the process, teams can reduce the need for
later rework, which can save time and resources.

Overall, addressing conflicts during requirement engineering is essential for developing a

successful software system that meets stakeholder needs and expectations.

# Responsibility & necessity of a good project manager.

A project manager is a key figure in any software development project, responsible for
overseeing the entire project from start to finish. A good project manager is essential for the
success of the project, and has several important responsibilities and roles.

Some of the key responsibilities and necessity of a good project manager are:

Planning: A project manager is responsible for developing a detailed project plan that outlines
the project scope, timelines, milestones, budget, resources, and deliverables. The project plan
serves as a roadmap for the project team and helps ensure that the project stays on track.

Communication: A project manager is responsible for communicating project goals, status

updates, and requirements to all stakeholders, including the project team, clients, and
management. Effective communication helps ensure that everyone is on the same page and
understands their roles and responsibilities.

Risk management: A project manager is responsible for identifying potential risks and
developing strategies to mitigate or avoid them. This involves anticipating potential issues and
developing contingency plans to address them if they arise.

Resource management: A project manager is responsible for allocating resources, including

personnel, budget, and equipment, to ensure that the project is completed on time and within
budget.

Team management: A project manager is responsible for leading and managing the project
team, including assigning tasks, providing feedback, and addressing any issues that arise.

Quality control: A project manager is responsible for ensuring that the project meets the
required quality standards, by establishing quality metrics and conducting quality assurance
testing.

In summary, a good project manager is critical for the success of a software development
project. They are responsible for planning, communicating, managing risks and resources,
leading and managing the project team, and ensuring that the project meets the required quality
standards.

# necessity of software project planning

Software project planning is crucial because it helps to ensure the success of a software project
by identifying and managing risks, establishing clear objectives and goals, and creating a
roadmap for the project. Here are some specific reasons why software project planning is
necessary:

Clarifies Objectives: Planning helps to clarify the objectives of a software project, which in turn
helps to ensure that everyone involved in the project understands what is expected of them.
This clarity helps to reduce confusion and prevent misunderstandings that could derail the
project.

Identifies Risks: Planning allows project managers to identify potential risks and challenges
that could impact the success of the project. This enables them to develop strategies for
managing these risks and mitigating their impact on the project.

Helps to Manage Resources: Planning enables project managers to allocate resources more
effectively, including people, time, and budget. This helps to ensure that the project is
completed on time and within budget.

Provides a Roadmap: Planning provides a roadmap for the project, outlining the tasks that
need to be completed and the timeline for completing them. This helps to keep the project on
track and ensures that everyone involved knows what is expected of them.

Facilitates Communication: Planning facilitates communication between team members and

stakeholders, ensuring that everyone is on the same page and working towards the same goals.
This helps to prevent misunderstandings and promotes collaboration.

In summary, software project planning is necessary because it helps to ensure the success of a
software project by clarifying objectives, identifying risks, managing resources, providing a
roadmap, and facilitating communication.

# advantages and disadvantages of good quality software

Disadvantages of good quality software

Advantages of good quality software

Customer satisfaction Higher development costs

Increased user productivity Longer development time

Improved reliability and stability More rigorous testing and quality assurance
 Better maintainability and support May require specialized skills or resources

Enhanced security and reduced vulnerabilities Possible limitations on functionality or performance

Higher market competitiveness Higher demands for continuous improvement and updates

Greater customer loyalty and referrals Increased complexity and management overhead

# Known Risks vs Predictable risks

Known risks and predictable risks are both types of risks that can affect a project, but they differ
in terms of their likelihood and impact.

Known Risks:
Known risks are risks that are already identified and documented, and for which mitigation
strategies have been developed. These risks are typically based on historical data, experience,
and previous projects. Known risks are relatively more likely to occur and can have a moderate
to significant impact on the project. Examples of known risks include resource constraints,
changes in requirements, and technology limitations.

Predictable Risk:
Predictable risks, on the other hand, are risks that are not yet identified but can be anticipated
based on the project context and characteristics. Predictable risks are less likely to occur than
known risks, but they can have a significant impact on the project if they do occur. Examples of
predictable risks include unexpected changes in regulations or standards, sudden changes in
the market or competition, and natural disasters or other external factors that can affect the
project.

To summarize, known risks are those that have already been identified and can be managed
with mitigation strategies, while predictable risks are those that can be anticipated but have not
yet been identified. Both types of risks are important to consider when planning a project and
developing a risk management strategy.

# Development Speed vs Product Quality

Development speed and product quality are two important factors in software development, and
striking a balance between them is essential for the success of a project.

Development Speed:
Development speed refers to the rate at which a software product is developed and released to
the market. In some cases, speed may be a critical factor, especially in highly competitive
markets where being first to market can provide a significant advantage. However, prioritizing
development speed over product quality can result in a product that is not fully tested, is prone
to bugs and errors, and may not meet customer needs.

Product quality refers to how well a software product meets customer needs and expectations,
as well as how reliable and stable the product is. High-quality software is essential for building
customer loyalty, maintaining market competitiveness, and avoiding costly rework and
maintenance. However, prioritizing product quality over development speed can lead to longer
development times, higher development costs, and potential delays in product releases.

To strike a balance between development speed and product quality, software development
teams must carefully manage their development process, prioritize critical features and
functionality, and ensure that quality assurance and testing processes are rigorous and
effective. This can help to reduce development time and costs while still delivering a high-quality
product that meets customer needs and expectations.

# Software process, steps

The software process is a structured set of activities that are used to design, develop, and
maintain software. It typically (সাধারনত) consists of the following steps:

Requirements Gathering: This involves gathering the requirements for the software system from
stakeholders and users. The requirements help define the scope and goals of the software
system.

Analysis and Specification: This step involves analyzing the requirements and defining a
detailed specification for the software system. The specification includes details such as system
architecture, user interfaces, and functionality.

Design: In this step, the system architecture and software design are created. The design
includes details such as data structures, algorithms, and the overall system structure.

Implementation: This step involves writing the code and building the software system. The
software is typically built in multiple iterations, with each iteration adding new functionality.

Testing: This step involves testing the software system to ensure that it meets the requirements
and works correctly. Testing can be automated or manual, and it includes activities such as unit
testing, integration testing, and system testing.

Deployment: This step involves deploying the software system to the production environment.
This may involve installing the software on servers, configuring it, and training users.

Maintenance: Once the software system is deployed, it requires ongoing maintenance and
support. This involves fixing bugs, adding new features, and updating the system to keep it
current with changing user needs and technology.

These steps are often iterative and overlap with each other. For example, testing may reveal
issues with the design or implementation that require changes to the requirements or design.
Effective software development requires a flexible approach that can adapt to changing needs
and requirements over time.

# Potential Classes
The potential classes in an application depend on the requirements and functionality of the
application. Here are some examples of potential classes in different types of applications:

E-commerce application: User, Product, Order, Shopping Cart, Payment, Shipping

Social media application: User, Post, Comment, Like, Follower, Following

Banking application: Account, Transaction, Customer, Loan, Bank, Branch

Game application: Player, Game, Level, Score, Power-up, Enemy

Healthcare application: Patient, Doctor, Appointment, Prescription, Medical Record, Insurance

These are just a few examples, and the actual classes required for an application will depend on
the specific needs and functionality of that application. A well-designed class structure is
important for creating a maintainable, scalable, and easily understandable application.

# Taste Case
A test case is a set of conditions or variables under which a tester will determine whether an
application or system under test satisfies requirements and works correctly.

# white box testing vs black box testing vs gray box testing

White box testing, black box testing, and gray box testing are different types of software testing
methods used in software engineering.

White box testing:

White box testing, also known as clear box testing, involves testing the internal structure and
code of a software system. The tester has access to the source code and the internal workings
of the system and can design test cases based on that knowledge. This type of testing is often
used to test software modules and components at the unit level to ensure they meet the
expected requirements.

Black box testing, also known as functional testing, involves testing the software system from an
external perspective, without knowledge of the internal workings or source code. The tester
designs test cases based on the system's specifications or requirements and evaluates the
system's behavior and output against those requirements. This type of testing is often used to
test the system as a whole and validate that it meets the functional requirements.

Gray box testing is a combination of white box and black box testing. The tester has partial
knowledge of the internal workings of the system, such as the database schema or application
programming interface (API). This type of testing is often used to test the integration of different
components of a software system and to validate that they are working together correctly.

In summary, white box testing involves testing the internal structure and code of a system, black
box testing involves testing the system from an external perspective, and gray box testing
involves a combination of the two. Each method has its own strengths and weaknesses and is
used in different situations depending on the software testing goals and requirements.

# Risk Table: def, creating for given project idea

A risk table in software engineering is a tool that lists potential risks, their likelihood (সম্ভাবনা) of
occurrence, and their potential impact on a project or system. The scores are then used to
calculate a priority or risk level for each risk. This helps project managers and developers
identify and prioritize risks and take appropriate actions to mitigate or manage them.

# browser compatibility testing, types of quality factors

Browser compatibility testing is a type of software testing that ensures that a website or web
application is displayed and functions correctly across different web browsers, versions, and
devices.

The following are some common types of quality factors that software engineering teams
consider when developing and testing software products:

Functionality: The software must meet the functional requirements specified by the client or end-
users.
Usability: The software must be easy to use, navigate, and understand for the intended users.
Performance: The software must be able to perform efficiently and respond quickly to user
interactions and inputs.
Security: The software must be secure and protect against unauthorized access, attacks, and
data breaches.
Compatibility: The software must be compatible with different hardware, software, and
platforms.
Reliability: The software must be reliable and perform consistently without errors or crashes.
Maintainability: The software must be easy to maintain, update, and modify when required.
Portability: The software must be portable and able to run on different platforms and
environments.
Browser compatibility testing falls under the compatibility quality factor. Other examples of
compatibility testing include testing software compatibility with different operating systems,
devices, or third-party applications.

Each quality factor plays an essential role in ensuring that software products are of high quality
and meet the expectations of end-users. By considering and testing these quality factors,
software engineering teams can create reliable, efficient, and user-friendly software products.

# functions of system analysts, methods of system analysts

Functions of System Analysts:
System analysts are responsible for analyzing and designing information systems to solve
specific business problems. They work closely with end-users, stakeholders, and technical
teams to gather requirements, design and develop solutions, and implement and maintain
information systems. Some of the key functions of system analysts include:

Requirements gathering: System analysts identify and collect business requirements from end-
users and stakeholders to develop a clear understanding of the problem domain and solution
objectives.
Analysis and design: System analysts analyze the requirements, identify information flows,
develop system models and design documents, and propose solutions that meet the business
needs.

Development and testing: System analysts work with development teams to implement and test
the proposed solution to ensure that it meets the requirements and specifications.

Implementation and maintenance: System analysts work with end-users and stakeholders to
deploy the solution and provide ongoing support and maintenance to ensure that it remains
functional and relevant.

Methods of System Analysts:

System analysts use a variety of methods to analyze and design information systems,
depending on the project objectives, scope, and complexity. Some of the most common
methods used by system analysts include:

Interviews: System analysts conduct interviews with end-users and stakeholders to gather
requirements, identify problems, and validate proposed solutions.

Questionnaires and surveys: System analysts use questionnaires and surveys to collect
information from large groups of end-users and stakeholders.

Observation: System analysts observe users and business processes to identify inefficiencies
and areas for improvement.

Prototyping: System analysts create prototypes of information systems to test design concepts
and validate requirements.

Data modeling: System analysts use data modeling techniques to design the structure and
relationships of the data used by an information system.

Business process modeling: System analysts use business process modeling techniques to
design and analyze business processes to identify areas for improvement.

Overall, system analysts play a critical role in the development of information systems, from
requirements gathering and analysis to system design, development, and implementation. They
use a variety of methods and tools to ensure that information systems meet the needs of end-
users and stakeholders and provide value to the organization.

# writing user scenario

Short Notes
# Reliability, Security, Downtime
Reliability: This refers to the ability of a software system to perform its intended function
correctly and without errors over an extended period of time. Reliability is a crucial factor in
ensuring that software functions as intended and that users can trust it.
Security: Security in software refers to the ability of a software system to protect its data and
users from unauthorized access, unintended harm, or destruction. Security is an important
aspect of software to protect the integrity and confidentiality of users and data.

Downtime: Downtime refers to the time during which a software system or IT infrastructure is
unavailable or not functioning due to planned or unplanned events that may include updates,
errors, or system crashes. Downtime can cause significant losses in productivity and revenue
for businesses, so it's important to minimize its effects and ensure quick recovery in the event of
an incident.

# System testing
System testing is a type of software testing that evaluates the entire system or application as a
whole to ensure it meets the specified requirements and functions as expected. It is performed
after integration testing and before acceptance testing. The testing may include functional, non-
functional, and regression testing to identify defects and issues in the system before it is
released to end-users. The results are documented and used to prioritize and fix issues.

# Error, bugs and faults

Error, bugs, and faults are related concepts in software engineering that refer to different types
of defects in software systems:

Error: An error is a human action or decision that produces an incorrect or unexpected result. It
is a mistake made during the development process that can cause a software defect or bug.

Bug: A bug is a defect in the software that causes it to behave in an unintended way or
produces incorrect results. Bugs can be caused by errors in the code, design, or requirements.

Fault: A fault is a defect in the software that causes it to fail to perform its intended function.
Faults can be caused by bugs, errors, or external factors such as hardware failures or
environmental conditions.

In general, an error is a mistake made by a human, while a bug is a result of that mistake that
causes the software to malfunction. A fault is a broader term that encompasses both errors and
bugs and refers to any defect that causes the software to fail. Identifying and fixing errors, bugs,
and faults is an important part of software development to ensure that the software performs as
intended and meets user expectations.

Requirements Engineering
10-16: Software Engineering Bangla Tutorial (Course Completed) - YouTube

# Normal, Expected & Exciting Requirements: def, finding

Normal, expected, and exciting requirements are terms used in software engineering to
describe different types of software requirements:

Normal Requirements: Normal requirements are the basic or essential requirements that a
software system must meet to function properly. These requirements are often specified in the
system's functional specifications and describe the core features and functions of the software.
Expected Requirements: Expected requirements are requirements that are not strictly
necessary for the software to function properly, but are still important for the software to meet
user expectations. These requirements are often specified in the system's non-functional
specifications and may include performance, reliability, and security requirements.

Exciting Requirements: Exciting requirements are requirements that are not essential for the
software to function properly or meet user expectations, but are included to make the software
more appealing or enjoyable to use. These requirements may include features that are unique,
innovative, or fun.

By categorizing requirements into normal, expected, and exciting requirements, software

developers can prioritize their efforts and resources to ensure that the core features and
functions of the software are developed first, followed by the important non-functional
requirements, and then the exciting features that can set the software apart from competitors.

# Seven functions of requirements engineering: Elicitation, Analysis, Specification, Verification,

Validation, Management, Evolution
Elicitation: The process of gathering requirements from stakeholders, users, and other sources.

Analysis: The process of analyzing, organizing, and prioritizing the requirements to ensure they
are complete, unambiguous, and consistent.

Specification: The process of documenting the requirements in a clear and concise manner,
typically in a requirements document or specification.

Verification: The process of ensuring that the requirements have been implemented correctly
and meet their intended purpose.

Validation: The process of ensuring that the requirements accurately reflect the needs and
expectations of the stakeholders and users.

Management: The process of tracking and controlling changes to the requirements throughout
the software development lifecycle.

Evolution: The process of continuously reviewing and updating the requirements as the software
evolves and new information becomes available.

By following these seven functions of requirements engineering, software developers can

ensure that the software system meets the needs and expectations of its stakeholders and
users, and is developed and maintained in a controlled and effective manner.

# Functional and Non-functional requirements: finding, describing

Functional and non-functional requirements are two types of software requirements that
describe different aspects of a software system:

Functional Requirements: Functional requirements describe what the software system must do
in order to meet the needs and expectations of its users. These requirements typically describe
the features, functions, and behaviors of the system, and are often specified in use cases or
user stories. Examples of functional requirements might include:
The software must allow users to log in and create an account
The software must be able to search and display a list of products
The software must be able to process transactions and payments
Non-functional Requirements: Non-functional requirements describe how the software system
should perform, and often describe qualities such as performance, reliability, and usability.
These requirements are typically specified in a separate set of documents from functional
requirements, and are often grouped into categories such as performance, security, and
accessibility. Examples of non-functional requirements might include:
The software must be able to handle a large number of concurrent users
The software must be available 99.9% of the time
The software must be compatible with all major web browsers

In general, functional requirements describe what the software must do, while non-functional
requirements describe how the software should do it. Both types of requirements are important
for ensuring that the software system meets the needs and expectations of its users, and are
essential for effective software development and testing.
# Finding requirements with QFD
Quality Function Deployment (QFD) is a method used to translate customer needs and
expectations into technical requirements for a product or service. QFD can be used to identify
and prioritize requirements by mapping customer needs and expectations to product features,
and then determining the technical requirements necessary to meet those needs.

The basic steps involved in using QFD to find requirements are:

Identify customer needs: The first step in using QFD is to identify the customer needs that the
product or service must satisfy. This can be done through surveys, focus groups, or other
methods of gathering customer feedback.

Develop a House of Quality (HOQ): The HOQ is a matrix that maps customer needs to product
features and technical requirements. Each row of the HOQ represents a customer need, and
each column represents a product feature or technical requirement. The cells of the matrix are
filled in with numerical ratings that indicate the importance of each feature or requirement in
satisfying each customer need.

Prioritize requirements: Once the HOQ has been developed, the next step is to prioritize the
requirements. This is typically done by calculating a weighted score for each requirement,
based on its importance in satisfying customer needs and the feasibility of implementing it.

Identify trade-offs: QFD can also be used to identify trade-offs between requirements, and to
help stakeholders make informed decisions about which requirements to prioritize. This can be
done by analyzing the relationships between the requirements and identifying areas where
trade-offs may need to be made.

By using QFD to identify and prioritize requirements, product development teams can ensure
that they are building products and services that meet the needs and expectations of their
customers, while also being feasible and cost-effective to implement.

# Collaborative Requirements Prioritization

Collaborative requirements prioritization is a technique that involves gathering input and
feedback from various stakeholders in order to prioritize requirements for a software system.
This approach recognizes that different stakeholders may have different priorities and
perspectives on the importance of various requirements, and seeks to create a consensus on
which requirements should be given higher priority.

The basic steps involved in collaborative requirements prioritization are:

Identify stakeholders: The first step is to identify the stakeholders who will be involved in the
prioritization process. These may include business analysts, developers, end-users, and other
stakeholders who have a vested interest in the software system.

Gather requirements: The next step is to gather all of the requirements for the system. This may
involve reviewing documentation, conducting interviews with stakeholders, and other methods
of gathering input.
Prioritize requirements: Once all of the requirements have been gathered, the next step is to
prioritize them. This may involve creating a matrix or chart that allows stakeholders to rate each
requirement on a scale of importance.

Facilitate discussions: As stakeholders rate the requirements, it may become clear that there
are differing opinions on the importance of certain requirements. In these cases, it is important
to facilitate discussions among stakeholders to help them understand each other's perspectives
and come to a consensus on the importance of each requirement.

Refine priorities: As stakeholders work through the prioritization process, it may become clear
that some requirements are more important than others. In these cases, it may be necessary to
refine the priorities and adjust the rankings to reflect the consensus of the group.

Document results: Once the prioritization process is complete, it is important to document the
results and share them with all stakeholders. This helps ensure that everyone is on the same
page and understands the priorities for the software system.

By using a collaborative approach to requirements prioritization, software development teams

can ensure that they are building software systems that meet the needs and expectations of all
stakeholders, while also being feasible and cost-effective to implement.

Diagrams
# Use case, Class, Swimlane, Activity, Data Flow, ERD, State, Sequence
# Flow Graph
# UML: diagram, implementation, code, uses area
—-----------------------------------------------------------------------

These are different types of diagrams used in software engineering to represent various aspects
of a system or process:

Use case diagram: A use case diagram is a type of behavioral diagram that shows the
interactions between actors and a system. It illustrates the use cases, actors, and their
relationships.

Class diagram: A class diagram is a type of structural diagram that shows the classes,
interfaces, and their relationships. It depicts the static structure of a system and the objects in
the system.

Swimlane diagram: A swimlane diagram is a type of process flow diagram that displays the
flow of activities and responsibilities of multiple participants or departments involved in a
process. It divides the process into lanes, each representing a specific participant or
department.

Activity diagram: An activity diagram is a type of behavioral diagram that shows the flow of
activities in a system. It depicts the activities, actions, and decisions involved in a process or
workflow.
Data flow diagram: A data flow diagram is a type of flowchart that illustrates the flow of data
through a system. It shows how data is input, processed, and output within a system or process.

ERD diagram: An Entity-Relationship Diagram (ERD) is a type of data modeling diagram that
shows the relationships between entities in a system. It depicts the relationships between data
objects and their attributes.

State diagram: A state diagram is a type of behavioral diagram that shows the states and
transitions of an object or system. It depicts the behavior of an object or system in response to
external events or internal conditions.

Sequence diagram: A sequence diagram is a type of interaction diagram that shows the
interactions between objects or components in a system. It depicts the sequence of messages
exchanged between objects or components to achieve a specific goal or behavior.

SRS
# UML Class Diagram
Software Process Models
# Software Process Models: Def, determine
Waterfall (examples), agile (when should use & not use), spiral, v-model, incremental,
iterative, rapid action development 

Design Pattern
# reason of studying design pattern
There are several reasons why it is important for software developers and engineers to study
design patterns:

Reusability: Design patterns provide proven solutions to common software design problems that
can be reused in different contexts. This saves time and effort by reducing the need to reinvent
the wheel for every new project.

Maintainability: Design patterns promote maintainable code by providing a common language

and structure that helps developers understand and modify existing code more easily.

Scalability: Design patterns help developers design software systems that can scale with
changing requirements and increasing complexity. They provide a flexible and adaptable
framework that can be modified to meet evolving business needs.
Collaboration: Design patterns provide a common language and structure that helps developers
collaborate more effectively on software projects. This improves communication and reduces
the risk of misunderstandings and errors.

Best practices: Design patterns are based on proven best practices and principles of software
design, such as abstraction, encapsulation, and separation of concerns. Studying design
patterns can help developers learn and apply these principles to their own software design.

Overall, studying design patterns helps software developers and engineers become more
effective at designing, building, and maintaining software systems that are scalable,
maintainable, and reusable. It provides a common language and framework for collaboration,
and promotes the use of best practices and proven solutions to common software design
problems.

# singleton pattern
The Singleton pattern is a design pattern that ensures only one instance of a class exists in an
application. This is achieved by making the class constructor private and creating a static
method that checks if an instance already exists before creating a new one.

The Singleton pattern can improve performance, encapsulate implementation details, and
provide a single point of access to an object. However, it can also make testing more difficult
and introduce concurrency issues.

Overall, the Singleton pattern can be useful in some situations but should be used carefully and
with an understanding of its potential drawbacks.

# MVC Design pattern: example, code

# Potential Classes with CRC class cards

Class Responsibility Collaboration (CRC) cards are a design technique used to describe the
classes in an object-oriented program. Here are some potential classes with their corresponding
CRC class cards:

User
Responsibilities:
Authenticate login credentials
Manage personal information
Interact with other users

Collaborators:
Product
Order
Payment
Shopping Cart
Account

Responsibilities:
Store and manage account information
Process transactions
Generate reports
Collaborators:
Transaction
Customer
Bank
Loan
Post

Responsibilities:
Create and manage posts
Interact with other posts
Display information to users

Collaborators:
User
Comment
Like
Follower
Appointment
Responsibilities:

Schedule appointments
Send reminders
Manage availability

Collaborators:
Patient
Doctor
Medical Record
Prescription
Game

Responsibilities:
Manage game play
Keep track of score
Interact with players

Collaborators:
Player
Level
Power-up
Enemy
These are just a few examples, and the actual classes required for an application will depend on
the specific needs and functionality of that application. The CRC class cards are a useful
technique for brainstorming and discussing the design of classes in an object-oriented program.

# GRASP, relation between GRASP and pattern, 5 GRASP patterns

GRASP is an acronym for General Responsibility Assignment Software Patterns. It is a
collection of design principles and patterns used in object-oriented software design to identify
and assign responsibilities to objects.
The relationship between GRASP and patterns is that GRASP patterns are a subset of design
patterns. They provide a set of guidelines and principles for assigning responsibilities to objects,
which helps to create more maintainable, reusable, and scalable software solutions.

The following are five common GRASP patterns:

Creator: The Creator pattern identifies the object that is responsible for creating another object.
This helps to ensure that object creation is encapsulated and objects are created correctly.

Controller: The Controller pattern identifies the object that is responsible for managing the flow
of communication and coordination between objects. This helps to ensure that objects are
properly synchronized and that the system behaves correctly.

Information Expert: The Information Expert pattern identifies the object that has the most
information or knowledge needed to perform a particular task. This helps to ensure that objects
are responsible for the information they possess and reduces coupling between objects.

Low Coupling: The Low Coupling pattern identifies the object that is responsible for reducing the
dependencies between objects. This helps to ensure that objects are loosely coupled and
changes to one object do not affect other objects in the system.

High Cohesion: The High Cohesion pattern identifies the object that is responsible for ensuring
that objects are designed with a clear and single responsibility. This helps to ensure that objects
are cohesive and that their behavior is clear and easy to understand.

Overall, GRASP patterns help to create more effective and maintainable software solutions by
assigning responsibilities to objects and reducing dependencies between objects. By using
these patterns, developers can design software systems that are more flexible, scalable, and
easier to maintain.

# OO design, pattern in OO design

# Other Design Patterns