14-Architecture

CSE 503 – Software Engineering
Lecture 14: Introduction to software architecture
Rob DeLine
12 May 2004
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine
1
What is a software architecture?
According to Google Images...
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine
2
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
3
Carving out a new level of abstraction
In the early age of programming languages...
no control
abstractions
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
semi-formal notations
and jargon
sum := 0
i := 0
i <= 10
T
sum := sum + i;
i := i + 1;
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine
F
return
precise notations
and disciplines
sum := 0;
i := 0;
while (i < 10) {
sum := sum + i;
i := i + 1;
}
return;
“structured
programming”
4
Architecture as a new abstraction
Researchers are carving out a higher-level abstraction
no interaction
abstractions
semi-formal notations
and jargon
s = socket(...);
bind(s, ...);
listen(s, ...);
while (true) {
x = accept(s, ...);
receive(x, ...);
close(x);
}
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine
precise notations
and disciplines
architectural
description
languages (ADLs)
classifications
pattern languages
and other
guidance
5
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
6
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.
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine
7
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
8
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
comp spec =
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)
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine
9
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
in let 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
in let 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)
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine
10
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
11
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
12
Shaw and Clements taxonomy
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine
13
Shaw and Clements taxonomy
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine
14
Kazman et al 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
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
 503
Next
Wed:
A quick
tour
different architectural styles
UW CSE
▪ Software
Engineering
▪ Spring 2004
▪ Robof
DeLine
19

Download Report