Fundamentals of Software Engineering

Instructor: Meti Dejene

[email protected]
Haramaya University
Chapter 5 – Software Design
 Software Design
After requirements analysis and specification, the next phase in SDLC is software
design.

Software design refers to the process of conceptualizing how a software system will be
implemented, and specifying the structure, behavior, and characteristics of a software
system to meet specific requirements and quality criteria.

It is an iterative process through which requirements are translated into a detailed

“blueprint” for constructing the software.

During this phase, the software architecture, components, modules, interfaces, and data
are defined in detail.
 Cont.
To achieve this, the design phase takes the SRS document and transform the
requirements specified in the SRS document into a structure that is suitable for
implementation using a programming language in the subsequent (coding) phase.

So, software design creates a blueprint, representation or model of the software which
provides detail about software architecture, data structures, interfaces, and
components that are necessary to implement the system.
 The Design Process

Design in Software engineering is an iterative process.

➢ A good software design is seldom realized by using a single step procedure, rather it

requires iterating over a series of steps and design activities.

Thus, we can broadly classify design into two.

1. Preliminary design (also called High-level design or Architectural design) and

2. Detailed design (also called Low-level design).

 1. High-level design

High-level design involves

➢ decomposing the system into subsystems, components and many small functionally

independent modules,

➢ identifying the interfaces between subsystems, components, modules, and

➢ identifying the invocation and control relationships among the modules.

The outcome of high-level software design is the software architecture.

 Software Architecture
Any complex system is composed of subsystems that interact so that the system
provides the expected behavior.

When designing such systems, therefore, the logical approach is to identify the
subsystems that should compose the system, the interfaces of these subsystems, and
the rules for interaction between the subsystems.

➢ This is what software architecture aims to do.

Meaning, architecture partitions the system in to logical parts such that each part can
be understood independently, and then describes the system in terms of these parts
and as a set of communicating components.
 Cont.
Software architecture refers to the fundamental organization of a software system,
encompassing its components, structure, relationships, and principles governing their
design.
➢ Components: The building blocks of the software system, each responsible for specific
functionality.

➢ Structure: The arrangement and organization of components within the system, defining
how they interact and collaborate to achieve the system's goals.

➢ Relationships: The connections and dependencies between components, specifying how

they communicate, share data, and coordinate their activities.
 Cont.

Generally speaking, architecture of a software system is a very high level view of

➢ the overall structural parts (components or modules) of the system,

➢ how they are related to form the whole system,

➢ the arrangement and interaction of components, as well as the distribution of

responsibilities.
 Cont.
Thus, software design begins with deriving an architectural rendering of a system that
serves as a framework later for detailed design activities.

The architectural design for software is the equivalent to the floor plan of a house.

The floor plan depicts the overall layout of the rooms; their size, shape, and
relationship to one another; and the doors and windows that allow movement into and
out of the rooms.

The floor plan gives us an overall view of the house.

Likewise, software architectural design elements give us an overall view of the software.

The architectural design process yields an architectural model.

 Cont.

One major aspect to keep in mind is that, due to a wide range of options now available
for how a system may be configured and connected, carefully designing the
architecture becomes very important.

➢ This is mainly because, as the software systems increasingly become distributed

and more complex, the way in which these components are organized and
communicate affects the performance, robustness, and maintainability of a system.

Thus, selecting appropriate architectural styles and patterns is key to achieve the
desired system qualities.
 2. Low-level design

Detailed design focuses on refining the high-level architecture and system components
identified in earlier stages into more concrete details.

Here, each component/module is examined carefully and internals of the individual

modules such as the data structures and algorithms of the modules are designed and
documented.
 Cont.
Detailed design also involves

➢Designing the database schema and data model

➢Designing strategies for handling errors, exceptions, and failures gracefully.

➢Designing the user interface (UI) components, layout, navigation flow, and
interaction patterns to create an intuitive and visually appealing user experience.

➢Designing security measures (authentication, authorization, encryption, and secure

communication mechanisms) to protect the software system.

➢Specifying performance optimization techniques

 Cont.

