Abstract: Complex software systems require expressive notations for representing their software architectures. Two competing paths have emerged. One is to use a specialized notation for architecture - or architecture description language (ADL). The other is to adapt a general-purpose modeling notation, such as UML. The latter has a number of benefits, including familiarity to developers, close mapping to implementations, and commercial tool support. However, it remains an open question as to how best to use object-oriented notations for architectural description, and, indeed, whether they are sufficiently expressive, as currently defined. In this paper we take a systematic look at these questions, examining the space of possible mappings from ADLs into object notations. Specifically, we describe (a) the principle strategies for representing architectural structure in UML; (b) the benefits and limitations of each strategy; and (c) aspects of architectural description that are intrinsically difficult to model in UML using the strategies.

Abstract: Complex software systems require expressive notations for representing their software architectures. Two competing paths have emerged, one using a specialized notation for architecture - or architecture description language (ADL), the other using notations applied generally throughout design, such as UML. The latter has a number of benefits, including familiarity to developers, close mappings to implementations, and commercial tool support. However, it remains an open question how best to use object-oriented notations for architectural description and whether they are sufficiently expressive as currently defined. In this paper, we present a mapping between Acme?a notation designed for expressing architectures - and the UML Real-Time Profile - an object-oriented design notation. Specifically, we describe (a) how to map Acme descriptions to descriptions in the UML Real-Time Profile, and (b)the places where this mapping breaks down.

Abstract: Complex software systems require expressive notations for representing their software architectures. Two competing paths have emerged. One is to use a specialized notation for architecture -- or architecture description language (ADL). The other is to adapt a general-purpose modeling notation, such as UML. The latter has a number of benefits including familiarity to developers, close mapping to implementations, and commercial tool support. However, it remains an open question as to how best to use object-oriented notations for architectural description, and, indeed, whether they are sufficiently expressive, as currently defined. In this paper we take a systematic look at these questions, examining the space of possible mappings from ADLs into object notations. Specifically, we describe (a) the principle strategies for representing architectural structure in UML; (b) the benefits and limitations of each strategy; and (c) aspects of architectural description that are intrinsically difficult to model in UML using the strategies.

Abstract: The widespread presence of the Unified Modeling Language (UML) has led practitioners to try to apply it when documenting software architectures. While early versions of UML have been adequate for documenting many kinds of architectural views, they have fallen somewhat short, particularly for documenting component and connector views. UML 2. 0 has added a number of new constructs and modified some existing ones to address these problems. In this report, we explore how changes in this version affect UML’s suitability as a notation for docu- menting component and connector views.