SEPM Mod 3 Design Engineering

Design Process & quality

Design Process

The software design process is a crucial phase in software engineering that involves transforming the
customer requirements, as described in the Software Requirements Specification (SRS) documents, into
a form that can be implemented using a programming language. This process ensures that the final
software product meets the needs of the users and performs efficiently. The design phase can be
divided into three main levels or phases:

1. Interface Design

2. Architectural Design

3. Detailed Design

1. Interface Design

Interface Design focuses on defining how the software components will interact with each other and
with external entities. This includes designing user interfaces, APIs (Application Programming
Interfaces), and the way different modules of the system communicate.

 User Interface (UI) Design: This involves creating the layout and interactive elements of the
software that users will interact with. It includes designing screens, menus, buttons, icons, and
any visual elements that the user sees and interacts with.

 API Design: For software systems that require integration with other systems or components,
API design specifies how different parts of the software communicate. This includes defining the
endpoints, request and response formats, and error handling mechanisms.

 Communication Protocols: Designing the protocols that govern the exchange of data between
different parts of the system, ensuring they can work together seamlessly.

2. Architectural Design

Architectural Design involves the high-level structuring of the software system. This phase defines the
overall structure and style of the system and identifies the main components and their interactions.

 System Architecture: Establishing the main components of the system, their responsibilities,
and how they interact. This can involve choosing an architectural pattern (e.g., layered
architecture, microservices, client-server architecture).

 Subsystem Decomposition: Breaking down the system into smaller, manageable subsystems or
modules, each with a specific role. This helps in organizing the development effort and can
facilitate parallel development.

 Technology Stack Selection: Deciding on the technologies, frameworks, and platforms that will
be used to implement the system. This includes choosing the programming languages,
databases, and other tools required.
3. Detailed Design

Detailed Design focuses on the internal workings of each module or component identified in the
architectural design. It provides a detailed plan for the implementation, ensuring each part of the
system can be built effectively.

 Class Diagrams and Data Structures: Defining the data structures, classes, and objects that will
be used within each module. This includes specifying attributes, methods, and the relationships
between different classes.

 Algorithm Design: Outlining the algorithms that will be implemented to perform specific tasks
within the system. This includes detailing the logic and steps required for processing data,
making decisions, and producing outputs.

 Interface Specifications: Providing detailed specifications for interfaces between different

modules, including method signatures, input and output parameters, and data formats.

Quality

Software Quality shows how good and reliable a product is. To convey an associate degree example,
think about functionally correct software. It performs all functions as laid out in the SRS document. But,
it has an associate degree virtually unusable program. even though it should be functionally correct, we
tend not to think about it to be a high-quality product.

Key Aspects of Software Quality

1. Functionality

 The software must perform the tasks it was designed for, correctly and completely. This
includes ensuring that all specified features and functions as outlined in the Software
Requirements Specification (SRS) document are implemented and working correctly.

2. Reliability

 The software should operate without failure under specified conditions for a given
period. Reliability is crucial for ensuring that the software performs consistently and
accurately.

3. Usability

 Usability refers to how easy and intuitive it is for users to interact with the software.
This includes user interface design, ease of navigation, and the overall user experience.
High usability means that users can achieve their goals effectively and efficiently with
the software.

4. Efficiency

 Efficiency relates to the performance of the software, particularly how well it utilizes
system resources like CPU, memory, and network bandwidth. Efficient software
performs its functions with minimal resource consumption and optimal speed.
 5. Maintainability

 Maintainability is the ease with which the software can be modified to correct defects,
improve performance, or adapt to a changed environment. Good maintainability
requires clear, well-documented, and modular code that can be easily understood and
altered by developers.

6. Portability

 Portability refers to the ability of the software to operate in different environments,

such as different operating systems, hardware platforms, or web browsers. Portable
software can be transferred from one environment to another with minimal
modification.

Design Concepts

The software design concept simply means the idea or principle behind the
design. It describes how you plan to solve the problem of designing software,
and the logic, or thinking behind how you will design software. It allows the
software engineer to create the model of the system software or product that
is to be developed or built. The software design concept provides a
supporting and essential structure or model for developing the right software.
There are many concepts of software design and some of them are given
below:

1. Abstraction

