Architectural Transformations Vincenzo Ambriola Dipartamento di Informatica Università di Pisa Pisa, Italy [email protected] Alina Kmiecik Instytut Informatyki Politechnika Łódzka Łódź, Poland [email protected] ABSTRACT The first draft of a software architecture almost never constitutes the final picture of the system to be developed. In most cases it misses some of required properties and needs to be improved or even completely rebuilt. The software architect applies architec-tural transformations in order to “repair” the system structure. In this paper we present our approach to software architecture and architectural transformations. We also discuss three related issues: ADLs, architectural styles and non-functional requirements. Some arguments for architectural change automation are also given. 1. INTRODUCTION The software development process can be described as a set of transformations that convert less specified documents and dia-grams into more formal and detailed ones. Architectural transfor-mations require special attention, because of their crucial impact on the project success. There are several arguments that support this statement. Firstly, architectural transformations change the software structure and directly influence system properties like quality and functionality. Secondly, they construct the software architecture, which is the input of the next development stage. Lastly, because of their influence on software quality, they can provide good mechanisms for early-stage software quality man-agement. The idea of moving the control of the system quality to the stage of architectural transformations is very promising since it can decrease software production costs and speed up time-to-market. On the other hand, it enhances the role of the software architect making him/her responsible not only for functional de-composition, but also for non-functional requirements fulfillment. This paper is organized as follows: Section 2 describes software architecture with respect to UML diagrams and abstraction levels; Section 3 introduces architectural transformations; Section 4 discusses transformations that can be applied for architectural change. Section 5 discusses ADLs, non-functional requirements, and architectural styles. Section 6 is related to the automation of architectural transformations. Related works are discussed in Section 7 and Section 8 concludes the paper. Software architecture is usually defined as “a structure or struc-tures of the system which comprise software components, the externally visible properties of those components and relationships among them” [3]. This description suggests that only component diagrams belong to software architecture. However, no diagram exists without relations to other models, especially from an object-oriented and a UML perspective. Components are grouped into nodes of the deployment diagram that defines the system topol-ogy. They are also related to the elements of the class diagram that represents their internal structure (architecture). In turn, classes consist of methods and attributes, and methods invoke each other and influence attributes values as well. When we put all these elements together, we obtain a graph-like structure with three abstraction levels (deployment, component, and class level) linked by relationships among their elements. If we add some behavior knowledge to this graph, we have a software architecture descrip-tion. Following the UML notation [4] and the architecture description proposed by Jacobson, Booch, and Rumbaugh [12], we use six elements to build a software structure: nodes, components, inter-faces, classes, methods, and attributes. Elements have a name, a stereotype; each of them can be associated to other elements. Relationships between elements are the most complex issue. The main reason lies in the multiplicity of available connections. Moreover, some relationships are available only between elements of the same type, whereas others can connect elements of different abstraction levels. In architectural diagrams one can also find few highly specialized relationships that can be used only for specified elements. Realization relationship is an example; it can be used only between component and interface or class and interface in a way that class/component is a given interface realization. 3. ARCHITECTURAL TRANSFORMATIONS A software architecture is developed during the early development phases, when user requirements are translated into the first, usu-ally unsatisfactory, draft of the system structure. This process is creative and somehow reminds the art of painting. We start with an idea, few quickly prepared sketches and some indications about the possible evolution of a given theme. However, these careless drafts, painted usually one over the other, do not constitute the 2. SOFTWARE ARCHITECTUREPermission to make digital orhard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.SEKE '02, July 15-19, 2002, Ischia, Italy.Copyright 2002 ACM 1-58113-556-4/02/0700...$5.00.- SEKE '02 - 275 -final product. They need to be carefully repainted and improved in order to become a masterpiece. The same happens with software architecture. The first draft of a software architecture rarely satisfies all the properties required to the developed system. Sometimes an ele-ment is missing or needs to be completed, sometimes the whole structure is too complex and requires some simplification for proper analysis and understanding. Sometimes it does not provide the needed software functionality and must be entirely rebuilt. The software architect uses architectural transformations to repair the software “picture”. There are two general groups of transformations: for change and for explanatory purposes. The former are used to modify and improve the software architecture, whereas the latter are applied for architecture analysis and understanding. Transformations for understanding and diagnosis do not change the software structure permanently. They are applied only during some analysis execu-tion or viewpoint usage. Fahmy and Holt describe this group of