Software Design

1
Design Knowledge Area
 Software Design Fundamentals

 Key Issues in Software Design

 concurrency,

 control and handling of events,

 distribution of components,

 error and exception handling and fault tolerance,

 interaction and presentation, and

 data persistence 2
Design KA..
 Software Structure and Architecture
◦ architectural structures and viewpoints,
◦ architectural styles,
◦ design patterns,
◦ families of programs and frameworks

 Software Design Quality Analysis and Evaluation

 Software Design Notations

◦ Structural
◦ Behavioural 3
Design KA ..
 Software Design Strategies and Methods
◦ general strategies (divide-and-conquer, stepwise
refinement, …)

◦ function-oriented design methods,

◦ object-oriented design methods,

◦ data-structure-centered design,

◦ component- based design,

◦ Service-Oriented Design
◦ …. 4
Definition
 Software Architecture =
a set of high-level decisions that determine
the key elements of the system-to-be and
their relationships
◦ Principal decisions made throughout the development and evolution
of a software system
◦ made early and affect large parts of the system (―design
philosophy‖) — such decisions are hard to modify later

 The software architecture of a program or

computing system is the structure or
structures of the system, which comprise
software elements, the externally visible
properties of those elements, and the
relationships among them.
5
Def..

 “Software architectural design (sometimes

called top level design): describing
software’s top-level structure and
organization and identifying the various
components‖

 “Architectural design describes how

software is decomposed and organized
into components (the software
architecture)‖ [IEEEP1471-00]
6
Notion …

7
8
Google Architecture
 Amenable to extensive parallelization,
 google’s web search
◦ Application lets different queries run on different processors and,

◦ By partitioning the overall index, also lets a single query use Multiple processors.

 To handle this workload,

 Architecture features clusters of
◦ more than 15,000 commodity class Pcs with fault-tolerant software.

 This architecture achieves

◦ Superior performance at a fraction of the cost of a system built From fewer,
but more expensive, high-end servers

9
10
Design Fundamentals

11
Design Concepts and Principles

 Software Design -- An iterative process

transforming requirements into a
―blueprint‖ for constructing the software

 Process of breaking down the system into

components, defining interfaces and defining
components to a level of detail that enables
their construction
12
Fundamental Concepts
 Abstraction—data, procedure, control

 Refinement—elaboration of detail for all

abstractions

 Modularity—compartmentalization of data and

function

 Hiding—controlled interfaces
13
Effective Modular Design -- Functional
Independence
 Critical in dividing system into
independently implementable parts

 Measured by two qualitative criteria

◦ Cohesion
 Relative functional strength of a module
◦ Coupling
 Relative interdependence among modules
14
Effective Modular Design -- Cohesion
• Coincidental Cohesion
– Occurs when modules are grouped together for no
reason at all
– ex. OO classes with unrelated methods or subsystems
with unrelated components.
• Logical Cohesion
– Modules have a logical cohesion, but no actual
connection in data and control
– Ex. a library of mathematical functions (sine, cosine,..).
• Temporal Cohesion
– Modules are bound together because they must be used
at approximately the same time
– Ex. initialization modules for startup of a system 15
…Effective Modular Design --Cohesion
 Communication Cohesion
◦ Modules grouped together because they access the
same Input/Output devices

 Sequential Cohesion
◦ Elements in a module are linked together by the
necessity to be activated in a particular order (with
control coupling)

 Functional Cohesion
◦ All elements of a module relate to the performance
of a single function
16
Modular Design -- Coupling
 Coupling describes the interconnection
among modules

 Data coupling
◦ Occurs when one module passes local data
values to another as parameters

 Stamp coupling
◦ Occurs when part of a data structure is passed
to another module as a parameter
17
Modular Design -- Coupling
 Control Coupling
◦ Occurs when control parameters are passed
between modules

 Common Coupling
◦ Occurs when multiple modules access
common data areas

18
Architectural Patterns

19
Origins of Patterns
―Each pattern describes a problem which occurs over and
over again in our environment and then describes the
core of the solution to that problem, in such a way that
you can use this solution a million times over, without
ever doing it in the same way twice‖

 Christopher Alexander, A Pattern Language, 1977

 Context: City Planning and Building architectures