Abstraction is the process of reducing complexity by focusing on the essential

characteristics of an object or process while ignoring irrelevant details. In software
design, abstraction allows developers to manage complexity by breaking down the
system into simpler, more manageable components.
  Data Abstraction: Involves defining complex data structures in a simplified
manner.
 Control Abstraction: Focuses on defining control structures (like loops and
conditionals) in a simplified way.
3. Modularity (subdivide the system): Modularity simply means dividing the
system or project into smaller parts to reduce the complexity of the
system or project. In the same way, modularity in design means
subdividing a system into smaller parts so that these parts can be created
independently and then use these parts in different systems to perform
different functions
4. Architecture (design a structure of something): Architecture simply
means a technique to design a structure of something. Architecture in
designing software is a concept that focuses on various elements and the
data of the structure. These components interact with each other and use
the data of the structure in architecture.
5. Refinement (removes impurities): Refinement simply means to refine
something to remove any impurities if present and increase the quality.
The refinement concept of software design is a process of developing or
presenting the software or system in a detailed manner which means
elaborating a system or software. Refinement is very necessary to find
out any error if present and then to reduce it.
5. Pattern (a Repeated form): A pattern simply means a repeated form or
design in which the same shape is repeated several times to form a
pattern. The pattern in the design process means the repetition of a
solution to a common recurring problem within a certain context.
6. Information Hiding (Hide the Information): Information hiding simply
means to hide the information so that it cannot be accessed by an
unwanted party. In software design, information hiding is achieved by
designing the modules in a manner that the information gathered or
contained in one module is hidden and can’t be accessed by any other
modules.
7. Refactoring (Reconstruct something): Refactoring simply means
reconstructing something in such a way that it does not affect the
behavior of any other features. Refactoring in software design means
reconstructing the design to reduce complexity and simplify it without
impacting the behavior or its functions
 The design Model
The design model in software engineering is a blueprint for the system's architecture,
components, interfaces, and data flow, created during the design phase. It serves as a
bridge between the high-level requirements specified in the Software Requirements
Specification (SRS) and the low-level code implementation. The design model includes
various elements and diagrams that provide a comprehensive view of the system's
structure and behavior Here are the key components of the design model:

1. Data Design

Data design focuses on defining the data structures and databases required for the
system. It includes:

 Data Structures: Detailed descriptions of data structures used within the software, including
arrays, linked lists, trees, etc.
 Database Design: Schemas, tables, relationships, normalization, and other aspects of database
design to ensure efficient data storage and retrieval.
 Data Flow Diagrams (DFDs): Diagrams that show how data moves through the system,
depicting processes, data stores, and data flows.

2. Architectural Design

Architectural design defines the high-level structure of the software system. It includes:

 Architectural Styles and Patterns: The overall style of the architecture, such as layered
architecture, microservices, client-server, or event-driven architecture.
 System Components: Identification of major components or subsystems and their
responsibilities.
 Component Interaction: How these components interact with each other, often shown through
component diagrams or interaction diagrams.

3. Interface Design

Interface design specifies how the software components will interact with each other
and with external systems. It includes:

 User Interface (UI) Design: Layouts, mockups, and prototypes of the user interface. This
includes screen designs, navigation flow, and interactive elements.
 API Design: Definitions of application programming interfaces, including endpoints,
request/response formats, and error handling.
 Communication Protocols: The protocols used for communication between different system
components and with external systems.

4. Component-Level Design

Component-level design provides a detailed description of the internal workings of each

software component. It includes:

 Class Diagrams: Visual representations of the classes, attributes, methods, and relationships
between classes in object-oriented design.
 Sequence Diagrams: Diagrams that show the sequence of interactions between objects to
accomplish a specific task.
 State Diagrams: Diagrams that represent the states of an object and the transitions between
these states.
Pattern-based Software Design

Pattern-based software design involves the use of design patterns to solve common problems in
software architecture and development. Design patterns are proven, reusable solutions to
recurring problems within a given context in software design. They provide a standard
terminology and are specific to particular scenarios, helping to streamline the development
process, enhance code readability, and promote best practices.

Key Concepts in Pattern-based Software Design

