FORM: Feature-Oriented Reuse Method

1. FORM: Feature-Oriented Reuse Method Kaan Kaynar

2. Domain Analysis and Engineering • Domain: a family of related systems • Domain analysis:examining a family of related systems and extracting the commonalitiesand differences of these systems • Domain engineering: using analysis results to create a set ofreference models, i.e., reusable software architectures and components • Application engineering: creating applications using these reusable artifacts

3. Feature-Oriented Domain Modeling Methods • Captures the commonalities and differences of systems in a domain in terms of features • The use of features is motivated by the fact that customers and developers speak about product characteristics in terms of features the product has or delivers • Features are distinctively identifiable functional abstractions of a system (that is relevant to any end-user or developer of the system)

4. Feature Model • The model constructed during the analysis is called the "feature model” whichrepresents relationships between features as an AND/OR graph • AND branches imply the mandatory selection of all the children of the parent feature, OR branches imply the selection of exactly one of the children -- whenever the parent feature is selected • FODA (Feature-Oriented Domain Analysis) can be termed as the mother of all feature-oriented modeling methods

5. Feature Model

6. Importance of Feature Models Standardization • The feature model standardizes the meanings of features, it is possible to define standard domain terminology and ease communication problems Feature Model = Theory of a Domain • The feature model can be used for evaluating commonalities and differences between domains, and surely, applications in a domain Commonalities -> Reusable Artifacts • Feature models areused to support engineering of reusable domain artifacts and development of applications using these domain artifacts

7. FORM • FORM extends FODA, however it covers both domain and application engineering • There are three phases in FORM domain engineering: context analysis, domain modeling, and architecturemodeling • During the context analysis, the scope and intended use of the domain are identified • Domain modeling definesthe “decision space” (the feature model) consisting of user selectable features • Architectural modeling defines the “artifact space” which consists of the reusable artifactsand their hierarchicaldecompositions

8. FORM Domain Modeling • FORM domain modeling identifies the features in four different layers: service, operating environment, domain technology, and implementation technique layer features • A “service” or a “capability” feature represents a distinct serviceor a functionality that an applicationmay have. Service features can be found in user manuals • They are divided into “functional” and “non-functional” ones. Non functional features represent intended use, or expected performance • An “operating environment” feature represents attributes ofenvironment in which an application is operated. They can be found in requirements and design documents

9. FORM Domain Modeling (cont.) • “Domain technology” and “implementation technique” features represent implementation details at lower levels • The difference between these two is that a “domain technology” feature is more related to a given domain (e.g., navigation methods in the aviation domain), while“implementation technique” feature is more generic • Domain technologyfeatures can be found inrequirements and design documents, andimplementation technique features can be found in design documents and program sources

10. FORM Feature Model of the EBBS (Electronic Bulletin Board System) Domain

11. FORM Feature Model • Features can be “mandatory”, “optional” (denoted with a circle), or “alternative” (denoted with an arc) • Three types of relationships are represented in this model: “composed-of”,“generalization/specialization” and “implemented-by” • Composition rules can support the feature model with mutual dependency and mutual exclusion relationships • Issues and decisions can also support the feature model withtrade-offs andselection criteria for feature selection

12. Comments on the Feature Model • A feature model with AND-nodes at an upper level and OR-nodes at a lower level indicates a high level of reusability. There are different ways ofimplementing certain components below in the hierarchy • OR-nodes at the upper level indicates thatapplications in the domain do not have much commonalities in terms of services provided by them

13. Validation of the Feature Model • The feature model should be validated before use • Validation isperformed by instantiating the model for each application considered in the domain analysis and checking if the instantiated model represents theapplication’s requirements • An instantiation of a feature model is a selection of a set of capability, operating environment, domain technology and implementation technique features from the model

14. FORM Architecture Modeling • Reference architectures and reusable components instantiatable during application development are defined • Reference architectures are defined in three levels of abstraction: subsystem model, process model and module model “Decision Space” “Artifact Space” • They are defined according to the feature model following the four-level hierarchy and considering the “functional” and “non-functional” features • The functional features are used to identify components, while non functional features are used to partition the components – at every abstraction level

