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?