Software Design

Design Concepts
• Concepts are defined as a principal idea or invention that comes into
our mind or in thought to understand something. 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.
• Abstraction (Hide Irrelevant data): Abstraction simply means to hide the details to reduce
complexity and increase efficiency or quality. Different levels of Abstraction are necessary
and must be applied at each stage of the design process so that any error that is present
can be removed to increase the efficiency of the software solution and to refine the
software solution. The solution should be described in broad ways that cover a wide range
of different things at a higher level of abstraction and a more detailed description of a
solution of software should be given at the lower level of abstraction.
• 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. It is necessary to divide the software into components known
as modules because nowadays, there are different software available like Monolithic
software that is hard to grasp for software engineers. So, modularity in design has now
become a trend and is also important. If the system contains fewer components then it
would mean the system is complex which requires a lot of effort (cost) but if we can
divide the system into components then the cost would be small.
• 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.
• 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.
• 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.
• 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.
• 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. Fowler has defined refactoring
as “the process of changing a software system in a way that it won't impact the behavior
of the design and improves the internal structure”.
• Architectural Design: The architecture of a system can be viewed as the
overall structure of the system and the way in which structure provides
conceptual integrity of the system. The architectural design identifies the
software as a system with many components interacting with each other.
At this level, the designers get the idea of the proposed solution domain.
• Preliminary or high-level design: Here the problem is decomposed into a
set of modules, the control relationship among various modules identified,
and also the interfaces among various modules are identified. The outcome
of this stage is called the program architecture. Design representation
techniques used in this stage are structure chart and UML.
• Detailed design: Once the high-level design is complete, a detailed design
is undertaken. In detailed design, each module is examined carefully to
design the data structure and algorithms. The stage outcome is
documented in the form of a module specification document.
• Principles Of Software Design :
• Should not suffer from "Tunnel Vision" - While designing the process, it
should not suffer from “tunnel vision” which means that is should not only
focus on completing or achieving the aim but on other effects also.
•
Traceable to analysis model - The design process should be traceable to
the analysis model which means it should satisfy all the requirements that
software requires to develop a high-quality product.
•
Should not "Reinvent The Wheel" - The design process should not reinvent
the wheel that means it should not waste time or effort in creating things
that already exist. Due to this, the overall development will get increased.
•
Minimize Intellectual distance - The design process should reduce the gap
between real-world problems and software solutions for that problem
meaning it should simply minimize intellectual distance.
• Exhibit uniformity and integration - The design should display uniformity which means it
should be uniform throughout the process without any change. Integration means it
should mix or combine all parts of software i.e. subsystems into one system.
•
Accommodate change - The software should be designed in such a way that it
accommodates the change implying that the software should adjust to the change that is
required to be done as per the user's need.
•
Degrade gently - The software should be designed in such a way that it degrades
gracefully which means it should work properly even if an error occurs during the
execution.
•
Assessed or quality - The design should be assessed or evaluated for the quality meaning
that during the evaluation, the quality of the design needs to be checked and focused on.
•
Review to discover errors - The design should be reviewed which means that the overall
evaluation should be done to check if there is any error present or if it can be minimized.
•
Design is not coding and coding is not design - Design means describing the logic of the
program to solve any problem and coding is a type of language that is used for the
implementation of a design.
Architectural Design
• It needs an architectural design to represent the design of the
software.
• IEEE defines architectural design as "the process of defining a
collection of hardware and software components and their interfaces
to establish the framework for the development of a computer
system."
• 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.
• This data-centered architecture will promote 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.
 • 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.
• 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.
 • 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.