So overall in software design,

❖ Initially the design is represented at a high level of abstraction and the blueprint
depicts a holistic view of software.

❖ Then, as design iterations occur, subsequent refinement leads to design

representations at much lower levels of abstraction.
 Approaches to Software Design

There are two fundamentally different approaches to software design that are in use
today. These are:

1. Function-oriented design, and

2. Object-oriented design.
 1. Function-oriented Design
This is a design approach in which a system is designed from a functional viewpoint to
achieve functional decomposition of the system.

That is, each function that the system needs to perform is analyzed, hierarchically
decomposed into more detailed functions and mapped to a module structure.

One feature of the function-oriented design approach is using top-down

decomposition.

In top-down decomposition, starting at a high-level view of the system, each high-level

function is successively refined into more detailed functions.
 2. Object-oriented Design (OOD)

In object-oriented design approach, a system is viewed as being made up of a

collection of objects (i.e., entities).

Each object essentially contains its own data that is called attributes of the object and
associated set of operations (termed as methods) that operate on those data.

So, objects are the basic building blocks of an OO design, just like functions and
modules are for a function-oriented design.

Objects appear as nouns in the problem description; whereas functions appear as

verbs.
 Basic Concepts and Principles in Software Design
Modularization

➢ Modularization is the process of continuous decomposition of the software system

into multiple discrete modules until fine-grained components are created.

➢ This determines complexity of the design solution greatly.

➢ Modular design implements the rules of ‘divide and conquer’ problem-solving

strategy.
 Cont.
Stepwise refinement

➢Refinement is a process of elaboration.

➢This is a top-down strategy where a design is refined with increasing levels of details.

➢The process should proceed from a highly conceptual model to lower level details.

Information Hiding

➢ Simply put, information hiding implies concealing information so that an unauthorized

entity cannot access it.

➢ Modules should be specified and designed so that information (algorithms and data)
contained within a module is obscured and inaccessible to other modules that have no
need for such information.
 Cont.
Abstraction

➢ Abstraction is the removal of the irrelevant and the amplification of the essentials.

Coupling

➢ Coupling is an indication of the manner in which modules are connected to one

another.

➢ It is a measure of the degree of interdependence between the two modules.

➢ The lower the coupling, the better is the program design.

 Cont.
Cohesion

➢ Cohesion is a measure that defines the degree to which different elements within

one module co-operate to work towards a single objective.

➢ It is a measure of the functional strength of a module.

➢ The greater the cohesion, the better is the program design.

 Software Design Patterns
A Software Design Pattern is a general, reusable solution to a commonly occurring
problem within a given context in software design.

➢ Design patterns provide an abstract description of good practice, a set of proven

solutions or a template, which has been tried and tested in different systems and
environments.

Each problem and its solution is described by a design pattern that has been cataloged and
vetted by other software engineers who have encountered the problem and implemented
the solution while designing other applications.

By using these existing proven design patterns, you can avoid “reinventing the wheel” and
save time and effort.
 Good Software Design
A few desirable characteristics that every good software design must possess are:
A. Understandability: A good design should be easily understandable.
➢ Unless a design solution is easily understandable, it would be difficult to implement and
maintain it.
➢ This would lead to severely increased development costs and the effort required to
maintain the product.
➢ A design solution to be easily understandable:

❖ It should assign consistent and meaningful names to various design components.

❖ It should make use of the principles of decomposition and abstraction in good

measures to simplify the design.
 Cont.

B. Efficiency: A good design solution should adequately address resource, time, and cost
optimization issues.

C. Maintainability: A good design should be easy to change. This is an important

requirement, since change requests usually keep coming from the customer even after
product release.
 Design Review

After a design is complete, the design is required to be reviewed.

➢ The design documents are reviewed by the members of the development team to

ensure that the design solution conforms to the requirements specification.

 Cont.

The review team checks the design documents especially for the following aspects:
❖ Traceability: check whether each requirement in the SRS document can be traced to the
design model and vice versa.

❖ Correctness: whether the algorithms and data structures of the detailed design are
correct.

