12. Architecture, Design, Implementation
sw design
12
«Architecture is concerned with the
selection of architectural elements, their
interaction, and the constraints on those
elements and their interactions …»
Dewayne E. Perry,
Alexander L. Wolf, 1992
13. Architecture, Design, Implementation
sw design
13
«Design is concerned with the
modularization and detailed interfaces of
the design elements, their algorithms and
procedures, and the data types needed to
support the architecture and to satisfy the
requirements …»
Dewayne E. Perry,
Alexander L. Wolf, 1992
14. Architecture, Design, Implementation
sw design
14
«Since a principal use of an architectural
design is to reason about overall system
behavior, architectural designs are typically
concerned with the entire system»
Robert T. Monroe, Andrew J. Kompanek,
Ralph Melton, David Garlan, 1997
15. Architecture, Design, Implementation
sw design
15
«[design] patterns deal with lower-level
implementation issues than architectures
generally specify»
Robert T. Monroe, 1997
16. Architecture, Design, Implementation
sw design
16
«Structural issues
[that architecture is concerned with]
include gross organization and global
control structure; … physical
distribution; composition of design
elements; scaling and performance”»
David Garlan, Mary Shaw, 1993
20. Architecture, Design, Implementation
sw design
20
Universal Base Class - Example
(Satisfaction)
public class Object {
...
}
public class Foo extends Object {
...
}
p =
p ⊨ 𝜑
21. Architecture, Design, Implementation
sw design
21
Universal Base Class - Example
(Violation)
p’ =
public class Object {
...
}
public class Foo extends Object {
...
}
public class Bar { // ‘extends’?
...
}
p’ ⊭ 𝜑 THINK PURE MODEL
23. Architecture, Design, Implementation
sw design
23
‣ Compiler must check (and update)
each and every class to make sure that
all of them inherit from some other class
(‘check everything’ rule is applicable for
all tools enforcing architectural
constraints)
Universal Base Class
25. Architecture, Design, Implementation
sw design
25
‣ Statement must be definitive
‣ Statement should describe collection
of conforming programs in terms of
entities and relations
‣ Statement should have a signature
(constant symbols + relation symbols)
Statement Requirements
26. Architecture, Design, Implementation
sw design
26
Finite Structure / Design Model
Formally
Finite structure M
is an ordered pair <UM,RM> such that
UM={a1,…ak} is a finite set of entities, and
RM={R1,…Rn} is a finite set of relations over
the entities in UM
27. Architecture, Design, Implementation
sw design
27
Finite Structure / Design Model
(Satisfaction)
Entities:
Object, Foo
Relations:
Class = { Object, Foo }
Inherit = { ( Foo, Object ) }
⟦p⟧ =
public class Object {
...
}
public class Foo extends Object {
...
}
p =
⟦p⟧ ⊨ 𝜑
28. Architecture, Design, Implementation
sw design
28
Finite Structure / Design Model
(Violation)
Entities:
Object, Foo, Bar
Relations:
Class = { Object, Foo, Bar }
Inherit = { ( Foo, Object ) }
⟦p’⟧ =
p’ =
public class Object {
...
}
public class Foo extends Object {
...
}
public class Bar { // ‘extends’?
...
}
⟦p’⟧ ⊭ 𝜑
30. Architecture, Design, Implementation
sw design
30
Tarski’s Truth Conditions
Finite structures +
Tarski’s truth conditions =
Straightforward criterion of satisfaction
against statements in first-order predicate calculus
31. Architecture, Design, Implementation
sw design
31
Closed Statements
(Example)
∃x • Method(x)
Satisfied by M iif there exists an entity m
in M such that m is a method entity in M
32. Architecture, Design, Implementation
sw design
32
Open Statements
(Example)
Inherit(x, y)
Satisfied by M iif there is an assigment
σ where Inherit(σ(x), σ(y)) holds true
(e.g. σ(x)=Foo and σ (y)=Object)
33. Architecture, Design, Implementation
sw design
33
How Are The Programs Translated
into Finite Structures?
Abstract interpretation function I
is a functional relation which maps each
program p into a finite structure I(p),
written ⟦p⟧i
34. Architecture, Design, Implementation
sw design
34
Intension/Locality
Thesis
‣ Architectural specifications are
intensional and non-local
‣ Design specifications are intensional
but local
‣ Implementation specifications are
both extensional and local
39. Architecture, Design, Implementation
sw design
39
LOCALITY CRITERION
(less formally)
A statement 𝜑 is local iif
a program that satisfies cannot be
expanded into a program that violates it
43. Architecture, Design, Implementation
sw design
43
INTENSION CRITERION
A statement 𝜑 is extensional iif
it is preserved both under expansion
and under reduction
44. Architecture, Design, Implementation
sw design
44
INTENSION CRITERION
(less formally)
A statement 𝜑 is extensional iif
a program that satisfies it cannot be
expanded or reduced into a program that
violates it
46. Architecture, Design, Implementation
sw design
46
Expansion Formally
M = <U,R> - finite structure.
M’ = <U’,R’> is an expansion of M if it
can result by:
‣ adding a non-empty finite set of new entities to U,
i.e. U’=U ∪ {b1,...bj}
‣ adding to each n-ary relation R in R zero or more
n-tuples, each of which contains at least one of
b1,...bj
47. Architecture, Design, Implementation
sw design
47
Valid Expansion (Universal Base Class)
public class Object {
...
}
public class Foo extends Object {
...
}
public class Object {
...
}
public class Foo extends Object {
...
}
public class Bar { // ‘extends’?
...
}
48. Architecture, Design, Implementation
sw design
48
Invalid Expansion (Universal Base Class)
public class Object {
...
}
public class Foo extends Object {
...
}
public class Object {
...
}
public class Foo extends Object {
void newMethod() {
...
}
}
adding method
is a modification
50. Architecture, Design, Implementation
sw design
50
Layered Architecture
«A layered system is organized
hierarchically, each layer providing
service to the layer above it and serving
as a client to the layer below»
David Garlan, Mary Shaw, 1993
51. Architecture, Design, Implementation
sw design
51
Layered Architecture (Formally)
• Each element belongs to exactly one
layer
• Each element may depend (invoke,
inherit, etc.) only on elements of same or
lower layers
𝜑 =
57. Architecture, Design, Implementation
sw design
57
Pipe & Filter
«Each component has a set of inputs
and a set of outputs. A component reads
streams of data on its inputs and
produces streams of data on its outputs»
David Garlan, Mary Shaw, 1993
66. Architecture, Design, Implementation
sw design
66
Factory Method Design Pattern
Define an interface for creating an
object, but let subclasses decide which
class to instantiate. Factory Method lets
a class defer instantiation to subclasses
68. Architecture, Design, Implementation
sw design
68
Factory Method - Example
public interface Currency {
String getCode();
}
public class Euro implements Currency {
public String getCode() {
return "EUR";
}
}
public class USD implements Currency {
public String getCode() {
return "USD";
}
}
69. Architecture, Design, Implementation
sw design
69
Factory Method - Example
public interface CurrencyFactory {
Currency create();
}
public class EuroFactory implements CurrencyFactory {
public Currency create() {
return new Euro();
}
}
public class USDFactory implements CurrencyFactory {
public Currency create() {
return new USD();
}
}
70. Architecture, Design, Implementation
sw design
70
Factory Method - Example
public class Client {
public static void main(String[] args) {
CurrencyFactory factory = new USDFactory();
Currency currency = factory.create();
System.out.println(currency.getCode());
}
}
71. Architecture, Design, Implementation
sw design
71
Factory Method - Formal Definition
1. All methods have the same signature
2. Each method is a member of exactly one class in f
3. Each method produces instances of exactly one
class p
79. Architecture, Design, Implementation
sw design
79
Factory Method - Reduction
Remove Euro or USD:
Allowed since these classes are not part of the
formal definition:
=> Causes violation:
83. Architecture, Design, Implementation
sw design
83
UML
Standardized, general-purpose modeling
language. Used in the industry as a
design (?) and architectural (??)
specification language
90. Architecture, Design, Implementation
sw design
90
UML Diagram - Reduction
We may reduce entities that are not explicitly
mentioned by the figure. Such reductions will keep
containing all entities and relations
101. Architecture, Design, Implementation
sw design
101
‣ Decision to use Singleton is strategic
‣ Singleton is designed to provide
services to clients from the entire scope
of the program
‣ Anomaly among design patterns
Singleton - Afterword
103. Architecture, Design, Implementation
sw design
103
«Future breakthroughs in software
productivity will depend on our ability to
combine existing pieces of software to
produce new applications»
David Garlan, Robert Allen,
J. Ockerbloom, 1995
106. Architecture, Design, Implementation
sw design
106
Formulation
Softbench assumes
all data to be communicated is
represented as ASCII strings
1. p = Softbench
2. 𝜑 = assumption
3. ⟦p⟧ ⊨ 𝜑
107. Architecture, Design, Implementation
sw design
107
Formulation
App includes Softbench, but it is
not an app where Softbench is
«intended to operate»
1. q = App
2. ⟦q⟧ ⊭ 𝜑
p and q mismatch on 𝜑
108. Architecture, Design, Implementation
sw design
108
Architectural Mismatch
• Let 𝜑 designate a statement
satisfied by component p
• Let q designate an expansion of p
• If ⟦p⟧ ⊨ 𝜑 but ⟦q⟧ ⊭ 𝜑 then
we say that q mismatch 𝜑
111. Architecture, Design, Implementation
sw design
111
ASPECTS OF
A LONG-TERM SOLUTION
L-criterionInformal
Make architectural
assumptions explicit
Make non-local NL
assumptions explicit
1
112. Architecture, Design, Implementation
sw design
112
L-criterionInformal
Construct large pieces
of software using
orthogonal components
Minimize the number
of non-local NL
assumptions. Ideally,
each module should
only make local
assumptions
ASPECTS OF
A LONG-TERM SOLUTION
2
113. Architecture, Design, Implementation
sw design
113
L-criterionInformal
Develop sources of
architectural design
guidance
Design rules for composition:
Whenever non-local NL
assumptions are made, either
ensure that they are
compatible or else relinquish
the attempt to combine the
components
ASPECTS OF
A LONG-TERM SOLUTION
3
115. Architecture, Design, Implementation
sw design
115
LOCALITY CRITERION
A statement 𝜑 is local iif
it is preserved under expansion
PARAMOUNT TO ANY
LARGE PROJECT
116. Architecture, Design, Implementation
sw design
116
DECISION TIMING
• Non-local NL (architectural) design
decisions must be taken (and made explicit)
early
• Each non-local NL decision taken may
potentially violate every other design
decision (architectural mismatch)
117. Architecture, Design, Implementation
sw design
117
DECISION TIMING
• Local L design decisions have limited
consequences and are thus better
postponed to the point following all non-
local NL design decisions
120. Architecture, Design, Implementation
sw design
120
FURTHER
CONCLUSIONS
• When developing a new
component, minimize the non-
local NL assumptions it
makes and make them explicit
121. Architecture, Design, Implementation
sw design
121
• When assembling an application
from existing components, use
only components whose non-
local NL assumptions ‘match’,
or else clashes may arise
FURTHER
CONCLUSIONS
122. Architecture, Design, Implementation
sw design
122
TOOLING
• Tools that enforce non-local
NL rules are inherently
different from tools that verify
local L statements
123. Architecture, Design, Implementation
sw design
123
TOOLING
• Java/C# compiler enforcing
OOD axioms, information hiding
• Linux/Unix shell enforcing that
every filter has at least one pipe
NL
124. Architecture, Design, Implementation
sw design
124
TOOLING
• Tools that support the use of
design patterns, refactorings and
programming idioms may focus
on the part of the program that
implements the statement and
ignore the remainder
L
126. Architecture, Design, Implementation
sw design
126
«EASY» QUESTIONS
FROM NOW ON
• What information goes into architecture
documents? Design documents?
• What to examine in an architectural
evaluation? Design walkthrough? Code
review?
127. Architecture, Design, Implementation
sw design
127
REFERENCES
• A. H. Eden, Y. Hirshfeld, R. Kazman. "Abstraction Classes in Software Design". http://
www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf (2006)
• A. H. Eden. “Strategic Versus Tactical Design”. http://www.eden-study.org/articles/
2005/strategic-vs-tactical-design_hicss38_.pdf (2005)
• A. H. Eden, R. Kazman. “On the Definitions of Architecture, Design, and
Implementation”. http://dces.essex.ac.uk/technical-reports/2003/csm377.pdf (2003)
• A. H. Eden, R. Kazman. “Architecture, Design, Implementation”. http://
www.sei.cmu.edu/library/assets/ICSE03-1.pdf (2003)
• A. H. Eden, R. Turner. “Towards an ontology of software design: The Intension/
Locality Hypothesis.” http://www.eden-study.org/articles/2005/il-
hypothesis_ecap05.pdf (2005)
• D. Garlan, R. Allen, J. Ockerbloom. “Architectural Mismatch or, Why it's hard to build
systems out of existing parts.” http://repository.cmu.edu/cgi/viewcontent.cgi?
article=1714&context=compsci (Nov. 1995)
128. Architecture, Design, Implementation
sw design
128
REFERENCES
• E. Gamma, R. Helm, R. Johnson, J. Vlissides. "Design Patterns: Elements of
Reusable Object Oriented Software." (1995)
• D. Garlan, M. Shaw. “An Introduction to Software Architecture.” (1993)
• Dewayne E. Perry, Alexander L. Wolf. “Foundation for the Study of Software
Architecture.” (1992)
• Robert T. Monroe, Andrew J. Kompanek, Ralph Melton, David Garlan. “Architectural
Styles, Design Patterns, and Objects.” (1997)
• M. Kanat-Alexander. "Code Simplicity. The Fundamentals of Software." (2012)
• http://stackoverflow.com/
• http://wikipedia.org/
