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: Software system builders are increasingly recognizing the importance of exploiting design knowledge in the engineering of new systems. One way to do this is to define an architectural style for a collection of related systems. The style determines a coherent vocabulary of system design elements and rules for their composition. By structuring the design space for a family of related systems a style can, in principle, drastically simplify the process of building a system, reduce costs of implementation through reusable infrastructure, and improve system integrity through style-specific analyses and checks. Like architectural style, object-oriented design patterns attempt to capture and exploit design knowledge to ease the process of designing software systems and reusing proven designs. There are, however, significant differences in the roles and capabilities of architectural styles and object-oriented design patterns, as there are between architectural design and object-oriented design. In this paper we illustrate the relationship between software architecture and object-oriented design, as well as the relationship between architectural styles and design patterns. We begin by defining our terms and then proceed to compare and contrast the various approaches with examples.

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: With an eye toward sharing event-based behavior in architectural descriptions, a number of researchers at ISI (Wile), CMU (Garlan & Kompanek) and Stanford (Luckham & Kenney) started a dialogue to converge on an event standard. The results are summarized in this working report. The main idea of the proposal is to adopt an Acme-like approach: a simple base-level event representation would capture the minimal, core aspects of events. Additionally, other more tool-specific information could be added to those event representations in the form of annotations. In this report we outline the proposed scheme. We begin by enumerating some of the requirements that we identified early in our discussions. Next we discuss the basic ontology of events, activities and their types. Then we introduce two proposals for concrete representation: one based on XML, the other on an Acme-like syntax. Finally, we illustrate how collections of events derived from existing ADLs can be mapped into the activity language.