SAQs

1. Define any 3 principles of modelling developing use cases.

When developing use cases for modelling purposes, several principles guide the process
to ensure effectiveness and accuracy. Here are three key principles:

1. Clarity and Precision: Use cases should be clear and precise, providing
unambiguous descriptions of system interactions and functionalities. Ambiguity
can lead to misunderstandings and misinterpretations, which can result in errors
in system design and implementation.
2. Relevance and Realism: Use cases should accurately represent the system's
intended functionality and the users' real-world interactions with it. They should
focus on the most critical and relevant aspects of the system, avoiding unnecessary
details.
3. Modularity and Completeness: Break down complex systems into smaller,
manageable modules or components represented by individual use cases. Each
use case should encapsulate a specific user goal or functionality, making it easier
to understand, implement, and test.

2. What is requirement analysis?

Requirement analysis is a critical phase in the software development lifecycle that
involves gathering, documenting, and analysing requirements for a software system. It's
the process of understanding and defining what a software system should accomplish
and how it should behave to meet the needs of its users or stakeholders.
3. Define:
a. specifying attributes
specifying attributes refers to defining and documenting characteristics or properties of
software components, modules, or systems. These attributes provide detailed
information about the behaviour, performance, quality, and other relevant aspects of the
software, aiding in its development, evaluation, and maintenance. Specifying attributes
helps ensure that software meets the desired standards, requirements, and expectations
of stakeholders.
b. analysis packages
analysis packages refer to sets of related functionalities or components within a software
system that are grouped together for the purpose of analysis and design. These packages
are organized based on logical or functional relationships between the components they
contain, and they help manage the complexity of large software systems by breaking them
down into smaller, more manageable units.
4. What are class-based components?
class-based components refer to a programming paradigm commonly used in object-
oriented programming (OOP) languages like Java, C++, and Python. In this paradigm,
software components are organized into classes, which are templates for creating objects.
Each class defines the properties (attributes) and behaviours (methods) that objects of
that class can exhibit.
5.Define user interface design rules.
User interface (UI) design rules are guidelines and principles that govern the creation of
effective and user-friendly interfaces for software applications, websites, or any
interactive system. These rules help designers create interfaces that are intuitive, visually
appealing, and easy to use, enhancing the overall user experience. Here are some common
UI design rules:
Consistency, Simplicity, Visibility, Feedback, Hierarchy, Navigation, Accessibility,
Flexibility, Error Handling, User Testing.
LAQs
1. Define requirements engineering and explain the groundwork and eliciting
requirements in detail.
Requirements engineering is a systematic process within software engineering that
involves eliciting, analysing, documenting, and managing requirements for a software
system. The primary goal of requirements engineering is to understand and define what
the stakeholders expect from the software system and to translate those expectations
into a clear and unambiguous set of requirements that guide the development process.

1. Groundwork in Requirements Engineering:

a. Stakeholder Identification: Identify and involve all relevant stakeholders who
have an interest or influence in the software project. Stakeholders may include
end-users, customers, business analysts, domain experts, developers, testers, and
project managers.
b. Understanding the Domain: Gain a comprehensive understanding of the
domain in which the software system will operate. This involves studying the
business processes, industry standards, regulations, and constraints that may
impact the requirements and design of the system.
c. Establishing Communication Channels: Establish effective communication
channels between the development team and stakeholders to facilitate the
exchange of information and feedback throughout the requirements engineering
process. This may involve holding meetings, workshops, interviews, or using
collaboration tools.
d. Defining Scope and Objectives: Define the scope and objectives of the
software project to establish clear boundaries and goals for the requirements
engineering process. Identify the high-level features and functionalities that the
software system is expected to deliver.
2. Eliciting Requirements:
a. Stakeholder Engagement: Engage with stakeholders to gather their
perspectives, needs, expectations, and constraints related to the software system.
This may involve conducting interviews, surveys, focus groups, or workshops to
elicit requirements directly from stakeholders.
b. Observation and Ethnography: Observe users in their natural environment to
understand how they currently work and identify opportunities for improvement.
 Ethnographic techniques such as contextual inquiry or shadowing can provide
