Software Design and

Architecture
WEEK 1
COU RS E I N T RODUC TI ON
COU RS E I N STRU C TOR: TA ZZA I NA M A L I K
Course Contents
Software Design
◦ Design Concepts
◦ Design Principles
◦ Patterns (GRASP & GoF)

Software Architecture
◦ What is SA and its core concepts
◦ Quality Attributes
◦ Designing, documenting and evaluating SA
◦ Architectural Patterns and Styles
◦ Service Oriented Architecture

2
Course Goals
Students should be able to

◦ Apply various design patterns and

◦ Understand core software architecting activities

3
Tentative Marks distribution
Quizzes 20%
Presentations 10%
Assignments 20%
Midterm 20%
Final Exam 30%

4
Recommended books
Software Architecture and Design Illuminated, Kai Qian, Xiang Fu, Lixin
Tao, Chong-Wei Xu, Jorge L. Diaz-Herrera, Jones and Bartlett Publishers,
1st Edition (or latest edition).
Introduction to Software Engineering Design: Processes, Principles and
Patterns with UML2, Christopher Fox, Addison-Wesley Professional,
2006 (or Latest Edition).
Software Engineering Design: Theory and Practice, Carlos Otero, CRC
Press, 2012 (or Latest Edition).
Software Architecture in Practice by Len Bass, Paul Clements, Rick
Kazman

5
General rules
Appropriate behavior expected
No makeups of any Assessments
Zero tolerance for Cheating and Plagiarism (which means zero marks in
that particular assessment)
Mobile Phone usage not allowed

6
Course Introduction

7
8
Floor Plan

9
Landscape Plan

10
Interior Plan

11
When we
talk about
Software

12
We build multiple diagrams

13
Architecture

14
Example-3 Tier Model

15
Why so much pain?

16
 De Architectura
firmitatis utilitatis venustatis
the firmness of the utility of charm

• Durability:
the building should last for a long time without falling down on the
people inside it
• Utility:
the building should be useful for the people living in it
• Beauty:
the building should look good and raise the spirits of its
inhabitants

17
Example:

18
Example:
19
Example:

20
Example:
21
Example:

22
Example:
23
 Architecture:
The Art and Science of Building
• Architects are not concerned with the creation of building
technologies and materials—making glass with better thermal
qualities or stronger concrete.
• Architects are concerned with how building materials can be put
together in desirable ways to achieve a building suited to its
purpose.
• The design process that assembles the parts into a useful,
pleasing (hopefully) and cost-effective (sometime) whole that is
called “architecture”.

24
Is it a new Concept?
Architecting, the planning and
building of structures, is as old
as human societies
– and as modern as the
exploration of the solar system
Eberhardt Rechtin
1991

25
When do you need an
architect?
It depends what you are trying to build…

26
 Small Scale:
One person can do it alone with:
Minimal modeling Simple process Simple tools

27
 Medium:

Better to build a house as a team using some:

Modeling plans Well-defined process Power tools

28
Large:

You definitely need an

architect for planning a
skyscraper!
Am I right?

29
How Large?
• Always choose the
tools and design
strategy
appropriate for the
size of the project
you're working on

30
 How much time to build it?

How many people in the project?

How much did it cost?

How Large?
Hard to measure software size:

• Estimate the “lines of code” (LOC)

• Measure the deployment size (GB)

31
 How Large?
