Abstraction Classes in Software Design

Vladimir Tsukur / FOLLOW ME: twitter.com/ﬂushdia or EMAIL TO: ﬂushdia@gmail.com 2013
sw design
ABSTRACTION CLASSES
IN SOFTWARE DESIGN

Architecture, Design, Implementation
sw design
2
vladimir tsukur partner @
team &
tech lead @

sw design
3
Abstraction Strata
in Software Design Statements:
‣ Strategic (architectural, global) design
‣ Tactical (detailed, local) design
‣ Implementation
What is the distinction?

sw design
4
Goal
Clear understanding
of distinction between strategic and
tactical design decisions

sw design
5
?
Quiz :)
http://quizegg.com/q/
74625

sw design
6
«The difference between a bad programmer
and a good programmer is understanding»
Max Kanat-Alexander
Why?

sw design
7

sw design
8
«BEST» ANSWER

sw design
9
IMPORTANT ANSWER

sw design
10

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

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

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

sw design
15
«[design] patterns deal with lower-level
implementation issues than architectures
generally specify»
Robert T. Monroe, 1997

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

sw design
17
Architecture
Design
Implementationmore detail
less detail
Quantitative View

sw design
18
Architectural
Statements

sw design
19
Universal Base Class
There is a class from which all other
classes inherit (possibly indirectly)
𝜑 =
𝜑 =

sw design
20
Universal Base Class - Example
(Satisfaction)
public class Object {
...
}
public class Foo extends Object {
...
}
p =
p ⊨ 𝜑

sw design
21
Universal Base Class - Example
(Violation)
p’ =
...
}
...
}
public class Bar { // ‘extends’?
...
}
p’ ⊭ 𝜑 THINK PURE MODEL

sw design
22
Universal Base Class is in NL
(Non-Local)
Preserved under expansion? NO

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
25
‣ Statement must be deﬁnitive
‣ Statement should describe collection
of conforming programs in terms of
entities and relations
‣ Statement should have a signature
(constant symbols + relation symbols)
Statement Requirements

sw design
26
Finite Structure / Design Model
Formally
Finite structure M
is an ordered pair <UM,RM> such that
UM={a1,…ak} is a ﬁnite set of entities, and
RM={R1,…Rn} is a ﬁnite set of relations over
the entities in UM

sw design
27
(Satisfaction)
Entities:
Object, Foo
Relations:
Class = { Object, Foo }
Inherit = { ( Foo, Object ) }
⟦p⟧ =
...
}
...
}
p =
⟦p⟧ ⊨ 𝜑

sw design
28
(Violation)
Entities:
Object, Foo, Bar
Relations:
Class = { Object, Foo, Bar }
Inherit = { ( Foo, Object ) }
⟦p’⟧ =
p’ =
...
}
...
}
...
}
⟦p’⟧ ⊭ 𝜑

sw design
29
Finite Structures Represent:
< structural
properties
behavioural
properties >

sw design
30
Tarski’s Truth Conditions
Finite structures +
Tarski’s truth conditions =
Straightforward criterion of satisfaction
against statements in ﬁrst-order predicate calculus

sw design
31
Closed Statements
(Example)
∃x • Method(x)
Satisﬁed by M iif there exists an entity m
in M such that m is a method entity in M

sw design
32
Open Statements
(Example)
Inherit(x, y)
Satisﬁed by M iif there is an assigment
σ where Inherit(σ(x), σ(y)) holds true
(e.g. σ(x)=Foo and σ (y)=Object)

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 ﬁnite structure I(p),
written ⟦p⟧i

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

sw design
35
Intension/Locality
Hierarchy

sw design
36
Intension/Locality
Hierarchy

sw design
37
LOCALITY CRITERION
A statement 𝜑 is local iif
it is preserved under expansion

sw design
38
p’
Local Statements L
p
p ⊨ 𝜑
p’ ⊨ 𝜑
Design,
Implementation
𝜑 is in L

sw design
39
LOCALITY CRITERION
(less formally)
a program that satisﬁes cannot be
expanded into a program that violates it

sw design
40
Local Statements L
«There exists an entity
(set of entities)
that satisﬁes so-and-so condition»

sw design
41
p
p’
Non-Local Statements NL
p ⊨ 𝜑
p’ ⊭ 𝜑
Architecture
𝜑 is in NL

sw design
42
Non-Local Statements NL
«For all entities,
so-and-so condition applies»

sw design
43
INTENSION CRITERION
A statement 𝜑 is extensional iif
it is preserved both under expansion
and under reduction

sw design
44
INTENSION CRITERION
(less formally)
A statement 𝜑 is extensional iif
a program that satisﬁes it cannot be
expanded or reduced into a program that
violates it

sw design
45
p’
Extensional Statements LE
p’’ ⊨ 𝜑
p ⊨ 𝜑
Implementation
p
p’’
p’ ⊨ 𝜑 𝜑 is in LE

