The book is an introduction to the idea of design patterns in software engineering, and a catalog of twenty-three common patterns. The nice thing is, most experienced OOP designers will find out they've known about patterns all along. It's just that they've never considered them as such, or tried to centralize the idea behind a given pattern so that it will be easily reusable.

Design Patterns: Elements of Reusable Object-Oriented Software

As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system -- the software architecture -- presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms. In this paper we provide an introduction to the emerging field of software architecture. We begin by considering a number of common architectural styles upon which many systems are currently based and show how different styles can be combined in a single design. Then we present six case studies to illustrate how architectural representations can improve our understanding of complex software systems. Finally, we survey some of the outstanding problems in the field, and consider a few of the promising research directions.

/pdf/an-introduction-to-software-architecture-393c7s2he2.pdf

An Introduction to Software Architecture

As software systems become more complex, the overall system structure—or software architecture—becomes a central design problem. An important step toward an engineering discipline of software is a formal basis for describing and analyzing these designs. In the article we present a formal approach to one aspect of architectural design: the interactions among components. The key idea is to define architectural connectors as explicit semantic entities. These are specified as a collection of protocols that characterize each of the participant roles in an interaction and how these roles interact. We illustrate how this scheme can be used to define a variety of common architectural connectors. We further provide a formal semantics and show how this leads to a system in which architectural compatibility can be checked in a way analogous to type-checking in programming languages.

/pdf/a-formal-basis-for-architectural-connection-5cve12uupd.pdf

A formal basis for architectural connection

Systematic discovery and exploitation of commonality across related software systems is a fundamental technical requirement for achieving successful software reuse By examining a class/family of related systems and the commonality underlying those systems, it is possible to obtain a set of reference models, ie, software architectures and components needed for implementing applications in the class FORM (FeaturedOriented Reuse Method) supports development of such reusable architectures and components (through a process called the “domain engineering”) and development of applications using the domain artifacts produced from the domain engineering FORM starts with an analysis of commonality among applications in a particular domain in terms of services, operating environments, domain technologies, and implementation techniques The model constructed during the analysis is called a “feature” model, and it captures commonality as an AND/OR graph, where AND nodes indicate mandatory features and OR nodes indicate alternative features selectable for different applications Then, this model is used to define parameterized reference architectures and appropriate reusable components instantiatable during application development Architectures are defined from three different viewpoints (subsystem, process, and module) and have intimate association with the features The subsystem architecture is used to package service features and allocate them to different computers in a distributed environment Each subsystem is further decomposed into processes considering the operating environment features Modules are defined based on the features on domain technology and implementation techniques These architecture models that represent an architecture at different levels of abstraction are derived from the feature hierarchy captured in the feature model Modules serve as basis for creating reusable components, and their specification defines how they are integrated into the application (eg, asdis integration of predcoded component, instantiation of parameterized templates, and fillingdin skeletal codes) Our experiences have shown that for the electronic bulletin board and the private branch exchange (PBX) domains, “features” make up for a common domain language and the main communication medium among application users and developers Thus, the feature model well represents a “decision space” of software development, and is a good starting point for identifying candidate reusable components

FORM: A feature-oriented reuse method with domain-specific reference architectures

Architectures for software use rich abstractions and idioms to describe system components, the nature of interactions among the components, and the patterns that guide the composition of components into systems. These abstractions are higher level than the elements usually supported by programming languages and tools. They capture packaging and interaction issues as well as computational functionality. Well-established (if informal) patterns guide the architectural design of systems. We sketch a model for defining architectures and present an implementation of the basic level of that model. Our purpose is to support the abstractions used in practice by software designers. The implementation provides a testbed for experiments with a variety of system construction mechanisms. It distinguishes among different types of components and different ways these components can interact. It supports abstract interactions such as data flow and scheduling on the same footing as simple procedure call. It can express and check appropriate compatibility restrictions and configuration constraints. It accepts existing code as components, incurring no runtime overhead after initialization. It allows easy incorporation of specifications and associated analysis tools developed elsewhere. The implementation provides a base for extending the notation and validating the model. >

/pdf/abstractions-for-software-architecture-and-tools-to-support-e4i74tl4ti.pdf

Abstractions for software architecture and tools to support them

: The DARPA Domain Specific Software Architecture Program (DSSA) is a five-year effort that has been active since July 1991. This document contains an overview of the work being done in the program as of July 1992. Software architectures serve as frameworks for software reuse. Domain-specific software architectures also serve as a common language in which domain engineers can discuss, understand and teach the principles of their craft. There are six independent projects within the DSSA program. Four of these projects are working in specific, Military-significant domains. Avionics Software, Domain-Specific Software Development, Command and Control Software, Software Architecture, Control Software, Software Reuse.

/pdf/the-domain-specific-software-architecture-program-yb3fqxi0o9.pdf

The Domain-Specific Software Architecture Program

This report explores issues related to the use of database management technology in support of real-time system programming. It describes the potential benefits of database support for real-time systems, and it describes the state of the art in database technologies relevant to real-time. The report concludes that more research and development will be needed before the benefits of database management can be applied to real-time system development.

/pdf/issues-in-real-time-data-management-4l6vlxuuaw.pdf

Issues in real-time data management

: The SQL Ada Module Description Language, SAMeDL, is a language for the specification of Interfaces as delineated by the SQL Ada Module Extensions (SAME) methodology. The language is formally defined in the SAMeDL reference Manual (Chastek 90). This document is a companion to the Reference Manual. Whereas the Reference Manual is meant to be precise, the Rationale is meant to be clear. An explanation of the problem solved by the SAMeDL is given. The creation of a new language is justified and the underlying principles of that language are described. Crucial issues in the language are then explained. These include: The form and meaning of identifiers in the SAMeDL. The role of and procedures for data definition in the SAMeDL. This includes support for enumerations and constants in the SAMeDL. The typing rules of the SAMeDL. The proposed use of some SAMeDL features is also illustrated. These include Standard Post Processing and User Defined Base Domains. This document is a revision of an earlier technical report, SEI/CMU-91-TR-4 (Chastek 91). The revision consists of the addition of a reference model of database programming language interfaces to Section 1.3. The reference model gives a context for the survey of Ada SQL interface solutions given in Section 1.3.

/pdf/rationale-for-sql-ada-module-description-language-samedl-2tbgbso1a3.pdf

Rationale for SQL Ada Module Description Language SAMeDL, Version 2.0

The SQL Ada Module Description Language, SAMeDL, is a language for the specification of Abstract Interfaces as delineated by the SQL Ada Module Extensions (SAME) methodology. The language is formally defined in the SAMeDL Reference Manual [Chastek 90]. This document is a companion to the Reference Manual. Whereas the Reference Manual is meant to be precise, the Rationale is meant to be clear. An explanation of the problem solved by the SAMeDL is given. The creation of a new language is justified and the underlying principles of that language are described. Crucial issues in the language are then explained. These include: • The form and meaning of identifiers in the SAMeDL. • The role of and procedures for data definition in the SAMeDL. This includes support for enumerations and constants in the SAMeDL. • The typing rules of the SAMeDL. The proposed use of some SAMeDL features is also illustrated. These include Standard Post Processing and User Defined Base Domains.

/pdf/rationale-for-sql-ada-module-description-language-samedl-40k5gzzxpn.pdf

Marc H. Graham

Papers

The Domain-Specific Software Architecture Program

Issues in real-time data management

Rationale for SQL Ada Module Description Language SAMeDL, Version 2.0

Rationale for SQL Ada Module Description Language SAMeDL

Down in the details: lessons learned in interfacing Ada and SQL