Software Engineering
Outline
Software Design
•Data Design
•Architectural Design
•Interface Design
•Component Design
Objectives
• To explain importance of software design
• To understand different design models and
their importance
• To introduce architectural design and to
discuss its importance
• To suggest some general design principles for
user interface design
2
Software Design
• Requirements specification was about the WHAT
the system will do
• Design is about the HOW the system will perform
its functions
• It is also a technical description about how the
system will implement the requirements
• System Design
– Reduces the gap between requirements and the (virtual)
machine
– Decomposes the overall system into manageable parts
3
Cont’d
• Software design encompasses the set of
principles, concepts, and practices that lead to the
development of a high quality system or product
• Goal of software design is to produce a model or
representation that is bug free (firmness), suitable
for its intended uses (commodity), and
pleasurable to use (delight)
• The design model provides detail about software
data structures, architecture, interfaces, and
components that are necessary to implement the
system.
4
Design models
• Software design model consists of 4 designs:
– Data/class Design
– Architectural Design
– Interface Design
– Component Design
• 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 5
Cont’d
• 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 form the
analysis model class-based elements, flow-oriented
elements, and behavioral elements
6
Translating the analysis model into a software design
Component -
sc enario- based f low- oriented L evel Design
elements elements
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
Int erfac e Design
Analysis Model
Arc hit ec t ural Design
c lass- based behavioral
elements elements
class diagrams state diagrams
analysis packages sequence diagrams
CRC models Dat a/ Class Design
collaboration diagrams
Design Model
7
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
8
Levels of Design
• Architectural design (also: high-level design)
– architecture - the overall structure: main modules and their
connections
– design that covers the main use-cases of the system
– addresses the main non-functional requirements (e.g.,
throughput, reliability)
– hard to change
• Detailed design (also: low-level design)
– the inner structure of the main modules
– may take the target programming language into account
– detailed enough to be implemented in the programming
language
9
Challenges in Design
• Complexity
– Often arbitrary, dependent on designer rather than problem
(“accidental complexity”)
• Conformity
– Often expected to conform to other software (e.g., legacy,
standards)
• Changeability
– Needs to support change due changing requirements,
constraints, etc.
• Invisibility
– No visible link from between design plans and product
10
Design and Software Quality
• S/w design is an iterative process through which
requirements are translated into a “blueprint” for
constructing the s/w.
• Quality
– Design is the place where quality is fostered in software
engineering.
– Design provides us with representation of software that can
be assessed for quality.
– Design is the only way we can translate customers
requirements into finished software product or system.
– Software design serves as the foundation for all the software
engineering and software support steps. 11
Characteristics of a Good Design
• 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 readable, understandable guide for
those who generate code and for those who test and
support the software.
• The design should provide a complete picture of the
software, addressing the data, functional and
behavioral domains from an implementation
perspective.
12
General Design Guidelines
• A design should exhibit an architecture that
(1) has been created using recognizable architectural styles or
patterns,
(2) is composed of components that exhibit good design
characteristics and
(3) can be implemented in an evolutionary fashion
For smaller systems, design can sometimes be developed linearly.
• 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. 13
Cont’d
• A design should lead to components that exhibit
independent functional characteristics.
• 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.
14
Design Concepts/Fundamentals
• The design should be based on requirements specification.
• The design should be documented (so that it supports
implementation, verification, and maintenance.)
• The design should use abstraction (to reduce complexity and to
hide unnecessary detail.)
• The design should be modular (to support abstraction,
verification, maintenance, and division of labor.)
• The design should be assessed for quality as it is being created,
not after the fact.
• Design should produce modules that exhibit independent
functional characteristics.
• Design should support verification and maintenance.
15
Design Concepts….
• Design concepts provide the necessary
framework for “to get the thing on right way”.
– Abstraction
– Refinement
– Modularity
– Architecture
– Control Hierarchy
– Functional Independence
– Refactoring
– Structural Partitioning
– Data Structure
– Software Procedure
– Information Hiding
16
Abstraction
• Concentrate on problem at some level of
generalization without considering irrelevant details
• Allows working with concepts/terms familiar in the
problem environment
• Is one of the fundamental ways that can be used to
cope with complexity.
17
Modular Design
• Easier to build, easier to change ,easier to fix
• Architecture and design pattern embody modularity.
• Software is divided into separately named and
addressable components, sometimes called modules,
which are integrated to satisfy problem requirement.
• modularity is the single attribute of software that
allows a program to be intellectually manageable
• It leads to a “divide and conquer” strategy. – it is
easier to solve a complex problem when you break
into a manageable pieces.
18
• Refer fig. that state that effort (cost) to develop an
individual software module does decrease if total
number of modules increase.
• However as the no. of modules grows, the effort
(cost) associated with integrating the modules also
grows.
Mo
dul
arit
y&
Soft
wa
re C
ost
19
• Undermodularity and overmodularity should be
avoided. But how do we know the vicinity of M?
• We modularize a design so that development can be
more easily planned.
• Software increments can be defined and delivered.
• Changes can be more easily accommodated.
• Testing and debugging can be conducted more
efficiently and long-term maintained can be
conducted without serious side effects.
20
Architecture
• Software architecture suggest “ the overall structure of the
software and the ways in which that structure provides
conceptual integrity for a system.
• Number of different models can use to represent architecture.
– Structural Model- represent architecture as an organized
collection of components
– Framework model – Increase level of design abstraction by
identifying repeatable architectural design framework.
– Dynamic model – address behavior of the program architecture
and indicating how system or structure configuration may
change as a function.
– Process Model – focus on design of the business or technical
process that the system must accommodate.
– Functional models – used to represent the functional hierarchy
of a system. 21
Functional independence
• Functional independence is achieved by developing
modules with "single-minded“ function and an "aversion"
to excessive interaction with other modules.
• In other words - each module addresses a specific sub-
function of requirements and has a simple interface when
viewed from other parts of the program structure.
• Independence is important –
– Easier to develop
– Easier to Test and maintain
– Error propagation is reduced
– Reusable module.
• To summarize, functional independence is a key to good
design, and design is the key to software quality.
22
• To measure independence, have two qualitative criteria:
– cohesion and
– coupling
• Cohesion is a measure of the relative functional strength of a module.
• High cohesion: The classes in the subsystem perform similar tasks
and are related to each other (via associations)
• Low cohesion: Lots of miscellaneous and auxiliary classes, no
associations
• Coupling is a measure of the relative interdependence among
modules.
• High coupling: Changes to one subsystem will have high impact
on the other subsystem (change of model, massive
recompilation, etc.)
• Low coupling: A change in one subsystem does not affect any
other subsystem
• Subsystems should have as maximum cohesion and minimum
23
coupling as possible:
Cohesion
• Cohesion is a natural extension of the information hiding
concept
• A cohesive module performs a single task within a
software procedure, requiring little interaction with
procedures being performed in other parts of a program
• Simply state, a cohesive module should (ideally) do just
one thing.
• We always strive for high cohesion, although the mid-
range of the spectrum is often acceptable.
• Low-end cohesiveness is much "worse" than middle
range, which is nearly as "good" as high-end cohesion.
• So. designer should avoid low levels of cohesion when
modules are designed. 24
Coupling
• Coupling depends on the interface complexity between
modules, the point at which entry or reference is made to a
module, and what data pass across the interface
• In software design, we strive for lowest possible coupling.
Simple connectivity among modules results in software that
is easier to understand and less prone to a "ripple effect"
caused when errors occur at one location and propagate
through a system.
• It occur because of design decisions made when structure
was developed.
• Coupling is characterized by passage of control between
modules.
• “Control flag” (a variable that controls decisions in a
subordinate or superordinate module) is passed between
modules d and e (called control coupling). 25
• Relatively high levels of coupling occur when
modules are communicate with external to software.
• External coupling is essential, but should be limited
to a small number of modules with a structure.
• High coupling also occurs when a number of
modules reference a global data area.
• Common coupling, no. of modules access a data
item in a global data area
• So it does not mean “use of global data is bad”. It
does mean that a software designer must be take
care of this thing.
26
Control Hierarchy/Program Structure
– Organization of modules that implies a hierarchy of control
– Depth, width, fan-out, fan-in
– Tree like control diagram
Manager
Module A Module B Module C
Module D Module E Module K Module L Module M
Module F Module G Module H Module N Module O Module P Module Q
Module I Module J Module R
27
Data Structure
• Data structure is a representation of the logical
relationship among individual elements of data
• A scalar item is the simplest of all data structures. It
represents a single element of information that may be
addressed by an identifier.
• When scalar items are organized as a list or contiguous
group, a sequential vector is formed.
• When the sequential vector is extended to two, three, and
ultimately, an arbitrary number of dimensions, an n-
dimensional space is created. Most common n-
dimensional space is the two-dimensional matrix
28
• A linked list is a data structure that organizes contiguous scalar
items, vectors, or spaces in a manner (called nodes) that
enables them to be processed as a list.
• A hierarchical data structure is implemented using multilinked
lists that contain scalar items, vectors, and possibly, n-
dimensional spaces.
Software Procedure
– Software procedure focuses on the processing details of
each module individually.
– Procedure must provide a precise specification of
processing, including sequence of events, exact decision
points, repetitive operations, and even data organization
and structure. 29
Information hiding
• The principle of information hiding suggests that modules be
"characterized by design decisions that (each) hides from all
others modules.“
• In other words, modules should be specified and designed so that
information (algorithm and data) contained within a module is
inaccessible to other modules that have no need for such
information.
• The intent of information hiding is to hide the details of data
structure and procedural processing behind a module interface.
• It gives benefits when modifications are required during testing
and maintenance because data and procedure are hiding from
other parts of software, unintentional errors introduced during
modification are less. 30
Refinement
• Successively decomposing or refining specifications in
stepwise fashion
• Development of a program by successively refining levels of
procedure detail
• Complements abstraction, which enables a designer to
specify procedure and data and yet suppress low-level
details
• Refinement is actually a process of elaboration.
• begin with a statement of function (or description of
information) that is defined at a high level of abstraction.
• That is, the statement describes function or information
conceptually but provides no information about the internal
workings of the function or the internal structure of the
information. 31
Refactoring
• A reorganization technique that simplifies the design (or
internal code structure) of a component without changing its
function or external behavior
• "Refactoring is the process of changing a software system in
such a way that it does not alter the external behavior of the
code [design] yet improves its internal structure.”
• When software is refactored, the existing design is examined
for
– redundancy
– unused design elements
– inefficient or unnecessary algorithms
– poorly constructed or inappropriate data structures
– or any other design failure that can be corrected to yield a better
design. 32
Structural partitioning
• Horizontal partitioning (division of functionality):
separate branches of control hierarchy
• Vertical partitioning (factoring): distributing work to
“worker” modules
33
Design Elements
• A system is a logical entity, having a set of definable
responsibilities or objectives, and consisting of hardware,
software or both.
• A subsystem is a system that is part of a larger system, and
which has a definite interface.
• A component is any piece of software or hardware that has a
clear role.
– A component can be isolated, allowing you to replace it with
a different component that has equivalent functionality.
• A module is a component that is defined at the programming
language level
– For example, methods, classes and packages are modules in
Java.
34
Design Goals
• Overall goals of good design:
– Increasing profit by reducing cost and increasing
revenue
– Ensuring that we actually conform with the
requirements
– Accelerating development
– Increasing qualities such as
• Usability
• Efficiency
• Reliability
• Maintainability
• Reusability 35
Data Design
• High level model depicting user's view of the data or
information
• Designing the algorithms for the individual parts
• Design of data structures and operators is essential to
creation of high-quality applications
• Translation of data model into database is critical to
achieving system business objectives
• Data design transforms the information domain model
created during analysis into the data structures that
will be required to implement the software.
36
• The data objects and relationships defined in ERD and
the detailed data content depicted in the data
dictionary provide the basis for the data design
activities.
• Data Specification Principles
• Identify all data structures and associated operations
• Establish a data dictionary to define data & program
design
• Representation of data structure should only be known
to modules with direct use of data within the structure
• Develop a library of useful data structures
• Language should support abstract data types
37
Architectural Design
• Designing the structure of the system
• Objective is to develop a modular program structure and
represent the control relationships between modules
• Derived from the system specification, the analysis model,
and the interaction of subsystems defined within the
analysis model.
• Usually depicted as a set of interconnected systems that
are often derived from the analysis packages
• Software architecture is process of designing the global
organization of a software system, including:
– Dividing software into subsystems.
– Deciding how these will interact.
– Determining their interfaces. 38
Cont’d
• The architecture is the core of the design, so all
software engineers need to understand it.
• The architecture will often constrain the overall
efficiency, reusability and maintainability of the
system.
• Once interactions between the system and its
environment have been understood, you use this
information for designing the system architecture.
• You identify the major components that make up the
system and their interactions, and then may organize
the components using an architectural pattern such
as a layered or client-server model. 39
The importance of software architecture
• Why you need to develop an architectural model:
– To enable everyone to better understand the system
– To allow people to work on individual pieces of the system in
isolation
– To prepare for extension of the system
– To facilitate reuse and reusability
Developing an architectural model
• Start by sketching an outline of the architecture
– Based on the principal requirements and use cases
– Determine the main components that will be needed
– Choose among the various “architectural patterns” 40
Describing an architecture using UML
• All UML diagrams can be useful to describe aspects
of the architectural model
• Four UML diagrams are particularly suitable for
architectural modeling:
– Package diagrams
– Subsystem diagrams
– Component diagrams
– Deployment diagrams
41
Package diagrams
• shows structure of the designed system at the level
of packages.
– A package is a grouping of pieces of a model.
• Packages are very useful in managing models.
They're also quite helpful in grouping related items,
such as use cases, in order to make it easier to break
up work among subteams.
42
• The name of the package appears within the tab, and the
contents of the package are listed in the body of the order package
tab
43
• Example: Package Diagram for ATM System
– Each of these classes, in turn, depends on the
package atm which contains the class ATM that
represents the system as a whole, and the class
Session that represents one session. ATM depends
on Session, and vice versa - since the ATM creates
Sessions, and each Session, in turn, uses the ATM
to interact with the customer.
– This package diagram shows how the various
classes are grouped into packages. There are two
"top-level" classes - ATMMain and ATMApplet -
which allow the system to be run (respectively) as
an application.
44
– The subpackage transaction contains the classes used
to represent individual transactions that a customer
initiates. The class Session depends on the transaction
package because it creates individual transaction
objects. These, in turn, again depend on the ATM to
interact with the customer.
– The subpackage physical contains the classes that
represent the various physical components of the ATM
– Finally, the package banking contains classes that
represent the banking enterprise itself and the
information communicated back and forth between
the ATM and the bank - i.e. classes which might be the
same in a totally different implementation of an ATM
that interacts with the same bank.
45
46
Package diagrams show packages contained in one
view and how they relate to each other
47
Subsystem diagrams
• The UML provides a graphical representation for systems
and subsystems
• Subsystem diagrams helps to visualize the decomposition
of a system into smaller subsystems.
• Graphically, a system and a subsystem are rendered as a
stereotyped package icon.
• A system, possibly decomposed into a collection of
subsystems
• A system is the thing itself that you are developing
and for which you build models.
48
Diagram of Systems and Subsystems
49
Course Registration Subsystem diagram
50
Component diagrams
• A component is a physical and replaceable part of a system
that conforms to and provides the realization of a set of
interfaces.
– “… a modular, deployable, and replaceable part of a system
that encapsulates implementation and exposes a set of
interfaces.”
• The component diagram's main purpose is to show the
structural relationships between the components of a system
• A component diagram provides a physical view of the system.
• It focuses on a set of components and the structural
relationships among them.
• Its purpose is to show the dependencies that the software
has on the other software components (e.g., software
libraries) in the system. 51
• You use components to model the physical things that may
reside on a node, such as:
– executables
– libraries
– Tables
– Files and
– documents.
• In software, many operating systems and programming
languages directly support the concept of a
component.
52
design of a Component diagram for Book Bank
Management System
53
Deployment diagrams
• A deployment diagrams
– shows how the finished system will be deployed on one or
more machines.
– are used to visualize the topology of the physical
components of a system where the software components
are deployed.
– are used for describing the hardware components where
software components are deployed.
• Component diagrams and deployment diagrams are
closely related.
54
• Deployment diagram shows the configuration of
run time processing nodes and the components
that live on them.
• A deployment diagram can include all sorts of
features such as:
– Machines
– Processes
– Files and
– dependencies.
• Deployment diagrams are used:
1. To model embedded systems.
2. To model client/ server systems.
3. To model fully distributed systems. 55
Deployment diagram of an order management system
56
• Deployment diagram showing run-time nodes and
components for a browser-based three-tier account
management system
57
Component-Level Design
• Describes the internal detail of each software component
• Defines
– Data structures for all local data objects
– Algorithmic detail for all component processing functions
– Interface that allows access to all component operations
• Modeled using UML component diagrams, UML activity
diagrams, and pseudo code (PDL)
58
Deployment-Level Design
• Indicates how software functionality and
subsystems will be allocated within the
physical computing environment
• Modeled using UML deployment diagrams
59
User Interface Design
• Specifying the interfaces between the parts of the system.
• Interface is a set of operations that describes the externally
observable behavior of a class and provides access to its
operations
• Important elements
– User interface (UI)
– External interfaces to other systems
– Internal interfaces between various design components
• Modeled using UML collaboration diagrams
• User interface is the front-end application view to which user
interacts in order to use the software.
60
• User can manipulate and control the software as well as hardware
by means of user interface.
• Today, user interface is found at almost every place where digital
technology exists, right from computers, mobile phones, cars,
music players, airplanes, ships etc.
• User interfaces should be designed to match the skills, experience
and expectations of its anticipated users.
• System users often judge a system by its
interface rather than its functionality.
• A poorly designed interface can cause a user to make catastrophic
errors.
• Poor user interface design is the reason why so many software
systems are never used.
• UI provides fundamental platform for human computer interaction
• UI can be graphical, text-based, audio-video based, depending
upon the underlying hardware and software combination.
61
• The software becomes more popular if its user interface is:
• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interfacing screens
• UI is broadly divided into two categories:
– Command Line Interface
– Graphical User Interface
Command Line Interface(CLI)
• CLI provides a command prompt, the place where the user types
the command and feeds to the system.
• The user needs to remember the syntax of command and its use.
62
Graphical User Interface
• Graphical User Interface provides the user graphical
means to interact with the system. GUI can be
combination of both hardware and software. Using GUI,
user interprets the software.
• Typically, GUI is more resource consuming than that of
CLI.
• With advancing technology, the programmers and
designers create complex GUI designs that work with
more efficiency, accuracy and speed.
63
Human factors in interface design
• Limited short-term memory
– People can instantaneously remember about 7 items of
information. If you present more than this, they are more
liable to make mistakes.
• People make mistakes
– When people make mistakes and systems go wrong,
inappropriate alarms and messages can increase stress
and hence the likelihood of more mistakes.
• People are different
– People have a wide range of physical capabilities.
Designers should not just design for their own capabilities.
• People have different interaction preferences
– Some like pictures, some like text.
64
UI design principles
• User familiarity
– The interface should be based on user-oriented
terms and concepts rather than computer concepts
– E.g., an office system should use concepts such as
letters, documents, folders etc. rather than
directories, file identifiers, etc. be similar, etc.
• Consistency
– The system should display an appropriate level of
consistency
– Commands and menus should have the same
format, command punctuation should be similar, etc.
65
• Minimal surprise
– If a command operates in a known way, the user should be
able to predict the operation of comparable commands
• Recoverability
– The system should provide some interface to user errors
and allow the user to recover from errors
• User guidance
– Some user guidance such as help systems, on-line
manuals, etc. should be supplied
• User diversity
– Interaction facilities for different types of user should be
supported
– E.g., some users have seeing difficulties and so larger text
should be available
66
Summary
• The software architecture is the fundamental
framework for structuring the system.
• The user interface design process involves user
analysis, system prototyping and prototype
evaluation.
67
A general model of the design process
68
Analysis Model to Design Model
Component-level Design
(Class-based model, Flow-oriented model
Behavioral model)
Interface Design
(Scenario-based model, Flow-oriented model
Behavioral model)
Architectural Design
(Class-based model, Flow-oriented model)
Data/Class Design
(Class-based model, Behavioral model)
69
Con’t
70