sw design
46
Expansion Formally
M = <U,R> - ﬁnite structure.
M’ = <U’,R’> is an expansion of M if it
can result by:
‣ adding a non-empty ﬁnite 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

sw design
47
Valid Expansion (Universal Base Class)
...
}
...
}
...
}
...
}
...
}

sw design
48
Invalid Expansion (Universal Base Class)
...
}
...
}
...
}
void newMethod() {
...
}
}
adding method
is a modiﬁcation

sw design
49
Layered Architecture

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»

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
𝜑 =

sw design
52
Layered Architecture - Example
p =
2: E2
1: E1

sw design
53
Layered Architecture -
Finite Structure
⟦p⟧ =
Entities:
1, 2, E1, E2
Relations:
Layer = { (E1, 1), (E2, 2) }
Depend = { (E2, E1) }
⟦p⟧ ⊨ 𝜑

sw design
54
Layered Architecture - Expansion
p’ =
2: E2
1: E1 E3

sw design
55
Layered Architecture - Expansion
⟦p’⟧ =
Entities:
1, 2, E1, E2, E3
Relations:
Layer = { (E1, 1), (E2, 2), (E3, 1) }
Depend = { (E2, E1), (E3, E2) }
Depend(E3, E2) but
Layer(E3) < Layer(E2)
⟦p’⟧ ⊭ 𝜑

sw design
56
Layered Architecture is in NL
(Non-Local)

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»

sw design
58
Pipe & Filter
𝜑 =
cat cities.txt | grep Kiev

sw design
59
Pipe & Filter - Example
p = F2F1
P

sw design
60
Pipe & Filter - Finite Structure
⟦p⟧ =
Entities:
F1, F2, P
Relations:
Filter = { F1, F2 }
Pipe = { P }
Connect = { (F1, P), (P, F2) }
⟦p⟧ ⊨ 𝜑

sw design
61
Pipe & Filter - Expansion
p’ =
F2F1
P
F3

sw design
62
Pipe & Filter - Expansion
⟦p⟧ =
Entities:
F1, F2, P, F3
Relations:
Filter = { F1, F2, F3 }
Pipe = { P }
Connect = { (F1, P), (P, F2) }
F3 is NOT
connected to any pipe
⟦p’⟧ ⊭ 𝜑

sw design
63
Pipe & Filter is in NL
(Non-Local)

sw design
64
‣ Information Hiding
‣ Axioms of OOD
‣ Architectural Styles
‣ Law of Demeter
‣ Frameworks (EJB, OSGi, JPA)
Architecture
(Strategic Statements)

sw design
65
Design
Statements

sw design
66
Factory Method Design Pattern
Deﬁne an interface for creating an
object, but let subclasses decide which
class to instantiate. Factory Method lets
a class defer instantiation to subclasses

sw design
67
Factory Method - Visualization

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";
}
}

sw design
69
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();
}
}

sw design
70
public class Client {
public static void main(String[] args) {
CurrencyFactory factory = new USDFactory();
Currency currency = factory.create();
System.out.println(currency.getCode());
}
}

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

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

sw design
73
Relations:
Class = { Currency, Euro, USD,
CurrencyFactory, EuroFactory, USDFactory }
Method = {
Currency.getCode, USD.getCode,
Euro.getCode,
CurrencyFactory.create, EuroFactory.create,
USDFactory.create
}

sw design
74
Inherit = {
(Euro, Currency), (USD, Currency),
(EuroFactory, CurrencyFactory),
(USDFactory, CurrencyFactory)
}
Produce = {
(EuroFactory, Euro),
(USDFactory, USD)
}
...

sw design
75
Factory Method - Formal Definition
Assignment against these
variables becomes Entities in
the formal structure

sw design
76
Factory Method - Assignment
Entities:
Products = { Euro, USD }
Factories = {
EuroFactory,
USDFactory
}
FactoryMethods = {
EuroFactory.create,
USDFactory.create
}

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

sw design
78
modiﬁcation,
not an expansion!
Entities:
Products = { Euro, USD, Hryvnia }
Factories = {
EuroFactory,
USDFactory
}
FactoryMethods = {
EuroFactory.create,
USDFactory.create
}
Factory Method - Expansion ...

sw design
79
Factory Method - Reduction
Remove Euro or USD:
Allowed since these classes are not part of the
formal deﬁnition:
=> Causes violation:

sw design
80
Factory Method is in LI
(Local Intensional)
Preserved under expansion? YES
Preserved under reduction? NO

sw design
81
‣ Design Patterns
‣ Programming Idioms
‣ Refactorings
Design
(Tactical Statements)

sw design
82
Implementation
Statements

sw design
83
UML
Standardized, general-purpose modeling
language. Used in the industry as a
design (?) and architectural (??)
speciﬁcation language

