David Stotts

Elemental design patterns: a formal semantics for composition of OO software architecture

Design patterns are an important concept in the field of software engineering, providing a language and application independent method for expressing and conveying lessons learned by experienced designers. There is a large gap, however, between the aesthetic and elegance of the patterns as intended and the reality of working with an ultimately mathematically expressible system such as code. We describe a step towards meaningful formal analysis of code within the language of patterns, and discuss potential uses. The major contributions include: a compendium of elemental design patterns (EDPs), a layer of seemingly simplistic relationships between objects that, on closer inspection, provide a critical link between the world of formal analysis and the realm of pattern design and implementation without reducing the patterns to merely syntactic constructs; an extension to the /spl sigmav/-calculus, termed /spl rho/-calculus, a formal notation for expressing relationships between the elements of object oriented languages, and its use in expressing the EDPs directly. We discuss their use in composition and decomposition of existing patterns, identification of pattern use in existing code to aid comprehension, and future research directions, such as support for refactoring of designs, interaction with traditional code analysis systems, and the education of students of software architecture.

Collaborative hyperdocuments and prototyping groupware

Abstract In this paper we informally explain a new Trellis model that incorporates colored tokens into the previously-described timed-Petri-net-based definition. We give examples of using Trellis to define protocols for Computer Supported Cooperative Work (CSCW). We then explain an interesting analog to procedure call we have developed for subdocument invocation in collaborative hyper-documents. Trellis prototype implementations are based around a client—server architecture and interpret their specifications. Consequently they provide an environment for the rapid prototyping and incremental development of multi-user distributed protocols, and for groupware based on such protocols.

Extending SPQR to Architectural Analysis by Semi-Automated Training

We present an overview of SPQR, the System for Pattern Query and Recognition, a toolkit that detects instances of known design patterns directly from object-oriented source code in an automated and flexible manner. Based on our previous work in ñ-calculus and Pattern/Object Markup Language (POML), SPQR is retargetable to most OO languages, and system design notations. We discuss how this approach may be applied to architectural concerns by leveraging SPQR’s training mode. The System for Pattern Query and Recognition, or SPQR, is an automated framework to analyze software systems in the small or the large, and detect instances of known programming concepts in a flexible yet formal manner. These concepts, combined in well-defined ways to form abstractions, as found in the design patterns literature, then lead to the possible automated detection of design patterns directly from source code and other design artifacts. Our previous publications [7, 8] have described SPQR in detail, as well as its successful application to a number of software systems. Here we describe SPQR briefly, and how these principles can be extended to architectural analysis.

Early experience with a repository for patterned injury data

We have constructed a proof-of-principle system called the repository for patterned injury data (RPID) for supporting collaborative forensic medicine. The early RPID prototype is built on ABC/DGS, a graph-server and collaborative hypermedia system built in the UNC Collaboratory. ABC provides collaboration services for work groups via shared artifacts, giving common views of the information and allowing conferencing over the data. A second prototype is underway that has more flexible control of multiperson creation of, and access to, the shared patient data and pathology artifacts. We conclude by describing a planned third prototype, to be built not on ABC, but on a modification of the WWW httpd distribution data server.