❖ Maintainability: whether the design can be easily maintained in future.

❖ Implementation: whether the design can be easily and efficiently be implemented.

 Summary of the design process and its relevance
Overall, the design process works to determine the following aspects about a software.

❖ Different modules required: The different modules in the solution are identified. Each
module is a collection of functions and the data shared by these functions. Each module
should accomplish some well-defined task out of the overall responsibility of the software.

❖ Control relationships among modules: A control relationship between two modules essentially
arises due to function calls across the two modules.

❖ Interfaces among different modules: The interfaces between two modules identifies the exact
data items that are exchanged between the two modules when one module invokes a
function of the other module.
 Cont.
❖ Data structures of the individual modules: Each module normally stores some data that the
functions of the module need to share to accomplish the overall responsibility of the
module. Suitable data structures for storing and managing the data of a module need to be
properly designed and documented.

❖ Algorithms required to implement the individual modules: Each function in a module usually
performs some processing activity. The algorithms required to accomplish the processing
activities of various modules need to be carefully designed and documented with due
considerations given to the accuracy of the results, space and time complexities
System Modelling
 Cont.

A model is an abstraction of the system being studied.

An abstraction deliberately simplifies, leaves out detail and picks out the most salient
characteristics.

System modeling is the process of developing such abstract models of a system, with
each model presenting a different view or perspective of that system in order to
obtain a better understanding of the system being developed.
 Cont.
A model can be used for a variety of purposes.

So, it is reasonable to expect that the models would vary with respect to the details they
capture and this would depend on the purpose for which these models are being
constructed.

➢ For example, analysis models should be different from design models.

Analysis models show "what" the system shall provide while a model constructed for
design purposes (design models) should capture all the design decisions on "how"
system shall be structured into components.
 Cont.
A model in the context of software development can be textual, mathematical (formal),
or graphical.

Of these, graphical models are very popular among software developers because these
are easy to understand and construct.

Over the years, although various graphical models are proposed, Unified Modeling
Language (UML) is primarily the most prevalent graphical modeling language.
 Cont.
As the name itself implies, UML is a standard modeling language for object-oriented
modeling.

➢ It can be used to visualize, specify, and document the artifacts of a software system.

As is the case with any other language, UML has its syntax (a set of basic symbols,
graphical notations and sentence formation rules) and semantics (meanings of basic
symbols and sentences).

The UML contains an extensive set of diagram types to help document several aspects
(views) of a design solution.
 Cont.

In a broader view, UML diagrams mainly represent two different views of a system
model:

1. Static (or structural) view

2. Dynamic (or behavioral) view

 Cont.
1. Static (or structural) view

This view emphasizes the static structure of the system using objects, attributes,
operations and relationships.

For example, Class diagrams.

❖ Class diagrams are used when developing an object-oriented system model to show
the object classes in a system and the associations between these classes.
Different representations of the LibraryMember class
 Cont.
2. Dynamic (or behavioral) view

This view emphasizes the dynamic behavior of the system by showing collaborations
among objects and changes to the internal states of objects.

It captures interaction between user the system, interaction between the system being
developed and other systems or interaction between the components of the system.

For example use case diagrams, sequence diagrams, activity diagrams, state diagrams.
 Cont.
Use case diagram is mostly used to model interactions between a system and external
actors (users or other systems).

Sequence diagrams are used to model interactions between system components.

➢ As the name implies, a sequence diagram shows the sequence of interactions that
take place during a particular use case or use case instance.

Activity diagrams are intended to show the activities that make up a given system
process and the flow of control from one activity to another.
 Cont.
State diagrams are event-driven models that shows how a system responds to external
and internal events.

➢ It is based on the assumption that a system has a finite number of states and that
events (stimuli) may cause a transition from one state to another. So, State diagrams
show system states and events that cause transitions from one state to another.
Use case diagram of the Super market prize scheme
➢ A sequence diagram that illustrates the interactions involved in the View patient
information use case, where a medical receptionist can see some patient information.
Sample Activity diagram for Login
Sample state diagram