valuable insights into users' behaviours, goals, and pain points.
c. Prototyping and Mock-ups: Create prototypes or mock-ups of the software
system to stimulate discussions and gather feedback from stakeholders.
Prototypes help stakeholders visualize the proposed solution and provide
concrete examples for discussion and refinement.
d. Document Analysis: Analyse existing documentation such as business
documents, user manuals, requirements specifications, or system documentation
to extract relevant requirements and insights about the software system.
e. Brainstorming: Facilitate brainstorming sessions with stakeholders to
generate new ideas, explore alternative solutions, and uncover hidden
requirements. Brainstorming encourages creative thinking and collaboration
among stakeholders.
f. Questionnaires and Surveys: Distribute questionnaires or surveys to a wide
audience of stakeholders to gather quantitative data about their preferences,
priorities, and requirements for the software system. Surveys can reach a larger
audience and provide valuable input for decision-making.
g. Use Cases and Scenarios: Develop use cases, scenarios, or user stories to
describe how users will interact with the software system in different situations.
Use cases help capture functional requirements and illustrate the system's
behaviour from the user's perspective.

3. Explain the UML models in detail.

Unified Modelling Language (UML) is a standardized modelling language used in
software engineering to visually represent software systems.
1. Use Case Diagrams:
• Use case diagrams depict the interactions between actors (users or
external systems) and the system under consideration.
• Actors are represented as stick figures, and use cases are represented as
ovals.
• Relationships between actors and use cases are shown with lines
indicating associations or dependencies.
• Use case diagrams help identify the functional requirements of the system
and define the system's boundaries and scope.
2. Class Diagrams:
• Class diagrams represent the static structure of the system by depicting
classes, their attributes, methods, and relationships.
• Classes are represented as rectangles with three compartments: class
name, attributes, and methods.
• Relationships between classes, such as associations, generalizations,
aggregations, and compositions, are depicted with lines connecting the
classes.
• Class diagrams help visualize the system's data model and the
relationships between different classes in the system.
3. Sequence Diagrams:
• Sequence diagrams illustrate the interactions between objects or
components over time in a particular scenario or use case.
 • Objects are represented as rectangles, and the interactions between them
are depicted with arrows showing the sequence of messages exchanged.
• Lifelines represent the existence of an object over time, and activation bars
indicate when an object is actively processing a message.
• Sequence diagrams help understand the dynamic behaviour of the system
and the sequence of steps involved in a particular scenario.
4. Activity Diagrams:
• Activity diagrams represent the flow of control or workflow within the
system, depicting activities, decisions, branching, concurrency, and
synchronization.
• Activities are represented as rounded rectangles, and transitions between
activities are shown with arrows.
• Decision points are represented by diamonds, and branches indicate
different possible paths in the workflow.
• Activity diagrams help model the business processes, use cases, or
algorithms within the system and visualize the sequence of actions
required to achieve a particular goal.

5. State Machine Diagrams:

• State machine diagrams model the behaviour of individual objects or
system components in response to different events and changes in state.
• States are represented as rounded rectangles, and transitions between
states are shown with arrows labelled with events or conditions.
• Initial and final states indicate the starting and ending points of the state
machine, respectively.
• State machine diagrams help describe the lifecycle of objects and the
transitions between different states in response to external stimuli.
6. Deployment Diagrams:
• Deployment diagrams depict the physical deployment of software
components onto hardware nodes or execution environments.
• Nodes represent hardware devices or software execution environments,
and components represent software artifacts or modules.
• Deployment relationships show how components are deployed onto
nodes, such as associations, dependencies, or deployments.
• Deployment diagrams help visualize the distribution and configuration of
software components across different hardware nodes or environments.
4. Define classes and explain CRC (Class-Responsibility-Collab) modelling.

In object-oriented programming (OOP), a class is a blueprint or template for

creating objects, which are instances of that class. A class defines the attributes
(data fields) and behaviours (methods or functions) that all objects of that class
will possess. Each object created from a class has its own set of attributes and can
perform the defined behaviours.
Here's a breakdown of the components of a class:
Attributes, Methods, Constructor, Modifiers, Inheritance.