1. Reusability: Design patterns promote code reuse by providing templates that can be applied to
new problems.
2. Scalability: Patterns help in designing systems that can grow and scale efficiently.
3. Maintainability: Using well-established patterns makes the code more maintainable and
understandable.
4. Flexibility: Patterns often provide solutions that are flexible and adaptable to change.

Categories of Design Patterns

Design patterns are generally divided into three main categories: creational, structural,
and behavioral.

1. Creational Patterns
Creational patterns deal with object creation mechanisms, trying to create objects in a
manner suitable to the situation. These patterns abstract the instantiation process,
making the system independent of how its objects are created, composed, and
represented.
 Singleton: Ensures there is only one instance of a class.

 Example: A settings manager in an application that should only have one set of
settings.

 Factory Method: Creates objects without specifying the exact class of object that will be
created.

 Example: A button factory that creates different types of buttons (e.g., Windows button,
Mac button) without knowing the specific button type in advance.

 Builder: Builds complex objects step by step.

 Example: Building a computer by selecting components (CPU, RAM, etc.) step by step.

2. Structural Patterns
Structural patterns deal with the composition of classes or objects. They help ensure
that if one part of a system changes, the entire system doesn’t need to change.

 Adapter: Allows objects with incompatible interfaces to work together.

 Example: A power adapter that allows a plug from one country to fit into a socket from
another country.

 Composite: Treats individual objects and compositions of objects uniformly.

 Example: A drawing application where a drawing can contain shapes like circles and
rectangles, as well as groups of shapes.

 Decorator: Adds behavior to objects dynamically.

 Example: Adding scrolling to a window in a graphical user interface.

3. Behavioral Patterns
Behavioral patterns are concerned with algorithms and the assignment of
responsibilities between objects. They help in managing complex control flows and
improving communication between objects.

 Observer: Notifies multiple objects about changes to a single object.

 Example: A news agency that notifies subscribers (like newspapers and TV channels)
about breaking news.

 Strategy: Allows selecting an algorithm at runtime.

 Example: A sorting class that can use different sorting algorithms (e.g., bubble sort,
quicksort) based on the situation.

 Command: Encapsulates a request as an object.

 Example: An undo feature in a text editor where each operation (like typing or deleting)
is treated as a command that can be undone.
Architectural Design: Application Architectures
Architectural design in software engineering refers to the process of defining a structured
solution that meets all of the technical and operational requirements. It involves creating a
blueprint for the software system, which includes high-level structures, components, their
relationships, and how they interact.

Types of Architectural design

1] Data centered architectures:

 A data store will reside at the center of this architecture and is accessed
frequently by the other components that update, add, delete, or modify
the data present within the store.
 The figure illustrates a typical data-centered style. The client software
accesses a central repository. Variations of this approach are used to
transform the repository into a blackboard when data related to the client
or data of interest for the client change the notifications to client software.
 This data-centered architecture will promote integrability. This means that
the existing components can be changed and new client components can
be added to the architecture without the permission or concern of other
clients.
 Data can be passed among clients using the blackboard mechanism.

2] Data flow architectures:

 This kind of architecture is used when input data is transformed into
output data through a series of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe
and filter and it has a set of components called filters connected by lines.
 Pipes are used to transmitting data from one component to the next.
 Each filter will work independently and is designed to take data input of a
certain form and produces data output to the next filter of a specified form.
The filters don’t require any knowledge of the working of neighboring
filters.
 If the data flow degenerates into a single line of transforms, then it is
termed as batch sequential. This structure accepts the batch of data and
then applies a series of sequential components to transform it.
3] Call and Return architectures
It is used to create a program that is easy to scale and modify. Many sub-
styles exist within this category. Two of them are explained below.
 Remote procedure call architecture: This components is used to
present in a main program or sub program architecture distributed among
multiple computers on a network.
 Main program or Subprogram architectures: The main program
structure decomposes into number of subprograms or function into a
control hierarchy. Main program contains number of subprograms that
can invoke other components.

4] Object Oriented architecture

The components of a system encapsulate data and the operations that must
be applied to manipulate the data. The coordination and communication
between the components are established via the message passing.
5] Layered architecture
 A number of different layers are defined with each layer performing a well-
defined set of operations. Each layer will do some operations that
becomes closer to machine instruction set progressively.
 At the outer layer, components will receive the user interface operations