15. Subsystem Model • The “subsystem model” defines the overall system structure by packagingservice featuresinto subsystems • Features having a strong data or control dependency are allocated to a subsystem to minimize coupling • A feature that requires a time-critical function may be allocated to its own subsystem (a GUI service) • Data flow between subsystems (also processes) can be by a non-blocking communication via a message queue, or a blocking communication via a message/reply mechanism

16. A Subsystem Model For the EBBS Domain

17. Process Model • Each subsystem is decomposed into a set of concurrent processes considering the operating environment features • The process model represents the dynamic behavior of each subsystem • The decomposition/refinement process is guided by loose coupling and cohesion • Operational features of resident and transient nature should be separated • Operational features that are time-critical or have high priority may be allocated to separate processes

18. A Process Model For the Board Subsystem of the EBBS Domain • Choice of two operating environment features; “Database” and “Fault Tolerance” have resulted in a separate “DB Client Daemon” process

19. Module Model • Modules are defined based on the features on domain technology and implementation techniques • A module only contains an abstract specification which defines how it is integrated into an application • Multiple code level reusable components can be created that match the specification of the module • A module may be specified in different ways to enable different reuse techniques: selecting a precodedcomponent, instantiating a parameterized component by supplying the parameter values, or completing a skeletal code component

20. A Module Model of the Board Client Process of the EBBS Domain • Choice of domain technology feature “Textual display” is implemented by both providing “VT series” terminal handling module, integratable into the application as a template, and “TTY” terminal handling module

21. Parameterization in Architecture Modeling • There can exist as many reference architecture models as feature selections • Alternative features (OR-nodes)often indicate the need for parameterization of an architecture or a component • Hence, features are used as parameters of an architecture or a component template • In FORM, software reuse is advanced from the traditional module level to the design level through these architecture templates

22. Architecture Modeling: Summary

23. FORM Application Engineering • Concerns finding a correct reference architecture through feature selection and then putting in reusable software components Feature Selection • Users are concerned about services or functions provided by the system (service features) • System analysts and designers are concerned about operating environment conditions and domain technologies • Developers are concerned about implementation techniques • Applications are built by reconciling these concerns that results in a selected set of features (instantiation of a feature model)

24. Feature Selection Stepwise Refinement • An effective method of finding such a feature set is by following the four-level feature hierarchy: first considering capabilities, then operating environments, and finally domain technologies and implementation techniques • While findingthe features, there may be a case when a user is not allowed to select a feature because of the dependencies among the features • In such a case, the developershould analyze the path of feature selection and either negotiate with the user to change the requirements, or try to find an alternative feature set that will satisfy the requirements • At the end, the developer should verify the completeness and consistency of the selectedfeatures through the use of “composition rules” and “issues and decisions”

25. Architecture Selection and Components Integration • After the feature selection process, a corresponding reference architecture model is identified in the artifact space • Once a reference architecture is identified, reusable components are found by using the specifications and methods defined in the modules • Components are instantiated, and integrated in a bottom-up fashion completing the application development based on the integration rules defined in the modules • FORM defines various types of “connectors”(e.g. socket, LPC, RPC, CORBA) for different architectural models. This minimizes problems related tothe integration of reusable components

26. FORM Application Development

27. Conclusion • “Seperation of concerns” provides high adaptability and reusability of architectures and components to/by applications • While at the module model level matching reusable components can be searched, at the subsystem and process levels these components can be viewed in the context of a larger architecture • “Seperation of concerns” also provides ease of modification of architectures and components • In addition, the relations among different types of features can be analyzed and problems can be identified early in the development

28. References • FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures Kyo C. Kang, Sajoong Kim, Jaejoon Lee, Kijoo Kim, Gerard Jounghyun Kim, Euiseob Shin • Representing Feature Models of Software Product Families Using a Configuration Ontology Timo Asikainen, Tomi Männistö, Timo Soininen • Feature-Oriented Product Line Engineering Kyo C. Kang, Jaejoon Lee, Patrick Donohoe