CRC (Class-Responsibility-Collaboration) modelling is a technique used during the

early stages of object-oriented software design to identify classes, their
responsibilities, and collaborations between them. It is a simple and effective way
to brainstorm and capture the essential elements of a system's design.
1. Class: In CRC modelling, a class represents a group of objects that share similar
characteristics and behaviours. Each class is identified by a name and is
responsible for encapsulating related attributes and methods.
2. Responsibility: Responsibilities represent the behaviours or tasks that a class is
responsible for performing. Each class should have a clear and well-defined set of
responsibilities that relate to its purpose and role within the system.
Responsibilities are usually described in verb-noun format, such as
"calculateTotalPrice" or "displayCustomerInfo."

3. Collaboration: Collaboration describes the interactions and relationships

between classes. It identifies how classes work together to achieve the system's
functionality. Collaborations are typically depicted as arrows between classes,
indicating messages or method calls exchanged between them.

(Or)
• Classes:
• In object-oriented programming (OOP), a class is a blueprint for
creating objects. It defines the properties (attributes or fields) and
behaviours (methods or functions) that objects of the class will
have.
• Attributes represent the state or characteristics of an object. They
are like variables associated with the class.
• Methods represent the actions or behaviours that objects of the
class can perform. They are like functions associated with the class.
• For example, if we have a class called Car, it might have attributes
like make, model, and year, and methods like start(),
accelerate(), and brake().
• CRC Modelling (Class-Responsibility-Collaboration):
• CRC modelling is a technique used in the early stages of object-
oriented software design to identify and define classes, their
responsibilities, and their collaborations with other classes.
 • It's a brainstorming and design technique that helps in capturing
the essential aspects of a system's design in a collaborative manner.
• CRC modelling typically involves using index cards (or digital
equivalents) called CRC cards, each representing a class in the
system.
• Each CRC card includes:
• Class Name: The name of the class.
• Responsibilities: The tasks or functionalities that the class
is responsible for. These are usually described using short
verb phrases.
• Collaborators: Other classes with which the class interacts
or collaborates to fulfil its responsibilities. This is depicted
by arrows connecting CRC cards.

4. Define analysis packages and associations and dependencies in detail.

Analysis Packages:

analysis packages refer to sets of related functionalities or components within a

software system that are grouped together for the purpose of analysis and design.
These packages are organized based on logical or functional relationships
between the components they contain, and they help manage the complexity of
large software systems by breaking them down into smaller, more manageable
units.

Key points about analysis packages include:

• Functional Cohesion: Analysis packages are organized based on functional

cohesion, meaning that components within the same package are closely related
in terms of their purpose or behaviour.
• Modularity: Analysis packages promote modularity, which is the principle of
dividing a software system into discrete, interchangeable modules.
• Hierarchy: Analysis packages can be organized hierarchically, with higher-level
packages containing lower-level packages or sub-packages.
• Dependency Management: Analysis packages may have dependencies on one
another, where components within one package rely on components or
functionalities provided by other packages.

2. Associations and Dependencies:

In software engineering and UML (Unified Modelling Language), associations and

dependencies represent relationships between classes or components within a system.

• Associations: Associations represent the relationships or connections between

classes. They describe how objects of one class are related to objects of another
class. Associations are typically depicted as lines connecting the classes involved,
with optional labels indicating the nature of the relationship.
 • Dependencies: Dependencies represent a relationship where a change in one
element (e.g., class, package, module) may affect another element. Dependencies
can be based on the use of a method, function, or variable from another element.
They are typically depicted as dashed arrows pointing from the dependent
element to the element it depends on.

5. Explain software engineering design concepts, model and process in detail.

Software engineering design encompasses a set of principles, concepts, models, and
processes used to create software solutions that meet specific requirements, are
maintainable, scalable, and robust. Let's break down each aspect in detail:

