Software architectures have the potential to substantially improve the development and evolution of large, complex, multi-lingual, multi-platform, long-running systems. However, in order to achieve this potential, specific techniques for architecture-based modeling, analysis, and evolution must be provided. Furthermore, one cannot fully benefit from such techniques unless support for mapping an architecture to an implementation also exists. This paper motivates and presents one such approach, which is an outgrowth of our experience with systems developed and evolved according to the C2 architectural style. We describe an architecture description language (ADL) specifically designed to support architecturebased evolution and discuss the kinds of evolution the language supports. We then describe a component-based environment that enables modeling, analysis, and evolution of architectures expressed in the ADL, as well as mapping of architectural models to an implementation infrastructure. The architecture of the environment itself can be evolved easily to support multiple ADLs, kinds of analyses, architectural styles, and implementation platforms. Our approach is fully reflexive: the environment can be used to describe, analyze, evolve, and (partially) implement itself, using the very ADL it supports. An existing architecture is used throughout the paper to provide illustrations and examples. Keywords Software architecture, architecture description language,

Software architectures promote development focused on modular building blocks and their interconnections. Since architecture-level components often contain complex functionality, it is reasonable to expect that their interactions will also be complex. Modeling and implementing software connectors thus becomes a key aspect of architecture-based development. Software interconnection and middleware technologies such as RMI, CORBA, ILU, and ActiveX provide a valuable service in building applications from components. The relation of such services to software connectors in the context of software architectures, however, is not well understood. To understand the tradeoffs among these technologies with respect to architectures, we have evaluated several off-the-shelf middleware technologies and identified key techniques for utilizing them in implementing software connectors. Our platform for investigation was C2, a component- and message-based architectural style. By encapsulating middleware functionality within software connectors, we have coupled C2’s existing benefits such as component interchangeability, substrate independence and structural guidance with new capabilities of multi-lingual, multi-process and distributed application development in a manner that is transparent to architects.

Software architectures promote development focused on modular functional building blocks (components), their interconnections (configurations), and their interactions (connectors). Since architecture-level components often contain complex functionality, it is reasonable to expect that their interactions will be complex as well. Middleware technologies such as CORBA, COM, and RMI, provide a set of predefined services for enabling component composition and interaction. However, the potential role of such services in the implementations of software architectures is not well understood. Furthermore, components adhering to one middleware standard cannot readily interact with those adhering to another. In order to understand the role and tradeoffs among middleware technologies in implementing architectures and enable component interoperability across middleware platforms, we have investigated a set of techniques and conducted case studies involving a particular architectural style, C2, and its implementation infrastructure. In particular, by encapsulating middleware functionality within C2’s explicit software connectors, we have been able to couple C2’s existing benefits such as component interchangeability, substrate independence, and structural guidance with new capabilities of multi-lingual, multi-process, and distributed application development in a manner that is transparent to architects. Furthermore, we have demonstrated the utility of our connector-based approach in enabling components implemented on top of different middleware platforms to interoperate. Though several details of our approach derive from the characteristics of the C2 style, we believe that a number of lessons learned are more generally applicable. We argue that these lessons can help form a broader research agenda for coupling the modeling power of software architectures with the implementation support provided by middleware. 1.

Software architectures have the potential to substantially improve the development and evolution of large, complex, multi-lingual, multi-platform, long-running systems. However, in order to achieve this potential, specific architecture-based modeling, analysis, and evolution techniques must be provided. This paper motivates and presents one such technique: a type theory for software architectures, which allows flexible, controlled evolution of software components in a manner that preserves the desired architectural relationships and properties. Critical to the type theory is a taxonomy that divides the space of subtyping relationships into a small set of well defined categories. The paper also investigates the effects of large-scale development and off-the-shelf reuse on establishing type conformance between interoperating components in an architecture. An existing architecture is used as an example to illustrate a number of different applications of the type theory to architectural modeling and evolution. 1 1.