20
Architectural patterns…
 Model-View-Controller (MVC)

 Layered architecture

 Client-server architecture
◦ fat-client
◦ Thin-client

 Master-Slave Architecture
21
Model-View-Controller (MVC)
pattern

22
Web application architecture using
the MVC pattern

23
Model-View-Controller (MVC) pattern
Name MVC (Model-View-Controller)

Description Separates presentation and interaction from the system data. The system is
structured into three logical components that interact with each other. The
Model component manages the system data and associated operations on
that data. The View component defines and manages how the data is
presented to the user. The Controller component manages user interaction
(e.g., key presses, mouse clicks, etc.) and passes these interactions to the
View and the Model.

Example The next Figure shows the architecture of a web-based application system
organized using the MVC pattern.

When used 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.

Advantages Allows the data to change independently of its representation and vice versa.
Supports presentation of the same data in different ways with changes made
in one representation shown in all of them.
24
Disadvantages Can involve additional code and code complexity when the data model and
interactions are simple.
Layered architecture pattern

25
 Layered architecture
Used to model the interfacing of sub-systems.

Organises the system into a set of layers (or

abstract machines) each of which provide a set
of services.

Supports the incremental development of sub-

systems in different layers. When a layer
interface changes, only the adjacent layer is
affected.

However, often artificial to structure systems

in this way.
26
The Layered architecture pattern
Name Layered architecture

Description Organizes the system into layers with related functionality associated
with each layer. A layer provides services to the layer above it so the
lowest-level layers represent core services that are likely to be used
throughout the system.

Example A layered model of a system for sharing copyright documents held in

different libraries.
When used Used when building new facilities on top of existing systems; when
the development is spread across several teams with each team
responsibility for a layer of functionality; when there is a requirement
for multi-level security.

Advantages Allows replacement of entire layers so long as the interface is

maintained. Redundant facilities (e.g., authentication) can be
provided in each layer to increase the dependability of the system.

Disadvantages In practice, providing a clean separation between layers is often

difficult and a high-level layer may have to interact directly with lower-
level layers rather than through the layer immediately below it.
Performance can be a problem because of multiple levels of
interpretation of a service request as it is processed at each layer.
27
A generic layered architecture

28
The architecture of the LIBSYS system

29
Client-Server architecture
pattern

30
Client-server architecture
 A system model which shows how data and
processing is distributed across a range of
components.

 Set of stand-alone servers which provide

specific services such as printing, data
management, etc.

 Set of clients which call on these services.

 Network which allows clients to access

servers.
31
The Client–server pattern
Name Client-server

Description In a client–server architecture, the functionality of the system is

organized into services, with each service delivered from a
separate server. Clients are users of these services and access
servers to make use of them.

Example The Figure on the next slide is an example of a film and video/DVD
library organized as a client–server system.

When used Used when data in a shared database has to be accessed from a
range of locations. Because servers can be replicated, may also be
used when the load on a system is variable.

Advantages The principal advantage of this model is that servers can be

distributed across a network. General functionality (e.g., a printing
service) can be available to all clients and does not need to be
implemented by all services.

Disadvantages Each service is a single point of failure so susceptible to denial of

service attacks or server failure. Performance may be unpredictable
because it depends on the network as well as the system. May be
management problems if servers are owned by different 32
organizations.
A client–server architecture for a
film library

33
Two-tier client-server architecture

34
A fat-client architecture for an ATM system

35
Three-tier architecture for an
internet banking system

36
Use of client-server architectural patterns

37
Master-Slave Architecture
pattern

38
Master-Slave Architecture
/Distributed Systems/

39
Context awareness & Views
in Architecture

40
Context Aware..
 “fit for purpose” & “fit to context”

 a multilevel, context-aware approach

to software architecture

(1) treats contextual environment concerns as

first class entities
(2) groups concerns and techniques of different
abstraction, scope and grain into separate
explicit levels.

41
Context Aware..
 groups software architecture in
◦ macro-architecture level
 enterprise-level contextual concerns
 system-level contextual concerns.

◦ micro-architecture level

42
Multilevel Context-Aware Architecture

