Unit III
Software Design
The Software Design Process
Software design is a process that transforms software requirements into
implementation. The output of software design process is a blueprint of the
requirements gathered during the software gathering phase and described in the
SRS. This blueprint serves as a base for developing the software system.
Software design is the first step in SDLC, which moves the concentration from
problem domain to solution domain. It defines software methods, objects, functions,
and the overall interaction and code structure.
IEEE defines software design as ‘both a process of defining, the architecture,
components, interfaces, and other characteristics of a system and the result of that
process.’
The design process is a sequence of steps that describe all aspects of the software.
Creative skill, past experience, helps in designing a "good" software.
A set of principles for software design
1. The design process should not suffer from "tunnel vision."
A good designer should consider alternative approaches, each based on the
requirements, the resources available.
2. The design should be traceable to the analysis model.
It is necessary to have a means for tracking how requirements have been satisfied by
the design model.
3. The design should not reinvent the wheel. Time is short and resources are
limited; design time should be invested in representing truly new ideas.
4. The design should "minimize the distance" between the software and the
problem as it exists in the real world. i.e., the structure of the software design
should, copy the structure of the problem domain.
5. The design should exhibit uniformity and integration. A design is uniform if it
appears fully coherent. In order to achieve this, rules of style and format should be
defined before design work begins.
6. The design should be structured to accommodate changes.
7. Design is not coding; coding is not design.
8. The design should be reviewed to minimize errors.
A design team should ensure that major conceptual elements of the design have
been addressed.
Design Concepts
Abstraction - is the process of reducing the information in order to retain only the
information which is relevant for a particular purpose. It is, representing essential
features without including the background details or explanations.
Refinement/Modularity - is the process of elaboration. A hierarchy is developed by
decomposing in a step-wise fashion. In each step, programs are decomposed into
more detailed instructions. Software is divided into components called modules.
Software Architecture - It refers to the overall structure of the software and the ways
in which that structure provides integrity for a system. Good software architecture
gives good performance, quality, schedule and cost.
Data Structure - It is a representation of the logical relationship among individual
elements of data.
Software Procedure - It focuses on the processing of each module individually.
Information Hiding - Modules should be specified and designed so that information
contained within a module is inaccessible to other modules that have no need for
such information.
What is Software Modeling? Software modeling refers to the creation of models of a
software system to help visualize, understand, communicate, and design its
components, behavior, and interaction. These models are used to visually represent
how software components will interact, the structure of the system, or how the system
will behave in various scenarios.
Software Modeling is Important for:
•Communication: It helps in communicating ideas and designs with teams and
stakeholders.
•Design: Helps in planning the software architecture before coding begins.
•Clarity: It clarifies the software's structure, behavior, and interactions.
•Problem-Solving: It aids in identifying problems early on, allowing for easier
corrections and improvements.
•Analysis and Testing: Enables early testing of system designs and analysis of
potential issues.
•Complexity Management: Simplifies the complexity of large systems by breaking
them into manageable parts.
Role of UML (Unified Modeling Language) in Software Modeling
What is UML? UML is a standardized set of graphical notations used to model the
structure and behavior of software systems.
•UML is a standardized visual language
used to model software systems. It
provides a common language for
developers, analysts, and designers to
visually represent their software.
•It provides a set of graphical notation techniques to create models for software
systems, covering structure, behavior, and interaction.
History and Evolution of UML
• UML was developed in the 1990s as a way to standardize and unify various
modeling methods.
• It has become a standard for software modeling, widely adopted in software
industry.
Purpose and Benefits of UML:
•Standardized: UML offers a universal set of diagrams, notations and semantics that
are accepted worldwide, enabling consistency across projects and teams.
•Clarity and Communication: UML provides clear visualizations, helping team
members and stakeholders understand the system’s design.
•Flexibility: UML can model a wide variety of systems, from object-oriented to event-
driven systems, and from traditional to Agile approaches.
•Documentation: UML helps document the system's design for future reference to
herlp in maintenance.
•Widely Accepted: It is used across different types of software development
environments and industries.
What it is A set of rules for drawing diagrams to model software systems
Purpose To standardize the way software systems are designed and
documented
Who uses it Software engineers, business analysts, and software architects
What it's used for To design, document, and visualize software systems
How it works Uses diagrams to represent the structure, behavior, and boundary
of a system
The nine standard UML diagrams are: use case, class, object, sequence, collaboration,
state chart, activity, component, and deployment diagrams.
Types of diagrams in UML
Behavioral Diagrams--DYNAMIC
•Use Case Diagram: Models the interactions between a system and its external actors
(users).
•Activity Diagram: Depicts the flow of activities and processes within a system.
•State chart Diagram (State Diagram): Visualizes the states of an object and the
transitions between them.
•Sequence Diagram: Shows the interactions between objects over time, emphasizing
the order of messages.
•Communication Diagram (Collaboration Diagram): Depicts the interactions
between objects, focusing on the structure of the interactions.
Structural Diagrams---STATIC (Component/Attributes/Relation)
Class Diagram:
•Represents the static structure of a system, including classes, attributes, and
relationships.
•Object Diagram:
•Shows a snapshot of the objects and their relationships in a system at a specific point
in time.
•Component Diagram:
•Models the components of a system and their interfaces, focusing on the physical
structure.
•Deployment Diagram:
•Visualizes the physical deployment of the system's components on hardware nodes.
Comparison between Behavioural Diagrams and Structural Diagrams
Aspect Behavioral Diagrams Structural Diagrams
Focus on the dynamic behavior of the Focus on the static structure and
Purpose
system. organization of the system.
Behavior, interactions, states, and System's components, relationships,
What they model
changes over time. and their organization.
Use Case Diagram, Sequence
Class Diagram, Object Diagram,
Diagram, Activity Diagram, State
Component Diagram, Deployment
Examples Diagram, Communication Diagram,
Diagram, Composite Structure
Interaction Overview Diagram, Timing
Diagram, Package Diagram
Diagram
Describes how the system behaves or Describes the static structure and
Type of information
operates. architecture of the system.
Focus on activities, interactions, and Focus on objects, classes,
Focus
events. components, and their relationships.
Static (shows how elements are
Dynamic vs Static Dynamic (shows changes over time). organized at a particular point in
time).
Actors, events, messages, states, Classes, objects, components, nodes,
Key Elements
transitions, activities. packages.
Used for understanding system Used for defining system components
When used
behavior and interactions. and their relationships.
Modeling the flow of messages Defining the class structure and the
Example Use Case
between objects. relationship between different entities.
Focuses on the interaction between Focuses on the structure of entities and
Interaction
entities. their relationships.
Practical Examples and Applications of UML
Use Case: A use case diagram can be drawn to show
how a customer (actor) interacts with an online shopping
application. The use case might include "Login," "Add to
Cart," and "Checkout," illustrating the system's
functionality from the user's perspective.
Actors in an Online Shopping Application:
1.Customer: A user who browses the store, makes
purchases, and tracks their orders.
2.Admin: The store administrator who manages products,
processes orders, and handles customer queries.
3.System: The system is responsible for operations like
payment processing, inventory updates, etc.
Class Diagram: The most widely use UML diagram is the class diagram. It is
the building block of all object oriented software systems.
We use class diagrams to depict the
static structure of a system by
showing system’s classes, their
methods and attributes. Class
diagrams also help us identify
relationship between different classes
or objects.
•Sequence Diagram: A sequence diagram can be used to show how objects
communicate in the "Checkout" process, including interactions like "Customer"
sending a "placeOrder" message to "ShoppingCart," which in turn sends a
"calculateTotal" message to the "Product" class.
A Sequence Diagram illustrates how objects in a system interact with one another
in a specific sequence. In the case of an Online Shopping System, the sequence
diagram shows the interaction between different components (such as Customer,
ShoppingCart, Order, Payment, etc.) for a particular use case, like placing an order.
Scenario for the Sequence Diagram:
Let's consider the scenario where a Customer places an order and makes a
payment. This involves several steps:
1.The Customer browses products and adds items to the ShoppingCart.
2.The Customer proceeds to checkout and places an order.
3.The System verifies the order and processes the payment.
4.The System sends an order confirmation and updates the inventory.
Participants (Objects):
•Customer: The user who is making the purchase.
•ShoppingCart: Manages the products added by the customer.
•Order: Represents the order placed by the customer.
•Product: Represents the individual products in the system.
•Payment: Handles the payment process.
•Inventory: Updates the product stock.
•System: Manages the overall process.
Challenges and limitations of using UML in Software Engineering
•UML is large and can sometimes grow in complexity.
•UML may result in ignoring the genuine program and overanalyzing the underlying
problem.
•It takes a lot of time to manage the diagrams and keep them consistent with each
other.
Coupling and Cohesion: When a software program is modularized, its tasks are
divided into several modules based on some characteristics. Modules are set of
instructions put together in order to achieve some tasks, may refer to each other to
work together. 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 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.
Coupling is a measure that defines the level of inter-dependability among modules of
a program. The lower the coupling, the better the program.
Why are they important?
Coupling and cohesion are very important because help us to find a balance between
the system components. We need Less coupling and high cohesion in our software
source code.
What is a Coupling?
Coupling in software development refers to the extent to which one component or
module depends on another.
A high degree of coupling indicates that the components are closely related and
changes in one can have significant effects on others. On the other hand, a low
degree of coupling means that components are independent of each other and can be
changed or reused without significantly affecting other components.
Cohesion is how much the elements consisting a whole(in our case
let's say a class) can be said that they actually belong together. Thus,
it is a measure of how strongly related each piece of functionality
expressed by the source code of a software module is.
One way of looking at cohesion in terms of OO is if the methods in the
class are using any of the private attributes.
High Cohesion (or the cohesion's best type - the functional
cohesion) is when parts of a module are grouped because they all
contribute to a single well-defined task of the module.
Types of Cohesion:
1. Functional Cohesion: Every essential element for a single
computation is contained in the component. A functional cohesion
performs the task and functions. It is an ideal situation.
2. Sequential Cohesion: An element outputs some data that
becomes the input for other element, i.e., data flow between the
parts.
3. Communicational Cohesion: Two elements operate on the same
input data or contribute towards the same output data. Example-
update record in the database and send it to the printer.
Procedural Cohesion: Elements of procedural cohesion ensure the
order of execution. Actions are still weakly connected and unlikely to
be reusable. Ex- calculate student GPA, print student record,
calculate cumulative GPA, print cumulative GPA.
Temporal Cohesion: The elements are related by their timing
involved. In a module connected with temporal cohesion, all the tasks
must be executed in the same time-span. This cohesion contains the
code for initializing all the parts of the system. Lots of different
activities occur, all at same time.
Logical Cohesion: The elements are logically related and not
functionally. Ex- A component reads inputs from tape, disk, and
network.
Coincidental Cohesion: The elements
are not related(unrelated). The elements
have no conceptual relationship other
than location in source code. It is
accidental and the worst form of
cohesion.
Coupling is how much one component (imagine a class) knows
about the inner workings or inner elements of another one, i.e. how
much knowledge it has of the other component.
Loose coupling is a method of interconnecting the components in a
system or network so that those components, depend on each other
to the least extent practically possible…
Types of Coupling:
1. Data Coupling: if the dependency between the modules is based
on the fact that they communicate by passing only data, then the
modules are said to be data coupled. In data coupling, the
components are independent to each other and communicating
through data.
2. Stamp Coupling: In stamp coupling, the complete data structure is
passed from one module to another module.
3. Control Coupling: If the modules communicate by passing
control information, then they are said to be control coupled.
4. External Coupling: In external coupling, the modules depend on
other modules, external to the software being developed or to a
particular type of hardware.
5. Common Coupling: The modules have
shared data such as global data structures. The
changes in global data mean tracing back to all
modules which access that data to evaluate the
effect of the change.
6. Content Coupling: In a content coupling,
one module can modify the data of another
module or control flow is passed from one
module to the other module. This is the worst
form of coupling and should be avoided.
Design Verification: The output of software design process is design
documentation, pseudo codes, detailed logic diagrams, process
diagrams and detailed description of all functional or non-functional
requirements.
The next phase, which is the implementation of software, depends on
all outputs mentioned above.
It then becomes necessary to verify the output before proceeding to
the next phase. The early any mistake is detected, the better it is or it
might not be detected until testing of the product.
A good design review is important for good software design, accuracy
and quality.
Tight coupling:
An example of tight coupling in software development
could be a system where Class A directly calls the
methods of Class B.
For example, let’s say we have a Class “StarShip” and a Class “Engine”. If the Class
“StarShip” has a direct reference to the Class “Engine” object and uses its methods to
function, it means that the Class “StarShip” is tightly coupled to the Class “Engine”.
Taking the example above, If any change is made to the Class “Engine”, for example
renaming a method, the Class “StarShip” would also have to be modified to handle the
change at time to call the method with the new name, that kind of cases increases the
complexity of maintaining the system.
Loose coupling: Loose coupling in software development could be a
system where Class A uses an interface to interact with
Class B.
For example, if the Class “StarShip” implements an interface “IEngine” and uses the
interface to interact with a specific instance of Class “Engine”, it means that the
Class “StarShip” is loosely coupled to the Class “Engine”, as the Class “StarShip”
does not have a direct reference to the Class “Engine” and only uses the interface.
This allows for a greater degree of flexibility, as different implementations of the
“IEngine” interface can be swapped out without affecting the Class “StarShip”.
In summary, coupling refers to the degree of dependency between components in a
software system.
Tight coupling means that components are closely related and changes to one
component can significantly affect others. On the other hand, loose coupling means
that components are independent of each other and can be changed or reused
without significantly affecting other components.
