1 CS115 Class 7: Architecture Due today –Requirements –Read Architecture paper pages 1-15 Next Tuesday –Read Practical UML.

1

CS115 Class 7: Architecture

• Due today– Requirements – Read Architecture paper pages 1-15

• Next Tuesday– Read Practical UML

2

Software Architecture

• After requirements (what to build), next step is design (how to build it)

• Often split into two phases– High-level design (aka Architectural design)– Low-level design (aka detailed design)

• So architecture = initial design decisions– often graphical (boxes and arrows)

3

Choose Wisely

• “Marry your architecture in haste, repent at your leisure.” – Barry Boehm

• “Software is transparent and malleable in the small, but opaque and brittle in the large.”

4

Software Architecture: What?

• It’s an abstraction of the system that enables you to reason about critical aspects of its behavior– “intellectually graspable”

• What to abstract away?– anything you can, unrelated to critical behavior– art in choosing level of abstraction (details to support

reasoning, simplification to be able to grasp)

• What’s left in?– components, connectors, interactions– may want multiple views

5

Architecture as Modular Decomposition

• An architecture specifies how the system is decomposed into cooperating modules.

• What is a module?• Why are modules good?• Which modules are good?• Which modular decompositions are good?

6

Module

• Some way to break a program into pieces and relationships– Lexically contiguous sequence of program

statements, having an aggregate identifier • (Yourden and Constantine, 1979)

– Java: package, class, method• not so much a statement block {}, expression

7

Characteristics of Good Modules

• Support thinking-inside– High cohesion (single purpose)– Complete (can understand with little context) and

reusable– All methods focus on attributes associated with the

object

• Support thinking-outside (abstraction)– Low coupling (simple interface) – Information hiding (implementation/representation

details)

8

Example module decomposition:What’s good and not-so-good?

9

Evaluating an Architecture

• Consider a collection of change case scenarios• For each scenario, estimate changed LOC• Sum over all scenarios

– (probability of scenario changing) x (changed LOC for scenario)

• Gives indication of evolveability of architecture– good selection of scenarios is critical

• Hard to do in practice

10

Architectural Models

• Architectural Models distill essence of past successes– recurring solutions to recurring problems– “Set of constraints on an architecture that

defines a set or family of architectures that satisfies them” from SWEBOK

– like design patterns, but at strategic, whole system scale

– some may seem familiar/obvious

11

Call/Return Architecture

12

Layered Architecture

13

Layered Architecture

14

Data-Flow Architecture

15

Dataflow Architecture

• Each component has a set of inputs and outputs.• A component reads a stream of data on its input and

produces a stream of data on its outputs.• Input is transformed both locally and incrementally so that

output begins before input is consumed (a parallel system).• Components are called filters; independent, don’t know

other filters.– If every filter process all data at one go, is batch sequential

• Connectors serve as conduits for the information streams and are termed pipes– specializations: pipeline (single sequence thru), bounded

(amount in pipe is restricted)• Common style: Unix, compilers, signal processing, parallel

systems, distributed systems

16

Dataflow Architecture

• easy understanding of the system's behavior as the composition of filters

• obvious reuse• easy to maintain and

enhance• support concurrent

execution

• often leads to batch processing - when all goes thru first filter then all thru 2nd

• poor for interactive apps• may force lowest common

denominator on data transmission, resulting in added work for each filter to parse input and format output data which can, in turn, affect performance and increase complexity of the filters

Pro Con

17

Client-Server Model (Two Tier)

18

Limitations of Two Tier Architecture

• Fat client– does application code (code update problem)

• Thin client– just user interface code (overloads server)

• Really have three conceptual layers– user interface– application code– data storage

19

Three-Tier Model

20

Crafting a Good Architecture

• Understand domain• Internalize common architectural models• Evaluate (see earlier)• Iterate

• Choose your architecture wisely.

21

Design Deliverable Expectations

• After Architecture comes (detailed) design• Both are together in same deliverable

– allows iteration on architecture– due May 4

• Most technically challenging deliverable– plan to review designs in class

• May 4 Blue Team , 9 - Awesome and Quadratron, 11 – PhermWare and SKARGO , 16 – ZeroVector

– one per day, 30+ minutes– interactive

• would you want to be involved in implementing this design?• can you make it better?