| A. van der Hoek, M. Mikic-Rakic, R. Roshandel, and N. Medvidovic. Taming architectural evolution. In Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering, pages 1--10. ACM Press, 2001. |
....two levels. Rather, evolution is supported in a unified way in the underlying architectural language and the respective support tools. In [30, 31] it is argued that software architecture and SCM are highly related, and the advantages of a single, unified system model are stressed. The Mae system [32] was developed along these lines. To cope with architectural evolution, Mae provides multiple concepts such as (sequences of) revisions, variants, optionality, and inheritance. Version selection is supported at the architectural level. Several opportunities of this integrated approach are ....
van der Hoek, A., Mikic-Rakic, M., Roshandel, R., Medvidovic, N.: Taming architectural evolution. In: Proceedings of the Joint 8th European Software Engineering Conference and the 9th ACM SIGSOFT Symposium on Fundamentals of Software Engineering. ACM Software Engineering Notes 26-5, Vienna, Austria, ACM Press (2001) 1--10
.... the architectural language Rapide [31] Alexander L Wolf at University of Colorado at Boulder and Andr van der Hoek at University of California, Irvine, has conducted research in relating software architecture to other disciplines, such as versioning, configuration management and product families [37 42]. In Sweden, we can mention Blekinge Institute of Technology (Blekinge tekniska hgskola) where Jan Bosch until recently led the research; he is the author of a book on software architecture with focus on product line approaches [6] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, ....
....different types of causes of changes: requirements are modified or added, errors need correction, the quality needs to be improved, technology changes, other systems in the environment change, parts of it is to be reused etc. The question of change can be viewed either on the architectural level [37,39 42] or from a componentbased point of view [30] Part of my research will be to combine these points of view. There is a trend that more and more of a software system should be variable, so that it is a system administrator who should carry out needed changes rather than a programmer. It is further ....
[Article contains additional citation context not shown here]
van der Hoek A., Mikic-Rakic M., Roshandel R., and Medvidovic N., "Taming Architectural Evolution", In Proceedings of The Sixth European Software Engineering Conference (ESEC) and the Ninth ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-9), 2001.
No context found.
A. van der Hoek, et al. Taming Architectural Evolution. Proceedings of the Sixth European Software Engineering Conference and the Ninth ACM SIGSOFT Symposium on the Foundations of Software Engineering, 2001: p. 110.
....a product line architecture. After many changes, the overall structure generally has disintegrated and the clean design picture that once existed has deteriorated. In addition to exploring how design critics [11] and analysis techniques help in maintaining a consistent product line architecture [31], we are investigating how metrics that calculate the utilization of the functionalities provided by components in a product line architecture [30] can provide an architect with graphical visualizations that highlight potential structural problems in the product line architecture. Typically, these ....
A. van der Hoek, et al. Taming Architectural Evolution. Proceedings of the Sixth European Software Engineering Conference and the Ninth ACM SIGSOFT Symposium on the Foundations of Software Engineering, 2001: p. 1-10.
.... defines the structure of a single product, a product line architecture (PLA) defines the common architecture for a set of related products [5] A PLA explicitly specifies: 1) elements that are present in all products, 2) elements that are optional, and (3) variation points among products [31, 32, 33]. Particular product instances are selected by choosing the desired optional components and selecting one element per variation point. Perry [27] outlined the space of possibilities for modeling PLAs and observed that a PLA modeling technique must be both generic enough to encompass all members of ....
.... support for modeling behaviors and constraints on the properties of components and connectors [24] which can be leveraged to ensure the consistency of an architecture (e.g. by establishing conformance between the services of interacting components) Unfortunately, with the exception of Mae [32], Koala [33] and GenVoca [9] few existing ADLs explicitly support the specification of all aspects of PLAs. 3. Service utilization metrics This section presents the metrics we have defined to assess the structural quality of a PLA. The metrics are based upon the concept of service utilization. ....
van der Hoek, A., et al. Taming Architectural Evolution. in Sixth European Software Engineering Conference (ESEC) and the Ninth ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-9). 2001. Vienna, Austria: p. 1-10.
.... disciplines of SA and configuration management, and focus on a distinction between mandatory elements (which are present in the architecture of each and every product) and variation points (which define the dimensions along which the architectures of the individual products di#er from each other) [7,14,11,12]. Variation points typically are specified either as optional elements, which may or may not be present in a product, and variant elements, which must be present in a product architecture but can be chosen to be one of a number of di#erent alternatives (i.e. a component that represents a GUI ....
....[17] which can be leveraged to ensure the consistency of an architecture (e.g. by establishing conformance between the services of interacting components) These approaches have been extended to provide mechanisms to capture product line architectures. xADL 2. 0 [8] Koala [20] and Mae [12] are examples of such product line architecture description languages. Figure 1 shows a simple example product line architecture consisting of four components (connectors are omitted for simplicity) The component foo is a standard part of every architecture, as is the component bar. The ....
van der Hoek, A., Mikic-Rakic, M., Roshandel, R., and N. Medvidovic. Taming Architectural Evolution. In Proc. of the Sixth European Software Engineering Conference and the Ninth ACM SIGSOFT Symposium on the Foundations of Software Engineering, 2001, pp. 1-10.
....to Java classes. 3.2.3 Modeling Architectural Evolution and Product Line Architectures Modeling architectural evolution and product lines are emerging, but important research areas. Initial work in both these areas has focused on applying configuration management concepts to architectures [17][18]. Thus, from a modeling perspective, both areas can be addressed by adding configuration management concepts to an ADL. The three most important aspects of modeling the evolution of architectures and product lines are versions, options, and variants. Versions record information about the ....
....of an ADL now used in architectural modeling experiments for spacecraft systems demonstrating the adaptability of the infrastructure to new architectural domains with unique modeling requirements. Third, we show how our infrastructure supported the development of ADLs for Koala [32] and Mae [18], two representations used to model product line architectures demonstrating the extensibility of the XML schemas and tools in our infrastructure. These three Figure 3. ArchEdit screenshot. Tree based representation of ADL document. Editors for element and attribute values. ....
[Article contains additional citation context not shown here]
A. van der Hoek, M. Mikic-Rakic, R. Roshandel, and N. Medvidovic. Taming Architectural Evolution. In Proceedings of the Ninth ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-9), Vienna, Austria, September 2001.
....same product) and propagating these architectural changes to yet another, third (version of a) product. The first problem has already been addressed through the advent of architectural description languages that incorporate facilities for capturing different versions of a product line architecture [10,17]. The second problem, however, has not been addressed as of yet. Consider a situation in which a number of architects maintain a product line architecture. The product line architecture is defined as a set of core components and connectors that are shared among all of the products, and a set of ....
van der Hoek, A., Mikic-Rakic, M., Roshandel, R., and Medvidovic, N. Taming Architectural Evolution. In Proceedings of the Sixth European Software Engineering Conference (ESEC) and the Ninth ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-9). p. 1-10, Vienna, Austria, September 10-14, 2001.
....To avoid this kind of problem in the domain of product family architectures, we offer the following observations. 1. We can expect a significant amount of commonality among representations for product family architectures, as evidenced by the set of features shared by Koala [11] and Mae [10], two of the first such representations. 2. Representations for product family architectures can be viewed as representations for software architectures that are extended with some features designed specifically for capturing product family aspects of those architectures. 3. XML [2] schemas ....
....a common, extensible representation onto which new modeling constructs can be efficiently added. This greatly reduces the duplication of effort that would result from building an entirely new product family architecture representation from scratch. 2 Existing Representations Koala [11] and Mae [10] are two of the first representations for product family architectures. Both have adopted the philosophy that a product family architecture is considered a normal software architecture that contains several well defined variation points. To capture these variation points, both have created ....
[Article contains additional citation context not shown here]
van der Hoek, A., et al., Taming Architectural Evolution,inProceedings of the Joint 8th European Software Engineering Conference and 9th ACM SIGSOFT International Symposium on the Foundations of Software Engineering. 2001 (to appear).
....component based application families. Various technical challenges exist in this domain, such as the need to represent family members, to express and capture commonality, variability, and incompleteness, as well as to incorporate domain knowledge while populating generic, reference architectures [1]. In addition to technical challenges, organizations face strategic, financial, and human factors challenges that make it difficult to initially adopt product line families within an organization. However, if properly deployed, large scale reuse results in numerous rewards including reduced costs ....
A. van der Hoek, M. Rakic, R. Roshandel, and N. Medvidovic. Taming Architectural Evolution. ESEC/FSE 2001, Vienna, September 2001.
No context found.
A. van der Hoek, M. Mikic-Rakic, R. Roshandel, and N. Medvidovic. Taming architectural evolution. In Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering, pages 1--10. ACM Press, 2001.
No context found.
A. van der Hoek, M. Mikic-Rakic, R. Roshandel, and N. Medvidovic. Taming architectural evolution. In Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering, pages 1--10. ACM Press, 2001.
No context found.
A. van der Hoek, M. Mikic-Rakic, R. Roshandel, and N. Medvidovic, "Taming architectural evolution," in Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering. ACM Press, 2001, pp. 1--10.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC