There is a real need for clear and sound design specifications of distributed systems at the architectural level. This is the level of the design which deals with the high-level organisation of computational elements and the interactions between those elements. The paper presents the Darwin notation for specifying this high-level organisation. Darwin is in essence a declarative binding language which can be used to define hierarchic compositions of interconnected components. Distribution is dealt with orthogonally to system structuring. The language supports the specification of both static structures and dynamic structures which may evolve during execution. The central abstractions managed by Darwin are components and services. Services are the means by which components interact. In addition to its use in specifying the architecture of a distributed system, Darwin has an operational semantics for the elaboration of specifications such that they may be used at runtime to di...

As the design of software architectures emerges as a discipline within software engineering, it will become increasingly important to support architectural description and analysis with tools and environments. In this paper we describe a system for developing architectural design environments that exploit architectural styles to guide software architects in producing specific systems. The primary contributions of this research are: (a) a generic object model for representing architectural designs; (b) the characterization of architectural styles as specializations of this object model; and (c) a toolkit for creating an open architectural design environment from a description of a specific architectural style. We use our experience in implementing these concepts to illustrate how style-oriented architectural design raises new challenges for software support environments.

Although numerous mechanisms for promoting software reuse have been proposed and implemented over the years, most have focused on the reuse of implementation code. There is much conjecture and some empirical evidence, however, that the most effective forms of reuse are generally found at more abstract levels of software design. In this paper we discuss software reuse at the architectural level of design. Specifically, we argue that the concept of “architectural style ” is useful for supporting the classification, storage, and retrieval of reusable architectural design elements. We briefly describe the Aesop system’s Software Shelf, a tool that assists designers in selecting appropriate design elements and patterns based on stylistic

this document are those of the author and should not be interpreted as representative of the official policies, either expressed or implied, of the ONR or the U.S. Government. vii Contents Preface iv Acknowledgements vi 1 Introduction 1

A critical issue in the design of a professional software engineeringdegree program is the way in which formal methods are integrated into the curriculum. The approach taken by most programs is to teach formal techniques for software development in a separate course on formal methods. In this paper we detail some of the problems with that approach and describe an alternative in which formal methods are integrated across the curriculum. We illustrate the strengths and weaknesses of this alternative in terms of our experience of using it in the Master of Software Engineering Program at Carnegie Mellon University. 1

: Recent research in software architecture and design patterns has focussed on identifying existing large-scale chunks of design, with the intent of communicating these designs so that they may be reused. However, these design patterns, idioms, and styles are typically given to designers whole and the rationale for their internal structure is seldom made clear. Because of this, the relationship between these operations and non-functional qualities is difficult to reason about. This paper presents a theory of more primitive design operations (called unit operations) that have been derived through a study of the software design literature and interviews with expert software designers. Unit operations are common structure-modifying operations that designers regularly employ, things like: abstraction, resource sharing, is-a decomposition, etc. The relationship between unit operations and non-functional qualities is determined through an empirical study that surveys expert industrial design...

Machine. 8 The software architecture research community is realizing that these notations overlap considerably, particularly with respect to the structural aspects of a software architecture specification. ACME is an emerging generic architecture description language that is designed to facilitate the interchange of architectural designs between different ADLs and toolsets. 9 The notations used to express the architectural diagrams and style specifications in this article's examples reflect terminology and notations commonly found in these architecture description languages. REFERENCES 1. M. Shaw et al., "Abstractions for Software Architecture and Tools to Support Them," IEEE Trans. Software Eng., Apr. 1995, pp. 314-335. 2. D.C. Luckham et al., "Specification and Analysis of System Architecture using Rapide," IEEE Trans. Software Eng., Apr. 1995, pp. 336-355. 3. R. Allen and D. Garlan, "Formalizing Architectural Connection," Proc. 16th Int'l Conf. Software Eng., IEEE Computer Soc...

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....

technique. Section 7.7 describes software architectures, which represent an independent research area. For most of the techniques (where appropriate), a list of enabling methodologies and technologies is presented. They include UML for OOA and OOD, CORBA and DCOM for OO frameworks, and Java Beans and ActiveX for component based development. 7.2. Object Oriented Techniques Object oriented techniques (OOT) provide methods and mechanisms for structuring models and program code to correspond to the objects (concepts) found in the problem domain. For example, in the business application domain, objects can describe a customer or a bank account, by means of attributes (e.g. the account number), behaviours (e.g. issuing the account balance), and relationships with other objects (e.g. the account belongs to a customer). Compared withtraditional procedural programming, OOT has the advantage of allowing the development of highly modular systems. This is accomplished by means of a set of pr

A conceptual approach An introduction to corporate architecture modeling