Introduction

The purpose of this paper is to outline a process¹currently under development, that can be used to generate a Domain-Specific Software Architecture (DSSA). It is based on the work of Ruben Prieto-Diaz[3] and Sholom Cohen[1]. The fundamental premises of this work are that:

1. an application can be defined by a set of needs that it fulfills,
2. user needs can be mapped into a set of requirements that meet those needs,
3. requirements can be met in a number of ways,
4. implementation constraints limit the number of ways requirements can be met.

The goal of the process is to map user needs into system and software requirements that, based on a set of implementation constraints, define a DSSA. The separation of user needs from system requirements and implementation constraints differentiates this process from previous work. In particular most domain analysis processes do not differentiate between functional requirements and implementation constraints, but rather simply classify them under the heading of ``requirements''. Similarly, this process differentiates between the System Architecture and the Software Architecture that is part of it.

Another difference between this approach to domain engineering and other domain analysis approaches (e.g., Prieto-Diaz[2]) is that case-based reasoning and reverse engineering are not central mechanisms for identifying reusable resources, but rather existing applications are used as vehicles to validate the architectures that are derived, top-down, from generalized user requirements².

At the top-most level there are 5 stages in the process. Each stage is further broken into sub-steps or stages. Furthermore, this process is concurrent, recursive, and iterative, therefore completion may require several passes through each stage with additional levels of detail being addressed, or new insights (or oversights) requiring further definition or analysis. For example, during Stage 1: Defining/Scoping the Domain, one is concurrently identifies key aspects of the domain, which is part of Stage 2.2: Defining a Domain Vocabulary.

The five stages in the DSSA Definition Process are:

1. Define/Scope the Domain
   • Define what can be accomplished — emphasis is on user's needs.
2. Define/Refine Domain Specific Concepts/Requirements
   • Similar to Requirements Analysis — emphasis is on problem space.
3. Define/Refine Domain Specific Implementation Constraints
   • Similar to Requirements Analysis — emphasis is on solution space.
4. Develop Domain Architectures/Models
   • Similar to High-Level Design — emphasis is on defining module/model interfaces and semantics.
5. Produce Reusable Workproducts
   • Implementation of reusable artifacts (e.g., code, documentation, etc.).

The remaining material in this paper consist of a breakdown of the stages listed above. A detailed description of each stage is found in[4], which is currently under development. Each stage consists of a series of questions to be answered and a list of outputs to be generated.

• Domain Engineering Process Overview