0% found this document useful (0 votes)
20 views12 pages

Unit 3

Software design is a process that transforms user requirements into a structured format for coding and implementation, focusing on modules, control relationships, interfaces, data structures, and algorithms. Key objectives include correctness, efficiency, flexibility, and maintainability, while concepts like abstraction, encapsulation, and modularity guide the design process. Various design paradigms, levels, and strategies are discussed, alongside the importance of coupling and cohesion in module interaction and the review process to ensure adherence to software requirements and quality standards.

Uploaded by

customgoodies199
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views12 pages

Unit 3

Software design is a process that transforms user requirements into a structured format for coding and implementation, focusing on modules, control relationships, interfaces, data structures, and algorithms. Key objectives include correctness, efficiency, flexibility, and maintainability, while concepts like abstraction, encapsulation, and modularity guide the design process. Various design paradigms, levels, and strategies are discussed, alongside the importance of coupling and cohesion in module interaction and the review process to ensure adherence to software requirements and quality standards.

Uploaded by

customgoodies199
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

Unit-3

Software Design

Software design is a process to transform user requirements into some suitable form,
which helps the programmer in software coding and implementation.
The following items are designed and documented during the design phase:
● Different modules are required.
● Control relationships among modules.
● Interface among different modules.
● Data structure among the different modules.
● Algorithms are required to be implemented among the individual modules.

Objectives of Software Design :


● Correctness
● Efficiency
● Flexibility
● Understandability
● Completeness
● Maintainability

Concept of software Design :


1. Abstraction: Abstraction is the process to hide its implementation details and
simplify the interface.
2. Encapsulation: Encapsulation is the practice of bundling data and methods that
manipulate the data within the same object or class, creating a self-contained
unit of code.
3. Modularity: Modularity refers to the division of a software system into smaller,
independent components that can be developed, tested, and maintained
separately.
4. Normalization: Normalization is the process of organizing data in a relational
database to eliminate redundancy and improve data integrity.
5. Reusability: Reusability is the ability to use existing components and modules in
multiple applications, reducing development time and cost.
6. Refinement : Refinement in software design involves clarifying and enhancing the
initial design artifacts, such as requirements, specifications, and architectural
diagrams, to better align them with the project's goals and constraints.
7. Refactoring : Refactoring is the process of restructuring existing code without
changing its external behavior.
Software Design Paradigms/Approaches

Software design paradigms are fundamental approaches or philosophies that guide the
process of designing software systems. These paradigms provide principles, concepts,
and methodologies for structuring, organizing, and developing software.

Some of the common software design paradigms include:

1. Procedural Paradigm: This paradigm focuses on breaking down the program into a
set of procedures or routines. It emphasizes step-by-step instructions and follows a
top-down approach. Languages like C are often associated with this paradigm.

2. Object-Oriented Paradigm (OOP): In this paradigm, software is designed around


objects that encapsulate data and behavior. It emphasizes concepts such as classes,
objects, inheritance, and polymorphism. Languages like Java, C++, and Python are
based on OOP principles.

3. Functional Paradigm: Functional programming focuses on computation as the


evaluation of mathematical functions. It emphasizes immutability, pure functions, and
higher-order functions. Languages like Haskell, Lisp, and Scala follow functional
programming principles.

4. Declarative Paradigm: Declarative programming focuses on describing what should


be accomplished rather than how to accomplish it. This includes languages and
paradigms like SQL for database queries and Prolog for logical programming.

5. Event-Driven Paradigm: In this paradigm, the flow of the program is determined by


events such as user actions, sensor outputs, or messages from other programs.
Event-driven programming is commonly used in graphical user interfaces (GUIs) and
asynchronous programming.

6. Service-Oriented Architecture (SOA): SOA is an architectural approach that


structures software systems as a collection of loosely coupled services. These services
communicate with each other over a network. SOA promotes interoperability, flexibility,
and scalability.
Software Design Levels/Categories :

Software design occurs at multiple levels, each focusing on different aspects of the
system's architecture, functionality, and behavior. These levels include:

1. High-level design:
● At this level, architects and designers define the overall structure and
components of the system.
● This includes deciding on the major modules, subsystems, and their interactions.
High-level design typically involves creating architectural diagrams,
● Example : such as UML diagrams or system flowcharts, to illustrate the system's
structure and how components communicate.

2. Detailed design: Detailed design develops deeper into individual components and
modules defined during high-level design. Designers specify the internal logic of each
module, including algorithms, data structures, interfaces, and dependencies. This level
of design is more granular and focuses on ensuring that each module performs its
specified functions efficiently and reliably.

3. Component-level design: At this level, designers focus on designing individual


components or classes within the system. They define the attributes, methods, and
relationships of each component, often using techniques such as class diagrams and
sequence diagrams to illustrate the interactions between objects.

4. Database design: Database design involves defining the structure, organization, and
relationships of the system's data storage. Designers create entity-relationship
diagrams (ERDs) to model the data schema, specifying tables, fields, and constraints.
Database design also includes decisions regarding data normalization, indexing, and
data access strategies to ensure efficient data storage and retrieval.