43
Enterprise-Level Contextual Concerns
 Strategic business architectural concerns
 Business goals architectural concerns
 Operating model architectural concerns
 Software development model architectural concerns
 On-going maintenance model architectural concerns
 Deployment and hosting architectural concerns
 Technology operations architectural concerns
 Business operations architectural concerns
 Financial architectural concerns
 Funding model architectural concerns

44
System-Level Contextual Concerns
 Workflow and business process profile
 Network intensive profile
 Messaging oriented profile
 User interaction profile
 System-to-system profile
 Transactional profile
 Business analytics profile
 Legacy integration profile
…
45
 Architectural views
 What views or perspectives are useful
when designing and documenting a system’s
architecture?

 What notations should be used for

describing architectural models?

 Each architectural model only shows one

view or perspective of the system.
46
4 + 1 view model of software
architecture
 A logical view,
◦ which shows the key abstractions in the system.
–
◦ a module view - Module structures
◦ The decomposition structure
 A process view,
◦ which shows how, at run-time, the system is
composed of interacting processes.
◦ concurrency and distribution of functionality
◦ Component-and-connector structures
◦ data progress through the system
◦ parts of the system that can run in parallel
47
 4 + 1 view model …
 A development view,
◦ which shows how the software is decomposed
for development.
◦ mapping software to the development
environment
◦ Allocation structures
 A physical view,
◦ which shows the system hardware and how
software components are distributed across the
processors in the system.
◦ Allocation structures
 (+1) Related using use cases or scenarios
48
4+1 View

49
Documenting Software
Architectures

50
51
52
53
Documenting

Important concepts
A software architecture comprises multiples structures.
◦ Each structure represents a different view of
the system.

◦ Each structure concentrates in one aspect of

the system.

54
Documenting …

• A view or view type denotes a representation of a

structure.

• A view type instance is a particular representation

for a particular structure of a given system.

55
Documenting …
A view may have several representations of
the same structure.
E.g. A database structure: can be
expressed using
- an Entity-relationship model or
- a SQL script

(both representations are equivalent as they

express the same elements and relationships)
56
Documenting …
• The architecture serves as the blueprint for
 1) the system and
 2) the project developing it

• A perfect architecture is useless if no one understands it

or if key stakeholders misunderstand it

• Documentation should be sufficiently

abstract to be quickly understood by new
employees but sufficiently detailed to
serve as a blueprint for analysis.
57
Documenting…
• Architecture documentation is both
Prescriptive: prescribes what should be true by placing
constraints on decisions to be made

Descriptive: describeswhat is true by recounting decisions

already made about a system's design

• Architecture documentation is a key means for educating

people who need an overview: new developers, funding
sponsors, visitors to the project, and so forth.

58
Documenting …
Write
from the point of view of the reader --- a
communication vehicle among stakeholders
◦ requirements engineers who represent customer
◦ Programmers, Testers, quality specialists,

Documenting an architecture is a matter of

documenting the relevant views and then adding
documentation that applies to more than one view.

59
RUP Approach
 It is based on the 4+1 view model.

 It includes the logical, process, deployment, physical

and scenarios views from Kruchten’s model.

 A view is considered a projection of a system on one

of its relevant aspects.

 A projection emphasizes certain aspects and ignores

others.

 UML diagrams are used to represent views.

60
1. Introduction
 - background (V&S, SRS)
 - Scope
 - Document structure and reading suggestions
2. Design Considerations and Decisions
 - contextual considerations
 - Quality attribute considerations and
architectural decisions
 - Assumptions and Dependencies
3. System Decomposition and Views
- sub systems
- sub system interfaces
- allocation views
4. Interface and Object Design
Glossary
Appendix
61
System Integration Techniques
Integration Approaches
 There are 4 basic strategies to approaching
application integration:
◦ Information Oriented

◦ Business Process Integration Oriented

◦ Service Oriented

◦ Portal Oriented

63
Integration Approaches…
 Information oriented interfaces fall into 3
categories
◦ Data replication
 Movement of data between systems

◦ Data federation
 Common database model

◦ Interface processing
 Defined application interfaces (API)

64
Integration Approaches…
 Steps to the integration process include:
◦ Identify the data
 Forms
 Data Dictionary
 Integrity Constraints
 Latency Issues
 Data Structures

◦ Catalog the Data

◦ Build the enterprise meta-data model