1. Design Concepts:
a. Abstraction: Abstraction involves simplifying complex systems by focusing on
the essential details while hiding unnecessary complexity. It helps in managing the
complexity of software systems by representing them at different levels of detail.
b. Modularity: Modularity is the principle of dividing a software system into
discrete, interchangeable modules or components. Each module encapsulates a
set of related functionalities and can be developed, tested, and maintained
independently. Modularity promotes code reuse, scalability, and maintainability.
c. Encapsulation: Encapsulation involves bundling the data (attributes) and
behaviours (methods) of a class into a single unit. It hides the internal
implementation details of an object and exposes only the necessary interfaces for
interacting with it. Encapsulation enhances data security, code readability, and
maintainability.
d. Information Hiding: Information hiding is a design principle that restricts the
visibility of certain components within a system. It ensures that the
implementation details of a module are hidden from other modules, promoting
loose coupling and minimizing the impact of changes.
e. High Cohesion and Low Coupling: High cohesion refers to the degree to which
the elements within a module are related to one another. Modules with high
cohesion have well-defined and focused responsibilities. Low coupling refers to
the degree of interdependence between modules. Modules with low coupling are
loosely connected and can be modified or replaced independently.
2. Design Models:
a. Structural Models: Structural models depict the static structure of a software
system, including its components, relationships, and configurations. Examples
include class diagrams, component diagrams, and deployment diagrams.
b. Behavioural Models: Behavioural models describe the dynamic behaviour of a
software system, illustrating how components interact and respond to stimuli
over time. Examples include sequence diagrams, activity diagrams, and state
machine diagrams.
c. Architectural Models: Architectural models provide an abstract
representation of the overall structure and organization of a software system.
They define the high-level components, their interactions, and the distribution of
responsibilities. Examples include architectural patterns like client-server,
layered architecture, and microservices architecture.
 3. Design Process:
a. Requirement Analysis: Requirement analysis involves gathering, analysing,
and documenting the requirements for the software system. It helps in
understanding the stakeholders' needs and expectations and forms the basis for
the subsequent design activities.
b. System Design: System design involves defining the overall architecture and
structure of the software system. It includes designing the software components,
their interactions, interfaces, and dependencies. System design aims to address
functional and non-functional requirements while ensuring scalability, reliability,
and maintainability.
c. Detailed Design: Detailed design involves refining the system design into more
detailed specifications for individual components or modules. It includes
designing data structures, algorithms, interfaces, and internal logic. Detailed
design focuses on optimizing performance, minimizing resource usage, and
ensuring code readability and maintainability.
d. Implementation: Implementation involves translating the design
specifications into executable code using programming languages and
development tools. It includes writing, testing, and debugging the code to ensure
that it meets the specified requirements and quality standards.
e. Testing and Validation: Testing and validation involve verifying that the
implemented software meets the specified requirements and behaves as expected.
It includes various testing activities such as unit testing, integration testing,
system testing, and acceptance testing. Testing aims to uncover defects and ensure
the quality and reliability of the software.

6. Define software architecture and explain types of architectural styles in detail.

Software architecture refers to the fundamental organization of a software system,
encompassing its components, relationships, interactions, and design principles. It
provides a high-level view of the system's structure and behaviour, guiding the design
and development process. Software architecture defines the blueprint for building
software solutions that are scalable, maintainable, and adaptable to change.

Key aspects of software architecture include:

1. Components: The building blocks of the system, such as modules, classes, or

services, which encapsulate related functionalities.
2. Relationships: The connections and dependencies between components,
describing how they interact and communicate with one another.
3. Architectural Styles: The fundamental design principles and patterns that
govern the organization and structure of the system.
4. Quality Attributes: The non-functional requirements or quality attributes that
the architecture aims to achieve, such as performance, scalability, reliability, and
security.

Now, let's discuss different types of architectural styles:

