1 / 44

Feature Oriented Programming

Feature Oriented Programming. A brief introduction. Idea. A system can be combined in some different way. Decomposition by class. Decomposition by feature. Problem in OOP. Features are tangled and scattered in current object-oriented software.

adelle
Télécharger la présentation

Feature Oriented Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Feature Oriented Programming A brief introduction

  2. Idea A system can be combined in some different way. Decomposition by class Decomposition by feature

  3. Problem in OOP • Features are tangled and scattered in current object-oriented software. • "Tangled" means that several features are implemented in one place. • " Scattered" means that one feature's code is spread over several classes. • The more code you reuse en bloc, the less it fits the different contexts of deployment.

  4. Feature Driven Development • Developers like it. They get something new to work on every two weeks. (They love new things.) They get closure every two weeks that is an important must-have element for job satisfaction. • Managers like it. They know what to plan and how to establish meaningful milestones. They get the risk-reduction that comes from managing a project that delivers frequent, tangible, working results. They get real percentage numbers on progress. • Clients like it. They see plans with milestones that they understand. They see frequent results that they understand. And they know exactly how far along the project is at any point in time.

  5. Concepts • A feature is a characteristic that is used to distinguish different programs within a family of programs. • Feature Oriented Programming(FOP) is the study of feature modularity, where features are raised to first-class entities in design. • Refinements — develop a complex program from a simple program by incrementally adding details.

  6. Concepts (Cont’d.) • There are many implementations of feature refinements (cross-cutting), each with different names, capabilities, and limitations: layers, feature modules, meta-classes, collaborations, subjects, aspects, andconcerns. • Product-line architectures (PLAs) are designs for families of related applications; application construction is accomplished by composing reusable components.

  7. Perspective New paradigms will likely embrace: • Generative Programming (GP) • want software development to be automated • Domain-Specific Languages (DSLs) • not Java & C#, but high-level notations • Automatic Programming (AP) • declarative specs → efficient programs

  8. An Example

  9. An Example (Cont’d.)

  10. GenVoca : Concepts • GenVoca is a design methodology for creating application families and architecturally-extensible software, i.e., software that is customizable via module additions and removals. • Programs are values and refinements are functions that add features to programs. • Design rules capture syntactic and semantic constraints that govern legal compositions.

  11. GenVoca : Equation • f // program with feature f • i(x) // adds feature i to program x • app1 = i(f) // app1 has features i and f • app2 = i(j(f)) // app2 has features i, j, f • k1(x) // adds k with implementation1 to x k2(x) // adds k with implementation2 to x

  12. GenVoca : Implementation • Linear inheritance chains, called refinement chains. • Only the bottom-most class of a chain is instantiated. • c = ck(cj(ci)).

  13. GenVoca : Refinement • A program has many different representations besides source code. A program can be defined by UML, process diagrams, makefiles, performance models, design rule files, etc. each written in its own DSL. • Conventional notions of modularity must be broadened: a module is a containment hierarchy of artifacts. • The impact of refinements need not be limited to source code. • Refining non-code artifacts is intuitively evident. Most artifact types are object-based. The only thing to be done when introducing a new artifact type is define what refinement means.

  14. GenVoca : An Example • Principle of Uniformity: treat all non-code artifacts as classes, and refine them in an analogous manner as code.

  15. AHEAD • Algebraic Hierarchical Equations for Application Design (AHEAD), expresses an arbitrary number of programs and representations as nested sets of equations, a form that is ideal for generators to manipulate. • Base artifacts are constants and artifact refinements are functions. An artifact that results from a refinement chain is modeled equationally as a series of functions (refinements) applied to a constant (base artifact).

  16. AHEAD : Equation h•f = { ah, bh, ch} • { af, bf, df} = { ah•af, bh•bf, ch, df}

  17. AHEAD : Equation (Cont’d) h•f = { a, b, c, d } where a = ah•af b = bh•bf c = ch d = df

  18. AHEAD : Composition • Containment Hierarchies : Composition of compound artifacts is achieved by recursively composing collectives. • The depth to which collectives are nested is the rank of the collective. { } is an empty collective of rank0; {{ }} is a collective of rank 1, and so on. • A feature — whether it represents an AHEAD constant or a function — is defined by a tree of artifacts. When features are composed, all of their corresponding artifacts are composed.

  19. AHEAD : Polymorphism • The composition operator • is polymorphic. Artifacts are composed by operators that are specific to that artifact type. • Principle of Abstraction Uniformity : the operator for composing collectives of rank n is no different than the operator for composing collectives of rank n+1, for n≥0. • Imposing uniformity on all levels of abstraction produces a very compact and powerful algebra for defining and composing systems.

  20. AHEAD : Scalability • Equations elegantly express refinement relationships for all representations. Furthermore, equations enable step-wise refinement and its generators to scale.

  21. AHEAD : Metamodel • A metamodel is a model whose instances are models. • M = { a, b, c } // model • MM = { AAA, BBB, CCC } = { {a}, {b}, {c} } // metamodel • M = AAA • BBB • CCC • Uk♦ Uj= Uk// Ukreplaces Uj

  22. Origami • If layers (features) are the building blocks of programs, what are the building blocks of layers? We argue that an answer is a facet. • A product-family is an integrated suite of programs, each program having different capabilities.

  23. Origami

  24. Origami J = { Java, Sm(x), Tmpl(x), ... } Jak = Sm( Tmpl( Java )) Jak = Tmpl( Sm( Java )) D = { JavaDoc, SmDoc(x), TmplDoc(x), ... } Jedi = SmDoc( TmplDoc( JavaDoc )) Jedi = TmplDoc( SmDoc( JavaDoc ))

  25. Origami

  26. Origami Jedi = Tdoclet( Tharvest( Tparse( Sdoclet( Jdoclet( Sharvest( Jharvest( Sparse( Jparse )))))))))

  27. Origami Jak = Jprint( Treduce( Sreduce( Jreduce( Tparse( Sparse( Jparse ))))))

  28. Origami • Without loss of generality, instead of writing A = B(C(D)) we will write A = B o C o D. • Origami matrix, where rows denote language features and columns are tool features. • Let us call matrix entries gluons.

  29. Origami

  30. Origami

  31. Origami • An application (expression) is created by folding an Origami matrix. Folding continues until a matrix is produced; the entry of this matrix is the desired expression. • Rows and columns cannot be chosen at random for folding. Rows (columns) must be composed in design rule order.

  32. Origami • Representing architectural specifications of programs as equations • Origami allows us to annotate (give advice to) architectural specs • Specs are not Java programs, but equational representations of programs • Representing software designs as equations is enormously powerful • ideal for generators • equational representations scale • ideas of origami apply to all levels of abstraction equally • no reason to believe that equational representations can’t scale to much larger systems

  33. Origami • Relationship to AOP Eqn = Cafter2 ●Cafter1●C ●Bafter2●Bafter1●B ●Aafter2●Aafter1●A Jedi = (TDoclet ● THarvest ● TParse) ● (SDoclet ● SHarvest ● SParse )● (JDoclet ● JHarvest ● JParse )

  34. Tools Support • Jakarta Tool Suite • Jampack • Mixin & Unmixin • AHEAD Tool Suite

  35. AHEAD vs. AspectJ

  36. AHEAD vs. HyperJ

  37. GenVoca vs. AOP • AOP starts with user-written components that cleanly encapsulate some application function in code.  AOP components can be methods, classes, etc.  AOP then applies one or more aspects to these components to perform large-scale refinements.  Aspects implement design features that may modify or cross-cut multiple components.  All modifications take place at predefined join points.  Join points may be as generic as constructs in the host programming language or as specific as code markers unique to an application.

  38. GenVoca vs. AOP • GenVoca defines standardized interfaces called realms which may contain multiple classes and their methods.  GenVoca components are modules that export a realm interface and encapsulate the implementation of a single design feature.  GenVoca components may also import realm interfaces allowing components to be parameterized by other components.  Such compositions are specified in type equations.  Each component implements a large scale refinement; a composition of components represents a composition of such refinements.

  39. GenVoca vs. AOP • Though AOP and GenVoca have different starting points, both begin with some encapsulated representation of system function (AOP component, GenVoca realm) and provide a mechanism to define and apply large-scale refinements (AOP aspects, GenVoca components) at specific sites (AOP join points, parameters in GenVoca components).

  40. GenVoca vs. AOP • In AOP, aspect languages are defined which operate on and transform components that conform to each language's specification.  In GenVoca, a type equation guides the transformation of multiple components to produce a monolithic implementation of a realm's interface.  • The AOP weaver and the GenVoca generator perform these transformations respectively.  Both have been implemented as preprocessors to underlying programming language compilers. 

  41. GenVoca vs. AOP • Not all compositions of GenVoca components are correct.  General algorithms for validating the component compositions have been developed. Corresponding validation problems will surface when multiple AOP aspects are composed. • For optimization purposes, some GenVoca implementations allow interactaction between components at composition time.  Similar techniques may be required for  AOP aspects to generate efficient code in similar circumstances. • GenVoca type equations can be automatically rewritten using expert knowledge to express a more optimized application design.  The same type of built-in guidance would also be valuable to AOP users composing large numbers of aspects at once.

  42. GenVoca vs. AOP • AOP can build an aspect language and weaver for any existing code base.  If the aspect language uses only the constructs of the underlying programming language as join points (such as aspects that wrap any method definition), then it can be applied to all programs written in the language.  If the aspect language uses application-specific patterns or markers as join points, then the language is restricted to that application.

  43. GenVoca vs. AOP • GenVoca requires the definition of standardized realm interfaces as its starting point. This is usually preceded by a domain analysis which reveals what standardized interfaces should be supported.  Each interface defined represents a subsystem abstraction whose implementations are specified by families of subsystems (type equations), called an application family. • Whereas GenVoca provides techniques to decompose existing applications into reusable and composable components, AOP supports the reuse of existing code by applying new features in a controlled and localized way.

  44. FOP VS. AOP Conjecture: all belong to an encompassing paradigm based on refinements.

More Related