SE - Software Design
SE - Software Design
1
Design Knowledge Area
Software Design Fundamentals
distribution of components,
data persistence 2
Design KA..
Software Structure and Architecture
◦ architectural structures and viewpoints,
◦ architectural styles,
◦ design patterns,
◦ families of programs and frameworks
◦ data-structure-centered 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
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.
9
10
Design Fundamentals
11
Design Concepts and Principles
Hiding—controlled interfaces
13
Effective Modular Design -- Functional
Independence
Critical in dividing system into
independently implementable parts
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‖
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.
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.
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.
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.
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”
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?
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.
54
Documenting …
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
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,
59
RUP Approach
It is based on the 4+1 view model.
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
◦ 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
65
Data-Oriented B2B Application
Integration
• Data-oriented B2B application integration allows for data
to be moved between data stores.
67
Advantages &Disadvantages
Simplicity
68
Federated Database B2B Application
Integration
69
Advantages & Disadvantages
• It relies on middleware to share information between
applications.
70
Integration Approaches…
Business Process Integration-Oriented
71
Integration Approaches…
Service Oriented
◦ Allows applications to share common logic or
methodologies, usually through the use of a composite
application
72
Integration Approaches…
Portal Oriented
◦ Basically defined as the integration of a multitude of
differing systems through a single user interface or
access point.
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
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
78
Solution
Describes the elements that make up the
◦ design
◦ relationships
◦ responsibilities
◦ collaborations
79
Consequences
Results and trade-offs of applying the pattern
Critical for:
◦ evaluating design alternatives
◦ understanding costs
◦ understanding benefits of applying the pattern
81
Example: Stock Quote Service
Real time
Market
Data
Feed
Stock Quotes
Customer Customer
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
} +detach(in Observer)
ConcreteObserver
ConcreteSubject
-subjectSate * +update()
1
+getState()
84
Collaborations in Observer Pattern
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
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
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 …
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);
}
99