CS115 Class 7: Architecture

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?

• Its 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)
• Whats 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 decompositionWhats 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, dont
  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
Con
Pro

• 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

• easy understanding of the system's behavior as
  the composition of filters
• obvious reuse
• easy to maintain and enhance
• support concurrent execution

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?