CHARMY: A Framework for Designing and Verifying Architectural Specifications Patrizio Pelliccione, Paola Inverardi, and Henry Muccini Abstract—Introduced in the early stages of software development, the CHARMY framework assists the software architect in making and evaluating architectural choices. Rarely, the software architecture of a system can be established once and forever. Most likely poorly defined and understood architectural constraints and requirements force the software architect to accept ambiguities and move forward to the construction of a suboptimal software architecture. CHARMY aims to provide an easy and practical tool for supporting the iterative modeling and evaluation of software architectures. From an UML-based architectural design, an executable prototype is automatically created. CHARMY simulation and model checking features help in understanding the functioning of the system and discovering potential inconsistencies of the design. When a satisfactory and stable software architecture is reached, Java code conforming to structural software architecture constraints is automatically generated through suitable transformations. The overall approach is tool supported. Index Terms—Software architectures, model checking. Ç 1 INTRODUCTION S OFTWARE Architectures (SAs) emerged in the ‘90 to structure complex software systems while providing a high-level system description. Nowadays, SA is an auton- omous discipline that focuses on the overall organization of a large software system by using abstractions to express the logical structure of complex distributed systems. SA specification emphasizes the system structure (i.e., the architecture topology) in terms of architectural components and connectors and the system behavior (i.e., the architecture dynamics) by identifying how components and connectors interact [1], [35]. A general workflow that can be found in practice [20] is represented in Fig. 1 and shows that typically, the software architecture of a system cannot be established once forever. In fact, when software architects start defining the software architecture of a system, ideas, needs, requirements, and challenges of the system coming from different stakeholders (such as end users, customers, developers, sales and field support, maintainers, develop- ment managers, and system administrators) constitute the nebulous dark set of architectural constraints. Significant decisions at the software architecture level have to be made and they encompass the organization of a software system, the selection of the structural elements, their interfaces, their behavior, and the composition of these elements into progressively larger subsystems. Often, all these aspects are not well defined and the architect must move forward making suboptimal solutions in a partly dark world while accepting unavoidable ambiguities. Decisions are made by analyzing and studying an architecture prototype that in practical contexts is often manually sketched by the architect starting from the nebulous dark set of constraints, requirements, and ideas. This situation calls for architectur- al design iterations. However, SAs are typically used as a high-level design blueprint of the system to be used during the system development and later on for maintenance and reuse (in order to capture and model architectural design alterna- tives). Therefore, assuring as early as possible, the correct- ness of an SA is a fundamental task in order to produce quality software. Unfortunately, the analysis techniques and tools proposed till now mostly rely on formal languages (e.g., [1], [37]) in which software architectures are modeled by following a heavy and expensive process. Therefore, it is difficult to use these techniques in an iterative and agile workflow. This slows down the transi- tion of SA verification approaches and tools from “research theory” to “industry practice.” In this setting, the challenge is to automatize the activities of software architectures synthesis, software architecture prototype production, and evaluation; these activities require a tool that, starting from a software architecture, performs the generation of an executable prototype. More- over, the input to this tool should be expressed on one hand in an easy to learn language, and on the other hand in a language rigorous and amenable for simulation and verification. In addition, the use of this tool should be agile and practical so that it is possible to reach rapidly the point from which the tool becomes concretely useful. The CHARMY framework, introduced in [28], intends to be a step in this direction by providing an automated, easy to use tool for the model-based formal design, and validation of SAs. The notation used for modeling the software architecture is based on UML; even if UML is not the most suitable notation for modeling software architectures, it is widely adopted in industries. However, the CHARMY IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 3, MAY/JUNE 2009 325 . The authors are with the Dipartimento di Informatica, Universita` dell’Aquila, Via Vetoio, 67010 L’Aquila, Italy. E-mail: {pellicci, inverard, muccini}@di.univaq.it. Manuscript received 21 July 2008; accepted 16 Sept. 2008; published online 2 Dec. 2008. Recommended for acceptance by R. Cleaveland. For information on obtaining reprints of this article, please send e-mail to: tse@computer.org, and reference IEEECS Log Number TSE-2008-07-0228. Digital Object Identifier no. 10.1109/TSE.2008.104. 0098-5589/09/$25.00 ß 2009 IEEE Published by the IEEE Computer Society Authorized licensed use limited to: University of Virginia Libraries. Downloaded on June 3, 2009 at 14:53 from IEEE Xplore. Restrictions apply.