Fundamental Software Engineering

SEng2051

Chapter Four

1
Fundamental Software Engineering
CoSc 3091

Chapter Four

2
Fundamental Software Engineering
CoSc 3091

Chapter Four

3
Fundamental Software Engineering
CoSc 3091

Chapter Four

4
Fundamental Software Engineering
CoSc 3091

Chapter Four

5
Fundamental Software Engineering
CoSc 3091

Chapter Four

6
Fundamental Software Engineering
CoSc 3091

Chapter Four

7
Fundamental Software Engineering
CoSc 3091

Chapter Four

8
Software
Design
 Software design model consists of 4
designs:
 Data/class Design
 Architectural Design
 Interface Design
 Component Design

9
 Cont.…
 Data/class design - Created by transforming the analysis model class-
based elements into classes and data structures required to implement
the software
 Architectural design - defines the relationships among the major
structural elements of the software, it is derived from the class-based
elements and flow-oriented elements of the analysis model
 Interface design - describes how the software elements, hardware
elements, and end-users communicate with one another, it is derived from
the analysis model scenario-based elements, flow-oriented elements, and
behavioral elements
 Component-level design - created by transforming the structural
elements defined by the software architecture into a procedural
description of the software components using information obtained from
the analysis model class-based elements, flow-oriented elements, and
behavioral elements

3
Why design is so
important?
 It is place where quality is fostered.
 It provides us with representation of software
that can be
assessed for quality.
 Only way that can accurately translate a
customer’s requirements into a finished
software product.
 It serves as foundation for all software
engineering activities.
 Without design difficult to assess:
 Risk
 Test
 Quality

1
1
Design Process and Design
Quality
 S/w design is an iterative process through
which requirements are translated into a
“blueprint” for constructing the s/w.
 As design iteration occur, subsequent
refinement leads to design representation at
much lower levels of abstraction.

1
2
Goal of design
process
 The design must implement all of the explicit
requirements contained in the analysis
model, and it must accommodate all of the
implicit requirements desired by the
customer.
 The design must be a readable, understandable
guide for those who generate code and for
those who test and subsequently support the
software.
 The design should provide a complete picture of
the software, addressing the data, functional,
and behavioral domains from an
implementation perspective.

1
3
Design quality
attributes
 Acronym
FURPS –
 Functionality
 Usability
 Reliability
 Performance
 Supportability
 Functionality – is assessed by evaluating the
feature set and capabilities of the program.
 Functions that are delivered and security of
the overall system.
 Usability – assessed by considering human
factors,
consistency &
documentation.
 Reliability – evaluated by
 measuring the frequency
and severity of failure.
 Accuracy of output
results.
 Ability to recover from failure and
predictability of the program.
 Performance - measured by processing speed,
Quality
Guidelines
Characteristics of good design
A design should exhibit an architecture that
 as been created using recognizable architectural styles or
patterns,
 is composed of components that exhibit good design
characteristics and
 can be implemented in an evolutionary fashion
 A design should be modular; that is, the software should
be logically partitioned into elements or subsystems
 A design should contain distinct representations of data,
architecture, interfaces, and components.
 A design should lead to data structures that are
appropriate for the classes to be implemented and are
drawn from recognizable data patterns.
 A design should lead to components that exhibit
independent functional characteristics
Quality Guidelines
(contd.)
 A design should lead to interfaces that reduce
the complexity of connections between
components and with the external environment.
 A design should be derived using a repeatable
method that is driven by information obtained
during software requirements analysis.
 A design should be represented using a
notation that effectively communicates its
meaning.
Design
Principles
 S/W design is both a process and a model.
 Design process - sequence of steps that
enable the designer to describe all aspects
of the software to be built.
 Design model - created for software provides
a variety of different views of the computer
software
 Software Architecture

 S/W design is both a process and a model.

 Design process - sequence of steps that
enable the designer to describe all aspects
of the software to be built.
 Design model - created for software provides
a variety of different views of the computer
software
 Software

architecture
Architecture serves as a blueprint for a system.
 It provides an abstraction to manage the system complexity and establish a communication
and coordination mechanism among components.
Some of architectural type
1. Repository architecture: An architecture where subsystems access and modify data
from a single data structure called the central repository.
 Sub-systems must exchange data. This may be done in two ways:
 Share data in central database or repository and may be accessed by all sub system
 Each sub-system maintains its own database and passes data explicitly to other sub-
systems
 All data in a system is managed in a central repository that is accessible to all system
components.
 Components do not interact directly, only through the repository
 You should use this pattern when you have a system in which large volumes of information
are generated that has to be stored for a long time. E.g. Bank

14
 Software
1. architecture
MVC ArchitectureThe MVC (Model-View-Controller) architecture is a design
pattern that separates application concerns into three interconnected components:
 Model: Represents the data and business logic.
 View: Handles the user interface and presentation.
 Controller: Manages user inputs and updates the model and view.
