• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Abstraction Classes in Software Design
 

Abstraction Classes in Software Design

on

  • 705 views

 

Statistics

Views

Total Views
705
Views on SlideShare
701
Embed Views
4

Actions

Likes
2
Downloads
7
Comments
0

2 Embeds 4

https://twitter.com 2
https://www.linkedin.com 2

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Abstraction Classes in Software Design Abstraction Classes in Software Design Presentation 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 Strata in Software Design Statements: ‣ Strategic (architectural, global) design ‣ Tactical (detailed, local) design ‣ Implementation What is the distinction?
    • Architecture, Design, Implementation sw design 4 Goal Clear understanding of 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 Architectural Statements
    • 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 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
    • 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 behavioural properties >
    • 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 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
    • 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
    • Architecture, Design, Implementation sw design 35 Intension/Locality Hierarchy
    • Architecture, Design, Implementation sw design 36 Intension/Locality Hierarchy
    • Architecture, Design, Implementation sw design 37 LOCALITY CRITERION A statement 𝜑 is local iif it 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 iif a 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 iif it is preserved both under expansion and under reduction
    • 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
    • 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 method is 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, E2 Relations: 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, E3 Relations: Layer = { (E1, 1), (E2, 2), (E3, 1) } Depend = { (E2, E1), (E3, E2) } Depend(E3, E2) but Layer(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 = F2F1 P
    • Architecture, Design, Implementation sw design 60 Pipe & Filter - Finite Structure ⟦p⟧ = Entities: F1, F2, P Relations: Filter = { F1, F2 } Pipe = { P } Connect = { (F1, P), (P, F2) } ⟦p⟧ ⊨ 𝜑
    • Architecture, Design, Implementation sw design 61 Pipe & Filter - Expansion p’ = F2F1 P F3
    • Architecture, Design, Implementation 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’⟧ ⊭ 𝜑
    • 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 Design Statements
    • 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 - 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"; } }
    • 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(); } }
    • 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 signature 2. Each method is a member of exactly one class in f 3. 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 - Assignment Entities: 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 Implementation Statements
    • 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 diagram explicitly 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 Architectural Mismatch
    • 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 assumes all 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 Practical Implications
    • 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
    • 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
    • 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
    • Architecture, Design, Implementation sw design 114 Provide techniques for bridging mismatches ASPECTS OF A LONG-TERM SOLUTION 4
    • Architecture, Design, Implementation sw design 115 LOCALITY CRITERION A statement 𝜑 is local iif it is preserved under expansion PARAMOUNT TO ANY LARGE 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 NL decisions Local L decisions
    • Architecture, Design, Implementation sw design 119 WHY BOTHER? amount of detail effort to settle clashes
    • 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
    • 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
    • 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 enforcing OOD 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» QUESTIONS FROM 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?