feature oriented programming n.
Skip this Video
Loading SlideShow in 5 Seconds..
Feature Oriented Programming PowerPoint Presentation
Download Presentation
Feature Oriented Programming

Loading in 2 Seconds...

play fullscreen
1 / 44

Feature Oriented Programming - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Feature Oriented Programming' - adelle

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
feature oriented programming

Feature Oriented Programming

A brief introduction


A system can be combined in some different way.


by class


by feature

problem in oop
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.
feature driven development
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.
  • 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.
concepts cont d
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.

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
genvoca concepts
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.
genvoca equation
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

genvoca implementation
GenVoca : Implementation
  • Linear inheritance chains, called refinement chains.
  • Only the bottom-most class of a chain is instantiated.
  • c = ck(cj(ci)).
genvoca refinement
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.
genvoca an example
GenVoca : An Example
  • Principle of Uniformity: treat all non-code artifacts as classes, and refine them in an analogous manner as code.
  • 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).
ahead equation
AHEAD : Equation

h•f = { ah, bh, ch} • { af, bf, df}

= { ah•af, bh•bf, ch, df}

ahead equation cont d
AHEAD : Equation (Cont’d)

h•f = { a, b, c, d }

where a = ah•af

b = bh•bf

c = ch

d = df

ahead composition
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.
ahead polymorphism
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.
ahead scalability
AHEAD : Scalability
  • Equations elegantly express refinement relationships for all representations. Furthermore, equations enable step-wise refinement and its generators to scale.
ahead metamodel
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
  • 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.

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


Jedi = Tdoclet( Tharvest( Tparse(

Sdoclet( Jdoclet( Sharvest(

Jharvest( Sparse( Jparse )))))))))


Jak = Jprint( Treduce( Sreduce( Jreduce(

Tparse( Sparse( Jparse ))))))

  • 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.
  • 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.
  • 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
  • Relationship to AOP

Eqn = Cafter2 ●Cafter1●C



Jedi = (TDoclet ● THarvest ● TParse) ● (SDoclet ● SHarvest ● SParse )● (JDoclet ● JHarvest ● JParse )

tools support
Tools Support
  • Jakarta Tool Suite
  • Jampack
  • Mixin & Unmixin
  • AHEAD Tool Suite
genvoca vs aop
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.
genvoca vs aop1
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.
genvoca vs aop2
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).
genvoca vs aop3
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. 
genvoca vs aop4
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.
genvoca vs aop5
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.
genvoca vs aop6
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.
fop vs aop

Conjecture: all belong to an encompassing paradigm based on refinements.