Example: A Simple Example Bank Web Application
Imagine a banking system where users can view account balances and perform
transactions:
Model: Contains account details and business logic for processing transactions.
View: Displays account details and transaction results.
Controller: Handles user input and updates the model and view.
2. Pipe and Filter Architecture
In the Pipe and Filter architecture, data flows through a series of processing elements
(filters) connected by pipes. Each filter performs a specific transformation or
computation on the data.
Example: Transaction Processing in ExampleBank
Imagine a batch processing system for bank transactions (e.g., deposits, withdrawals)
where each transaction goes through a series of filters.
Pipe: Connects filters, passing data between them.
14
Filters: Perform transformations, e.g., parsing, validation, and processing.
 Software
architecture
Implementation:
Input Filter: Reads transactions from a file.
Validation Filter: Validates transaction formats.
Processing Filter: Updates account balances.
Output Filter: Logs results or writes to a database.

The Peer-to-Peer (P2P) Architecture is a distributed system design where each node (peer)
acts as both a client and a server. This architecture enables decentralized communication and
resource sharing between nodes without relying on a central server.

14
 Cont
2. Model/View/Controller:

…
In the Model/View/Controller (MVC) architecture subsystems are classified into three
different types:
 The system is structured into three logical components that interact with each other.
1. Model Component
 manages the system data and associated operations on that data.
 Responsible for maintain domain information
 It maintain central data structure
2. View Component
 Responsible for displaying it to the user
 defines and manages how the data is presented to the user.
3. Controller Component
 Responsible for managing the sequence of interaction
 It gather input from the user and send message to the model
 manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these
interactions to the View and the Model.
Used when there are multiple ways to view and interact with data. Also used when the
future requirements for interaction and presentation of data are unknown.
 Cont
3. …Client/server architecture
 In the client/server architecture a subsystem, the server, provides services to
instances of other subsystems called the clients, which are responsible for
interacting with the user.
 The request for a service is usually done via a remote procedure call mechanism
or a common object broker.
 The client/server architecture is a generalization of the repository architecture.
 Used when data in a shared database has to be accessed from a range of
locations. Because servers can be replicated

Fig. Client/server architecture (UML class

 Cont
4.…A peer-to-peer architecture
 It is a generalization of the client/server architecture in
which subsystems can act both as client or as servers, in
the sense that each subsystem can request and provide
services.
 The control flow within each subsystem is independent
from the others except for synchronizations on
requests.

Fig. Peer-to-peer architecture (UML class

diagram).
 Cont
5. Pipe and filter architecture
… In this architecture subsystems process data received
from a set of inputs and send results to other
subsystems via a set of outputs.
 The subsystems are called filters, and the associations
between the
subsystems are called pipes.
 Each filter only knows the content and the format of
the data received on the input pipes, not the filters
that produced them.
 Each filter is executed concurrently and synchronization is
done via the pipes.
 Most operating systems and programming languages
provide a data stream mechanism; .
 A Filter can have many inputs and outputs. A Pipe connects
one of the outputs of a Filter to one of the inputs of another
 Identifying design
goalsgoals are desirable qualities that can be derived from non-
 Design
functional requirements
 Design goals guide the decisions to be made by the developers
especially when trade offs are needed
Design goals
 Reliability:
 Fault Tolerance:
 Security:
 Modifiability:
 Cont
…
Design criteria are grouped into
five: 1. Performance
. 2
.
dependability
3 cost
.
4 maintenance
.
5 and end user
.
1. criteria. criteria: include the speed and space
Performance
requirements imposed on the system.
 Cont.
2.. Dependability criteria: determine how much effort
should be expended in minimizing system crashes and their
consequences. How often can the system crash? How
available to the user should the system be? Are there safety
issues associated with system crashes? Are there security
risks associated with the system environment?
 Cont
3.…Cost criteria: include the cost to develop the
system, to deploy it, and to administer it.
 Cont
4.…Maintenance criteria: determine how difficult it is to
change the system after deployment. How easily can new
functionality be added? How easily can existing functions be
revised? Can the system be adapted to a different application
domain? How much effort will be required to port the system
to a different platform?
 Cont
5.…End user criteria: include qualities that are desirable from
a users’ point of view that have not yet been covered under
the performance and dependability criteria.

 N.B. Developers need to prioritize design goals and trade them

off against each other. E.g it is unrealistic to develop software
that is safe, secure, and cheap. Some of the common trade-off are:
 Space vs. speed
 Delivery time vs.
 functionality Delivery
 time vs. quality Delivery
time vs. staffing
 Chapter Review question
1. list a number of possible design criteria?
2. List and describe types of system requirement?
3. List and describe Software design model ?
Thank You!!!