5. User interface (UI) design: UI design focuses on creating intuitive and visually
appealing interfaces for end-users. Designers consider factors such as usability,
accessibility, and user experience (UX) when designing interfaces for different devices
and platforms. UI design often involves creating wireframes, mockups, and prototypes
to iterate on the layout, navigation, and visual elements of the interface.

6. System architecture design: System architecture design involves defining the overall
structure and organization of the system, including hardware, software, networks, and
other components. Architects make decisions regarding system topology, deployment
models, scalability, security, and performance to meet the system's requirements and
objectives.

7. Security design: Security design focuses on identifying potential vulnerabilities and


threats to the system and implementing measures to mitigate risks. Designers define
security policies, access controls, encryption mechanisms, and other security measures
to protect the system's assets and data from unauthorized access, manipulation, or
disclosure.

Elements of a System

Architecture: This is the conceptual model that defines the structure, behavior, and
views of a system. We can use flowcharts to represent and illustrate the architecture.
Modules: These are components that handle one specific task in a system. A
combination of the modules makes up the system.
Components: This provides a particular function or group of related functions. They are
made up of modules.
Interfaces: This is the shared boundary across which the components of a system
exchange information and relate.
Data: This is the management of the information and data flow.

Strategy of design
● Top-down
● Bottom-up
Use this link to get details
https://www.geeksforgeeks.org/difference-between-bottom-up-model-and-top-do
wn-model/
Software Design Process

Interface Design

Interface design should include the following details:


● Precise description of events in the environment, or messages from agents to
which the system must respond.
● Precise description of the events or messages that the system must produce.
● Specification of the data, and the formats of the data coming into and going out
of the system.
● Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs.

Architectural Design

● Gross decomposition of the systems into major components.


● Allocation of functional responsibilities to components.
● Component Interfaces.
● Component scaling and performance properties(Response time,latency,
throughput), resource consumption properties(CPU usage,memory usage,
Network bandwidth), reliability properties(Fault tolerance, Failover mechanism),
and so forth.
● Communication and interaction between components.

Detailed Design
Detailed Design is the specification of the internal elements of all major system
components, their properties, relationships, processing, and often their algorithms and
the data structures.
The detailed design may include:
● Decomposition of major system components into program units.
● Allocation of functional responsibilities to units.
● User interfaces.
● Unit states and state changes.
● Data and control interaction between units.
● Data packaging and implementation, including issues of scope and visibility of
program elements.
● Algorithms and data structures.

Modularization
Modularization is the process of dividing a software system into multiple independent
modules where each module works independently.
Purpose
● Easy to understand the system.
● System maintenance is easy.
● A module can be used many times as their requirements. No need to write it
again and again.

Benefits
1. Encapsulation: Modules encapsulate related functionality, data, and behavior, hiding
implementation details and exposing only necessary interfaces. This encapsulation
enhances code readability, reduces complexity, and facilitates easier debugging and
maintenance.

2. Abstraction: Modularization promotes abstraction by defining clear interfaces


between modules. This abstraction allows developers to focus on high-level
functionality without worrying about the internal workings of other modules, promoting
code reusability and easier collaboration among team members.

3. Decoupling: Modularization helps in decoupling different parts of the system,


reducing dependencies between modules. This loose coupling enables developers to
make changes to one module without affecting others, promoting flexibility, and
facilitating easier testing and evolution of the software.

4. Scalability: By breaking a system into smaller modules, it becomes easier to scale the
software both vertically (by adding more resources to individual modules) and
horizontally (by replicating modules across multiple instances). This scalability is
crucial for handling increasing loads and accommodating evolving requirements.

5. Reusability: Modularization encourages the creation of reusable modules that can be


utilized across different projects or within the same project. Reusable modules save
development time and effort, promote consistency, and improve overall software
quality.

6. Ease of Maintenance: With modularization, maintaining and updating software


becomes more manageable. Changes can be localized to specific modules, reducing
the risk of unintended side effects and making it easier to understand the impact of
modifications on the system as a whole.

7. Parallel Development: Modularization facilitates parallel development by enabling


different teams or developers to work on separate modules concurrently. This
parallelism accelerates the development process, enhances productivity, and supports
agile development methodologies.
Coupling and Cohesion

When a software program is modularized, its tasks are divided into several modules
based on some characteristics. There are measures by which the quality of a design of
modules and their interaction among them can be measured. These measures are
called coupling and cohesion.

Cohesion: Cohesion is a measure that defines the degree of intra-dependability within


elements of a module. The greater the cohesion, the better is the program design.

There are seven types of cohesion, namely –


● Coincidental cohesion - It is unplanned and random cohesion, which might be the
result of breaking the program into smaller modules for the sake of
modularization. Because it is unplanned, it may serve confusion to the
programmers and is generally not-accepted.
Example: A miscellaneous utility module containing unrelated functions for tasks such
as file I/O, date formatting, and mathematical calculations. These functions are grouped
together for convenience rather than any inherent relationship.

