UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 1 CSE 503 – Software Engineering Lecture 14: Introduction to software architecture Rob DeLine 12 May 2004

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 2 What is a software architecture? According to Google Images...

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 3 What do these figures contain? Components (boxes)  Places where computation takes place  Places where data is stored  Box shapes discriminate component type Connections (lines)  Some kind of interaction among components  Often binary, sometimes n-ary  Line attributes discriminate connection types Composition (grouping, backgrounds, fences)  Show commonality, boundaries Often accompanied by descriptive jargon  “pipe and filter”, “client/server”, “object-oriented”, “publish/subscribe”, “layered”, “microkernel”, “web services”,...

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 4 Carving out a new level of abstraction In the early age of programming languages... sum := 0; i := 0; while (i < 10) { sum := sum + i; i := i + 1; } return; 10: stconst r0, 0 11: stconst r1, 0 12: stconst r2, 10 13: sub r2,r0,r4 14: bz r4, 18 15: add r1,r0,r1 16: incr r0 17: br 12 18: ret sum := 0 i := 0 i <= 10 sum := sum + i; i := i + 1; return T F no control abstractions semi-formal notations and jargon precise notations and disciplines “structured programming”

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 5 Architecture as a new abstraction Researchers are carving out a higher-level abstraction architectural description languages (ADLs) s = socket(...); bind(s,...); listen(s,...); while (true) { x = accept(s,...); receive(x,...); close(x); } no interaction abstractions semi-formal notations and jargon precise notations and disciplines pattern languages and other guidance classifications

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 6 Architectural description languages In the 90s, researchers created many architectural notations  grew out of module interconnection languages (1975)  focus on recording system structure (typically static structure)  different goals, but many shared concepts Common concepts  Components  Connectors (common disagreement: aren’t these just components?)  Compositions (combinations of elements to form new elements)  Architecture style (constraints on elements and their composition)

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 7 UniCon Focus on encapsulating complex construction rules  Editor lets you drag-and-drop elements and hook them up  Given a system description, UniCon’s compiler produces low-level interaction code build instructions (makefile) that invokes needed tools Shaw, DeLine, Klein, Ross, Young and Zelesnik, “Abstractions for software architectures and tools to support them”, Trans. on Soft. Eng. 21(4):

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 8 Wright Focus on making interaction formal  Components interact through ports  Connectors interact through roles  Attachments are made by binding ports to roles  Ports and roles are formally defined as CSP processes  Port/role compatibility is a process refinement check Since we studied process calculi, let’s look in more detail... Allen and Garlan, “Formalizing architectural connection”, ICSE ’94.

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 9 Wright component description Split is a “tee” filter component Split = port In = read?x -> In [] read-eof  close   port Left, Right = write!x  Out ┌┐close   comp spec = let Close = In.close  Left.close  Right.close   in Close [] In.read?x  Left.write!x  (Close [] In.read?x  Right.write!x  computation)

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 10 Wright connector description A pipe is a queue of text connector Pipe = role Writer = write!x  Writer ┌┐close   role Reader = let ExitOnly = close   in let DoRead = (read?x  Reader [] read-eof  ExitOnly) in DoRead ExitOnly glue = let ReadOnly = Reader.read!y  ReadOnly [] Reader.read-eof  Reader.close   [] Reader.close   in let WriteOnly = Writer.write?x  WriteOnly [] Writer.close   in Writer.write?x  glue [] Reader.read!y  glue [] Writer.close  ReadOnly [] Reader.close  WriteOnly spec  Reader.read i !y.  Writer.write j ?x. i=j  x=y  Reader.read-eof  (Writer.close  #Reader.read = #Writer.write)

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 11 Wright system description A system composes components and connectors system Capitalize component Split =... connector Pipe = instances split: Split; p1, p2: Pipe; attachments split.Left as p1.Writer; upper.In as p1.Reader; split.Right as p2.Writer; lower.In as p2.Reader;... end Capitalize.

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 12 Classifying aspects of architecture Taxonomies and other classifications  Gather known examples into rigorous, but not formal, structure  Often a good first step toward theory  Important precedents in biology, chemistry Examples  Shaw and Clements, “A field guide to boxology: Preliminary classification of architectural styles for software systems,” Compsac ’97  Kazman, Clements, Abowd, and Bass, “Classifying architectural elements as a foundation for mechanism matching,” Compsac ’97  DeLine, “A catalog of techniques for resolving packaging mismatch”, Symp. on Software Reusability 1999  Mehta, Medvidovic, and Phadke, “Towards a taxonomy of software connectors”, ICSE 2000

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 13 Shaw and Clements taxonomy

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 14 Shaw and Clements taxonomy

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 15 Kazman et al taxonomy

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 16 Kazman et al taxonomy

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 17 Kazman et al taxonomy

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 18 Kazman et al taxonomy

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine 19 Guidance Researchers are recording what experts know about arch.  Given a problem, how do I pick an architecture? Lane, “Studying software architecture through design spaces and rules,” Tech Report CMU-CS  Given a set of extrafunctional requirements, how do I pick an arch.? Kazman, Bass, Abowd, Webb, “SAAM: A method for analyzing the properties of software architectures,” ICSE ’94  Given a set of attacks and security tools, which is most cost effective? Butler, “Security attribute evaluation method: a cost-benefit approach”, ICSE ’02 Important case: pattern languages  Catalogue of problem/solution pairs  Next Mon: A quick tour of Gamma &al’s pattern language  Next Wed: A quick tour of different architectural styles