Compositional Programming

2,882 views
2,725 views

Published on

This talk surveys the evolution of compositional paradigms in programming from the 1950s through to the present day. In particular, we explore the innovations introdiced by procedural programming, object-oriented langauges, component-based development, and model-driven engineering.

Published in: Education
1 Comment
2 Likes
Statistics
Notes
  • Very good introduction to the compositional programming.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,882
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
31
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Compositional Programming

  1. 1. Compositional ProgrammingOscar NierstraszSoftware Composition Groupscg.unibe.ch Dagstuhl Seminar 12511, Dec 2012
  2. 2. RoadmapEarly historyObjectsComponentsFeaturesMetaprogrammingConclusions 2
  3. 3. RoadmapEarly historyObjectsComponentsFeaturesMetaprogrammingConclusions 3
  4. 4. Subroutines (1949) Repeatedly invoke common code sequences call return 4
  5. 5. Libraries — FORTRAN II (1958) Large reusable libraries of scientific functions led to the long-term success of FORTRAN 5
  6. 6. Recursion — ALGOL (1958) ALGOL brought recursion into the mainstream 6
  7. 7. Modules — COBOL (1959) Modules enabled the stepwise decompositionof large software systems 7
  8. 8. Summary call return Paradigm: procedural composition Motivation: code reuse, managing complexity 8
  9. 9. RoadmapEarly historyObjectsComponentsFeaturesMetaprogrammingConclusions 9
  10. 10. Data AbstractionAbstraction = elimination of inessential detail Information hiding = providing only the information a client needs to know Encapsulation = bundling operations to access related data as a data abstraction In object-oriented languages we can implement data abstractions as classes. Edward V. Berard, “Abstraction, Encapsulation, and Information Hiding” in Essays On Object-Oriented Software Engineering, 1993. 10
  11. 11. Object-Oriented Programming (1962) sends-messages-to Class Attribute instance-of ... Method Object ... Attribute ...is-composed-of specializes * Subobject Subclass OOP was introduced in Simula as an extension to ALGOL to model simulations. 11
  12. 12. Smalltalk (1972)In “pure” OOP, objects are used to model all aspects of design Everything is an object Everything happens by sending messages 5 factorial ! 120 Integer»factorial ! self = 0 ifTrue: [^ 1]. 1] ! self > 0 ifTrue: [^ self * (self - 1) factorial]. ! self error: Not valid for negative integers Alan C. Kay. The Early History of Smalltalk. ACM SIGPLAN Notices, March 1993. http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_Abstract.html 12
  13. 13. The open / closed principle Software entities should be open for extension, but closed for modification.“In other words, we want to be able tochange what the modules do, withoutchanging the source code of the modules.” Bertrand Meyer, Object-Oriented Software Construction, 1988. See also: http://www.objectmentor.com/resources/articles/ocp.pdf 13
  14. 14. Design by ContractServices should specify clear contracts “If you promise to call S with the precondition satisfied, then I, in return, promise to deliver a final state in which the post-condition is satisfied.” If the precondition fails, it is the client’s fault. If the postcondition fails, it is the supplier’s fault. If the class invariant fails, it is the supplier’s fault. Bertrand Meyer, Object-Oriented Software Construction, 1988. See also: http://www.objectmentor.com/resources/articles/ocp.pdf 14
  15. 15. Principle of SubstitutabilityAn instance of a subtype can always beused in any context in which an instanceof a supertype was expected. substitutable? Peter Wegner, Stanley Zdonik. Inheritance as an Incremental Modification Mechanism or What Like Is and Isnt Like. ECOOP 1988. http://www.ifs.uni-linz.ac.at/~ecoop/cd/tocs/t0322.htm 15
  16. 16. Liskov substitution principle Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S, where S is a subtype of T.Restated in terms of contracts, a derived class is substitutablefor its base class if:• Its preconditions are no stronger than the base class method.• Its postconditions are no weaker than the base class method. Barbara Liskov, Jeannette M. Wing. A behavioral notion of subtyping. ACM TOPLAS, 1994. http://www.cse.ohio-state.edu/~neelam/courses/788/lwb.pdf 16
  17. 17. Polymorphism Polymorphic client code does not depend on the concrete type of the service provider> Universal: —Parametric: map function in Haskell —Inclusion: subtyping — graphic objects> Ad Hoc: —Overloading: integer vs real addition —Coercion: automatic conversion from ints to floats Luca Cardelli and Peter Wegner. On Understanding Types, Data Abstraction, and Polymorphism. ACM Computing Surveys 17(4) p. 471—522, 1985 17
  18. 18. Covariant subtyping DX CX fX DY CY fYA client who expects the behaviour of fX, and appliesfY to a value in DX might get a run-time type error. Anthony J. H. Simons, “The Theory of Classification”, Parts 1-3, Journal of Object Technology, 2002-2003, www.jot.fm. 18
  19. 19. Contravariant subtyping DY DX CXfX CY fY A contravariant result type guarantees that the client will receive no unexpected results. Anthony J. H. Simons, “The Theory of Classification”, Parts 1-3, Journal of Object Technology, 2002-2003, www.jot.fm. 19
  20. 20. Types vs ClassesClasses are generators of types. type Number class Number class Integer type Integer“Classes arenested volumes inthe space of types.Types are points atthe apex of eachbounded volume.” Anthony J. H. Simons, “The Theory of Classification”, Parts 4-8, Journal of Object Technology, 2002-2003, www.jot.fm. 20
  21. 21. Frameworks White box frameworks define a generic application that you instantiate by subclassing. «interface» «utility» Test Assert + run(TestResult) + assertTrue(boolean) ... TestSuite TestCase abstract TestResult+ addTest(Test) + void runBare() # void run(TestCase) # void runTest() + addError(Test, Throwable) # void setUp() + addFailure(Test, Throwable) # void tearDown() ... ... Ralph E. Johnson & Brian Foote. Designing Reusable Classes. Journal of Object-Oriented Programming, June/July 1988. http://www.laputan.org/drc.html 21
  22. 22. Design Patterns Patterns document common language- independent solutions to design problems. Most of the GOF patterns achieve flexibility by adding a level of indirection. Erich Gamma, et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995. 22
  23. 23. SummaryParadigm: object composition + incremental refinement Motivation: domain modeling 23
  24. 24. RoadmapEarly historyObjectsComponentsFeaturesMetaprogrammingConclusions 24
  25. 25. Software Product Lines Product A SPL is a way to decisions produce a range of similar systems from a shared set of software assetsSoftware asset inputs Software product outputs Production http://www.sei.cmu.edu/productlines/ 25
  26. 26. Software componentsA software component is a unit of compositionwith contractually specified interfaces andexplicit context dependencies only.A software component can be deployedindependently and is subject to compositionby third parties. Clemens Szyperski, Component Software: Beyond Object-Oriented Programming, 2nd ed.. Boston, MA: Addison-Wesley, 2002. 26
  27. 27. But what is a software component? an object a class a template a method a procedure a mixin a trait a module a package a subsystem a framework a script a service a metaobject a metaclass a design pattern ... ? it depends ... 27
  28. 28. Applications = Components + ScriptsComponents Scripts plugboth import and componentsexport services together A scripting language is a dedicated language for for orchestrating a set of tasks (or components). Jean-Guy Schneider, Oscar Nierstrasz. Components, Scripts and Glue. In Software Architectures — Advances and Applications, Springer-Verlag, 1999. 28
  29. 29. DSLs A DSL is a dedicatedSELECT * programming or! FROM Book specification language for WHERE price > 100.00 a specific problem domain ORDER BY title; cat Notes.txt | tr -c [:alpha:] 012 | sed /^$/d’ | sort 14 programming | uniq –c 14 languages | sort –rn 9 of | head -5 7 for 5 the 29
  30. 30. Internal DSLsmail() .from("build@example.com") .to("example@example.com") .subject("build notification") .message("some details about build status") .send(); Michael Meyer et al. Mondrian: An Agile Visualization Framework. SoftVis 2006. 30
  31. 31. “Fluent interfaces”mail() Java used .from("build@example.com") as a DSL .to("example@example.com") .subject("build notification") .message("some details about build status") .send(); An internal DSL leverages host language syntax to make an API look like a DSL. Smalltalk used as a DSL Martin Fowler. Domain-Specific Languages, Addison-Wesley, 2010. 31
  32. 32. PiccolaPiccola is a minimal language fordefining plugs, connectors and scripts 32
  33. 33. Piccola A, B, C ::= ✏ empty form | x7! bind | x variable | A; B sandbox | hide x hide | A·B extension | x.A abstraction | AB application | R current root | L inspect | A|B parallelbuilt on a process calculus | ⌫c.A restrictionwith explicit environments | c? input | c output Franz Achermann and Oscar Nierstrasz. A Calculus for Reasoning about Software Components. Theoretical Computer Science 331(2), 2005. 33
  34. 34. A, B, C ::= ✏ empty form Piccola | | | x7! x A; B bind variable sandbox | hide x hide | A·B extension | x.A abstraction | AB application | R current root | L inspect | A|B parallel | ⌫c.A restriction | c? input | c outputfor scriptingcomponentswritten in Java http://scg.unibe.ch/research/piccola 34
  35. 35. Plug-in ArchitecturesPlug-ins allow you to extend and (sometimes)configure the host application. 35
  36. 36. Service-oriented architectureSOA enables composition of distributed,heterogeneous web-based services. Presentation Integration Architecture QoS, Security, Mgt & Monitoring Business Services Enterprise Components Operational Systems 36
  37. 37. SummaryParadigm: configuration of interacting components Motivation: manage variation 37
  38. 38. RoadmapEarly historyObjectsComponentsFeaturesMetaprogrammingConclusions 38
  39. 39. Mixins (1980) Mixins are “abstract subclasses” Rectangle asStringMixins are serializeOn: MColor asString asStringsensitive to serializeOn: super asString, , self rgb asStringthe order in Rectangle + MColorwhich they are asString MBorder serializeOn:composed. asString asString serializeOn: super asString, , self borderWidth asString Rectangle + MColor + MBorder asString serializeOn: inherits from MyRectangle applies mixin David A. Moon. Object-Oriented Programming with Flavors. OOPSLA 1986 39
  40. 40. Traits Class = superclass + state + traits + glueTraits provide and require methods The composing class retains control Stéphane Ducasse, et al. Traits: A Mechanism for fine-grained Reuse. ACM TOPLAS, 2006 40
  41. 41. Feature-Oriented ProgrammingFOP is a SPL paradigm forsynthesizing programs from featuresTransformations are used toadd features to base programs. Don Batory and Sean OMalley. The Design and Implementation of Hierarchical Software Systems With Reusable Components. ACM TOSEM, 1992 41
  42. 42. Generative Programmingtemplate <int N>struct Factorial{ enum { value = N * Factorial<N - 1>::value };};template <>struct Factorial<0> Template meta-programming{ is a form of compile-time code enum { value = 1 };}; generation.// Factorial<4>::value == 24// Factorial<0>::value == 1void foo(){ int x = Factorial<4>::value; // == 24 int y = Factorial<0>::value; // == 1} Krzysztof Czarnecki and Ulrich W. Eisenecker. Generative programming: methods, tools, and applications, ACM Press/Addison-Wesley Publishing, 2000. 42
  43. 43. Subject-Oriented ProgrammingSOP adds a “third dimension” tomethod dispatch. William Harrison and Harold Ossher. Subject-Oriented Programming (A Critique of Pure Objects). OOPSLA 1993 43
  44. 44. Context-Oriented Programming Layer 3 Layer 2 Layer 1 Base layerCOP offers multi-dimensional dispatch, with multiple“layers” triggered by contextual information. Robert Hirschfeld, et al. Context-Oriented Programming. Journal of Object Technology, March 2008. http://dx.doi.org/10.5381/jot.2008.7.3.a4 44
  45. 45. SummaryParadigm: model and compose elementary features Motivation: features represent domain concepts 45
  46. 46. RoadmapEarly historyObjectsComponentsFeaturesMetaprogrammingConclusions 46
  47. 47. ReflectionReflection is the ability of aprogram to manipulate as datasomething representing thestate of the program during itsown execution. Daniel G. Bobrow, et al. CLOS in Context — The Shape of the Design. In “Object-Oriented Programming: the CLOS perspective”, MIT Press, 1993. A metaprogram is a program that manipulates a program (possibly itself) 47
  48. 48. Reflection and reificationIntercession is the ability for a program to modify its ownexecution state or alter its own interpretation or meaning. Introspection is the ability for a program to observe and therefore reason about its own state. 48
  49. 49. Structural and behavioral reflectionStructural reflection lets you reflecton the program being executed Behavioral reflection lets you reflect on the language semantics and implementation Malenfant et al., A Tutorial on Behavioral Reflection and its Implementation, 1996 49
  50. 50. Applications of metaprogramming IDE tools — debugging — profiling — refactoring Dynamic applications — UI generation — Modeling tools 50
  51. 51. Three approaches to reflectionThe tower of Reflective languages Openmeta-circular Implementationinterpreters (MOP) 51
  52. 52. Aspect-Oriented Programming AOP improves modularity by supporting the separation of cross-cutting concerns. A pointcut specifies aAn aspect set of join points in thepackages cross- target system to becutting concerns affected “Weaving” is the process of applying the aspect to the target system Gregor Kiczales, et al. Aspect-Oriented Programming. ECOOP97 52
  53. 53. AspectJ Demo.foo(1, tjp.Demo@939b78e)public class Demo { Demo.bar(3)!static Demo d; Demo.bar(3)!public static void main(String[] args){!!new Demo().go();!} Intercept execution within control flow of Demo.go()!void go(){! = new Demo(); !d!!d.foo(1,d); Identify all methods within Demo!!System.out.println(d.bar(new Integer(3)));!} Wrap all methods except Demo.go()!void foo(int i, Object o){ aspect GetInfo {!!System.out.println("Demo.foo(" + cflow(this(Demo) && execution(void go())); !pointcut goCut(): i + ", " + o + ")n");!} !pointcut demoExecs(): within(Demo) && execution(* *(..)); Intercepted message: foo!String bar (Integer j){ !Object around(): demoExecs() && !execution(* go()) && goCut() in class: tjp.Demo!!System.out.println("Demo.bar(" + j + ")n"); Arguments: {! println("Intercepted message: " 0. i : int = 1 !return "Demo.bar(" + j + ")"; +!} !!thisJoinPointStaticPart.getSignature().getName()); = tjp.Demo@c0b76fa 1. o : java.lang.Object Running original method:} !!... ! ... } Demo.foo(1, tjp.Demo@c0b76fa) } result: null Intercepted message: bar in class: tjp.Demo Arguments: 0. j : java.lang.Integer = 3 Running original method: Demo.bar(3) result: Demo.bar(3) http://www.eclipse.org/aspectj/downloads.php Demo.bar(3) 53
  54. 54. Dependency injectionDependency injection externalizesdependencies to be configurable Key techniques: Typical application: — parameterization injecting mocks — code generation — reflection Martin Fowler. Inversion of Control Containers and the Dependency Injection pattern. http://martinfowler.com/articles/injection.html 54
  55. 55. Model-Driven Engineering Platform Independent Modelsoftwaredeveloper automatic transformation 55
  56. 56. The OMG / MDA Stack µ c2 the MOF M3 The MOF source meta-meta µ Class Association M3 model destination The UML metamodel ++ µ µ µ M2 c2 the UML MetaModel metamodel Some UML Models ++ 1 * M2 Class Attribute M1 model µ µ c2 Various usages a UML Model of these modelsM0 "the real world" Client M1 Name : String 56
  57. 57. SummaryParadigm: composition as metaprogramming Motivation: separation of base and meta-levels 57
  58. 58. RoadmapEarly historyObjectsComponentsFeaturesMetaprogrammingConclusions 58
  59. 59. Mechanisms callreturn invocation messages binding code generation 59
  60. 60. Dimensionsmetalevel The core composition paradigm is component- based, but it varies along several dimensions.base dynamiclevel static fine grain coarse grain 60
  61. 61. Conclusion: Trends1960 1970 1980 1990 2000 2010procedural object component modeltechnology technology technology technologyProcedures, Objects, Classes, Components, Models, Pascal, Smalltalk, Frameworks, Transformations, C, C++, Patterns, UML, MOF, QVT ... ... … …procedural object component modelrefinement composition composition transformation 61
  62. 62. Attribution-ShareAlike 2.5You are free: ▪ to copy, distribute, display, and perform the work ▪ to make derivative works ▪ to make commercial use of the workUnder the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. ▪ For any reuse or distribution, you must make clear to others the license terms of this work. ▪ Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. http://creativecommons.org/licenses/by-sa/2.5/

×