Software Engineering Seminar

GT-SARG (Georgia Tech Software Architecture Reading Group

CS 8112 Winter Quarter 1995
Moderator: Gregory Abowd

Return to GT-SARG topic overview

Date: Feb 1 Topic Domain Specific Software Architectures

Discussant: Name

Readings

Additional readings

None

Summary of readings

1) Domain Specific Software Architeucture Engineering Process Guidelines

This paper defined what a domain-engineering process was, and how it was to be used to generate a Domain-Specific Software Architecture (DSSA). There were four basic premises of the work done in the paper:

  1. An application can be defined by a set of needs that it fulfills,
  2. user needs can be translated into a set of requirements that meet those needs,
  3. requirements can be met in a number of different ways (multiple solutions), and
  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.

According to the authors, most domain analysis processes do not differen- tiate between functional requirements and implementation constraints, but rather simply classify them under the heading of "requirements". This differentiation distinguishes other "domain-analysis" processes from the domain engineering process described in the paper. Existing domain-analysis processes fail to distinctly separate "problem-domain analysis" from "solution-space analysis."

A Domain Specific Software Architecture is, in effect, a multiple-point solution to a set of application-specific requirements (which define a problem domain). There are five stages in the DSSA definition/domain engineering process. They are:

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

This paper is very similar to the previous paper that described process guidelines for a Domain-Specific Software Architecture (DSSA). The difference is this paper gives an outline for each of the stage inputs and outputs associated with the 5 stages of the DSSA definition. They are as follows:

Stage 1) Define the Scope of the Domain

Inputs:

Outputs: Stage 2) Define/Refine Domain-Specific Concepts/Requirements

Inputs:

Outputs: Stage 3) Define/Refine Domain-Specific Design and Implementation Constraints

Inputs:

Outputs: Stage 4) Develop Domain Architectures/Models

Inputs:

Outputs: Stage 5) Produce/Gather Reusable Workproducts

Inputs:

Outputs:
3) A Process for Consolidating and Reusing Design Knowledge

This paper focused on the signficant improvements in design quality and productivity that are possible when designers operate in a domain-specific information workspace with low-cost access to relevant application, design, and technology information. A validated process for constructing such workspaces to support product family design and evolution was presented. The process involves three related efforts:

The authors answered the question, "When does it make sense to consolidate and reuse design knowledge," in the following manner: 1)When working on systems that are inherently difficult to understand, 2) When working on projects with high probability of design information being reused, and 3) When engineering organizations have short product development cycles, operating under challen- ging regulatory systmes, or with high product-maintenance costs.

Technlogy books consolidate the best knowledge available in the organization about a class of problems. They use a small number of semantic and syntactic tags. These tags represent a careful compromise between usability and for- mality. The information is stored in typed nodes and in relations between nodes. A typical information node may include encapsulated documents or infor- mation fragments, and other attributes

4) The Graft-Host Method for Design Change

"Normal" software design methodologies fail to address: (i) the interactions between multiple, concurrent software design dimensions: (ii) the integrated management of software and hardware design constraints: and, (iii) the change management problems that result from grafting partial designs onto existing host designs.

This paper proposed the Graft-Host (G-H) method for changing design incrementally by means of "graft-and-repair" steps. It derives its strength from the reuse of analysis and design information. Some key features of G-H are:

Functionally, The G-H method introduces structure into design change by means of graft-and-repair steps: a subset of a design (the target) is replaced by an equivalent but not identical subset (the graft), and the resulting new design is modified (repaired) to compensate for the differences between the graft and target. The goal is to provide developers with an infrastructure of reusable knowledge to help them analyze software grafts efficiently. This infrastructure is embodied in what the authors dub a technology book, and is specific to a task that a product performs. The knowledge represented in these "books" is distilled from various sources (eg. textbooks, systems documentation, etc.) through a process called domain analysis. The knowledge is stratified by levels of refinement: