CSE 503 – Software Engineering Lecture 14: Introduction to software architecture Rob DeLine

1. CSE 503 – Software Engineering • Lecture 14: Introduction to software architecture • Rob DeLine • 12 May 2004

2. What is a software architecture? • According to Google Images...

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”, ...

4. sum := 0 i := 0 F return i <= 10 T sum := sum + i; i := i + 1; Carving out a new level of abstraction • In the early age of programming languages... no control abstractions semi-formal notations and jargon precise notations and disciplines 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; while (i < 10) { sum := sum + i; i := i + 1; } return; “structured programming”

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

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)

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):314-335.

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.

9. Wright component description • Split is a “tee” filter • component Split = • port In = read?x -> In [] read-eof " close "P • port Left, Right = write!x " Out ┌┐close "P • compspec = • let Close = In.close " Left.close " Right.close "P • in Close [] • In.read?x " Left.write!x " • (Close [] In.read?x " Right.write!x "computation)

10. Wright connector description • A pipe is a queue of text • connector Pipe = • role Writer = write!x " Writer ┌┐close "P • role Reader = let ExitOnly = close "P • inlet DoRead = (read?x " Reader [] read-eof " ExitOnly) • in DoRead ExitOnly • glue = let ReadOnly = Reader.read!y " ReadOnly • [] Reader.read-eof " Reader.close "P [] Reader.close "P • inlet WriteOnly = Writer.write?x " WriteOnly [] Writer.close "P • in Writer.write?x "glue [] Reader.read!y "glue • [] Writer.close " ReadOnly [] Reader.close " WriteOnly • spec" Reader.readi!y . $ Writer.writej?x . i=j Ú x=y • Ù Reader.read-eof Þ (Writer.close Ù #Reader.read = #Writer.write)

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.

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

13. Shaw and Clements taxonomy

14. Shaw and Clements taxonomy

15. Kazman et al taxonomy

16. Kazman et al taxonomy

17. Kazman et al taxonomy

18. Kazman et al taxonomy

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-90-175 • 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