Introduction to Software Architecture Workshop

1. 6894 · workshop in software designlecture 12 · november 23, 1998 · software architecture

2. introduction • new? • software systems have always had ‘architectures’ • but a lot of recent interest in what exactly architecture is • this lecture • two parts • first, Garlan & Shaw’s argument for SA • second, critique and discussion

3. what is software architecture? • definition • level of abstraction: components are filters, databases, layers • aspects of design not addressed within modules • motivations • families of systems • getting it right: avoiding catastrophic design errors • choosing among design alternatives (cf. methods) • analysis and description (and tools) • shared vocabulary (cf. patterns)

4. style • what is style? • organize systems into families by architectural similarities • analogy to styles in building architecture • elements of style • structural pattern (topology): components, connectors & constraints • underlying computational model • essential invariants (by which G&S mean global properties) • common examples of use • common specializations • examples • pipe & filter • object-oriented • implicit invocation • layered system • …

5. pipes & filters • basic features • filters do not share state • filters communicate anonymously • order of execution immaterial • specializations • pipelines: linear sequence • bounded pipes • typed pipes • examples • UNIX shell • old-fashioned compilers • signal processing • benefits & liabilities • + flexible, analyzable • – become complex when sync needed P4 F1 F2 F3 P1 P2 F4 P3

6. abstract data types & objects • basic features • communication by procedure call • object preserves integrity of representation, hidden from other objects • objects may have their own threads • specializations • inheritance: single/multiple, spec/imp? • type system: static, functions as values, etc • asynchronous calls, objects have own threads • benefits & liabilities • + rep independence, interacting agents • – objects know each other’s identity

7. implicit invocation • basic features • instead of invoking procedure directly, component ‘announces’ event • system invokes procedures that have been ‘registered’ for that event • communication is anonymous • examples • programming environments & syntax-directed editors • triggers in databases • user interfaces (model-view-controller) • benefits & liabilities • + easy to replace, add new components • – components relinquish control over computation • – exchange of data can be hard • – hard to reason about correctness P1 e! REGISTRY P2 P3

8. layered systems • basic features • ‘onion skin’ organization, each a virtual machine • specializations • may restrict each layer to communicate only with adjacent layer • examples • communication protocols • benefits & liabilities • + support design based on levels of abstraction • + support enhancement of functionality • + reuse: layers can be interchanged • – performance may cause layers to be blurred • – can be hard to find right levels of abstraction

9. repositories • basic features • two kinds of component: central data structure + independent actors • specializations • various control disciplines: • blackboard: computation triggered by state of central structure • database: actors triggered to act on central state by input stream • examples • most compilers • AI blackboard systems for, eg, speech recognition • benefits & liabilities • + decoupling of actors: easy to add, change • – hard to predict overall behaviour A1 A3 C A2 A4

10. example: tektronix oscilloscopes • context • Garlan working at Tektronix • economies of scale across family of oscilloscopes? • object-oriented • ‘no model for how types fit together’ • led to confusion over partitioning of functionality • layered • layers • signal manipulation • waveform manipulation • display functions • user interface • abstraction boundaries a hindrance (eg, user needs to affect functions in all layers) • pipe & filter • big improvement, but how is user input handled? • added control interface to filters to set parameters • different pipe ‘colours’: process without copying, etc coupling Couple kind, rate Acquire trans Measure To-XY size Clip

11. kinds of architectural model • structural models • architecture = components + connectors + other stuff (constraints, style, properties, etc) • examples: Aesop, C2, Darwin, UniCon, Wright • framework models • focus on one specific structure • domain-specific architectures, CORBA, COM • dynamic models • large-grain behavioural properties • describe reconfiguration and evolution • examples: Chemical Abstract Machine, Conic, Darwin, Rapide

12. analysis of ADLs: what it offers • analysis of instances • event ordering and causality (Rapide) • evolution of configurations (Darwin) • real-time analysis (UniCon) • analysis of styles • is one style a substyle of another? • does a property hold for all instances of a style? • are connector types compatible with component types? (Wright)

13. sample ADL: Wright • connector Pipe = • role Writer = write!x -> Writer OR close -> done • role Reader = • let ExitOnly = close -> done • inlet DoRead = (read?x -> Reader [] read-eof -> ExitOnly) • in DoRead ExitOnly • glue = • let ReadOnly = Reader.read!y -> ReadOnly • [] Reader.read-eof -> Reader.close -> done • [] Reader.close -> done • in let WriteOnly = Writer.write?x -> WriteOnly [] Writer.close -> done • in Writer.write? x -> glue • [] Reader.read!y -> glue • [] Writer.close -> ReadOnly • [] Reader.close -> WriteOnly • specforall Reader.read(i)!y . exists Writer.write(j)?x . i = j && x = y • && Reader.read-eof => (Writer.close && #Reader.read = #Writer.write)

14. sample ADL: Darwin pipeline (n) output input F[0] F[1] F[n-1] • component pipeline (int n) { • provide input; • require output; • array F[n]: filter • forall k:0..n-1 { • inst F[k]; • bind F[k].output – output • when k < n-1 bind • F[k].next – F[k+1].prev; • } • bind • input – F[0].prev; • F[n-1].next – output; • }

15. critique • what is SA? • a level of abstraction? (but OO and pipe/filter seem far apart) • execution structure or code structure? • ‘components are the loci of computation and state’ • ‘a common organization for many reactive systems is the state transition system’ • why one SA per system? • connectors? • procedure call and database queries? • why not model with components alone? • styles? • are there more than a handful? • relation to object-oriented design • are patterns styles? • can OO express all G&S’s architectural styles? • are object models architectures? micro-architectures?

16. broader questions • what are the crucial design phases? • when are design representations needed? • when are rough sketches useful instead? • what’s the purpose of a design representation? • which properties should be expressed? • are graphical notations fundamentally any different? • does precision matter? • does non-ambiguity matter? • what role should a design continue to play? • code generation? • repository of information about evolving code? • to what extent should design express rationale, ie, why as well as what? • extra-functional properties?