1

Designing the Architecture

CSSE 477 Software ArchitectureSteve Chenoweth, Rose-Hulman InstituteWeek 3, Day 1, Monday, September 19, 2011

2

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

3

That’s thisThursday!

4

Outline

Architecture in Lifecycle – A quick review

Attribute-Driven Design Process And a chance to try it

5

First Cartoon of the Day

6

Review of Incremental Lifecycle Modelsand impact on architecture…

Spiral Evolutionary Prototyping Staged Delivery Design-to-Schedule Evolutionary Delivery

7

SpiralModel

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)

8

Evolutionary Prototyping

Initial Concept

Create Prototype

Refine Prototype

Release

The “bad” version of the spiral, for arch:

Good chance to test arch in the 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…

(Deliver)

9

Staged DeliveryInitial Concept

Requirements

Stage 1: Detailed design, implement, test, deliver

Stage 2: Detailed design, implement, test, deliver

Stage n: Detailed design, implement, test, deliver

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.

10

Design-to-ScheduleInitial Concept

Requirements

High Priority: Detailed design, implement, test

Medium Priority: Detailed design, implement, test

Low Priority: Detailed design, implement, test

Medium Priority: Detailed design, implement, test

ReleaseRan out of time or money

“Get done what we can by September” version…

Probably the most common model used (in practice).

11

Evolutionary DeliveryInitial Concept

Requirements

Architectural Design

Develop Version

Deliver Version

Elicit Feedback

Deliver Final Version

Bass’s recommendation. Looks a lot like “staged delivery.”

Incorporate Feedback

12

Second Cartoon of the Day

13

Attribute-Driven Design

Recursive decomposition Start with:

Functional requirements (use cases)ConstraintsQuality 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…

14

Attribute-Driven Design Process

1. Choose module to decompose2. Refine module:

a) Choose architectural drivers (from features, and from quality attribute scenarios, in supplemental spec. See next slide )

b) Choose architectural pattern (based on tactics in Bass Ch 5)

c) Instantiate modules, allocate functionality, and represent using multiple views

d) Define interfacese) Refine use cases and quality scenarios -- make

them constraints for sub-modules

3. Repeat until done

ReferenceModel

ArchitecturalPattern

ReferenceArchitecture

SoftwareArchitecture

15

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

16

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

Pattern for Garage Door Opener

This design allowed for:Semantic coherence and information hidingIncreased computational efficiencyScheduling wisely

17

18

2.c) Instantiate Modules

Refine (or interpret) the pattern for your particular problem

Result is a decomposition into sub-modules

19

First-Level Decomposition

20

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?

21

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

22

2.d) Define Interfaces

Child views need to show how they connect to other views:Each view provides information about interfacesNeed to identify services provided and used

23

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

24

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.”

25

26

27

28

29

30

The original Napster architecture, from http://www.slais.ubc.ca/COURSES/libr500/05-06-wt1/www/R_Martin/Nap_Arch.htm.

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.