and at the inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
 Intermediate layers to utility services and application software functions.
 One common example of this architectural style is OSI-ISO (Open
Systems Interconnection-International Organisation for Standardisation)
communication system.
Design Decisions

Design decisions are fundamental choices made during the architectural design process that
impact the system’s quality attributes, such as performance, security, scalability, and
maintainability. These decisions include:

1. Architectural Style: Choosing a high-level organizational structure (e.g., layered,

microservices, client-server, event-driven).

2. Component Definition: Identifying and defining major functional components and their
interactions.

3. Communication Patterns: Deciding on how components will interact (e.g., synchronous

vs. asynchronous communication, REST APIs, message queues).

4. Technology Stack: Selecting technologies and frameworks to be used (e.g.,

programming languages, web frameworks, databases).

5. Data Management: Determining how data will be stored, accessed, and managed (e.g.,
SQL vs. NoSQL databases, caching strategies).

6. Security Measures: Implementing security protocols (e.g., authentication, authorization,

encryption).

7. Scalability and Performance: Planning for handling increased loads and optimizing
performance (e.g., load balancing, horizontal scaling).

8. Fault Tolerance: Ensuring the system can recover from failures (e.g., redundancy,
failover mechanisms).
 9. Deployment Strategy: Deciding on deployment methods (e.g., on-premises vs. cloud
deployment, containerization).

10. Integration Management: Handling interactions with external systems (e.g., API
integration, service orchestration).

11. Monitoring and Maintenance: Setting up processes for ongoing monitoring, logging,
and maintenance.

Views and patterns

It is generally used to represent entire architecture that is useful and

meaningful to one or more stakeholders in system. Architecture view or
viewpoint is set of representations of an architecture that covers stakeholder
issues. It also represents functional and non-functional requirements of
software application. View is basically partial expression of system from
specific perspective. A viewpoint is generally collection of patterns,
templates, and even conventions for developing one type of view.
1. Use Case View:

 To capture and document the functional requirements of the system from the
perspective of its users. It defines the interactions between users (actors) and the system
to achieve specific goals or tasks.

2. Design View:

 To organize and describe the basic structure and functionality of the solution without
delving into implementation details. It focuses on architecturally significant features and
entities.

3. Process View:

 To address the dynamic aspects of the system, including its processes, communication
between components, and behavior during runtime.

4. Component View:

 The Component View focuses on the organization and structure of the software components
that make up the system. It provides insight into how these components are designed, interact
with each other, and collaborate to fulfill the system's functionalities.

5. Deployment View:

 The Deployment View focuses on how the software components are physically deployed and
distributed across nodes in the system architecture. It addresses the deployment topology,
infrastructure requirements, and communication between nodes.
Modeling Component level Design

Component-level design divides software into reusable modules, enhancing reusability, reliability,
and maintainability. It involves identifying design classes, elaborating on design, and developing
behavioral representations using diagrams. Component design for web apps focuses on content,
functional, and deployment design.

Component level design in software engineering involves dividing software design into modular,
reusable components with clear functionalities and benefits like reusability, cost reduction, client
interaction, reliability, and easy maintenance.

Component:
A component in software design is a self-contained, reusable piece of functionality that
encapsulates its implementation and interacts with other components through well-defined
interfaces.
Designing class based components

Designing class-based components in software design involves creating reusable, encapsulated

pieces of functionality that can be easily maintained and integrated into larger systems. This
approach is fundamental in object-oriented programming (OOP) and software engineering.
Below is an overview of how to design class-based components effectively:

1. Understand the Requirements

 Gather Requirements: Clearly define what the component needs to do, its inputs and
outputs, and its interactions with other components.

 Define Use Cases: Identify all the scenarios in which the component will be used. This
helps in understanding the requirements better.

2. Define Responsibilities

 Single Responsibility Principle (SRP): Each class should have one responsibility or reason
to change. This makes the class easier to understand, test, and maintain.

 High Cohesion: Ensure that the methods and properties of the class are closely related
and work together towards a single purpose.

3. Identify Collaborators

 Dependency Identification: Determine the other classes or components that your class
will interact with. This is essential for understanding the dependencies.

 Loose Coupling: Aim for minimal dependency on other classes. Use interfaces or abstract
