imported>Tommy |
imported>Mathieu |
| Line 1: |
Line 1: |
| − | {{TOCright}}
| + | Feature Modelling Tool (FMT) |
| − | The Petty Print Page of the [[Modelling User Interface|Event-B Editor]] provides a rendered view of an edited machine or context, for an quicker and easier reading.
| |
| | | | |
| − | [[Image:PrettyPrintPage.png|480px|center|An example of pretty print page]] | + | A Software Product Line (SPL) refers to a set of related products built from a shared set of resources having a common base [1]. Further members of the product line |
| | + | are built by reusing existing core components and adding extra functionality. SPLs provide the benefits of reusability in reducing the time to market, lower costs and reduce effort |
| | + | involved in product development. Feature modelling [2] is a well known technique for building SPLs. It has been used in many domains, product line projects and organizations where a feature (usually written in a programming language) is the unit of reuse, specialization and composition. It provides ways to manage variabilites and commonalities within a product line. Feature modelling was suggested as part of the Feature-Oriented Domain Analysis (FODA) [3] in the early 90’s and several tools have been developed to support feature modelling for SPL engineering [2]. |
| | | | |
| − | As a mechanism is available to extend Rodin's Structured Editor, such a mechanism also exists in order to extend the Pretty Print Page. For each element to be displayed, a "pretty printer" is defined within the element extension of the structured editor.
| |
| | | | |
| − | We will have a look at : | + | We have developed a feature modelling tool (FMT), as a Rodin plug-in, which can be used to build feature models. Feature models are used to specify a product line and are represented using tree-structured feature diagrams. These include variability among the product line members and the ways in which these feature models can be instantiated to generate the product line members. |
| | | | |
| − | * how the extensions can contribute to the pretty print page,
| |
| | | | |
| − | * how the pretty print page is created,
| + | References: |
| | | | |
| − | * how to implement pretty printers.
| + | [1] P. Clements and L. Northrop, Software Product Lines : Practices and Patterns. Addison-Wesley Professional, August 2001. [Online]. Available: http://www.amazon.ca/exec/obidos/redirect? tag=citeulike09-20n&path=ASIN/0201703327 |
| | | | |
| − | == How to contribute to the Pretty Print Page ==
| + | [2] K. Lee, K. C. Kang, and J. Lee, “Concepts and guidelines of feature modeling for product line software engineering,” in ICSR-7: Proceedings of the 7th International Conference on Software Reuse. London, UK: Springer-Verlag, 2002, pp. 62–77. |
| | | | |
| − | When contributing to the Event-B Editor, one uses the extension point <tt>org.eventb.ui.editorItems</tt>.
| + | [3] K. Kang, S. Cohen, J. Hess, W. Nowak, and S. Peterson, “Feature-oriented domain analysis (foda) feasibility study.” Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Tech. Rep., 1990. |
| − | This extension point defines extensions from which two of them have been updated in order to contribute to the pretty print page.
| |
| | | | |
| − | Those updated extensions are :
| |
| − | * <tt>element</tt>
| |
| − | :<tt>element</tt> has been extended with a child called <tt>prettyPrinter</tt> where the name of the class that will be used to pretty print the element in the pretty print view shall be given. This class must moreover implement <tt>org.eventb.ui.IElementPrettyPrinter</tt>.
| |
| | | | |
| − | * <tt>childRelation</tt>
| |
| − | :the child element <tt>childType</tt> of a <tt>childRelation</tt> has been extended with <tt>implicitChildProvider</tt> where the name of the class that will be used to retrieve implicit children of this type in the pretty print view shall be given. The class must moreover implement <tt>org.eventb.ui.IImplicitChildProvider</tt>.
| |
| | | | |
| − | Hence, one that wants to contribute to the pretty print page for added items, must at least provide a <tt>prettyPrinter</tt> for each of those added items, and if needed, an <tt>implicitChildProvider</tt>, that will harvest the implicit children of the given type that should also be displayed.
| + | [[User:Gondal|Ali Gondal]] at [[Southampton]] is working on the [[Feature Modelling Tool]]. |
| | | | |
| − | Note: if editor items are defined without such extensions, the added items will simply not appear on the pretty print page.
| |
| | | | |
| − | == How the Pretty Print Page is created ==
| + | [[Category:Plugin]] |
| − | | + | [[Category:User documentation]] |
| − | In this part, we will discribe the core algorithm for pretty printing (we will use the term "core pretty printer" to refer to this piece of code in the pretty print process).
| + | [[Category:Work in progress]] |
| − | The core algorithm starts on the root element (such as a context or a machine) and displays its related informations. Then in a recursive loop, it traverses all sub-elements and pretty print them.
| |
| − | | |
| − | Here is the corresponding algorithm in charge of sub-elements pretty print:
| |
| − | | |
| − | <tt>
| |
| − | traverse(Element parent)
| |
| − | begin
| |
| − | for all ContributionType c in parent.getChildTypes()
| |
| − | do
| |
| − | appendPrefixOrSpecialPrefix(c)
| |
| − | for each Element e in parent.elementsOfType(c)
| |
| − | do
| |
| − | appendItemBeginning(e);
| |
| − | '''IElementPrettyPrinter p = e.getPrettyPrinter();'''
| |
| − | '''p.prettyPrint(e, parent);'''
| |
| − | //recursive traverse to continue pretty printing child elements
| |
| − | traverse(e);
| |
| − | appendItemEnding(e);
| |
| − | od
| |
| − | od
| |
| − | end
| |
| − | </tt>
| |
| − | | |
| − | As one can see, reading this algorithm, the main method that one should implement to pretty print added items is the <tt>prettyPrint</tt> method.
| |
| − | | |
| − | Once all defined items are contributed to the structured editor, they should normally have if needed :
| |
| − | * a prefix, that will be appended once for all elements of this type,
| |
| − | * a childrenSuffix, that will be appended at the end of all elements of this type.
| |
| − | | |
| − | The pretty printing algorithm will handle those values if no special prefix is defined by an element pretty printer.
| |
| − | | |
| − | In fact, one that implements the interface for pretty printing <tt>IElementPrettyPrinter</tt> will be able to define a pretty printing method, but also auxiliary methods to tune the way elements are display by the Pretty Print Page.
| |
| − | | |
| − | There are 4 methods one can implement defining a pretty printer for an element :
| |
| − | | |
| − | <tt>
| |
| − | void prettyPrint(IInternalElement elt, IInternalElement parent, IPrettyPrintStream ps);
| |
| − | ::(Required)This method appends the string corresponding to the pretty print of the element elt.
| |
| − | | |
| − | boolean appendSpecialPrefix(IInternalElement parent, String defaultPrefix, IPrettyPrintStream ps, boolean empty);
| |
| − | ::(Optional)This method appends a custom prefix, and should be used to replace the default prefix which is contributed, to be appended. It shall return true to tell the core pretty printer that a special prefix was appended, so it avoids to append the default one.
| |
| − | | |
| − | void appendBeginningDetails(IInternalElement elt, IPrettyPrintStream ps);
| |
| − | ::(Optional)This methods appends some details that contributors can calculate on a given element, and for which there is not representation in the data model. This method appends details before traversing the children of the given element elt.
| |
| − | | |
| − | void appendEndingDetails(IInternalElement elt, IPrettyPrintStream ps);
| |
| − | ::(Optional)This method appends some details that contributors can calculate on a given element, and for which there is no representation in the data model. This method appends details after having traversed the children of the given element elt.
| |
| − | | |
| − | </tt>
| |
| − | | |
| − | == How to implement pretty printers (of Event-B Editor contributions) ==
| |
| − | | |
| − | In this part we will study concrete examples, to show how the pretty printer is contributed.
| |
Feature Modelling Tool (FMT)
A Software Product Line (SPL) refers to a set of related products built from a shared set of resources having a common base [1]. Further members of the product line
are built by reusing existing core components and adding extra functionality. SPLs provide the benefits of reusability in reducing the time to market, lower costs and reduce effort
involved in product development. Feature modelling [2] is a well known technique for building SPLs. It has been used in many domains, product line projects and organizations where a feature (usually written in a programming language) is the unit of reuse, specialization and composition. It provides ways to manage variabilites and commonalities within a product line. Feature modelling was suggested as part of the Feature-Oriented Domain Analysis (FODA) [3] in the early 90’s and several tools have been developed to support feature modelling for SPL engineering [2].
We have developed a feature modelling tool (FMT), as a Rodin plug-in, which can be used to build feature models. Feature models are used to specify a product line and are represented using tree-structured feature diagrams. These include variability among the product line members and the ways in which these feature models can be instantiated to generate the product line members.
References:
[1] P. Clements and L. Northrop, Software Product Lines : Practices and Patterns. Addison-Wesley Professional, August 2001. [Online]. Available: http://www.amazon.ca/exec/obidos/redirect? tag=citeulike09-20n&path=ASIN/0201703327
[2] K. Lee, K. C. Kang, and J. Lee, “Concepts and guidelines of feature modeling for product line software engineering,” in ICSR-7: Proceedings of the 7th International Conference on Software Reuse. London, UK: Springer-Verlag, 2002, pp. 62–77.
[3] K. Kang, S. Cohen, J. Hess, W. Nowak, and S. Peterson, “Feature-oriented domain analysis (foda) feasibility study.” Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Tech. Rep., 1990.
Ali Gondal at Southampton is working on the Feature Modelling Tool.