65
Data-Oriented B2B Application
Integration
• Data-oriented B2B application integration allows for data
to be moved between data stores.

• Data share among data stores with trading partners.

• Complex database technology

• Updating database and integrity issues.

• Complex and complicated variety of various database

technologies

• Data compatibility, and semantics

66
Database-to-Database B2B Application Integration

• Allows us to share information at the database

level.
• One-to-one, one-to-many, many-to-many
connections
• Database middleware & database replication
software
• Message broker
• Basic replication solution
 Maintain basic schema information
• Replication and transformation

67
Advantages &Disadvantages

 Simplicity

 Dealing with application information at the data

level.

 Too many applications that bind the application

logic to the data.  need to change application
interface.

68
Federated Database B2B Application
Integration

• It works at the database level.

• Creates a single virtual database model that allows

developers to use various brands, models, and schemas to
access any number of databases.

• The virtual database is mapped to any number of

connected physical databases.

69
Advantages & Disadvantages
• It relies on middleware to share information between
applications.

• Middleware hides the differences in the integrated

databases from the other applications.

• It’s not true integration.

• It is difficult to create common schema.

70
Integration Approaches…
 Business Process Integration-Oriented

◦ Layer’s an integration oriented set of processes on

top of (and interfacing to) existing sets of processes
on target systems

71
Integration Approaches…

 Service Oriented
◦ Allows applications to share common logic or
methodologies, usually through the use of a composite
application

◦ One of the key goals in this approach is to reuse

common methods to reduce total cost

72
Integration Approaches…
 Portal Oriented
◦ Basically defined as the integration of a multitude of
differing systems through a single user interface or
access point.

◦ Many ecommerce or B2B systems fall into this

category

73
OO Design Patterns

74
 What is a Design Pattern?

 A design pattern
◦ abstracts a recurring design structure
◦ comprises class and/or object
 dependencies,
 structures,
 interactions, or
 conventions
◦ distills design experience

75
 Elements of Design Patterns
 Design patterns have four essential elements:
◦ Pattern name

◦ Problem

◦ Solution

◦ Consequences

76
 Pattern Name
 Used to describe:
◦ a design problem
◦ its solutions

 Increases design vocabulary

 Makes it possible to design at a higher level of

abstraction

 Enhances communication
 “The Hardest part of programming is coming up with
good variable [function, and type] names.”

77
 Problem
 Describes when to apply the pattern

 Explains the problem and its context

 May describe specific design problems and/or

object structures

 May contain a list of preconditions that must

be met before it makes sense to apply the
pattern

78
 Solution
 Describes the elements that make up the
◦ design
◦ relationships
◦ responsibilities
◦ collaborations

 Does not describe specific concrete

implementation

 Abstract description of design problems and

how the pattern solves it

79
 Consequences
 Results and trade-offs of applying the pattern

 Critical for:
◦ evaluating design alternatives
◦ understanding costs
◦ understanding benefits of applying the pattern

 Includes the impacts of a pattern on a system’s:

◦ flexibility
◦ extensibility
◦ portability
80
 Describing Design Patterns
 Name and Classification: Essence of pattern
 Intent: What it does, its rationale, its context
 AKA: Other well-known names
 Motivation: Scenario illustrates a design problem
 Applicability: Situations where pattern can be applied
 Structure: Class and interaction diagrams
 Participants: Objects/classes and their responsibilities
 Collaborations: How participants collaborate
 Consequences: Trade-offs and results
 Implementation: Pitfalls, hints, techniques, etc.
 Sample Code
 Known Uses: Examples of pattern in real systems
 Related Patterns: Closely related patterns

81
 Example: Stock Quote Service
Real time
Market
Data
Feed

Stock Quotes

Customer Customer

Customer Customer Customer

Observers

82
 Observer Pattern
 Intent:
◦ Define a one-to-many dependency between objects so that
when one object changes state, all its dependents are
notified and updated automatically
 Key forces:
◦ There may be many observers
◦ Each observer may react differently to the same notification
◦ The subject should be as decoupled as possible from the
observers to allow observers to change independently of
the subject

83
 Structure of Observer Pattern
Subject Observer

for all observers obs +notify() * +update()

{
obs->update()
+attach(in Observer) 1

} +detach(in Observer)