classes to define interactions, promoting flexibility and reusability.

4. Define the Class Structure

 Class Name: Choose a descriptive and meaningful name for the class that reflects its
responsibility.

 Attributes (Fields): Identify the data that the class needs to store. These are the attributes
or properties.

 Methods: Define the functions that operate on the attributes. Ensure each method has a
single purpose and is named clearly.

5. Design Patterns

 Creational Patterns: Use patterns like Factory, Singleton, or Builder to manage the
creation of objects.
  Structural Patterns: Apply patterns like Adapter, Composite, or Decorator to define
relationships between classes.

 Behavioral Patterns: Implement patterns like Observer, Strategy, or Command to manage

how classes interact and distribute responsibilities.

6. Implementing the Class

 Constructor: Define a constructor to initialize the class. Ensure it sets up the object in a
valid state.

 Access Modifiers: Use appropriate access modifiers (public, private, protected) to

encapsulate the data and expose only what is necessary.

 Getters and Setters: Provide methods to access and modify private attributes if
necessary, adhering to the principles of encapsulation.

7. Error Handling

 Validation: Ensure that the class validates its state and inputs, throwing exceptions or
errors where appropriate.

 Exception Handling: Implement robust error handling within methods to manage

unexpected conditions gracefully.

8. Documentation and Comments

 Document the Class: Write clear documentation for the class, explaining its purpose,
usage, and any important details.

 Comment Code: Add comments within the code to explain complex logic or non-
obvious decisions.

9. Testing

 Unit Tests: Write unit tests to verify that each method performs as expected.

 Integration Tests: Test the component with its collaborators to ensure they interact
correctly.

10. Review and Refactor

 Code Review: Have peers review the code to catch issues and improve quality.

 Refactor: Periodically refactor the class to improve readability, performance, and

maintainability.
conducting component-level design

Component-level design is a critical phase in the system design process where the focus is on
designing individual components or subsystems that will make up the overall system. This phase
involves breaking down the system requirements into smaller, more manageable pieces and
designing each component to meet those requirements.

Conducting Component-Level Design

To conduct component-level design, follow these steps:

1. Identify Components: Identify the individual components or subsystems that will make up
the overall system. This can be done by reviewing the system architecture and identifying the
key functional blocks.
2. Define Component Requirements: Define the requirements for each component, including
functional, performance, and interface requirements. This can be done by reviewing the
system requirements and allocating them to individual components.
3. Develop Component Architecture: Develop a detailed architecture for each component,
including the internal structure, interfaces, and data flows.
4. Design Component Interfaces: Design the interfaces between components, including the
data formats, communication protocols, and APIs.
5. Select Component Technologies: Select the technologies and materials to be used for each
component, including hardware, software, and firmware.
6. Perform Component Analysis: Perform analysis and simulation to validate the design of
each component, including thermal, structural, and electromagnetic analysis.
7. Develop Component Prototypes: Develop prototypes of each component to test and
validate the design.
8. Test and Integrate Components: Test and integrate each component to ensure that they
meet the requirements and work together seamlessly.

User Interface Design

The user interface is the front-end application view to which the user interacts to use the
software. The software becomes more popular if its user interface is:

 Attractive
 Simple to use
 Responsive in a short time
 Clear to understand
 Consistent on all interface screens
 Types of User Interface

1. Command Line Interface: The Command Line Interface provides a command prompt, where
the user types the command and feeds it to the system. The user needs to remember the
syntax of the command and its use.

2. Graphical User Interface: Graphical User Interface provides a simple interactive interface to
interact with the system. GUI can be a combination of both hardware and software. Using
GUI, the user interprets the software.

The golden rules

User Interface Design Golden Rules

The following are the golden rules stated by Theo Mandel that must be followed during the
design of the interface. Place the user in control:

1. Define the interaction modes in such a way that does not force the user into unnecessary or
undesired actions: The user should be able to easily enter and exit the mode with little or no
effort.

2. Provide for flexible interaction: Different people will use different interaction mechanisms,
some might use keyboard commands, some might use mouse, some might use touch screen,
etc., Hence all interaction mechanisms should be provided.

