Software Architectures Day

sponsored by

Computer Science Group

Mathematics Department
Wesleyan University
Middletown, CT 06459

May 2, 1998

On May 2, 1998, the Computer Science Group organized a one day mini-conference on software architectures that was held in the Woodhead Lounge at Wesleyan University. This page contains information about the speakers and the abstracts of the talks that were presented at the conference.


Opening Remarks

In the last few years, the term "software architecture" has emerged as a general phrase that denotes either an informal high-level description of a software system or an abstract model of the system that conveys both syntactic and semantic information. On the one hand, an informal architectural description might consist of a collection of diagrams and use general terms such as client-server or interface while a formal architectural description might be based on a special macro-level system design methodology [analogous to hardware design with Verilog or VHDL], component engineering [based on COM, CORBA, or JavaBeans], or object-oriented design and programming based on Design Patterns or the Unified Modeling Language.

The lectures will present a variety of views and approaches to the subject of software architectures. Although none of the lectures is specifically designated as "introductory", the opening remarks and lectures should convey a general sense of the scope and intent of the field of software architectures.

Abstracts of Talks

Describing Software Architectures and Software Architectural Styles Top of Page

Stephen B. Seidman

Computer Science Department
Colorado State University

Software architectures are abstract models of software systems that represent the constituent elements of a software system and the interactions among those elements. The wide variety of actual and potential architectures has caused researchers to look at the constraints that govern the way in which an architecture is composed of interacting elements. These constraints, which are often application-dependent, have come to be called software architectural styles. Languages for describing software architectures and architectural styles must be able to represent arbitrary configurations and constraints. They must also be capable of describing the hierarchical structure of software systems and supporting the construction of architectures within a given style.

This talk will discuss how several architectural description languages and formalisms meet these requirements.

Functional Representation and Architecture Description Top of Page

Dean Allemang

Synquiry Technologies

"Functional Representation" is an approach to model-based reasoning based on representing a system in terms of the roles that its components play (their "functions") in its own function. An interesting feature of this style of modeling is that it does not require that a system be modeled at all levels of detail; various levels of abstraction are insulated from one another by the functional descriptions. In formal terms, a system can be described at each level as a justification (or "explanation", in the sense of "explantion-based generalization"), which need not refer to axioms or explanations at other levels.

When applied to software systems, this approach is similar in spirit to approaches that go under the name of "software architecture". One of the tenets of software architecture research is that it is possible to describe a system at a more abstract level than is captured by code - the so-called "architectural level", and that such descriptions can provide useful insight during the software evolution life cycle.

In this talk, I will show this correspondence in detail. In particular, I will present ZD, a formal language for describing functional representations, and ACME, a language for architecture interchange, and a mapping between the two. This allows us to apply the formal verification capabilities of ZD to architectures specified in ACME, and, according to the spirit of ACME, to allow other architecture processing tools to work on functional representations specified in ZD.

All of these components have been demonstrated in working systems; there is a processor for ZD that makes use of the NQTHM logic of Boyer and Moore, which is connected to the AcmeLib API for ACME. Architectures built in AcmeLib may, in turn, be graphically manipulated by AcmeStudio. Future development will involve using provisional ACME architecture diagrams as a mode of output of the results of ZD analyses.

This work has been done as part of DARPA's Evolutionary Design of Complex Software (EDCS) program. Recently, many EDCS researchers have made a commitment to making their systems compatible with ACME. We hope that this will allow for even further shared architecture definition and analysis capabilities.

Software Architecture Views and Slices from Industry Top of Page

Thomas J. Peters

Department of Computer Science and Engineering, U-155
University of Connecticut, Storrs, CT 06269-3155

Industrial software systems provide experimental proving grounds for software architecture theories. These systems can be seen from multiple views, dependent upon end-user interests. Considering computer-aided design and manufacturing software as an illustrative example, differing view are directed towards design, manufacturing, or analysis.

Across each such view, these systems can be sliced relative to differing needs for graphics, geometry, and topology. These slices will be presented, hierarchically, relative to individual algorithms, integrated systems and heterogeneous, distributed applications, where STEP is an international standard directed towards seamless inter-communication. This work is being pursued in collaboration with The Boeing Corporation, Pratt and Whitney, STEP Tools, Inc, PDES, Inc. Relevant industrial examples will be discussed.

Your Middleware Is Showing:
The Seamy Side of Component-Based Software Development
Top of Page

Jack C. Wileden

Convergent Computing Systems Laboratory
Computer Science Department
University of Massachusetts Amherst

Component-based software development (CBSD) has the potential to become an extremely important technology. At present, however, strong industrial forces, such as OMG, ODMG and Microsoft, are advocating CBSD approaches in which "middleware" plays a prominent role. In our view, these approaches make their middleware embarrassingly visible to software users. This inevitably leads to loss of "seamlessness", a software system property that we consider essential for practical, as well as esthetic, reasons.

In this talk, we first probe some analogies that often appear to serve as conceptual foundations for the currently predominant approaches to CBSD and software architecture. We then explain why we believe that middleware should appropriately be considered the "underwear" of CBSD. Finally, we outline our ongoing work on conceptual, formal and practical foundations for CBSD.

Dynamic Domain Architectures Top of Page

Chris Dellarocas

Sloan School of Management
Massachusetts Institute of Technology

Mission-critical software systems must frequently continue to operate in the face of a changing and even hostile environment. In order to do so, they must be able to adapt to change in the environment - to recognize when changing external circumstances can be better handled by alternative software modules, and to be able to dynamically swap these modules into place. However, placing a feedback loop around a field application requires functionality not currently found in software systems, including tools to expose the structure and function of the application's components, monitoring facilities, diagnosis and reasoning tools, replanning systems and repositories of software components annotated with purpose and constraint information. In order to provide these critical elements of functionality, we propose the Dynamic Domain Architecture, which combines elements of dynamic object-oriented programming languages with classical, or "static" domain architectures. This talk will present the basic concepts of Dynamic Domain Architectures and will describe a new project that we are starting at MIT around these ideas.

Page last modified on November 7, 1998
Report problems to mrice@wesleyan.eduTop of Page