ConcreteObserver
ConcreteSubject
-subjectSate * +update()
1
+getState()

return subjectState observerState = subject->getState()

84
 Collaborations in Observer Pattern

S1 : ConcreteSubject obs1 : ConcreteObserver obs2 : ConcreteObserver

notify()

update()

getState()
update()

getState()

85
 Types of Patterns
 Creational patterns:
◦ Deal with initializing and configuring classes and objects

 Structural patterns:
◦ Forming larger structures by composition – inheritance
◦ Composition of classes or objects

 Behavioural patterns:
◦ Deal with dynamic interactions among societies of
classes and objects
◦ How they distribute responsibility

86
Design Pattern Space
Purpose
Creational Structural Behavioral
Scope Class Factory method Adapter (class) Interpreter
Template method
Object Abstract factory Adapter (object) Chain of
Builder Bridge responsibility
Prototype Composite Command
Singleton Decorator Iterator
Façade Mediator
Flyweight Memento
Proxy Observer
State
Strategy
Visitor
Factory design patterns
(abstract\method\Lightweight)
 Creational pattern
 Can be given to client (abstract), pass
construction parameters or read creation types
from configuration or system environment
 Can use object pool (Lightweight)

88
Factory design pattern - example
abstract class GUIFactory {
public static GUIFactory getFactory() {
int sys = readFromConfigFile("OS_TYPE");
return sys == 0 ? new WinFactory() : new MacFactory();
}
public abstract Button createButton();
}
class WinFactory:GUIFactory {
public override Button createButton() {
return new WinButton();
}
}
class MacFactory:GUIFactory {
public override Button createButton(){
return new MacButton();
}
}
abstract class Button {
public string caption;
public abstract void paint();
89
}
Factory design pattern - example
class WinButton:Button
{
public override void paint()
{ // paint a button with Win API…}
}
class MacButton:Button
{
public override void paint()
{ // paint a button Mac style… }
}
class Application
{
static void Main(string[] args)
{
GUIFactory aFactory = GUIFactory.getFactory();
Button aButton = aFactory.createButton();
aButton.caption = "Play"; aButton.paint();
}
}
90
Facade
 You
◦ have a set of related classes
◦ want to shield the rest of the system from
these details

 Facade provides a simplified interface

 Encapsulates a subsystem
 Defines interface to a layer

91
 Façade…
 Structural Pattern
 Provide a unified interface to a set of interfaces in a
subsystem without damaging the genric form of the
sub system.

92
Façade…

93
Façade… Consequences
 Shields clients from subsystem components,
making the subsystem easier to use

 Promotes weak coupling between

subsystems

 Leads to reducing compilation

dependencies

94
 Strategy
 You want to
◦ use different algorithms depending upon the context
◦ avoid having to change the context or client

 Strategy
◦ decouples interface from implementation
◦ shields client from implementations
◦ Context is not aware which strategy is being used;
Client configures the Context
◦ strategies can be substituted at runtime
◦ example: interface to wired and wireless networks
95
 Strategy …

Client Policy

Context Strategy

Concrete Concrete
StrategyA StrategyB

96
Strategy …

static void Main(

{
SortedList studentRecords = new SortedList();
studentRecords.Add("Samual");
studentRecords.Add("Jimmy");
studentRecords.Add("Sandra");
studentRecords.SetSortStrategy(new QuickSort());
studentRecords.Sort();
studentRecords.SetSortStrategy(new ShellSort());
studentRecords.Sort();
}

97
Strategy …
abstract class SortStrategy
{
public abstract void Sort(ArrayList list)
}
class QuickSort : SortStrategy
{
public override void Sort(ArrayList list)
{
list.Sort(); // Default is Quicksort
}
}
class ShellSort : SortStrategy
{
public override void Sort(ArrayList list)
{
//list.ShellSort(); not-implemented
}
}
98
Strategy …
class SortedList
{
private ArrayList list = new ArrayList();
private SortStrategy sortstrategy;
public void SetSortStrategy(SortStrategy sortstrategy)
{
this.sortstrategy = sortstrategy;
}
public void Add(string name)
{
list.Add(name);
}

public void Sort()

{
sortstrategy.Sort(list);
}
}

99