1 / 21

CS115 Class 7: Architecture

CS115 Class 7: Architecture. Due today Requirements Read Architecture paper pages 1-15 Next Tuesday Read Practical UML. Software Architecture . After requirements (what to build), next step is design (how to build it) Often split into two phases

freja
Download Presentation

CS115 Class 7: Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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 Dataflow Architecture Con Pro

  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?

More Related