Software architecture research has yielded a variety of powerful techniques for assisting in the design, implementation, and long-term evolution of complex, heterogeneous, distributed, multi-user applications. Since software development environments are themselves applications with these characteristics, it is natural to examine the effectiveness of an architectural approach to constructing and changing them. We report on our experience in creating a family of related environments in this manner. The environments encompass a range of services and include commercial off-the-shelf products as well as custom-built tools. The particular architectural approach adopted is fully reflexive: the environments are used in their own construction and evolution. We also report on some engineering experiences, in particular with our use of XML as the vehicle for supporting a common and extensible representation of architectural models, including the model of the environment itself.

This paper addresses the issue of how to perform architectural analysis on an existing product line architecture. The contribution of the paper is to identify and demonstrate a repeatable product line architecture analysis process. The approach denes a \good" product line architecture in terms of those quality attributes required by the particular product line under development. It then analyzes the architecture against these criteria by both manual and tool-supported methods. The phased approach described in this paper provides a structured analysis of an existing product line architecture using (1) formal specication of the high-level architecture, (2) manual analysis of scenarios to exercise the architecture's support for required variabilities, and (3) model checking of critical behaviors at the architectural level that are required for all systems in the product line. Results of an application to a software product line of spaceborne telescopes are used to explain and evaluate t...

In software organizations there is a very real possibility that a commitment to existing assets will require migration of legacy software towards new environments that use modern technology. One technique that has been suggested for facilitating the migration of existing legacy assets to new platforms is via the use of the adapter design pattern, also known as component wrapping. In this paper, we describe an approach for facilitating the integration of legacy software into new applications using component wrapping. That is, we demonstrate the use of a software architecture description language as a means for specifying various properties that can be used to assist in the construction of wrappers. In addition, we show how these wrapped components can be used within a distributed object infrastructure as services that are dynamically integrated at runtime. 1 Introduction A software product line is a collection of systems that share a managed set of properties that are derived from a co...

Abstract. Home service robots have a wide range of potential applications, such as home security, patient caring, cleaning, etc. The services provided by the robots in each application area are being defined as markets are formed and, therefore, they change constantly. Thus, robot applications need to evolve both quickly and flexibly adopting frequently changing requirements. This makes software product line framework ideal for the domain of home service robots. Unfortunately, however, robot manufacturers often focus on developing technical components (e.g., vision recognizer and speech processor) and then attempt to develop robots by integrating these components in an ad-hoc way. This practice produces robot applications that are hard to re-use and evolve when requirements change. We believe that re-engineering legacy robot applications into product line assets can significantly enhance reusability and evolvability. In this paper, we present our experience of re-engineering legacy home service robot applications into product line assets through feature modeling and analysis. First, through reverse engineering, we recovered architectures and components of the legacy applications. Second, based on the recovered information and domain knowledge, we reconstructed a feature model for the legacy applications. Anticipating changes in business opportunities or technologies, we restructured and refined the feature model to produce a feature model for the product line. Finally, based on the refined feature model and engineering principles we adopted for asset development, we designed a new architecture and components for robot applications. 1

Product families promote reuse of software artifacts such as architectures, designs and implementations. Product family architectures are difficult to create due to the need to support variations. Traditional approaches emphasize the identification and description of generic components, which makes it difficult to support variations among products. This paper presents an approach to modeling family architectures using generic software connectors that provide bounded ambiguity and support flexible product families. The paper also proposes an approach for transforming a family architecture to a product design through a four-way refinement and evolution process.

Building component-based distributed applications is a complex task involving a set of cooperating actors like architects, developers, transactions or persistency specialists. For more than ten years, the Object Management Group (OMG) defines open standards to build interoperable distributed applications. First, the Common Object Request Broker Architecture (CORBA) introduced interoperability between heterogeneous distributed objects: An object oriented middleware. Now, the Model Driven Architecture (MDA) introduces interoperability between heterogeneous models: A model oriented middleware. In this context, we advocate the separation of concerns in order to structure the modeling and meta modeling of enterprise distributed component architectures. In the meantime, design related knowledge is most often lost at runtime. Nevertheless, this knowledge could be important to reify architectures of applications at runtime and to support their administration and reconfiguration. Thus, we intend to support separation of concerns from design to runtime of applications, using a meta data repository centric approach. This paper discusses our proposal, CODeX, to structure the definition of meta models in order to offer dedicated points of view of a model to each of the actors of the software engineering process, from architects to application administrators.