• Corpus ID: 17666239

Feature Interaction in Composed System

@inproceedings{Pulvermller2001FeatureII,
  title={Feature Interaction in Composed System},
  author={Elke Pulverm{\"u}ller and Andreas Speck and James O. Coplien and Maja D'Hondt and Wolfgang DeMeuter},
  year={2001}
}

• E. Pulvermüller, A. Speck, +2 authors Wolfgang DeMeuter
• Published 2001
• Computer Science

Featureinteractionis nothingnew andnot limited to computerscience.Theproblemof undesirable feature interaction (feature interactionproblem) hasalreadybeeninvestigatedin thetelecommunicationdomain.Ourgoalis theinvestigationof feature interactionin component-based systemsbeyondtelecommunication. Thepositionpaperoutlines terminologydefinitions. It proposesa classificationto comparedifferenttypesof featureinteraction. A list of examplesgiveanimpressionaboutthe natureandtheimportanceof featureinteraction. 1 Intr oduction and Problem The workshop“FeatureInteractionin Composed Systems”dealswith a problemwhich is not new. In fact, as opposedto that, it’s a problem even olderthanhumanlife. In the domainof telecommunicationthis problemwasexplicitely exploredfirst in thebeginning 1990susing the term “feature interactionproblem”. In a seriesof workshops(thefirst washeld in 1992)thedifficulty to manageimplicit andunforeseeninteractionsbetweennewly insertedfeaturesandthebasesystemhavebeenexamined. However, the problem is not limited to the telecommunicationdomain. As opposedto that feature interaction is an issue which occurs in nearly all domains although not known under the name “feature interaction”. In the last two years we found a growing awareness of this problem in the domain of system composition far beyond telecommunication issues. With the emerge of aspect-oriented programming it has become obvious that with the growing number of system units their interaction is a problem of its own, requiring research by its own. While AOP, CF, SOP, AP [1] and related approaches reveal this problem it’s not limited to those approaches either. It already exists in objectoriented or component-oriented systems, for instance. In many discussions we found that already a lot of work exists dealing with feature interaction in various domains and applying various programming paradigms. The workshop aims at collecting the different problems and to provide a platform for knowledge transfer. Some important questions are: What are suitable definitions for “feature” and “feature interaction”? Are there any commonalities in the different problems and / or their solutions? How can the problems be categorised in problem classes? What is the influence of advanced separation of concerns or component-based approaches to feature interaction problems and vice-versa? While it is easy to compose a system technically it’s hardly explored how systems can be combined in a way that the result is a valid and also reasonable system. The developer faces a lack of clearly structured composition and connection concepts. 2 Terminology or “What is a Feature?” When discussing about feature interaction it’s important to consider existing terminology. In a series of workshops the feature interaction problem has already been investigated in the telecommunication domain since 1992. The workshop statement explains that “feature interaction occurs when one telecommunication feature modifies or subverts the operation of another one”. A definition found in the telecommunication community is as follows: “The feature interaction problem can be simply defined as the unwanted interferencebetweenfeaturesrunningtogetherin a software system. ” A simple example given in [9] is a mailing list echoing all emails to all subscribers. If one of the subscribers has enabled the vacation program (without first suspending messages from the mailing list) an infinite cycle of mail messages between the mailing list and the vacation program will occur. In [10] a feature is defined as “an extension to the basic functionality provided by a service” while a service is explained as “a core set of functionality, such as the ability to establish a connection between two parties”. While these definitions concentrate on telecommunication, large and distributed systems or multimedia systems in particular the goal of this workshop is the investigation of feature interaction in the domain of software composition and systems built from components. We distinguish the terms “feature”, “concern” and “requirement”, “service”, “component” and “aspect” according to our experiences as follows: In [4] you may find the following explanation for “features”: “A feature is something especially noticeable: a prominent part or detail (a characteristic). A feature is a main or outstanding attraction, e.g. a special column or section in a newspaper or magazine”. Its origin is from Latin: “factura” which means the “act of making” or from “facere” which means “to make, do”. According to this definition we use the term feature in a broader sense than just as an extension to some basic functionality. It’s an observable and relatively closed behaviour or characteristic of a (software) part. In software, it’s not just an arbitrary section in the code except this code section “makes something of outstanding attraction”. This definition is fuzzy revealing the fuzzy nature of features. This viewpoint is consistent with that expressed in [2] where a feature is explained as “any part or aspect of a specification which the user perceives as having a self-contained functional role”. A feature is something an application has to do. It may be composed from other features. A basic feature should be as small as possible (basic building blocks). What a feature does should be documented. This might be done either manually (the implementer is forced to document it) or by deriving it from the program structure and program flow. We have a distinction between problem domain features and features on the implementation level (cf. figure 1). Different alternative implementation features may realise the higher-level problem domain features. Moreover, a problem domain feature may be implemented by one or more implementation feature. A component may have several features and, vice-versa, it realises at least one feature (otherwise the component is not useful). Moreover, a component implements functionality and has non-functional properties (e.g. real-time properties, platform). “Non-functional” is all which is not implemented directly. Therefore, a componenthasnon-functional properties but not implementsthose. Non-functional properties are additional properties implicitly resulting from the code. However, a consequence is that the developer may have to implement mechanisms to check whether the required non-functional requirements are met, i.e. you may even find the non-functional properties in the code. A feature may be implemented as functionality Problem Domain