● Logical cohesion - When logically categorized elements are put together into a
module, it is called logical cohesion.
Example : The module contains functions for calculating the average, finding the
maximum and minimum values, and computing the square root of numbers.

● Temporal Cohesion - When elements of a module are organized such that they
are processed at a similar point in time, it is called temporal cohesion.
Example: A module responsible for handling user session management in a web
application, where functions for starting a session, updating session data, and ending a
session are all triggered by user login/logout events and are executed within the same
session lifecycle.

● Procedural cohesion - When elements of a module are grouped together, which


are executed sequentially in order to perform a task, it is called procedural
cohesion.E.g. Calling function to another function, loops.
Example: A utility module for manipulating strings, where functions for string
concatenation, substring extraction, and case conversion are grouped together. Although
these functions perform different actions, they are all related to string manipulation.

● Communicational cohesion - When elements of a module are grouped together,


which are executed sequentially and work on the same data (information), it is
called communicational cohesion.
Example: A module responsible for processing customer data, where functions for
retrieving customer information, updating customer records, and generating customer
reports are grouped together. These functions operate on the same set of customer data
and produce related output.

● Sequential cohesion - When elements of a module are grouped because the


output of one element serves as input to another and so on, it is called sequential
cohesion.
Example: A module responsible for processing an online order, where the steps include
validating the order, updating inventory, and generating an order confirmation. Each step
relies on the completion of the previous step and follows a sequential order.

● Functional cohesion - It is considered to be the highest degree of cohesion, and it


is highly expected. Elements of modules in functional cohesion are grouped
because they all contribute to a single well-defined function. It can also be
reused.
Example: A module responsible for calculating the total price of items in a shopping cart.
All functions within this module, such as adding items, removing items, and calculating
discounts, are closely related to the single function of calculating the total price.
Coupling
Coupling is a measure that defines the level of inter-dependability among modules of a
program. It tells at what level the modules interfere and interact with each other. The
lower the coupling, the better the program design.

There are five levels of coupling, namely -

Content coupling - When a module can directly access or modify or refer to the content
of another module, it is called content level coupling.Change in one module needs to
update in other modules.
Example: Suppose you have a billing module that directly accesses the database schema of
the customer module to retrieve customer information for generating bills. Any changes in the
database schema of the customer module would require modifications in the billing module,
leading to tightly coupled systems.

Common coupling- When multiple modules have read and write access to some global
data, it is called common or global coupling.
Example: A system where multiple modules access a global configuration file to fetch various
settings. If the format of the configuration file changes, all modules relying on it need to be
updated, leading to common coupling.

External Coupling: In external coupling, the modules depend on other modules, external
to the software being developed or to a particular type of hardware.
Example : For instance, if one of the payment service providers updates its API version or
changes its authentication mechanism, the payment gateway module would need to be updated
to accommodate these changes. This external coupling introduces a dependency on the
external services, potentially impacting the system's stability, flexibility, and maintenance.

Control coupling- Two modules are called control-coupled if one of them decides the
function of the other module or changes its flow of execution.
Example: The central hub acts as the controller, and the individual devices like Light,
thermostat, security cameras are the controlled modules.

Stamp coupling- When multiple modules share common data structure and work on
different parts of it, it is called stamp coupling.
Example: A module that receives a large object but only uses a small portion of its attributes.
This creates unnecessary dependencies and can lead to inefficiencies.
Data coupling- Data coupling is when two modules interact with each other by means of
passing data (as parameter). If a module passes data structure as parameter, then the
receiving module should use all its components.
Example: An email sending module that receives a data structure containing the email content
and recipient information from a user input module. The email sending module is independent of
the user input module and only requires the data it needs to perform its task.
Ideally, no coupling is considered to be the best.

Review of conformance to software requirements and quality.


A review of conformance to software requirements and quality is a process of
evaluating a software system to ensure that it meets the specified requirements and
standards for functionality, reliability, performance, and usability.

The following are some key components of a software review process:

1. Requirements review: This involves verifying that the software meets the
requirements specified in the software requirement specification (SRS)
document. This includes checking for completeness, consistency, and
correctness of the requirements.
2. Design review: This involves evaluating the software design to ensure that it is
able to meet the requirements specified in the SRS document. This includes
checking the architecture, interfaces, and data structures of the software.

3. Code review: This involves evaluating the source code to ensure that it is of high
quality and adheres to programming best practices and coding standards. This
includes checking for errors, bugs, and security vulnerabilities in the code.

4. Test review: This involves evaluating the testing processes and testing results to
ensure that the software has been adequately tested and is of high quality. This
includes checking for completeness and coverage of the test cases, and the
accuracy of the test results.

5. Usability review: This involves evaluating the user interface and user experience
of the software to ensure that it is easy to use and meets the needs of the
end-users.

6. Performance review: This involves evaluating the performance of the software to


ensure that it meets the specified performance requirements and standards. This
includes checking for speed, scalability, and resource utilization.

7. Reliability review: This involves evaluating the reliability of the software to ensure
that it can operate correctly and continuously under various conditions and
loads.

You might also like