• 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.
Coupling and Cohesion?
• Coupling refers to the degree of interdependence between software
modules. High coupling means that modules are closely connected
and changes in one module may affect other modules. Low coupling
means that modules are independent, and changes in one module
have little impact on other modules.
• Cohesion refers to the degree to which elements within a module
work together to fulfill a single, well-defined purpose. High cohesion
means that elements are closely related and focused on a single
purpose, while low cohesion means that elements are loosely related
and serve multiple purposes.
Types of Coupling
• 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
of each other and communicate through data. Module communications
don't contain tramp data. Example-customer billing system.
• Stamp Coupling In stamp coupling, the complete data structure is passed
from one module to another module. Therefore, it involves tramp data. It
may be necessary due to efficiency factors- this choice was made by the
insightful designer, not a lazy programmer.
• Control Coupling: If the modules communicate by passing control
information, then they are said to be control coupled. It can be bad if
parameters indicate completely different behavior and good if parameters
allow factoring and reuse of functionality. Example- sort function that takes
comparison function as an argument.
• External Coupling: In external coupling, the modules depend on other
modules, external to the software being developed or to a particular type
of hardware. Ex- protocol, external file, device format, etc.
• 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. So it has got
disadvantages like difficulty in reusing modules, reduced ability to control
data accesses, and reduced maintainability.
• 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.
• Temporal Coupling: Temporal coupling occurs when two modules depend
on the timing or order of events, such as one module needing to execute
before another. This type of coupling can result in design issues and
difficulties in testing and maintenance.
• Sequential Coupling: Sequential coupling occurs when the output of
one module is used as the input of another module, creating a chain
or sequence of dependencies. This type of coupling can be difficult to
maintain and modify.
• Communicational Coupling: Communicational coupling occurs when
two or more modules share a common communication mechanism,
such as a shared message queue or database. This type of coupling
can lead to performance issues and difficulty in debugging.
• Functional Coupling: Functional coupling occurs when two modules
depend on each other's functionality, such as one module calling a
function from another module. This type of coupling can result in
tightly-coupled code that is difficult to modify and maintain.
Types of Cohesion[high][one module]
• 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.
• Sequential Cohesion: An element outputs some data that becomes the input for
other element, i.e., data flow between the parts. It occurs naturally in functional
programming languages.
• 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. 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 unit time.
• Logical Cohesion: The elements are logically related and not
functionally. Ex- A component reads inputs from tape, disk, and
network. All the code for these functions is in the same component.
Operations are related, but the functions are significantly different.
• 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. Ex- print
next line and reverse the characters of a string in a single component.
Software Design Approach
• Functional Oriented Model(Design)
• Functional viewpoint.
• Top- down approach
• Divide and conquer approach
• DFD is used.
• Object Oriented Model(Design)
• Collection of object
• Bottom-up approach
• UML is used.
UML Diagrams
• Unified Modeling Language (UML) is a standardized visual modeling
language that is a versatile, flexible, and user-friendly method for
visualizing a system's design.
• Software system artifacts can be specified, visualized, built, and
documented with the use of UML.
• We use UML diagrams to show the behavior and structure of a system.
• UML helps software engineers, businessmen, and system architects with
modeling, design, and analysis.
• Complex applications need collaboration and planning from multiple teams
and hence require a clear and concise way to communicate amongst them.
Types of UML Diagrams
class Diagrams
• In these diagrams, classes are depicted as boxes, each containing
three compartments for the class name, attributes, and methods.
Lines connecting classes illustrate associations, showing relationships
such as one-to-one or one-to-many.
• Class diagrams provide a high-level overview of a system's design,
helping to communicate and document the structure of the software.
They are a fundamental tool in object-oriented design and play a
crucial role in the software development lifecycle.
•class
• (OOP), a class is a blueprint or template for creating objects. Objects are
instances of classes, and each class defines a set of attributes (data
members) and methods (functions or procedures) that the objects created
from that class will possess. The attributes represent the characteristics or
properties of the object, while the methods define the behaviors or actions
that the object can perform.
• Class Name:
• The name of the class is typically written in the top compartment of the class box
and is centered and bold.
• Attributes:
• Attributes, also known as properties or fields, represent the data members of the
class. They are listed in the second compartment of the class box and often include
the visibility (e.g., public, private) and the data type of each attribute.
• Methods:
• Methods, also known as functions or operations, represent the behavior or
functionality of the class. They are listed in the third compartment of the class box
and include the visibility (e.g., public, private), return type, and parameters of each
method.
• Visibility Notation:Visibility notations indicate the access level of
attributes and methods. Common visibility notations include
• + for public - visible to all classes
• - for private - visible only within the class
• # for protected - visible to subclasses
• ~ for package or default visibility - visible to classes in the same
package
•Relationships between classes
• Association
• An association represents a bi-directional relationship between two classes.
• Directed Association
• A directed association in a UML class diagram represents a relationship between
two classes where the association has a direction, indicating that one class is
associated with another in a specific way.
• Aggregation
• Aggregation is a specialized form of association that represents a "whole-part"
relationship.
• Aggregation is represented by a diamond shape on the side of the whole class. In
this kind of relationship, the child class can exist independently of its parent class.
• Composition
• Composition is a stronger form of aggregation, indicating a more significant
ownership or dependency relationship.
• Composition is represented by a filled diamond shape on the side of the whole
class.
• Generalization(Inheritance)
• Inheritance represents an "is-a" relationship between classes, where one class (the
subclass or child) inherits the properties and behaviors of another class (the superclass or
parent).
• Inheritance is depicted by a solid line with a closed, hollow arrowhead pointing from the
subclass to the superclass.
• Realization (Interface Implementation)
• Realization indicates that a class implements the features of an interface.
• Realization is depicted by a dashed line with an open arrowhead pointing from the
implementing class to the interface.
• Dependency Relationship
• A dependency exists between two classes when one class relies on another, but the
relationship is not as strong as association or inheritance.
• It represents a more loosely coupled connection between classes. Dependencies are
often depicted as a dashed arrow.
• Usage(Dependency) Relationship
• A usage dependency relationship in a UML class diagram indicates that one class (the
client) utilizes or depends on another class (the supplier) to perform certain tasks or
access certain functionality.
• How to draw Class Diagrams
• Step 1: Identify Classes:
• Start by identifying the classes in your system. A class represents a
blueprint for objects and should encapsulate related attributes and
methods.
• Step 2: List Attributes and Methods:
• For each class, list its attributes (properties, fields) and methods
(functions, operations). Include information such as data types and
visibility (public, private, protected).
• Step 3: Identify Relationships:
• Determine the relationships between classes. Common relationships
include associations, aggregations, compositions, inheritance, and
dependencies. Understand the nature and multiplicity of these
relationships.
Step 4: Create Class Boxes:
• Draw a rectangle (class box) for each class identified. Place the class
name in the top compartment of the box. Divide the box into
compartments for attributes and methods.
• Step 5: Add Attributes and Methods:
• Inside each class box, list the attributes and methods in their respective
compartments. Use visibility notations (+ for public, - for private, # for
protected, ~ for package/default).
• Step 6: Draw Relationships:
• Draw lines to represent relationships between classes. Use arrows to
indicate the direction of associations or dependencies. Different line
types or notations may be used for various relationships.
• Step 7: Label Relationships:
• Label the relationships with multiplicity and role names if needed.
Multiplicity indicates the number of instances involved in the
relationship, and role names clarify the role of each class in the
relationship.
• Step 8: Review and Refine:
• Review your class diagram to ensure it accurately represents the
system's structure and relationships. Refine the diagram as needed
based on feedback and requirements.
State Chart Diagram
• The state diagram is a behaviour UML diagram. So, it depicts the
behaviour or dynamic aspect of a system. By dynamic aspect, we
mean that a state diagram represents the state or condition of a
system at a finite instance of time. These diagrams are also known
as state machine diagrams or state chart diagrams.
• Components Of A State Chart Diagram
• Initial State- Initial state represents the starting point of the state
diagram. A black filled circle represents it.
• State - State represents the condition of a system at a finite instance
of time. A rounded rectangle represents it.
Activity Diagram
• Activity diagrams show the steps involved in how a system works,
helping us understand the flow of control. They display the order in
which activities happen and whether they occur one after the other
(sequential) or at the same time (concurrent). These diagrams help
explain what triggers certain actions or events in a system.
• An activity diagram starts from an initial point and ends at a final
point, showing different decision paths along the way.
• They are often used in business and process modeling to show how a
system behaves over time.
Notations
Step to Draw an Activity Diagram
• Step 1. Identify the Initial State and Final States:
• Step 2. Identify the Intermediate Activities Needed:
• Step 3. Identify the Conditions or Constraints:
• Step 4. Draw the Diagram with Appropriate Notations:
Use Case Diagram
• A Use Case Diagram is a type of Unified Modeling Language (UML)
diagram that represents the interaction between actors (users or
external systems) and a system under consideration to accomplish
specific goals. It provides a high-level view of the system's
functionality by illustrating the various ways users can interact with it.
• Notation
• Actors
• Use Cases
• System Boundary
• Relationships
• Association Relationship
• Include Relationship
• Extend Relationship
• Generalization Relationship
• Steps to draw a Use Case diagram
• Step 1: Identify Actors: Determine who or what interacts with the system.
These are your actors. They can be users, other systems, or external
entities.
• Step 2: Identify Use Cases: Identify the main functionalities or actions the
system must perform. These are your use cases. Each use case should
represent a specific piece of functionality.
• Step 3: Connect Actors and Use Cases: Draw lines (associations) between
actors and the use cases they are involved in. This represents the
interactions between actors and the system.
• Step 4: Add System Boundary: Draw a box around the actors and use cases
to represent the system boundary. This defines the scope of your system.
• Step 5: Define Relationships: If certain use cases are related or if one
use case is an extension of another, you can indicate these
relationships with appropriate notations.
• Step 6: Review and Refine: Step back and review your diagram.
Ensure that it accurately represents the interactions and relationships
in your system. Refine as needed.
• Step 7: Validate: Share your use case diagram with stakeholders and
gather feedback. Ensure that it aligns with their understanding of the
system's functionality.
Sequence Diagrams
• Sequence diagrams are a type of UML (Unified Modeling Language)
diagram that visually represent the interactions between objects or
components in a system over time.
• They focus on the order and timing of messages or events exchanged
between different system elements.
•Notation
• Actors
• Object
• Lifelines
• Messages
• Activation bar
• Request
• Response
• Steps to create Sequence Diagrams
• Step 1: Identify the Scenario:
• Understand the specific scenario or use case that you want to represent in the sequence diagram.
This could be a specific interaction between objects or the flow of messages in a particular process.
• Step 2: List the Participants:
• Identify the participants (objects or actors) involved in the scenario. Participants can be users,
systems, or external entities.
• Step 3: Define Lifelines:
• Draw a vertical dashed line for each participant, representing the lifeline of each object over time.
The lifeline represents the existence of an object during the interaction.
• Step 4: Arrange Lifelines:
• Position the lifelines horizontally in the order of their involvement in the interaction. This helps in
visualizing the flow of messages between participants.
• Step 5: Add Activation Bars:
• For each message, draw an activation bar on the lifeline of the sending participant. The activation
bar represents the duration of time during which the participant is actively processing the message.
• Step 6: Draw Messages:
• Use arrows to represent messages between participants. Messages flow horizontally between
lifelines, indicating the communication between objects. Different types of messages include
synchronous (solid arrow), asynchronous (dashed arrow), and self-messages.
• Step 7: Include Return Messages:
• If a participant sends a response message, draw a dashed arrow returning to the original sender to
represent the return message.
• Step 8: Indicate Timing and Order:
• Use numbers to indicate the order of messages in the sequence. You can also use vertical
dashed lines to represent occurrences of events or the passage of time.
• Step 9: Include Conditions and Loops:
• Use combined fragments to represent conditions (like if statements) and loops in the
interaction. This adds complexity to the sequence diagram and helps in detailing the
control flow.
• Step 10: Consider Parallel Execution:
• If there are parallel activities happening, represent them by drawing parallel vertical
dashed lines and placing the messages accordingly.
• Step 11: Review and Refine:
• Review the sequence diagram for clarity and correctness. Ensure that it accurately
represents the intended interaction. Refine as needed.
• Step 12: Add Annotations and Comments:
• Include any additional information, annotations, or comments that provide context or
clarification for elements in the diagram.
• Step 13: Document Assumptions and Constraints:
• If there are any assumptions or constraints related to the interaction, document them
alongside the diagram.
• Step 14: Tools:
• Use a UML modeling tool or diagramming software to create a neat and
professional-looking sequence diagram. These tools often provide features for easy editing,
collaboration, and documentation.
Data Dictionary
• it is a centralized repository of information about data. It provides a
detailed description of the data, including its meaning, relationship to
other data, usage, and format.
• These are important in database management, data modeling, and
software development.
• It helps to ensure consistency, clarity, and efficient data
management.
• It helps to ensure that everyone in the organization understands the
data, how it should be used, and how it should be managed.
• It is essential for maintaining data quality and facilitating effective
data governance.
• Components of Data Dictionary
• Data Elements: This includes the attributes of the data element such as Name,
Description, Type, Length, Default Value, and Constraints.
• Data Structure: This includes Tables, Fields, Keys, and Indexes.
• Relationships: This includes information about the Relationships and
Dependencies.
• Usage and Access Information: This includes Access Permissions, Usage, and
Update Frequency.
• Data Quality Metrics: This includes information regarding Accuracy,
Completeness, Consistency, and Timelines about data.
• Data Lineage: Information about the Source, Transformation, and Destination of
data is included.
• Versioning and History: Version and History of the data element definition are
recorded.
• Technical Metadata: Storage Information and Storage Format are also recorded.
• Business Metadata: Business Rules and the Business Context in which the data is
used are included.
Create a Data Dictionary
• Define Scope and Objectives: This involves identifying the objective of the data
dictionary and the data elements it will cover.
• Gather Metadata: Collect detailed information about each data element.
• Organize Information: Structure the collected metadata in a clear and accessible
format.
• Implement Standard Naming Conventions: Ensure consistency in how data
elements are named and described.
• Create and Enter Data in Data Dictionary: Use software tools to build the data
dictionary and enter the data.
• Review and Validate: Ensure the accuracy and completeness of the data
dictionary.
• Maintain and Update Regularly: Keep the data dictionary up to date with ongoing
updates and changes.