sw design
84
UML Diagram Statement

sw design
85
UML Diagram - Finite Structure
Entities:
Client,
Abstraction, ConcreteOne, ConcreteTwo,
Product, ProductOne, ProductTwo,
Abstraction.normalMethod,
Abstraction.makeObject,
ConcreteOne.makeObject ...

sw design
86
Relations:
Class = { Client, Abstraction, ConcreteOne,
ConcreteTwo, Product, ProductOne,
ProductTwo }
Method = {
Abstraction.normalMethod,
Abstraction.makeObject,
ConcreteOne.makeObject
}

sw design
87
Inherit = {
(ConcreteOne, Abstraction), (ConcreteTwo,
Abstraction),
(ProductOne, Product),
(ProductTwo, Product)
}
Instantiates = {
(Abstraction.makeObject, Product),
}
...

sw design
88
UML Diagram
Every element in the diagram
explicitly represents a speciﬁc entity
or a speciﬁc relation

sw design
89
UML Diagram - Expansion
Proper expansions will keep containing all entities
and relations

sw design
90
UML Diagram - Reduction
We may reduce entities that are not explicitly
mentioned by the ﬁgure. Such reductions will keep
containing all entities and relations

sw design
Preserved under expansion? YES
Preserved under reduction? YES
91
UML Diagram is in LE
(Local Extensional)

sw design
92
‣ UML Diagrams
‣ Program Documentation
‣ Statements consisting entirely of
constant symbols, like «Foo extends
Object»
Implementation
(Extensional Statements)

sw design
94
Ensure a class has only one
instance, and provide a
global point of access to it

sw design
95
Window Manager File System
Examples

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

sw design
97
Singleton - Finite Structure
Entities:
Singleton,
Singleton.getInstance,
SingletonHolder,
SingletonHolder.instance

sw design
98
Singleton - Finite Structure
Relations:
Class = { Singleton, Singleton.Holder }
Object = { Singleton.Holder.instance }
InstanceOf = {
(Singleton.Holder.instance, Singleton)
}
Method = { Singleton.getInstance }
⟦p⟧ ⊨ 𝜑

sw design
99
Singleton - Expansion
⟦p’⟧ ⊭ 𝜑
Object = {
Singleton.Holder.instance, instance2
}
InstanceOf = {
(Singleton.Holder.instance, Singleton),
(instance2, Singleton)
}

sw design
100
Singleton is in NL
(Non-Local)

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
Architectural
Mismatch

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

sw design
104
http://repository.cmu.edu/cgi/viewcontent.cgi?
article=1714&context=compsci

sw design
105

sw design
106
Formulation
Softbench assumes
all data to be communicated is
represented as ASCII strings
1. p = Softbench
2. 𝜑 = assumption
3. ⟦p⟧ ⊨ 𝜑

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 𝜑

sw design
108
Architectural Mismatch
• Let 𝜑 designate a statement
satisﬁed by component p
• Let q designate an expansion of p
• If ⟦p⟧ ⊨ 𝜑 but ⟦q⟧ ⊭ 𝜑 then
we say that q mismatch 𝜑

sw design
109
The Architectural Mismatch theorem
A programs p, q mismatch on 𝜑
then 𝜑 is in NL

sw design
110
Practical
Implications

sw design
111
ASPECTS OF
A LONG-TERM SOLUTION
L-criterionInformal
Make architectural
assumptions explicit
Make non-local NL
assumptions explicit
1

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
2

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
3

sw design
114
Provide techniques for
bridging mismatches
ASPECTS OF
4

sw design
115
LOCALITY CRITERION
it is preserved under expansion
PARAMOUNT TO ANY
LARGE PROJECT

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)

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

sw design
118
DECISION TIMING
project timeline
Non-local NL
decisions
Local L
decisions

sw design
119
WHY BOTHER?
amount of detail
eﬀort to settle
clashes

sw design
120
FURTHER
CONCLUSIONS
• When developing a new
component, minimize the non-
local NL assumptions it
makes and make them explicit

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

sw design
122
TOOLING
• Tools that enforce non-local
NL rules are inherently
different from tools that verify
local L statements

sw design
123
TOOLING
• Java/C# compiler enforcing
OOD axioms, information hiding
• Linux/Unix shell enforcing that
every ﬁlter has at least one pipe
NL

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

sw design
125
UML
UML diagrams are inadequate means
for intensional speciﬁcations

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?

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 Deﬁnitions 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)

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://stackoverﬂow.com/
• http://wikipedia.org/

sw design
129
REFERENCES
Special thanks to
Amnon H. Eden
for clarifications and support

sw design
130
Thanks!
Questions?

Abstraction Classes in Software Design

More Related Content

Viewers also liked

Similar to Abstraction Classes in Software Design

More from Vladimir Tsukur

Recently uploaded

Abstraction Classes in Software Design