Post on 10-May-2015
transcript
Vladimir Tsukur / FOLLOW ME: twitter.com/flushdia or EMAIL TO: flushdia@gmail.com 2013
sw design
ABSTRACTION CLASSES
IN SOFTWARE DESIGN
Architecture, Design, Implementation
sw design
2
vladimir tsukur partner @
team &tech lead @
Architecture, Design, Implementation
sw design
3
Abstraction Stratain Software Design Statements:
‣ Strategic (architectural, global) design‣ Tactical (detailed, local) design‣ Implementation
What is the distinction?
Architecture, Design, Implementation
sw design
4
Goal
Clear understandingof distinction between strategic and
tactical design decisions
sw design
5
?Quiz :)
http://quizegg.com/q/74625
Architecture, Design, Implementation
sw design
6
«The difference between a bad programmer and a good programmer is understanding»
Max Kanat-Alexander
Why?
Architecture, Design, Implementation
sw design
7
Architecture, Design, Implementation
sw design
8
«BEST» ANSWER
Architecture, Design, Implementation
sw design
9
IMPORTANT ANSWER
Architecture, Design, Implementation
sw design
10
sw design
11
Intuitive Notion
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
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
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
Architecture, Design, Implementation
sw design
15
«[design] patterns deal with lower-level implementation issues than architectures
generally specify»
Robert T. Monroe, 1997
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
Architecture, Design, Implementation
sw design
17
Architecture
Design
Implementationmore detail
less detail
Quantitative View
sw design
18
ArchitecturalStatements
Architecture, Design, Implementation
sw design
19
Universal Base Class
There is a class from which all other classes inherit (possibly indirectly)
𝜑 =
𝜑 =
Architecture, Design, Implementation
sw design
20
Universal Base Class - Example(Satisfaction)
public class Object { ...}
public class Foo extends Object { ...}
p =
p ⊨ 𝜑
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
Architecture, Design, Implementation
sw design
22
Universal Base Class is in NL(Non-Local)
Preserved under expansion? NO
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
sw design
24Formal Vocabulary
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
Architecture, Design, Implementation
sw design
26
Finite Structure / Design ModelFormally
Finite structure Mis 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
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⟧ ⊨ 𝜑
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’⟧ ⊭ 𝜑
Architecture, Design, Implementation
sw design
29
Finite Structures Represent:
< structural properties
behaviouralproperties >
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
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
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)
Architecture, Design, Implementation
sw design
33
How Are The Programs Translatedinto Finite Structures?
Abstract interpretation function Iis a functional relation which maps each
program p into a finite structure I(p),
written ⟦p⟧i
Architecture, Design, Implementation
sw design
34
Intension/LocalityThesis
‣ Architectural specifications are intensional and non-local‣ Design specifications are intensional but local‣ Implementation specifications are both extensional and local
Architecture, Design, Implementation
sw design
35
Intension/LocalityHierarchy
Architecture, Design, Implementation
sw design
36
Intension/LocalityHierarchy
Architecture, Design, Implementation
sw design
37
LOCALITY CRITERION
A statement 𝜑 is local iifit is preserved under expansion
Architecture, Design, Implementation
sw design
38
p’
Local Statements L
p
p ⊨ 𝜑
p’ ⊨ 𝜑Design,Implementation
𝜑 is in L
Architecture, Design, Implementation
sw design
39
LOCALITY CRITERION(less formally)
A statement 𝜑 is local iifa program that satisfies cannot be
expanded into a program that violates it
Architecture, Design, Implementation
sw design
40
Local Statements L
«There exists an entity(set of entities)
that satisfies so-and-so condition»
Architecture, Design, Implementation
sw design
41
p
p’
Non-Local Statements NL
p ⊨ 𝜑
p’ ⊭ 𝜑Architecture
𝜑 is in NL
Architecture, Design, Implementation
sw design
42
Non-Local Statements NL
«For all entities,so-and-so condition applies»
Architecture, Design, Implementation
sw design
43
INTENSION CRITERION
A statement 𝜑 is extensional iifit is preserved both under expansion
and under reduction
Architecture, Design, Implementation
sw design
44
INTENSION CRITERION(less formally)
A statement 𝜑 is extensional iifa program that satisfies it cannot be
expanded or reduced into a program that violates it
Architecture, Design, Implementation
sw design
45
p’
Extensional Statements LE
p’’ ⊨ 𝜑
p ⊨ 𝜑Implementation
p
p’’
p’ ⊨ 𝜑 𝜑 is in LE
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
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’? ...}
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 methodis a modification
Architecture, Design, Implementation
sw design
49
Layered Architecture
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
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
𝜑 =
Architecture, Design, Implementation
sw design
52
Layered Architecture - Example
p =
2: E2
1: E1
Architecture, Design, Implementation
sw design
53
Layered Architecture -Finite Structure
⟦p⟧ =
Entities: 1, 2, E1, E2Relations: Layer = { (E1, 1), (E2, 2) } Depend = { (E2, E1) }
⟦p⟧ ⊨ 𝜑
Architecture, Design, Implementation
sw design
54
Layered Architecture - Expansion
p’ =
2: E2
1: E1 E3
Architecture, Design, Implementation
sw design
55
Layered Architecture - Expansion
⟦p’⟧ =
Entities: 1, 2, E1, E2, E3Relations: Layer = { (E1, 1), (E2, 2), (E3, 1) } Depend = { (E2, E1), (E3, E2) }
Depend(E3, E2) butLayer(E3) < Layer(E2)
⟦p’⟧ ⊭ 𝜑
Architecture, Design, Implementation
sw design
56
Layered Architecture is in NL(Non-Local)
Preserved under expansion? NO
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
Architecture, Design, Implementation
sw design
58
Pipe & Filter
𝜑 =
cat cities.txt | grep Kiev
Architecture, Design, Implementation
sw design
59
Pipe & Filter - Example
p = F2 F1 P
Architecture, Design, Implementation
sw design
60
Pipe & Filter - Finite Structure
⟦p⟧ =
Entities: F1, F2, PRelations: Filter = { F1, F2 } Pipe = { P } Connect = { (F1, P), (P, F2) }
⟦p⟧ ⊨ 𝜑
Architecture, Design, Implementation
sw design
61
Pipe & Filter - Expansion
p’ = F2 F1
P
F3
Architecture, Design, Implementation
sw design
62
Pipe & Filter - Expansion
⟦p⟧ =
Entities: F1, F2, P, F3Relations: Filter = { F1, F2, F3 } Pipe = { P } Connect = { (F1, P), (P, F2) }
F3 is NOTconnected to any pipe
⟦p’⟧ ⊭ 𝜑
Architecture, Design, Implementation
sw design
63
Pipe & Filter is in NL(Non-Local)
Preserved under expansion? NO
Architecture, Design, Implementation
sw design
64
‣ Information Hiding‣ Axioms of OOD‣ Architectural Styles‣ Law of Demeter‣ Frameworks (EJB, OSGi, JPA)
Architecture(Strategic Statements)
sw design
65
DesignStatements
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
Architecture, Design, Implementation
sw design
67
Factory Method - Visualization
Architecture, Design, Implementation
sw design
68
Factory Method - Examplepublic interface Currency { String getCode();}
public class Euro implements Currency { public String getCode() { return "EUR"; }}
public class USD implements Currency { public String getCode() { return "USD"; }}
Architecture, Design, Implementation
sw design
69
Factory Method - Examplepublic 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(); }}
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()); }}
Architecture, Design, Implementation
sw design
71
Factory Method - Formal Definition
1. All methods have the same signature2. Each method is a member of exactly one class in f3. Each method produces instances of exactly one class p
Architecture, Design, Implementation
sw design
72
Factory Method - Finite Structure
Entities: Currency, Euro, USD, CurrencyFactory, EuroFactory, USDFactory, Currency.getCode, Euro.getCode,USD.getCode, CurrencyFactory.create, EuroFactory.create, USDFactory.create
Architecture, Design, Implementation
sw design
73
Factory Method - Finite Structure
Relations:Class = { Currency, Euro, USD, CurrencyFactory, EuroFactory, USDFactory }Method = { Currency.getCode, USD.getCode, Euro.getCode, CurrencyFactory.create, EuroFactory.create, USDFactory.create}
Architecture, Design, Implementation
sw design
74
Factory Method - Finite Structure
Inherit = { (Euro, Currency), (USD, Currency), (EuroFactory, CurrencyFactory), (USDFactory, CurrencyFactory)}Produce = { (EuroFactory, Euro), (USDFactory, USD)}
...
Architecture, Design, Implementation
sw design
75
Factory Method - Formal Definition
Assignment against these variables becomes Entities in
the formal structure
Architecture, Design, Implementation
sw design
76
Factory Method - AssignmentEntities:Products = { Euro, USD }Factories = { EuroFactory, USDFactory}FactoryMethods = { EuroFactory.create, USDFactory.create}
Architecture, Design, Implementation
sw design
77
Factory Method - Expansion
Satisfaction by design model means that it incorporates instance of the pattern:
Products = { Euro, USD }Factories = { EuroFactory, USDFactory}FactoryMethods = { EuroFactory.create, USDFactory.create}
Proper expansions will keep containing this instance
Architecture, Design, Implementation
sw design
78
modification,not an expansion!
Entities:Products = { Euro, USD, Hryvnia }Factories = { EuroFactory, USDFactory}FactoryMethods = { EuroFactory.create, USDFactory.create}
Factory Method - Expansion ...
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:
Architecture, Design, Implementation
sw design
80
Factory Method is in LI(Local Intensional)
Preserved under expansion? YES
Preserved under reduction? NO
Architecture, Design, Implementation
sw design
81
‣ Design Patterns‣ Programming Idioms‣ Refactorings
Design(Tactical Statements)
sw design
82
ImplementationStatements
Architecture, Design, Implementation
sw design
83
UML
Standardized, general-purpose modeling language. Used in the industry as a
design (?) and architectural (??) specification language
Architecture, Design, Implementation
sw design
84
UML Diagram Statement
Architecture, Design, Implementation
sw design
85
UML Diagram - Finite Structure
Entities: Client, Abstraction, ConcreteOne, ConcreteTwo, Product, ProductOne, ProductTwo, Abstraction.normalMethod, Abstraction.makeObject, ConcreteOne.makeObject ...
Architecture, Design, Implementation
sw design
86
UML Diagram - Finite Structure
Relations:Class = { Client, Abstraction, ConcreteOne, ConcreteTwo, Product, ProductOne, ProductTwo }Method = { Abstraction.normalMethod, Abstraction.makeObject, ConcreteOne.makeObject}
Architecture, Design, Implementation
sw design
87
UML Diagram - Finite Structure
Inherit = { (ConcreteOne, Abstraction), (ConcreteTwo, Abstraction), (ProductOne, Product), (ProductTwo, Product)}Instantiates = { (Abstraction.makeObject, Product),}
...
Architecture, Design, Implementation
sw design
88
UML Diagram
Every element in the diagramexplicitly represents a specific entity
or a specific relation
Architecture, Design, Implementation
sw design
89
UML Diagram - Expansion
Proper expansions will keep containing all entities and relations
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
Architecture, Design, Implementation
sw design
Preserved under expansion? YES
Preserved under reduction? YES
91
UML Diagram is in LE(Local Extensional)
Architecture, Design, Implementation
sw design
92
‣ UML Diagrams‣ Program Documentation‣ Statements consisting entirely of constant symbols, like «Foo extends Object»
Implementation(Extensional Statements)
sw design
93
Singleton
Architecture, Design, Implementation
sw design
94
Ensure a class has only one instance, and provide a
global point of access to it
Architecture, Design, Implementation
sw design
95
Window Manager File System
Examples
Architecture, Design, Implementation
sw design
96
public class Singleton {
private static class Holder { public static Singleton instance = new Singleton(); }
private Singleton() {}
public static Singleton getInstance() { return Holder.instance; }
}
Sample Implementation
Architecture, Design, Implementation
sw design
97
Singleton - Finite Structure
Entities: Singleton, Singleton.getInstance, SingletonHolder, SingletonHolder.instance
Architecture, Design, Implementation
sw design
98
Singleton - Finite Structure
Relations:Class = { Singleton, Singleton.Holder }Object = { Singleton.Holder.instance }InstanceOf = { (Singleton.Holder.instance, Singleton)}Method = { Singleton.getInstance }
⟦p⟧ ⊨ 𝜑
Architecture, Design, Implementation
sw design
99
Singleton - Expansion
⟦p’⟧ ⊭ 𝜑
Object = { Singleton.Holder.instance, instance2}InstanceOf = { (Singleton.Holder.instance, Singleton), (instance2, Singleton)}
Architecture, Design, Implementation
sw design
100
Singleton is in NL(Non-Local)
Preserved under expansion? NO
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
sw design
102
ArchitecturalMismatch
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
Architecture, Design, Implementation
sw design
104
http://repository.cmu.edu/cgi/viewcontent.cgi?article=1714&context=compsci
Architecture, Design, Implementation
sw design
105
Architecture, Design, Implementation
sw design
106
Formulation
Softbench assumesall data to be communicated is represented as ASCII strings
1. p = Softbench
2. 𝜑 = assumption
3. ⟦p⟧ ⊨ 𝜑
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 𝜑
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 𝜑
Architecture, Design, Implementation
sw design
109
The Architectural Mismatch theorem
A programs p, q mismatch on 𝜑
then 𝜑 is in NL
Architecture, Design, Implementation
sw design
110
2Practical
Implications
Architecture, Design, Implementation
sw design
111
ASPECTS OFA LONG-TERM SOLUTION
L-criterionInformal
Make architecturalassumptions explicit
Make non-local NLassumptions explicit
1
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 OFA LONG-TERM SOLUTION
2
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 OFA LONG-TERM SOLUTION
3
Architecture, Design, Implementation
sw design
114
Provide techniques for bridging mismatches
ASPECTS OFA LONG-TERM SOLUTION
4
Architecture, Design, Implementation
sw design
115
LOCALITY CRITERION
A statement 𝜑 is local iifit is preserved under expansion
PARAMOUNT TO ANYLARGE PROJECT
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)
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
Architecture, Design, Implementation
sw design
118
DECISION TIMING
project timeline
Non-local NLdecisions
Local Ldecisions
Architecture, Design, Implementation
sw design
119
WHY BOTHER?
amount of detail
effort to settleclashes
Architecture, Design, Implementation
sw design
120
FURTHERCONCLUSIONS
• When developing a new component, minimize the non-local NL assumptions it makes and make them explicit
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
FURTHERCONCLUSIONS
Architecture, Design, Implementation
sw design
122
TOOLING
• Tools that enforce non-local NL rules are inherently different from tools that verify local L statements
Architecture, Design, Implementation
sw design
123
TOOLING
• Java/C# compiler enforcingOOD axioms, information hiding
• Linux/Unix shell enforcing that every filter has at least one pipe
NL
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
Architecture, Design, Implementation
sw design
125
UML
UML diagrams are inadequate means for intensional specifications
Architecture, Design, Implementation
sw design
126
«EASY» QUESTIONSFROM NOW ON
• What information goes into architecture documents? Design documents?
• What to examine in an architectural evaluation? Design walkthrough? Code review?
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)
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/
Architecture, Design, Implementation
sw design
129
REFERENCES
Special thanks to
Amnon H. Eden
for clarifications and support
sw design
130
Thanks!Questions?