1. Layered Architecture:
• Layered architecture organizes the system into multiple layers, where each
layer represents a different level of abstraction or functionality.
• Layers are arranged hierarchically, with higher layers depending on lower
layers. Communication typically occurs only between adjacent layers.
• Common layers include presentation (UI), application logic, business logic,
and data access layers.
• Layered architecture promotes modularity, separation of concerns, and
reusability.
2. Client-Server Architecture:
• Client-server architecture divides the system into two separate entities:
clients and servers.
• Clients are responsible for presenting the user interface and interacting
with users, while servers handle data storage, processing, and application
logic.
• Communication between clients and servers typically occurs over a
network using protocols such as HTTP, TCP/IP, or REST.
• Client-server architecture facilitates scalability, as multiple clients can
interact with a single server, and servers can be distributed across multiple
machines.
3. Microservices Architecture:
• Microservices architecture decomposes the system into a collection of
small, independent services, each focused on a specific business function.
• Each service is deployed and managed independently, allowing teams to
develop, deploy, and scale services autonomously.
• Communication between services often occurs via lightweight protocols
such as HTTP/REST or messaging queues.
• Microservices architecture promotes agility, scalability, and resilience but
adds complexity in managing distributed systems.
4. Event-Driven Architecture:
• Event-driven architecture decouples components by using events to
trigger and communicate changes or updates within the system.
• Components communicate asynchronously through events, which are
typically published to event brokers or message queues.
• Event-driven architecture supports loose coupling, scalability, and
responsiveness to changes, making it suitable for real-time or reactive
systems.
5. Component-Based Architecture:
• Component-based architecture organizes the system into reusable, self-
contained software components with well-defined interfaces.
• Components encapsulate specific functionalities and can be independently
developed, tested, and deployed.
• Communication between components occurs through well-defined
interfaces, promoting modularity, reusability, and maintainability.
 7. Explain architectural design.
Architectural design in software engineering is the process of defining the structure,
organization, and behaviour of a software system at a high level. It involves making
strategic decisions about the system's overall architecture to ensure that it meets the
desired requirements, quality attributes, and business goals. Architectural design
provides a blueprint for building the software system, guiding the development process
and facilitating communication among stakeholders.

Here's a breakdown of the key aspects of architectural design:

1. Understanding Requirements:
• The architectural design process begins with a thorough understanding of
the system requirements, including functional and non-functional
requirements.
• Requirements analysis helps identify the system's key features, user
interactions, performance expectations, scalability needs, security
concerns, and other critical aspects that influence the architecture.
2. Identifying Architectural Styles and Patterns:
• Based on the requirements and constraints, software architects select
appropriate architectural styles, patterns, and design principles to guide
the system's organization and structure.
• Architectural styles, such as layered architecture, client-server
architecture, microservices architecture, and event-driven architecture,
provide established design paradigms that address common system design
challenges.
3. Decomposition and Modularization:
• Architectural design involves decomposing the system into smaller, more
manageable modules or components.
• Modularization helps divide the system's functionality into cohesive units,
each responsible for a specific aspect of the system's behavior.
• Components are organized based on functional cohesion, with clear
interfaces and well-defined responsibilities.
4. Defining Components and Interfaces:
• Architectural design defines the components or building blocks of the
system and their interactions.
• Components encapsulate related functionality and data, while interfaces
specify how components communicate with one another.
• Interface design focuses on defining clear, consistent, and well-
documented contracts between components, promoting loose coupling
and modularity.
5. Addressing Quality Attributes:
• Architectural design aims to satisfy the system's quality attributes or non-
functional requirements, such as performance, scalability, reliability,
security, and maintainability.
• Design decisions are evaluated based on their impact on quality attributes
and trade-offs are made to achieve the desired balance between competing
objectives.
6. Prototyping and Evaluation:
• Prototyping and evaluation are important aspects of architectural design,
allowing architects to validate design decisions and identify potential risks
or issues early in the development process.
• Prototypes help stakeholders visualize and interact with the proposed
architecture, providing valuable feedback for refinement and
improvement.
7. Documentation and Communication:
• Architectural design documentation serves as a comprehensive reference
for developers, testers, and other stakeholders involved in the software
development process.
• Clear and concise documentation communicates the rationale behind
design decisions, system constraints, and the overall architecture,
facilitating collaboration and understanding among team members.