Name Size Time
Indusha 4-5 People (Java) 1 semester
Luca 2 People (C++, 4k LOC) 2 months
Athos 4 People (C, Hardware) 1 year
Alan 4 People (PHP, ~100 “pages”) 3 years
Andrea 1 Person (Bachelor Prj, PHP 40- 2.5 months
50 files)
Alessio 15-20 People (Wiki, Ruby, 1 semester
Atelier Project, 50 Ruby Files)
Labinot 5 People (C#, 70-80 classes) 8 months
Alessio G. 1 Person (Tapestry, Java5, 50 6 months
classes)
Danilo A. Robots (C++/Java/C, 30 big 6 months
classes)

32
Large Software Project:
• Lines of code: 50 Million
• Number of developers: 2000
• Time to compile: 24 hours
• Time to ship: 5 years (from previous release)

33
Software
Architecture:
As the size and complexity of
a software system increase,
the design decisions and the
global structure of a system
become more important than
the selection of specific
algorithms and data
structures.

34
 Context:
• Software Engineering
• Programming Languages How to build
• Algorithms and Complexity components
from scratch
• Databases

• Software Architecture
How to design large systems
• Component-based out of reusable components
Software Engineering

35
 Why SW Architecture?
1. Manage complexity of large software projects through
abstraction
2. Communicate, remember and share global design decisions
among the team
3. Visualize and represent relevant aspects (structure,
behavior, deployment, …) of a software system
4. Understand, predict and control how the design impacts
quality attributes of a system
5. Define a flexible foundation for the maintenance and future
evolution of the system

36
 Abstraction:

• The hard part is to know which details to leave

out and which should be emphasized
37
Who is a Software Architect?

38
You know him?

• William (Bill) H. Gates,

Chief Software Architect, Microsoft
(until June 2006)
39
 Customers

Marketing Analyst
Model the
problem Define
Requirements
Measure
Performance
Architect & Design Architect
IT Operations
Manager Product
Manager
Manage Manage
Change Program Modeler
Code
Deploy
Application Test
Support
Helpdesk
Developer

Operations Deployment Tester - QA Development

40
Role of the Architect:
1. Software Engineering Lead
– Excellent software engineering skills
– Lead technical development team by example
– Solve the hard problems
– Understand impact of decisions
– Defend architectural design decisions
– Promote good development practices
– Plan and manage software releases

41
Role of the Architect:
2. Facilitate Communication

42
Role of the Architect:
3. Technology Expert
– Know and understand relevant technology
– Evaluate and influence the choice of 3rd party
frameworks, component and platforms
– Track technology development
– Know what you don’t know

43
Role of the Architect:
4. Risk Management
– Estimate and evaluate risks associated with
design options and choices
– Document and manage risks, making the whole
team (incl. management) aware
– Prevent disasters from happening

44
 Architect Soft Skills:
Technical Leadership
• Creative problem solver • Charismatic and credible
• Practical/pragmatic • Committed, dedicated, passionate
• Insightful, Investigative • Know how to motivate teams
• Tolerant of ambiguity, willing to
backtrack, seek multiple solutions
• Good at working at an abstract level Organizational politics
• Able to see from and sell to
Consulting multiple viewpoints
• Committed to others’ success • Confident and articulate
• Empathetic, approachable • Ambitious and driven
• An effective change agent, process • Patient and not
savvy
• Resilient
• A good mentor, teacher
• Visionary • Sensitive to where the power is
and how it flows in an organization
• Entrepreneurial

45
Software Development Activities
Requirements Elicitation
Requirements Analysis (e.g., Structured Analysis, OO Analysis)
◦ analyzing requirements and working towards a conceptual model without
taking the target implementation technology into account
◦ useful if the conceptual gap between requirements and implementation is
large

Design
◦ coming up with solution models taking the target implementation
technology into account

Implementation
Test

46
Waterfall Model
1. Requirement Analysis
2. Design

Architecture

3. Implementation
4. Testing
5. Maintenance
47
Bridge the Gap:
Problem Space Solution Space

Problem Architecture Design

Definition
Data Models
Functional
Requirements Code

Non-functional Acceptance Tests

Requirements

48
 Evolutionary Model:
Software
concept

Preliminary Architecture
requirements
analysis

Design of
architecture and
system core
Develop
a version

Architectural decisions Incorporate Deliver a

are made early in customer
feedback
version

the development lifecycle Elicit

customer
feedback
49
 System Lifecycle:
Vision

Architectural decisions Inception

affect the whole lifetime
of a system Development

Deployment

Operation

Architecture Maintenance

Alteration

Legacy
operation

Death
50
Architecture Definition
• A software system’s architecture is the set
of principal design decisions made about
the system.
Architecture = {Principal Design Decision}

From N. Taylor et al
• It is the blueprint for a software system’s
construction and evolution
51
Architecture Definition
A “software architecture” is the structure
(or structures) of a system, which comprise
◦ software components,
◦ the externally visible properties of those
components,
◦ and the relationships among them.

52
Good Software Architecture:
Helps your software systems become:
1. Flexible
2. Reusable
3. Maintainable

53
Components & Structures
Architecture defines “components”
◦ an abstraction
◦ suppresses details not pertinent to its interactions with
other components
An architecture comprises more than one structure
◦ modular structure (calls/uses)
◦ process structure (invokes, communicates with,
synchronises with)
◦ physical structure (libraries, DLL’s, processors)
◦ inheritance structures (inherits)

54
In Practice
Divide into two levels:
◦System-Level Architecture
◦Programming-Level Design

55
Difference:
56
What Is Design?
Requirements specification was about the WHAT
the system will do
Design is about the HOW the system will perform
its functions
◦ provides the overall decomposition of the system
◦ allows to split the work among a team of developers
◦ also lays down the groundwork for achieving
nonfunctional requirements (performance,
maintainability, reusability, etc.)
◦ takes target technology into account (e.g., kind of
middleware, database design, etc.)

57
Good Design in a nutshell
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

58
Software Architecture
Specifying at the highest level the construction of the
system:
◦ Technology choices
◦ Platforms, language, database, middleware, …
◦ System construction
◦ Overall pattern: RDBMS, client/server, 3-tiered, n-tiered, distributed, …
◦ Hardware interfaces (if any)
◦ Division into programs
◦ E.g. a program for data entry, another for data analysis, a Web-oriented
interface, …
◦ Division of programs into major subsystems
◦ Reuse strategy (shared subsystems)
◦ Calls constraints
◦ Major strategies

59
Software Design
We are now considering how to lay down code.
E.g., Object-Oriented
◦ What classes? What inheritance amongst the classes?
◦ What classes will call what other classes?
◦ How are classes grouped into subsystems (e.g. Java
packages)?
◦ What data members of classes

60
Goals of Software Design
Design faces many challenges to produce a good product, e.g. shifting
requirements.
But what do we mean by good?
We need some clear goals here …

61
Design Goals
Good design leads to software that is:
1.Correct–does what it should
2.Robust–tolerant of misuse, e.g. faulty data
3.Flexible–adaptable to shifting requirements
4.Reusable–cut production costs for code
5.Efficient–good use of processor and memory

Also should be Reliable and Usable

62
Correctness
Correctness

Software is correct, if it satisfies its requirements.

A primary goal, incorrect software may look good, but will be poor or
worse.
Requirements are divided into functional (what it does) and non-
functional(how it does it, etc.)
Non Functional requirements can be further categorized into Product,
Organizational, and External requirements

63
Non Functional Requirements
Product
◦ Usability
◦ Efficiency
1. Speed
2. Throughput
3. Memory
◦ Reliability

64
Non Functional Requirements
Organizational
◦ Delivery (e.g. quality of documentation, manuals, training, support)
◦ Implementation (e.g. commenting, flexibility, openness, maintainability)
◦ Standards (e.g ISO 9000)

External
◦ Legislative
◦ Privacy
◦ Safety
◦ Commercial (e.g licences)
◦ Interoperability
◦ Ethical

65
Correctness
Verification

Checking software against its requirements is called verification. Three

main approaches:

1.Testing,
2.Formal Verification
3.Code Inspections

66
Robustness
Robustness

A design or system is robust if it tolerates misuse without catastrophic

failure. i-e., fault-tolerant.
Includes bad data, bad use, bad environment, bad programming.

67
Robustness
Robustness achieved in many ways:
Use data abstraction and encapsulation
◦ –Create ADTs and simple interfaces
◦ –Shield from data corruption
Initialize variables
Qualify all inputs (e.g. range check)
◦ –Same as precondition checking
Qualify all formal parameters to a method
Qualify invariants
◦ –(e.g. non-null pointer, not end_of_file )
Qualify postconditions

68
flexibility
Requirements may change during or after the project.
◦ Obtaining more of what’s present e.g. more kinds of different bank accounts
◦ Adding new kinds of functionality e.g. add internet banking to teller
functionality
◦ Changing functionality e.g. allow withdrawals to create an overdraft

Flexibility achieved in many ways:

◦ Different types of the same base category by means of abstract classes
◦ Extend functionality by new class methods or with an abstract class & several
derived classes.

69
reusability
Use modularity
Use classes

70
Reliability
Reliability–mean time to failure (system crash, error)
•On architectural level can use hardware support, backup servers,
multiple processors, hot swap, etc
•On code level achieved by software quality assurance methods,
testing, walkthroughs, formal methods etc.

71
Architecture & Design
Architecture
◦ High-level
◦ Major decisions
◦ Not even thinking about programming
Design
◦ “Laying out” the programming language code used to
implement the architecture
◦ Organizing programming language concepts
But, … N.B. no standard terminology

72
 Design & Architecture in
the Development Process
Requirements

Architecture

Design Design Design Design

Code C&ut C&ut C&ut C&ut C&ut C&ut

&
Unit
Test

Integration
Test

System Test
73
THANK YOU

74