3. Allow user interaction to be interruptible and undoable: When a user is doing a sequence of
actions the user must be able to interrupt the sequence to do some other work without
losing the work that had been done. The user should also be able to do undo operation.

4. Streamline interaction as skill level advances and allow the interaction to be

customized: Advanced or highly skilled user should be provided a chance to customize the
interface as user wants which allows different interaction mechanisms so that user doesn’t
feel bored while using the same interaction mechanism.

5. Hide technical internals from casual users: The user should not be aware of the internal
technical details of the system. He should interact with the interface just to do his work.

6. Design for direct interaction with objects that appear on-screen: The user should be able to
use the objects and manipulate the objects that are present on the screen to perform a
necessary task. By this, the user feels easy to control over the screen.

Interface Design steps & Analysis

The analysis and design process of a user interface is iterative and can be represented by a spiral
model. The analysis and design process of user interface consists of four framework activities.
1. User, Task, Environmental Analysis, and Modeling
Initially, the focus is based on the profile of users who will interact with the
system, i.e., understanding, skill and knowledge, type of user, etc., based on
the user’s profile users are made into categories. From each category
requirements are gathered. Based on the requirement’s developer
understand how to develop the interface. Once all the requirements are
gathered a detailed analysis is conducted. In the analysis part, the tasks that
the user performs to establish the goals of the system are identified,
described and elaborated. The analysis of the user environment focuses on
the physical work environment. Among the questions to be asked are:
1. Where will the interface be located physically?
2. Will the user be sitting, standing, or performing other tasks unrelated to
the interface?
3. Does the interface hardware accommodate space, light, or noise
constraints?
4. Are there special human factors considerations driven by environmental
factors?
2. Interface Design
The goal of this phase is to define the set of interface objects and actions
i.e., control mechanisms that enable the user to perform desired tasks.
Indicate how these control mechanisms affect the system. Specify the action
sequence of tasks and subtasks, also called a user scenario. Indicate the
state of the system when the user performs a particular task. Always follow
the three golden rules stated by Theo Mandel. Design issues such as
response time, command and action structure, error handling, and help
facilities are considered as the design model is refined. This phase serves as
the foundation for the implementation phase.
3. Interface Construction and Implementation
The implementation activity begins with the creation of a prototype (model)
that enables usage scenarios to be evaluated. As iterative design process
continues a User Interface toolkit that allows the creation of windows,
menus, device interaction, error messages, commands, and many other
elements of an interactive environment can be used for completing the
construction of an interface.
4. Interface Validation
This phase focuses on testing the interface. The interface should be in such
a way that it should be able to perform tasks correctly, and it should be able
to handle a variety of tasks. It should achieve all the user’s requirements. It
should be easy to use and easy to learn. Users should accept the interface
as a useful one in their work.

Design Evaluation

Design evaluation in software engineering is the process of assessing a software design to

ensure it meets specified requirements and quality attributes. It involves reviewing and analyzing
the design from various perspectives to identify potential issues and validate its feasibility. Here
are the key aspects of design evaluation, summarized:

1. Requirements Fulfillment

 Ensure the design meets all functional and non-functional requirements specified in the
requirements document.

 Check alignment with user needs and business objectives.

2. Consistency and Completeness

 Verify that the design is complete and covers all specified aspects of the system.

 Ensure consistency across different parts of the design documentation.

3. Modularity and Cohesion

 Evaluate the modularity of the design, ensuring components are well-defined and self-
contained.

 Check for high cohesion within components and low coupling between them.
4. Scalability and Performance

 Assess if the design can handle expected future growth in terms of data volume, number
of users, and transaction loads.

 Review design choices to ensure they support the required performance levels.

5. Maintainability and Flexibility

 Determine how easily the design can be maintained and extended.

 Check for the use of design patterns and best practices that enhance flexibility.

6. Security

 Evaluate the design for potential security vulnerabilities.

 Ensure appropriate security measures are integrated, such as access controls and data
encryption.

7. Usability and User Experience

 Assess the design from the end-user perspective to ensure it provides a good user
experience.

 Check for usability issues in the user interface design.

8. Feasibility and Risk

 Evaluate the technical feasibility of the design, ensuring it can be implemented with the
available technology and resources.

 Identify potential risks and design aspects that could pose challenges during
implementation.