Managing Software Architectural Evolution at Multiple Levels of Abstraction Tien N. Nguyen Electrical and Computer Engineering Department Iowa State University, Ames, IA 50011, USA Email: tien@iastate.edu Abstract— Software development is a dynamic process where engineers constantly modify and reﬁne systems. As a con- sequence, system architecture evolves over time. Software architectural evolution has been managed at different ab- straction levels: the meta level, the architectural level, the application level, and the implementation level. However, management supports for architectural evolution are lim- ited to evolution mechanisms in architectural description languages such as subtyping, inheritance, interface, and genericity. This paper presents a model-oriented version and conﬁguration control approach to managing the evolution of architectural entities and relationships among them in conﬁgurations at different levels of abstraction. This paper also illustrates our approach in building an ar- chitectural conﬁguration management system, MolhadoArch, that is capable of managing conﬁgurations and versions of software architecture across multiple levels of abstraction in a uniform and tightly connected manner. In MolhadoArch, consistent conﬁgurations are maintained not only among source code but also with the high-level software archi- tecture. MolhadoArch supports the management of both planned and unplanned evolution of software architecture. We have conducted an experimental study to show that MolhadoArch can handle large and real-world systems. By evaluation, we learned that the beneﬁts outweigh the extra space needed to represent architectural entities. I. I NTRODUCTION Software architecture [1] deﬁnes the overall logical structure of high-level design of a software system in terms of components, interactions, and relationships among them. Software architecture provides conceptual integrity for a system and the mental framework that engineers use to design, discuss, document, and reuse its elements. It can also be used for generating partial or full implementations and for structuring the repository of software artifacts. The ability to manage architectural evolution is cru- cial to a successful software development and mainte- nance process. Software architectural evolution has been managed at different abstraction levels: the meta level, the architectural level, the application level such as in the Software Architecture EVolution Model (SAEV) [2]. Unlike source code, for which the use of a software conﬁguration management (SCM) system is the predom- inant approach to capturing evolution, the management This paper is based on “Multi-level Architectural Evolution Manage- ment” by Tien N. Nguyen, which appeared in the Proceedings of the 40th IEEE Hawaii International Conference on System Sciences, HICSS 2007, Big Island, Hawaii, USA, January 2007. c  2007 IEEE. supports for architectural evolution are still limited to evolution mechanisms in architectural description lan- guages (ADLs) such as subtyping, inheritance, interface, and genericity [3]. In addition, architectural SCM systems treat a software architecture as a set of text ﬁles in a ﬁle system, and consistent conﬁgurations are deﬁned implicitly as sets of ﬁle versions with a certain label or tag as in CVS [4] or Subversion [5]. Existing architectural SCM systems focus only on the application level and could not manage the evolution of architectural entities that belongs to other levels of abstraction as well as the logical relations among them. A. Motivation Example Let us consider a client-server system (used as an example in [2]). According to SAEV [2], at the high- est level of abstraction (i.e. the meta level), all ADL architectural entities are deﬁned such as conﬁguration, component, connector, and interface. The architectural level is the level of the description of any architecture using one or more architectural entities deﬁned in the meta level. Figure 1 presents an architecture with a conﬁguration C and three component types: SERVER, CLIENT, DATABASE, and two connector types K1 and K2. Application level is the level of description of any application in accordance with its architecture. For ex- ample, in Figure 1, an application can made up of: one instance of the conﬁguration type C, two instances of the component CLIENT (c1,c2), one instance of the compo- nent DATABASE(Oracle), one instance of the component SERVER (s1), and three instances of connectors (k1,k2, and k3). The dotted arrows represent the architectural relationships such as “instance of” among entities. In current practice, a system’s architecture described in some graphical notation or in some ADL is often versioned as simple text ﬁles, whose logical contents are irrelevant to SCM systems. Those systems are able to manage versions of an architecture description ﬁle for a software system. However, the architectural relationships among architectural entities, and between those entities and source code that realizes them are hardly managed. These logical relationships are very crucial since they help developers to have good understanding of the architectural design and implementation of a system. When designs or implementation source code are changed, those mappings 60 JOURNAL OF SOFTWARE, VOL. 3, NO. 3, MARCH 2008 © 2008 ACADEMY PUBLISHER