Abstraction Classes in Software Design

Vladimir Tsukur / FOLLOW ME: twitter.com/flushdia or EMAIL TO: [email protected] 2013

sw design

ABSTRACTION CLASSES

IN SOFTWARE DESIGN

Architecture, Design, Implementation

sw design

2

vladimir tsukur partner @

team &tech lead @


sw design

3

Abstraction Stratain Software Design Statements:

‣ Strategic (architectural, global) design‣ Tactical (detailed, local) design‣ Implementation

What is the distinction?


sw design

4

Goal

Clear understandingof 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

11

Intuitive Notion


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

ArchitecturalStatements


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

24Formal Vocabulary


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


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


sw design

27

Finite Structure / Design Model(Satisfaction)

Entities: Object, Foo

Relations: Class = { Object, Foo } Inherit = { ( Foo, Object ) }

⟦p⟧ =



p =

⟦p⟧ ⊨ 𝜑


sw design

28

Finite Structure / Design Model(Violation)

Entities: Object, Foo, Bar

Relations: Class = { Object, Foo, Bar } Inherit = { ( Foo, Object ) }

⟦p’⟧ =

p’ =



public class Bar { // ‘extends’? ...}

⟦p’⟧ ⊭ 𝜑


sw design

29

Finite Structures Represent:

< structural properties

behaviouralproperties >


sw design

30

Tarski’s Truth Conditions

Finite structures +Tarski’s truth conditions =

Straightforward criterion of satisfaction against statements in first-order predicate calculus


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


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)


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


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


sw design

35

Intension/LocalityHierarchy


sw design

36

Intension/LocalityHierarchy


sw design

37

LOCALITY CRITERION

A statement 𝜑 is local iifit 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 statement 𝜑 is local iifa program that satisfies cannot be

expanded into a program that violates it


sw design

40

Local Statements L

«There exists an entity(set of entities)

that satisfies 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 iifit is preserved both under expansion

and under reduction


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


sw design

45

p’

Extensional Statements LE

p’’ ⊨ 𝜑

p ⊨ 𝜑Implementation

p

p’’

p’ ⊨ 𝜑 𝜑 is in LE


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


sw design

47

Valid Expansion (Universal Base Class)public class Object { ...}




public class Bar { // ‘extends’? ...}


sw design

48

Invalid Expansion (Universal Base Class)public class Object { ...}



public class Foo extends Object { void newMethod() { ... }}

adding methodis a modification


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, E2Relations: 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, E3Relations: Layer = { (E1, 1), (E2, 2), (E3, 1) } Depend = { (E2, E1), (E3, E2) }

Depend(E3, E2) butLayer(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 = F2 F1 P


sw design

60

Pipe & Filter - Finite Structure

⟦p⟧ =

Entities: F1, F2, PRelations: Filter = { F1, F2 } Pipe = { P } Connect = { (F1, P), (P, F2) }

⟦p⟧ ⊨ 𝜑


sw design

61

Pipe & Filter - Expansion

p’ = F2 F1

P

F3


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’⟧ ⊭ 𝜑


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

DesignStatements


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


sw design

67

Factory Method - Visualization


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


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


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


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


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 - AssignmentEntities: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

modification,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 definition:

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

ImplementationStatements


sw design

83

UML

Standardized, general-purpose modeling language. Used in the industry as a

design (?) and architectural (??) specification 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 diagramexplicitly represents a specific entity

or a specific 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 figure. 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

93

Singleton


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

ArchitecturalMismatch


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 assumesall 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

satisfied 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

2Practical

Implications


sw design

111

ASPECTS OFA LONG-TERM SOLUTION

L-criterionInformal

Make architecturalassumptions explicit

Make non-local NLassumptions 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


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


3


sw design

114

Provide techniques for bridging mismatches


4


sw design

115

LOCALITY CRITERION

A statement 𝜑 is local iifit is preserved under expansion

PARAMOUNT TO ANYLARGE 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 NLdecisions

Local Ldecisions


sw design

119

WHY BOTHER?

amount of detail

effort to settleclashes


sw design

120

FURTHERCONCLUSIONS

• 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

FURTHERCONCLUSIONS


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 enforcingOOD axioms, information hiding

• Linux/Unix shell enforcing that every filter 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 specifications


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?


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)

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf




http://www.eden-study.org/articles/2005/strategic-vs-tactical-design_hicss38_.pdf




http://dces.essex.ac.uk/technical-reports/2003/csm377.pdf

http://dces.essex.ac.uk/technical-reports/2003/csm377.pdf

http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf




http://www.eden-study.org/articles/2005/il-hypothesis_ecap05.pdf









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/

http://stackoverflow.com

http://stackoverflow.com

http://wikipedia.org

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

News & Politics

Transcript of Abstraction Classes in Software Design