Designing the
Architecture
CSSE 477 Software Architecture
Steve Chenoweth, Rose-Hulman Institute
Week 3, Day 1, Monday, September 19, 2011
1
Today


What’s a viola, anyway?
Project 2 – progress report from each team:
 Describe
any issues with the changes you have tried
to make to your system, at the coding and/or design
level, to implement the “availability improvement
plan.”



Bass Ch 7, on Designing the Arch – this 
Tomorrow – Second case study (Ch 8)
Thursday – Check out this special lecture 
2
That’s this
Thursday!
3
Outline

Architecture in Lifecycle –


A quick review
Attribute-Driven Design Process

And a chance to try it
4
First Cartoon of the Day
5
Review of Incremental Lifecycle Models
and impact on architecture…
Spiral
 Evolutionary Prototyping
 Staged Delivery
 Design-to-Schedule
 Evolutionary Delivery

6
Spiral
Model


If growth of
the arch is
planned to
be early,
and to grow
along with
feature
growth, this
could work
well.
Similar to
Larman’s
iterative
model (from
374).
(Deliver)
7
Evolutionary Prototyping
Initial Concept





The “bad” version
of the spiral,
Create Prototype
for arch:
Good chance to
test arch in the
Refine Prototype
prototype, but -Team tends to focus on
feature prototyping
That test, or exposure to the
customer, may of course
cause arch changes!
In particular, arch shortcuts
will require a redo…
Release
(Deliver)
8
Staged Delivery
Initial Concept

Requirements
Architectural Design


Note that this is a
bigger picture –
showing multiple
“releases” or
“deliveries.”
Within any one,
could be spiral
model, say.
These early stages could be
like Larman’s (from 374), with
prototyping, etc. as
requirements are gathered.
Stage 1: Detailed design, implement, test, deliver
Stage 2: Detailed design, implement, test, deliver
Stage n: Detailed design, implement, test, deliver
9
Design-to-Schedule
Initial Concept

Requirements

Architectural Design
“Get done what we can by
September” version…
Probably the most common
model used (in practice).
High Priority: Detailed design, implement, test
Medium Priority: Detailed design, implement, test
Medium Priority: Detailed design, implement, test
Ran out of time or money
Release
Low Priority: Detailed design, implement, test
10
Evolutionary Delivery
Initial Concept


Requirements
Bass’s recommendation.
Looks a lot like “staged delivery.”
Architectural Design
Deliver Final Version
Develop Version
Incorporate Feedback
Deliver Version
Elicit Feedback
11
Second Cartoon of the Day
12
Attribute-Driven Design
Recursive decomposition
 Start with:

 Functional
requirements (use cases)
 Constraints
 Quality attributes (scenarios like Bass’s)
We’re trying to discover, top-down,
the pieces for the Reference Model
(from Ch 2), and then pick an
Architectural Pattern to suit…
13
Attribute-Driven Design Process
1.
2.
Choose module to decompose
Refine module:
Reference
Model
a)
Architectural
Pattern
b)
c)
Reference
Architecture
d)
e)
Software
Architecture
3.
Choose architectural drivers (from features, and
from quality attribute scenarios, in supplemental
spec. See next slide )
Choose architectural pattern (based on tactics in
Bass Ch 5)
Instantiate modules, allocate functionality, and
represent using multiple views
Define interfaces
Refine use cases and quality scenarios -- make
them constraints for sub-modules
Repeat until done
14
2.a) Choose Architectural Drivers



Drivers are combination of functional
requirements and quality attributes
Prioritize requirements and select those that will
"shape" the architecture
May need some investigation to determine
drivers
15
2.b) Choose Architectural Pattern




Use tactics to achieve quality attributes
Patterns package tactics
Document your choice of tactics in your Design
Notebook!
Much of this work tends to be “how it works at
runtime” – The key view looks like component
and connector diagrams 
16
Pattern for Garage Door Opener
This design allowed
for:
 Semantic
coherence and
information hiding
 Increased
computational
efficiency
 Scheduling wisely
17
2.c) Instantiate Modules


Refine (or interpret) the pattern for your
particular problem
Result is a decomposition into sub-modules
18
First-Level Decomposition
19
2.c) Allocate Functionality

Use the use cases to identify flow of information
 Try
to “walk through” use cases in your component &
connector view


Assign responsibilities to sub-modules
Pattern may help this process
 Is
there an architectural style that applies?
 Can we apply a standard design pattern (e.g., proxy,
façade)?
 Is there a known algorithm for this kind of problem?
20
2.c) Represent Using Multiple Views

Pick one view from each major category:
 Module

Decomposition, Uses, Class
 Component

and Connector
Client-server, Concurrency, Process, etc.
 Allocation

Work assignment, Deployment, Implementation
21
2.d) Define Interfaces
Child views need to show how they connect to
other views:
 Each view provides information about interfaces
 Need to identify services provided and used
22
2.e) Refine Use Cases and Quality
Scenarios

Associate use cases and quality attributes to
sub-modules
 may

need to break up use cases
Quality scenarios:
 may
be satisfied by decomposition
 may impose constraints on sub-modules
 may be neutral with respect to decomposition
 may not be satisfiable with decomposition
23
Let’s try it
Your quiz refers to the Music4Sale
system, which you and a partner will
design.
 See the other quiz page for the
requirements. See the next slides for
some “competition.”

24
25
26
27
28
29
Napster:
 This one’s an example of
a peer-to-peer system.
 Once the central index
server provided the
information to make a
connection, all the file
activity was between
peers on the network.
The original Napster architecture, from http://www.slais.ubc.ca/COURSES/libr500/05-06-wt1/www/R_Martin/Nap_Arch.htm.
30