The term model-driven engineering (MDE) is typically used to describe software development approaches in which abstract models of software systems are created and systematically transformed to concrete implementations. In this paper we give an overview of current research in MDE and discuss some of the major challenges that must be tackled in order to realize the MDE vision of software development. We argue that full realizations of the MDE vision may not be possible in the near to medium-term primarily because of the wicked problems involved. On the other hand, attempting to realize the vision will provide insights that can be used to significantly reduce the gap between evolving software complexity and the technologies used to manage complexity.

/pdf/model-driven-development-of-complex-software-a-research-1l2kfenshb.pdf

Model-driven Development of Complex Software: A Research Roadmap

Systematic discovery and exploitation of commonality across related software systems is a fundamental technical requirement for achieving successful software reuse By examining a class/family of related systems and the commonality underlying those systems, it is possible to obtain a set of reference models, ie, software architectures and components needed for implementing applications in the class FORM (FeaturedOriented Reuse Method) supports development of such reusable architectures and components (through a process called the “domain engineering”) and development of applications using the domain artifacts produced from the domain engineering FORM starts with an analysis of commonality among applications in a particular domain in terms of services, operating environments, domain technologies, and implementation techniques The model constructed during the analysis is called a “feature” model, and it captures commonality as an AND/OR graph, where AND nodes indicate mandatory features and OR nodes indicate alternative features selectable for different applications Then, this model is used to define parameterized reference architectures and appropriate reusable components instantiatable during application development Architectures are defined from three different viewpoints (subsystem, process, and module) and have intimate association with the features The subsystem architecture is used to package service features and allocate them to different computers in a distributed environment Each subsystem is further decomposed into processes considering the operating environment features Modules are defined based on the features on domain technology and implementation techniques These architecture models that represent an architecture at different levels of abstraction are derived from the feature hierarchy captured in the feature model Modules serve as basis for creating reusable components, and their specification defines how they are integrated into the application (eg, asdis integration of predcoded component, instantiation of parameterized templates, and fillingdin skeletal codes) Our experiences have shown that for the electronic bulletin board and the private branch exchange (PBX) domains, “features” make up for a common domain language and the main communication medium among application users and developers Thus, the feature model well represents a “decision space” of software development, and is a good starting point for identifying candidate reusable components

FORM: A feature-oriented reuse method with domain-specific reference architectures

The present invention provides flexible call processing. For example, a call processor system can receive an inbound call intended for a called party and place an outbound call to the called party. The call processing system can provide the called party with a call transfer option.

Methods and apparatus for providing expanded telecommunications service

http://www.dcs.gla.ac.uk/~muffy/papers/calder-kolberg-magill-reiff.pdf

Feature interaction: a critical review and considered forecast

Distributed Feature Composition (DFC) is a new technology for feature specification and composition, based on a virtual architecture offering benefits analogous to those of a pipe-and-filter architecture. In the DFC architecture, customer calls are processed by dynamically assembled configurations of filter-like components: each component implements an applicable feature, and communicates with its neighbors by featureless internal calls that are connected by the underlying architectural substrate.

/pdf/distributed-feature-composition-a-virtual-architecture-for-1lmb1n2lhz.pdf

Distributed feature composition: a virtual architecture for telecommunications services

It is argued that the goal of the intelligent network (IN) is to accelerate the introduction of new telecommunications features in a multisupplier competitive environment. One major roadblock to fulfilling such requirements is the feature interaction problem-a new feature may interact with existing features in some undesirable ways, resulting in adverse behavior. Feature interaction examples are categorized by their causes, since problems arising from the same cause may have the same solution. These examples and taxonomies are developed to improve understanding of the problem's scope and to provide a benchmark for analyzing the coverage of a proposed approach to solving the problem. Informal definitions of the concepts given, feature, service, and feature interaction, are presented. Prototypical examples of feature interactions and their categorization by causes are also presented. Possible approaches to the problem are discussed. >

A feature-interaction benchmark for IN and beyond

The problems of defining features, services, and feature interactions in telecommunication systems are discussed. Several ways of classifying feature interactions are surveyed. Existing approaches for solving the feature-interaction problem are reviewed. It is seen that no full approach exists; they are all partial solutions. The approaches are divided into three classes: avoidance, detection, and resolution. Avoidance looks at ways to prevent undesired feature interactions. Detection assumes that feature interactions will be present, and determines methods for identifying and locating them. Resolution assumes that feature interactions will be present and detected, and looks at mechanisms for minimizing their potential adverse effects. >

E.J. Cameron

Papers

A feature-interaction benchmark for IN and beyond

Feature interactions in telecommunications systems