Domain-Speci�c Software ArchitectureEngineering Process GuidelinesADAGE-IBM-92-02BVersion 2.1Will Tracz | Lou CoglianeseLoral Federal Systems { OwegoMD 0210Owego, NY 13827-1298tracz@vnet.ibm.comAbstract\In order to reuse software, there needs to be software to reuse[12]."One of the dilemmas that has prevented software developers from reusing software is the lack of software artifactsto use or the existence of artifacts that are di�cult to integrate. Domain-Speci�c Software Architectures (DSSAs)have been proposed [7] in order to address these issues. A DSSA not only provides a framework for reusablesoftware components to �t into, but captures the design rationale and provides for a degree of adaptability. Thisdocument presents process guidelines for de�ning a Domain-Speci�c Software Architecture1 . Furthermore, the processis formally speci�ed in the Teamware Process Programming Language.Note to Reader: The following changes have been made to this version of the document:1. The terminology \Entity/Concept" has been changed to \Element" for reasons of clarity. While there are culturalissues surrounding the use of the terms \entity", \concept", and \feature" or \requirement", the (hopefully)neutral term \element" will serve the same purpose.The material still missing from this document includes:1. examples of actual outputs for each stage,2. more details regarding the tools begin used and being developed on the ADAGE project that support thisprocess, and3. some lessons learned from applying the process.1This e�ort is sponsored by the US Department of Defense Advanced Research Projects Agency in cooperation with the US Air ForceWright Laboratory Avionics Directorate under contract F33615-91-C-1788.1

ContentsIntroduction 3Terminology and De�nitions : : : : : : : : : : 4RDD-100 Considerations : : : : : : : : : : : : 5IBIS Implications : : : : : : : : : : : : : : : : 5DSSA Domain Engineering ProcessOverview 5Preparation for Applying the Domain-Engineering Process 6Domain Analysis Time-Line Outline : : : : : 7Desirable Attributes of a DSSA : : : : : : : : 7Process Diagram Notation : : : : : : : : : : : 8Stage 1: De�ne the Scope of the DomainAnalysis 8Stage 1.1: De�ne Goals of Domain Analysis : 8Stage 1.2: De�ne the Domain : : : : : : : : : 9Stage 1.3: De�ne Domain-Speci�c Resources 10Stage 1.4: De�ne Domain of Interest : : : : : 11Stage 1.5: Determine Model Veri�cation Pro-cedure : : : : : : : : : : : : : : : : : : : 11Stage 1 Inputs : : : : : : : : : : : : : : : : : 11Stage 1 Outputs : : : : : : : : : : : : : : : : 11Stage 1 Validation Procedure : : : : : : : : : 12Stage 2: De�ne/Scope Domain-Speci�c Ele-ments 12Stage 2.1: De�ne/Re�ne an Element : : : : : 12Stage 2.2: Classify Elements : : : : : : : : : : 15Stage 2.3: Cluster Common Elements : : : : 15Stage 2.4: Create a Domain Description Doc-ument : : : : : : : : : : : : : : : : : : : 15Stage 2.5: Create a Domain Vocabulary Dic-tionary : : : : : : : : : : : : : : : : : : : 15Stage 2.6: Create a High-Level RequirementsSpeci�cation Document : : : : : : : : : 15Stage 2.7: Evaluate Results and Iterate if Nec-essary : : : : : : : : : : : : : : : : : : : 15Stage 2 Inputs : : : : : : : : : : : : : : : : : 15Stage 2 Outputs : : : : : : : : : : : : : : : : 16

Stage 2 Validation Procedure : : : : : : : : : 16Stage 3: De�ne/Re�ne Domain-Speci�c De-sign and Implementation Constraints 16Stage 3.1: De�ne Constraints on Architecture 16Stage 3.2: Identify Relationships Between El-ements and Constraints : : : : : : : : : 17Stage 3.3: Evaluate Results and Iterate if Nec-essary : : : : : : : : : : : : : : : : : : : 18Stage 3 Inputs : : : : : : : : : : : : : : : : : 18Stage 3 Outputs : : : : : : : : : : : : : : : : 18Stage 3 Validation Procedure : : : : : : : : : 18Stage 4: Develop DomainArchitectures/Models 18Stage 4.1: De�ne Domain-Speci�c SoftwareArchitecture(s) : : : : : : : : : : : : : : 19Stage 4.2: De�ne Modules : : : : : : : : : : : 19Stage 4.3: Link Models to Elements and Re-quirements : : : : : : : : : : : : : : : : 20Stage 4.4: Evaluate Results and Iterate if Nec-essary : : : : : : : : : : : : : : : : : : : 21Stage 4 Inputs : : : : : : : : : : : : : : : : : 21Stage 4 Outputs : : : : : : : : : : : : : : : : 21Stage 4 Validation Procedure : : : : : : : : : 21Stage5: Produce/Gather Reusable Workprod-ucts 21Stage 5.1: Develop/Collect the Reusable Arti-facts : : : : : : : : : : : : : : : : : : : : 21Stage 5.2: Develop Each Module : : : : : : : 22Stage 5.3: Link Artifacts to Models, Elements,and Requirements : : : : : : : : : : : : 22Stage 5 Inputs : : : : : : : : : : : : : : : : : 22Stage 5 Outputs : : : : : : : : : : : : : : : : 23Stage 5 Validation Procedure : : : : : : : : : 23Concluding Remarks 23References 23A Overview of STARS Domain Analysis Ac-tivities 232

IntroductionThe purpose of this document is to de�ne a domain-engineering process2 to be used to generate aDomain-Speci�c Software Architecture (DSSA). It isbased on the Reuse Library Process Model that wasdeveloped as part of the STARS (Software Technol-ogy for Adaptable and Reliable Systems) program byRuben Prieto-Diaz [10] and the Feature-Oriented Do-main Analysis (FODA) work by Kyo Kang, Sholom Co-hen, et al. [3] at the Software Engineering Institute(SEI) cast into the methodology supported by Require-ments Driven Design tool (RDD-1003) [2] and the IssueBased Information Systems [4] (IBIS) model for record-ing design decisions and design rationales.The fundamental premises of this work are that:1. an application can be de�ned by a set of needs thatit ful�lls,2. user needs can be translated into a set of require-ments that meet those needs,3. requirements can be met in a number of di�erentways (multiple solutions), and4. implementation constraints limit the number ofways requirements can be met.The goal of the process is to map user needs into sys-tem and software requirements that, based on a set ofimplementation constraints, de�ne a DSSA.The separation of user needs from system require-ments and implementation constraints di�erentiatesthis process from previous work. In particular mostdomain analysis processes do not di�erentiate be-tween functional requirements and implementa-tion constraints, but rather simply classify them un-der the heading of \requirements". This di�erenti-ation distinguishes other \domain-analysis" processesfrom the \domain-engineering" process described inthis document. Existing domain-analysis processes failto distinctly separate \problem-domain analysis" from\solution-space analysis". In particular they tend tofocus on the latter rather than the former4. Domain-modeling processes (e.g., OCU Model [5]), on the otherhand, focus on problem-domain analysis. The domain-engineering process described in this document ad-dresses the issues raised by both domain-modeling anddomain-analysis processes in the de�nition of a Domain-Speci�c Software Architecture.A Domain-Speci�c Software Architecture is, ine�ect, a multiple-point solution to a set of2Note: a process is a series of steps or stages with entry andexit criteria and tasks to follow at each phase as well as a way onverifying its correctness and merit.3RDD-100 is a registered trademark of the Ascent LogicCorporation4Although their authors would probably �nd this to be a goodpoint of discussion!

application-speci�c requirements (which de�nea problem domain).Another di�erence between this approach to domain en-gineering and other domain analysis approaches (e.g.,Prieto-Diaz [9]) is that case-based reasoning and reverseengineering are not central mechanisms for identifyingreusable resources, but rather existing applications areused as vehicles to validate the architectures that arederived, top-down, from generalized user requirements.The reuse of existing artifacts is not the central goalof the proposed domain-engineering process, but ratherthe goal is the development of a reusable architectureinto which well-speci�ed components can be integrated.At the top-most level there are �ve stages/phases inthe process. Each stage is further divided into stepsor sub-stages. Furthermore, this process is concurrent,recursive, and iterative5, therefore completion may re-quire several passes through each stage with additionallevels of detail being addressed, or new insights (or over-sights) requiring further de�nition or analysis. For ex-ample, during Stage 1: De�ne/Scope the Domain,one concurrently identi�es key aspects of the domain,which are part of Stage 2.5: Create a Domain Vo-cabulary Dictionary.The �ve stages in the DSSA de�nition/domain-engineering process are:1. De�ne the Scope of the Domain� De�ne what can be accomplished | emphasisis on the user's needs.2. De�ne/Re�ne Domain-Speci�c Elements� Similar to Requirements Analysis | emphasisis on the problem space.3. De�ne/Re�ne Domain-Speci�c Design andImplementation Constraints� Similar to Requirements Analysis | emphasisis on the solution space.4. Develop Domain Models/Architectures� Similar to High-Level Design | emphasis ison de�ning module/model interfaces and se-mantics.5. Produce/Gather Reusable Workproducts� Implementation/collection of reusable arti-facts (e.g., code, documentation, etc.).The remaining material in this document focuses on ex-panding the �ve stages listed above. Each stage consistsof a series of questions to be answered and a list of in-puts required, outputs to be generated, and veri�cation5The process could justi�ably be called \spiral".3

criteria. Before each stage is presented in detail, theoverall knowledge-acquisition process is discussed andguidelines presented to assist domain engineers in tai-loring the process to meet the goals within their speci�cdomain.Finally, included in the appendix of this document is anoutline of the STARS Domain Analysis Process [10]. Itprovides the reader with an opportunity to compare thestages and activities within these two approaches.Terminology and De�nitionsBefore proceeding, in order to avoid unnecessary confu-sion, it is important to alert the reader to the choiceof terminology being used to describe this process.The following set of de�nitions were the results of theDARPA Domain-Speci�c Software Architecture Work-shop in Hidden Valley, PA, July 9-12th, 1989:Architecture1. A composite or assemblage of models that de�nethe structure or topology of subsystem components,which are de�ned by a composite of models.2. A canonical solution to patterns of requirementswhose behavior is expressed by the propagation ofinformation among component objects.Component1. An architectural software artifact that can be mod-eled.2. An element that may be composed/combined withother elements.Model1. A clearly identi�able interface and description ofsome design element, module, or object that maybe part of a larger model (composed to form) or aseparate entity.2. A scalable unit of engineering technology withknown structure and performance that maps func-tion to form.3. A speci�cation for a class of problems.Domain-Speci�c Software Architecture1. A context for patterns of problem elements, solu-tion elements and situation that de�ne mappingsbetween them.

Another interesting result of the workshop was thatthe attendees resorted to referring to the elements ina DSSA as \things". The \things" described by theprocess in this document are classi�ed by1. the level of abstraction that they apply to and2. the user who is referring to them.What follows are working de�nitions of important termsthat in the sections that follow, cast in the frameworkof a software development life cycle,A customer talks about his/her problem in terms ofwhat needs must be met given certain real constraintsin creating a solution. The user might want a systemwith certain features or functional units that operatesa certain way under certain conditions. The customerenters into a contractual relationship with a contractorbased on a set of requirements that need to be satis-�ed. These requirements detail the constraints (e.g.,cost, speed, size, language, hardware platform, etc.)that the must be met by a system that performs therequired functions.System engineers (or requirements analysts) starto� talking about certain concepts that exist in a domain.They might build models to gain insight into certain as-pects of these concepts and how they perform under cer-tain conditions (in certain contexts). The system engi-neer/analyst decomposes the system into hardware andsoftware elements or entities and assesses certain trade-o�s in how these may be realized.The programmer/software engineer designs andbuilds software modules or selects o�-the-shelf compo-nents and tailors them to a particular context speci�cto the task at hand.The terms concept, component, module, model, func-tional unit, element, entity, object, are synonymousto the same \thing", but used di�erently by di�erentpeople6 at di�erent times in the software developmentlife cycle. Special care has been taken throughout thisdocument to be consistent with their use.Finally, for purposes of clarity, the reader should notethat this process makes a special distinction betweenthe term \requirement", which describes a de�ningcharacteristic in the problem space, and the term \con-straint", which describes a discriminating characteris-tic in the solution space.6Note: Historically, the term concept is associated with the3-C Model[11] (Concept, Context, and Content) for designingreusable software components. The term feature plays a centralrole in the FODA process[3], and functional units or domain en-tities are described in the STARS process[10].4

RDD-100 ConsiderationsThe RDD-100 (Requirements Driven Design) is a de-sign tool that comes closest to directly supporting thedomain-engineering process described in this document.While its choice of terminology is slightly di�erent thanthat used in this document, the basic capabilities it pro-vides can be used to record the requirements, design,design alternatives, and rational. In particular, RDD-100 can be used to create data ow and control ow(state-transition) diagrams.IBIS ImplicationsOne of the most important goals of this domain-engineering process is the identi�cation and recordingof design decisions, design alternatives, and design ra-tionale. The IBIS (Issue-Based Information Systems)method of recording Issues, Positions, and Argu-ments provides the foundation for our process.Issues take the form of a question or decision that needsto be made.Positions are the possible choices/answers to an Is-sue/question.Arguments describe why a position is the \right one"{ the reasons/rationale (or rule) are for making a certaindecision.Obviously, there can be several positions associated witheach issue, and several arguments to support each po-sition. Sometimes the same arguments can be used tosupport other positions.Tool support is needed when a position is dependenton other issues, e.g., \take this position if the positionon this issue was X ... etc." This leads to \connectingissues" into a network that is related related either byarguments or positions. Clearly, having the right toolsto help record the issues, positions and arguments canhelp keep these relationships under control.By recording domain knowledge in this manner, severalthings \fall out" for free. In particular, the \DecisionTaxonomy" becomes a collection of the Issues, that areaddressed (positions taken) in some manner.DSSA Domain Engineering Pro-cess OverviewThe proposed domain-engineering process consists ofthe steps that follow. The domain engineer is encour-aged to scan this outline and become familiar with theoverall structure of the process.Stage 1 De�ne the Scope of Domain Analysis

Stage 1.1 De�ne goals of domain analysisStage 1.2 De�ne the domainStage 1.2.1 Draw a domain diagramStage 1.2.2 Identify scope of domainStage 1.2.3 Identify border of domainStage 1.3 De�ne domain-speci�c resourcesStage 1.3.1 Identify domain expertsStage 1.3.2 Identify domain artifactsStage 1.4 De�ne the domain of interestStage 1.5 Determine model veri�cation procedureStage 2 De�ne/Re�ne Domain-Speci�cElementsStage 2.1 De�ne/re�ne an elementStage 2.1.1 Identifyelements (behavior, temporal, and data)in the domainStage 2.1.2 Identify attributes of elementsStage 2.1.2.1 Identify re-quired/essential/mandatory elementsStage 2.1.2.2 Identify optionalelementsStage 2.1.2.3 Identify alternative ele-mentsStage 2.1.2.4 Identify requirementscommon between applicationsStage 2.1.2.5 Identify requirementsthat vary between applicationsStage 2.1.3 Determine entity's data owStage 2.1.4 Determine entity's control owStage 2.1.5 Identify relationship between el-ementsStage 2.1.5.1 Identify \is a/a kind of"relationshipsStage 2.1.5.2 Identify \consists of" re-lationshipsStage 2.1.5.3 Identify \uses/needs" re-lationshipsStage 2.2 Classify elementsStage 2.3 Cluster common elementsStage 2.4 Create a domain description documentStage 2.5 Create a domain vocabulary dictionaryStage 2.5.1 Create a domain thesaurusStage 2.6 Create a high-level requirements speci-�cation DocumentStage 2.7 Evaluated results and iterate if neces-saryStage 3 De�ne/Re�ne Domain-Speci�c Designand Implementation ConstraintsStage 3.1 De�ne constraints on the architectureStage 3.1.1 De�ne software constraintsStage 3.1.2 De�ne hardware/physical con-straints5

Stage 3.1.3 De�ne performance constraintsStage 3.1.4 De�ne design constraintsStage 3.2 Identify relationships between elementsand constraintsStage 3.3 Evaluate completeness and iterate ifnecessaryStage 4 Develop Domain models/ArchitecturesStage 4.1 De�ne a Domain-Speci�c Software Ar-chitectureStage 4.1.1 De�ne generic high-level designStage 4.1.2 Identify components/modulesStage 4.1.3 De�ne decision taxonomyStage 4.1.4 Record design issues, trade-o�s,and decision rationaleStage 4.2 De�ne ModulesStage 4.2.1 De�ne modules' interfaceStage 4.2.2 Specify semantics of each mod-uleStage 4.2.3 Specify constraints on eachmoduleStage 4.2.3.1 Specifyperformance/timing constraintsStage 4.2.3.2 Specify dependency (lay-ering) constraintsStage 4.2.3.3 Specify sequential-ity/order (operational) constraintsStage 4.2.3.4 Specify system designconstraintsStage 4.2.4 Specify performance character-istics of each modelStage 4.2.5 Identify con�guration (generic)parameters for each modelStage 4.2.6 Record issues, trade-o�s and de-sign rationaleStage 4.3 Link models to elements and require-mentsStage 4.4 Evaluate results and iterate if necessaryStage 5 Produce/Gather Reusable Workprod-uctsStage 5.1 Identify reusable artifactsStage 5.1.1 Identify COTS componentsStage 5.1.2 Identify in-house componentsStage 5.1.3 Determine con�gurabilityStage 5.1.4 Determine necessary modi�ca-tionsStage 5.2 Develop modulesStage 5.2.2 Implement each moduleStage 5.2.2 Test each moduleStage 5.2.3 Document each moduleStage 5.2.4 Record issues, tradeo�s and de-sign rationaleStage 5.3 Link artifacts to models, elements, andrequirements.

Preparation for Applying theDomain-Engineering ProcessWhat follows is a list of questions to be answered bya \domain expert or experts" as part of an interviewconducted by a \domain engineer". It is recommendedthat the interview process be either video taped or taperecorded as to allow an unimpeded ow of knowledgenot constrained by note taking. An alternative ap-proach is to have two domain engineers at the interview,one to take notes, the other to ask questions.Before domain engineers interview domain experts, do-main engineers should make every attempt to familiar-ize themselves with the domain. Ideally the person per-forming the domain analysis, the domain engineer, hassome experience in the domain and this process becomesone of the recording the necessary information. The do-main engineer should have some idea of the answers tothe questions found in these guidelines in order to drawout the answers or have them validated by the domainexpert.Most importantly the domain engineer should deter-mine which portions of the questions in this guide-line document are relevant and modify the domain-engineering process accordingly.It is also important to emphasize that before startingthe domain-engineering process, the domain engineershould understand what they hope to accomplish andwhy they are performing this task. Upon completionof the domain-engineering process, the domain engineershould have:1. a characterization and understanding of the prob-lem space (the domain),2. a characterization and understanding of the solu-tion space (for the domain),3. an understanding of how requirements in the prob-lem space map to solutions within the frameworkof a generic design (the Domain-Speci�c SoftwareArchitecture),4. (optionally) reusable components that can easilybe adapted and integrated into the architecture togenerate applications within the domain.To meet this end, the domain engineer must be preparedto ask leading questions such as:� Why is this here?� What is this?� Why is it done this way?� Is there any other way to do it?Finally, the outputs of the domain-engineering processserve several purposes. In order to facilitate the capture,6

representation, veri�cation, and navigation of domain-speci�c knowledge in a knowledge base, a hypertextsystem is recommended to link various domain ele-ments, requirements, constraints, and components to-gether with supporting documentation (e.g., rationale).Domain Analysis Time-Line OutlineThe following lists the sequence of steps a domain engi-neer might follow in conducting an initial Domain Anal-ysis (DA). This schedule has been successfully followedwithin IBM on several small domains by well-traineddomain engineers. The reader should be aware that thetimes may vary, depending on the skills of the domainengineer, the cooperation of the domain experts, andthe size to the domain7. This outline is o�ered more asa framework to plan a domain analysis, rather than ahard and fast schedule.Step 1: Meet with upper management to determine:1. goals of doing the Domain Analysis, and2. resources (e.g., people, products).Time = 1 hour.Step 2: Contact domain experts and tell them to:1. spend 15-45 minutes drawing a high-levelblock diagram for the design of applicationsin the domain,2. identify the major subsystems/modules andthe data that ows between them, and3. be prepared to make a presentation of yourdiagram at the DA meeting described in thenext step.Time = 15 minutes * number of Domain Expertsfor the Domain Engineer + 1 hour * number ofDomain Experts.Step 3: Conduct high-level domain analysis meeting:1. domain experts present diagrams,2. identify terminology,3. clarify elements,4. work toward consensus at top level, and5. as time permits, re�ne drawing to lower levels.Time = 4 hours.Step 4: Domain engineer coalesces knowledge gath-ered by putting together a strawman:1. Data Flow Diagram,2. Dictionary/Thesaurus, and7In some cases, an order of magnitude more time might berealistic than those proposed here!

3. Issues and Tradeo�s/Rational Documents.Time = 2{3 days depending on results.Step 5: Conduct an o�ine review of results of DAmeeting by1. sending Strawmen to domain experts,2. soliciting their feedback, and3. having domain engineer rework Strawmenbased on feedback.Time = 2{4 hours/Domain Expert's time + 2-3days by Domain Engineer, depending on type offeedback.Step 6: Hold second DA meeting to:1. review results,2. add detail, and3. etc. (focus on reason for doing DA, e.g., �nd-ing/de�ning reusable components).Time = 8 hours.The Domain Engineer would then iterate throughSteps 4{6, depending on the resources and goals.Step 7: Validate results by:1. going through a high-level design review usingexisting resources to create a new system, or2. bringing in a domain expert who did not par-ticipate in the analysis to review the materialfor completeness, consistency and accuracy.Time = 4{8 hours depending on the size of thedomain.Desirable Attributes of a DSSAThe following is a list of desirable attributes of a DSSA.They serve as goals the domain-engineer should keep inmind when conducting the domain-engineering process.� Understandability,� Usability,� Complexity (hiding of),� Adaptability,� Con�gurability,� Extensibility (ability to extend the domain of theDSSA),� Scalability (ability of DSSA to map to implemen-tation of increasing dimension within the domain),� Composability (ability of components to be com-bined with other components in the DSSA),� Interoperability (ability of components to be inte-grated with other software not in the DSSA),7

� Compatibility (with existing standards, terminol-ogy, and technology),� Predictability (the level of �delity of meeting per-formance and resource requirements),� Quality (of components and supporting documen-tation), and� Saleability (ability of DSSA to re ect the require-ments in the eyes of the end-user).Process Diagram NotationThe notation used in the process diagrams that followhas been developed as part of the Teamware ProcessProgramming Language [13]. Teamware has been de-signed to both support speci�cation and enactment ofsoftware processes. This document uses a simpli�ed ver-sion of the language to describe the domain engineeringprocess.Figure 1 shows some simple Teamware diagrams. Flowof control between activities is shown by using the fourconnectors: 2 (fork processes), � (join forked processes),2 (alternative paths), and � (join alternative paths).During execution, Teamware interpreter handles activi-ties di�erently depending on their system speci�cation.For example meeting activities are interpreted di�er-ently from general assigned activities. The letters inthe activity boxes denote the activity's system speci�-cation. In the domain engineering process we will di�er-entiate between general assigned activities (labeled A)and veri�cation activities (labeled V).Stage 1: De�ne the Scope of theDomain AnalysisThe �rst phase in the domain-engineering process fo-cuses on determining what is in the domain of interestand to what ends is this process being applied. One ofthe primary outputs of this phase is a list of needs thatusers of applications in this domain require being met.The answers to the �rst set of questions that followshould be determined by the interviewer before the �rstinterview commences. In that way, the interviewer isbetter prepared to take advantage of the �rst workingsession to ask the domain expert to verify these answers.Similarly, the answers to as many of the questions in theremaining portion of this section should be determinedbefore hand so that the domain expert can validate orexpand on them.1. What is the name of the domain being modeled?2. What is a short description of the application do-main?

3. What general user needs are satis�ed by applica-tions in this domain?Figure 2 shows the individual steps in this process stage.Stage 1.1: De�ne Goals of Domain Anal-ysisAs with the expression \mileage may vary" used to cau-tion customers regarding published �gures on cars, it isimportant to make the potential user of this domain-engineering process aware that customer's domain anal-ysis \goals may vary".Domain analysis is done for a variety of reasons. While,creating a domain-speci�c software architecture is themajor emphasis of this process, other applications of theprocess are equally relevant. The Workshop on DomainModeling at ICSE-13 in Austin, Texas, May 13, 1991identi�ed the following applications for domain analysis:1. understanding large systems as a maintenance aide,2. translation of natural language test scripts for me-chanical testing,3. evolution of software design,4. classi�cation of software components, and5. developing speci�cation languages and synthesiz-ers.In addition, at the First International Workshop onSoftware Reuse in Dortmund, Germany, July 3-5, 1991,the Domain Analysis Working Group observed domainanalysis being applied at various phases in the softwarelife cycle for the following reasons:1. Product De�nition: domain analysis can be usedprior to product development to determine whatpeople want.2. Requirements Analysis: domain analysis canbe used to analyze the characteristics of the appli-cation domain and cite opportunities for softwarereuse of common modules.3. Design: domain analysis techniques can help de-signing software for reuse by understanding whatthe domain of applicability/con�gurability is thatshould be addressed.4. Maintenance: reverse engineering, as a form ofdomain analysis, can lead to the identi�cation andclassi�cation of software components that can bereused.5. Implementation: creating new applications withreusable software components, integrating compo-nents on a generic architecture, or generating new8

A A

Activity A Activity B

Activity C

Meeting M

Activity B will begin whenActivity A is completed

A

A

Activity A

Activity B

A

Activities B & C will begin whenActivity A is completed

Activity C

M

A

Activity B

A

Either Activity B or Activity C will begin whenMeeting M is completed

A

A

Verification V

Activity B

Activity A

V

Verification Activity V will begin whenboth Activity A and Activity B have been completed

A

A

Activity C

Activity B

Activity A

Activity C will begin wheneither Activity A or Activity B has been completed

A

Multiple Activity A

Multiple instances of a given activity will be carriedout in parallel (e.g. execute multiple Code−Moduleactivities, one for each module in the system)Figure 1: Some Simple Teamware Examplesapplications through parameter selection are ap-proaches that are feasible as a result of domainanalysis.Questions relevant to de�ning the goals of the domainengineering are:1. What is the purpose of creating this DSSA?2. What is the DSSA going to be used for?3. Who is going to use the DSSA?4. When do you know you are done doing a domainanalysis?5. What are the reuse goals? How much of the archi-tecture should be reusable?Stage 1.2: De�ne the DomainThe goal of this stage in the domain-engineering processis to draw a high-level block diagram showing what is inthe domain and the relationships between the entitiesin the domain (e.g., an E/R diagram).Stage 1.2.1: Draw Preliminary Domain DiagramIdentify what is inside the scope of this domain analysis.Assuming a block diagram has been drawn, this steplabels the blocks and makes the �rst attempt at identi-fying variations.1. What are the classes of applications in this domain?2. What primary functions/objects/things are in thedomain?3. What kinds of (high-level) trade-o�s exists in thisdomain?Stage 1.2.2: Identify Scope of DomainIdentify what is outside the scope of this domain analy-sis.A problem domain generally can be divided into sev-eral smaller pieces, or sub-domains. These sub-domainsmight share commonality with sub-domains in other9

A

1.1 Define Goals of Domain Analysis

1.2 Define Domain

1.2.1 Draw Preliminary Domain Diagram

1.2.2 Identify Scope of Domain

1.2.3 Identify Border of Domain

1.3 Define Domain Specific Resources

1.3.1 Identify Domain Experts

1.3.2 Identify Domain Artifacts

1.5 Determine Model Verification Procedure

A

A

A

A

A

F

S

A

A

1.4 Define Domain of Interest

Figure 2: Stage 1: De�ne the Scope of the Domain Analysisproblem domains (e.g., communication protocol or database acquisition protocols). The focus of this stage is toidentify those commonalities and relationships.1. What functions/objects/things in the domain areoutside the scope of the sub-domain we are choos-ing to analyze?2. What are similar/related domains and sub-domains?3. How does this domain relate to other domains?Stage 1.2.3: Identify Border of DomainIdentify what is on the borders of the domain.An application generally interacts with other applica-tions either by supplying data or functionality or expect-ing data or services exported by other resources (e.g.,client/server relationships). The focus of this stage isto identify those entities or resources used or suppliedand their possible sources or destinations. The domainengineer should pay special attention to the classi�ca-tion of inputs (data/control). This separation will bevaluable in later stages of the process.1. What are the inputs (data/control) to the domain?2. What are the outputs (data/control) from the do-main?3. Where do inputs to the domain come from (whoprovides the services/data)?4. Where do outputs from the domain go to (who con-sumes the services/data { if known)?Stage 1.3: De�ne Domain-Speci�c Re-sourcesDomain engineers, once establishing their domain anal-ysis goals, must identify the resources from which theycan draw upon in meeting their goals.Stage 1.3.1: Identify Domain ExpertsDe�ne who you have to work with.The domain engineer must identify the individual or in-dividuals whose expertise and experience in the domaincan lend insight into various aspects of the domain, both10

in de�ning the requirements for applications in the do-main and identifying existing or potential solutions (andtheir trade-o�s).1. Who (else) knows about the domain under analy-sis?2. Who (else) knows about the software implementa-tion details for this domain?3. Who knows about the system design details for thisdomain?4. Who knows about the hardware constraints and de-pendencies for applications in this domain?5. Who knows about future user needs for applicationsin this domain?6. Who knows about future technology that may betransitioned into new applications in this domain?Stage 1.3.2: Identify Domain ArtifactsDe�ne what you have to work with.If the reuse of existing software artifacts is one of the pri-mary goals of the domain analysis, then identifying whatresources exists is an (obviously) important step. Cau-tion should be exercised in placing excessive dependenceon reversing engineering existing systems in order to de-rive a domain-speci�c software architecture because ofthe implementation biases that could exist from ana-lyzing a single-point solution or a family of solutionsderived from a single-point solution.1. What systems exist that re ect the aspects of thetype of applications we wish to model?2. What is the legacy of the systems that exist? Howare they the same? How are they di�erent? Whyare they di�erent?3. What relevant documentation exists for existingsystems?4. What textbooks, articles, or models are availablethat describe applications in this domain?Stage 1.4: De�ne Domain of InterestOnce an application domain has been de�ned, it is noteconomically feasible to explore all the possible imple-mentation and design trade-o�s nor develop all possibleimplementations in the solution space. Going back toStage 1.1 { De�ne Goals of Domain Analysis, the do-main analysis goals should be examined, and based onthe results of this stage in the process, a subset of workthat could be done should be de�ned.1. What applications in this domain are we interestedin addressing? (A business decision)

2. What technologies are we interested in using tobuild applications in this domain? (e.g., OS, lan-guage, platform, etc.)3. Why are certain inputs, outputs, and/or technolo-gies not of interest?4. What methodology are we interested in using tobuild applications in this domain?5. What documentation standards are we interestedin using to build applications in this domain?6. How much time and e�ort is available for the do-main engineering e�ort?Stage 1.5: Determine Model Veri�cationProcedureThe advantage of having several existing systems as re-sources from which to draw is that they can be used tovalidate the resulting domain-speci�c software architec-ture. But, this is just one validation mechanism, concur-rence of the DSSA (and associated artifacts) by domainexperts is desirable.1. What system(s) can be used to validate the cor-rectness of the model(s) and architecture(s)?2. Who can serve as reviewers for the domain model(s)and architecture(s)?3. What equipment (Simulators/Stimulators) areneeded to validate the model(s) and architec-ture(s)?Stage 1 Inputs1. Experts (see Stage 1.3.1)2. Existing systems (see Stage 1.3.2)3. Existing documentation (e.g., textbooks, articles)Stage 1 Outputs1. Block diagram of the domain of interest includinginputs and outputs to the domain and high-levelrelationships between functional units/elements inthe domain2. List of people's names to serve as future referencesor validation sources3. List of projects with pointers to documentation andsource code4. List of needs to be met by applications in this do-main11

Stage 1 Validation Procedure1. Meet with domain experts to evaluate complete-ness of information gathered to date. This maytake place on several occasions with several di�er-ent individuals82. Meet with end users/customers of applications inthis domain to verify that these are the needs theyexpect applications in this domain to meet.Stage 2: De�ne/Scope Domain-Speci�c ElementsThe goal for this stage in the domain-engineering pro-cess is to compile a dictionary and thesaurus of domain-speci�c terminology. Given the high-level block diagramde�ned in the previous phase of the domain-engineeringprocess (Stage 1.2 { De�ne the Domain), more detail isadded, with special emphasis on \identifying commonal-ities" and \isolating di�erences" between applications inthe domain. Special emphasis should be placed on try-ing to \standardize" and \classify" the basic elementsin the domain9. Figure 3 shows the individual steps inthis process stage.Stage 2.1: De�ne/Re�ne an ElementThe goal of this stage in the domain-engineering processis to add more detail to the block diagram de�ned in theprevious phase by creating data ow and control ow(operational sequences or state transition) diagrams.1. How does data ow between elements in the do-main?2. How does control ow between elements in the do-main?Stage 2.1.1: Identify a Domain ElementThe basic elements in the domain should be identi-�ed and classi�ed by describing their functional behav-ior, temporal/operational relationships (control ow orstate transitions), or data values. This is the highestlevel of component identi�cation and interface design.A more detailed and rigorous de�nition will take placein subsequent stages (see Stage 4.2 { De�ne Modules).8Note: Just as \beauty is in the eye of the beholder", the\correctness" of the domain-engineering results may be subjectto the opinion of the domain expert. Therefore, the domain engi-neer is urged to exercise diplomacy in resolving con icting experttestimony.9Note: the basic elements in the domain are also referred toas entities or concepts. In MIL-STD-499B they are referred toas primary functions. See the discussion on the bottom of page4 for an additional discussion of this topic.

1. What are the elements in the domain?2. Is this a data or functional element?3. What are the inputs to a (functional) element?4. What are the outputs from (functional) element?5. What services/operations does this element pro-vide?Stage 2.1.2: Identify Attributes of ElementsCritical to the robustness of the domain-speci�c soft-ware architecture being developed is the domain engi-neer's ability to address variations in \requirements"in a variety of manners. The goal of this stagein the domain-engineering process, as detailed in thesub-stages that follow, is to characterize the re-quired/essential features or elements in the domainalong with the optional features or elements. Fur-thermore alternative features or elements should beidenti�ed and tradeo�s recognized and recorded wherepossible.Stage 2.1.2.1: Identify Required, Essential, andMandatory ElementsThis stage in the domain-engineering process tries toidentify the features, elements, or concepts that are be-ing manipulated in a domain that readily distinguishapplications in this problem domain from applicationsin other problem domains.1. What are the required/essential elementss inthis problem domain?Stage 2.1.2.2: Identify Optional ElementsThe goal of this stage in the domain-engineering processis to \identify di�erences" or things that might changefrom application to application within this problem do-main.1. What are the optional elements in this problemdomain?2. What are the reasons that these elements are op-tional?Stage 2.1.2.3: Identify Alternative ElementsIt has long been recognized that fam-ilies of implementations[8] exist that provide the samefunctionality with di�erent performance and space char-acteristics. While the implementation tradeo�s will beaddressed in later stages, the alternative relationshipbetween features, entities, or concepts is important toidentify at this abstract level.12

S

2.1.3 Determine Entity’s Data Flows

2.1.4 Determine Entity’s Control Flows

A

A

A

2.1.1 Identify Entity

2.1.2 Identify Entity’s Attributes

2.2 Categorize Entities

2.1.5 Identify Entity’s Relationships

2.3 Cluster Entities

2.1 Define/Refine Entity/Concept

2.4 Create Domain Description Document

2.5 Create Domain Vocabulary Dictionary

A

A

A

2.6 Create High−Level Requirements Specification

2.7 Evaluate

A

A

A

A

FVFigure 3: Stage 2: De�ne/Re�ne Domain-Speci�c Elements13

1. What are the alternative elements in this problemdomain?2. What element is this element an alternative to?3. Is this element mutually exclusive with other ele-ments?4. What are the reasons that elements are alterna-tives?Stage 2.1.2.4: Identify Common RequirementsThe goal of this stage in the domain-engineering processis to \factor out commonality" across applications inthis domain. The domain engineer should note the spe-cial emphasis place on the term \Requirements". Thisis the �rst use of the word. It is being used to iden-tify functional/behavioral requirements and tem-poral/operational requirements.Note (for the second time): for purposes of clarity,the reader is reminded that this process makes a specialdistinction between a requirement, which is a de�ningcharacteristic in the problem space, and a constraint,which is a discriminating characteristic in the solutionspace.1. What are the elements that do not change from oneapplication to another (same functionality)?2. What requirements are common to all applicationsin this domain?Stage 2.1.2.5: Identify Variable RequirementsThe goal of this stage in the domain-engineering pro-cess is to classify the functional/behavior requirementsor temporal/operational requirements that di�erentiatevarious applications in the domain.1. What are the elements that change from one appli-cation to another?2. What is the range of variation between di�erentimplementations of this element?3. What trade-o�s exists and why?4. What alternative approaches exists and why werethey not chosen?5. What other issues may come to bear on future sys-tems and how?Stage 2.1.2: Determine Entity's Data Flows1. How does control ow between entities/elements inthe domain?

Stage 2.1.3: Determine Entity's Control Flows1. How does control ow between entities/elements inthe domain?Stage 2.1.5: Identify Relationship Between Ele-mentsThe only relationships between concepts, elements, orentities in the domain explicitly identi�ed so far in thedomain-engineering process have been:1. optional entities,2. alternative entities,3. required entities,4. common entities, and perhaps5. mutually exclusive entities.In addition, implicit relationships have been expressedthrough the creation of the data ow and control ow(or state transition) diagrams. The goal of this stagein the domain-engineering process is to apply object-oriented analysis techniques to describe the relation-ships between elements previously identi�ed in this pro-cess.A second kind of relationship may be identi�able atthis time, although it is more likely to be determinedin later stages (e.g., Stage 4 { Develop Domain Modelsand Architectures or Stage 6 { Produce/Gather ReusableWorkproducts). These \uses/needs" relationships maybe derived from the data ow and control ow diagrams.Stage 2.1.5.1: Identify \is a/kind of" Relation-shipsRelationships of this sort assist in building a thesaurus(see Stage 2.5.1). This relationship is the specializa-tion/generalization relationship usually associated withinheritance in an object-oriented paradigm.1. Is a element an instance of another element?Stage 2.1.5.2: Identify \consists of" Relation-shipsThis is the \aggregation" relationship associated withan object-oriented paradigm.1. Is a element part of another element?14

Stage 2.1.5.3: Identify \uses/needs" Relation-shipsOne should examine the data ow and control ow dia-grams for insight into identifying these relationships.1. What elements does this element need servicesfrom?2. What elements does this element provide servicesto?Stage 2.2: Classify ElementsThis step in the domain-engineering process is both aclassi�cation of previously identi�ed concepts, objects,or entities and the creation of new entities that repre-sent classes/generalizations of the concepts, objects, orentities identi�ed as being in the domain.1. Can elements be classi�ed into classes?2. Can elements be abstracted?Stage 2.3: Cluster Common ElementsThe results of Stage 2.1.5.1 Identify \is a/kind of" re-lationships should provide useful inputs to this stage.1. Can elements be clustered into type hierarchies?Stage 2.4: Create a Domain DescriptionDocumentThe domain engineer should consider creating anoverview document describing the elements and rela-tionships between the elements within the domain. Thismay be an optional stage in the domain-engineering pro-cess, as there may be textbooks or other documentationthat adequately describe the material, but if it is notavailable, it serves as an excellent vehicle for validatingprogress with the domain experts.As a minimum, a list of pointers to additional documen-tation should be created.1. What would the user of the DSSA like to have avail-able as reference material?Stage 2.5: Create a Domain VocabularyDictionaryThis dictionary could be part of the Domain Descrip-tion Document described in Stage 2.4. The purpose

of creating a dictionary of domain-speci�c terminologyis to serve as a focal point for consensus building of thedomain-speci�c software architecture.1. What is the vocabulary/terminology used to de-scribe elements in this domain?Stage 2.5.1: Create a Domain ThesaurusCreate a list of synonyms for terms in the domain.1. What alternative terminology can be used to de-scribe elements (synonyms)?Stage 2.6: Create a High-Level Require-ments Speci�cation DocumentThe �nal (and optional under some circumstances)developmental stage in this phase of the domain-engineering process is the creation of a \generic"(reusable) Requirements Speci�cation Document (inMIL-STD format). While this stage is tailored to meetDoD standards, a similar end-user requirements \shop-ping list" could be created to serve as a communicationsvehicle as well as advertising mechanism.1. What user requirements map into the elements thathave been identi�ed in the previous stages of thisprocess?Stage 2.7: Evaluate Results and Iterate ifNecessaryAs stated in the introductory material, the process ofcreating a domain-speci�c software architecture is aniterative process. Several sessions with the domain ex-perts and several review cycles could be required, if nec-essary or desirable, to complete this step in the domain-engineering process, again, depending on the domainanalysis goals.1. Can these elements identi�ed in the domain be bro-ken down further?2. Do the domain experts concur with the materialgenerated to date?Stage 2 Inputs1. Outputs from Stage 12. Selected systems3. Selected documentation (e.g., textbooks, articles)15

Stage 2 Outputs1. Data dictionary with thesaurus (Domain Ontology)2. Type/inheritance hierarchy (Domain Taxonomy)3. Generic high-level block diagram/architecture4. Data ow and control ow diagrams for various as-pects of applications in the domain5. Rationale and relationships between elements inthe domainStage 2 Validation Procedure1. Concurrence of domain experts on the complete-ness and accuracy of the Dictionary and Thesaurus2. Concurrence of domain experts on the complete-ness and accuracy of the Domain Description Doc-ument3. Concurrence of domain experts on the complete-ness and accuracy of the High-Level RequirementsSpeci�cation Document4. Concurrence of domain experts on the complete-ness and accuracy of the data ow and control owdiagramsStage 3: De�ne/Re�ne Domain-Speci�c Design and Implementa-tion ConstraintsAs initially stated in the Terminology and De�nitionssection on page 4, and emphasized in the Stage 2.2.1.4Identify Common Requirements on page 14, (for thethird time) this document makes a special distinctionbetween the term \requirement", which describes ade�ning characteristic in the problem space, and theterm \constraint", which describes a discriminatingcharacteristic in the solution space. This distinctionis partially motivated by an observation Ruben Prieto-Diaz made in describing the Establish Global Require-ments stage (A5113 { Stage 1.1.3) of the STARS Do-main Analysis Activities [10] (see appendix A) relatingto two kinds of requirements in an application domain:1. Stable|ones that do not change from applicationto application, and2. Variable | ones do/might change.Expanding on this observation, it is the thesis of thisprocess that is it ALWAYS the case that the� \Stable" requirements are the \what" require-ments and

� \Variable" requirements are the \how" require-ments.The following are examples of \how" and \what" \re-quirements":� \what it does" (functional/behavioral requirement)� \how often" (performance requirement),� \how fast" (performance requirement),� \how big",� \how accurate",� \how implemented" (physical requirements as wellas language),� \how delivered",� \how it looks" (user interface), and� \how it works" (operational requirements (proto-cols to follow) or algorithmic alternatives).Therefore, these \variable requirements" are referred toas \constraints" to distinguish their role in the cre-ation of a domain-speci�c software architecture.The series of steps found in this phase of the domain-engineering process correspond to the list of '\hows"stated above. The goal of this stage in the domain-engineering process is to characterize the discriminatingfeatures in the solution space.Finally, not only must the constraints be identi�ed,but their implications on design and implementationdecisions10 recorded as well as any discussions relatedto any issues that arise in dealing with them.Figure 4 shows the individual steps in this process stage.Stage 3.1: De�ne Constraints on Archi-tectureThis stage of the domain-engineering process identi�esthe overall technological, hardware, software, and per-formance constraints on possible implementations11. Ingeneral the following two questions must be addressedin various detail:1. What are the technology dependencies on the ele-ments identi�ed in Stage 2?2. What are the design implementation dependencieson the respective elements?Note: the domain engineer should be aware of a slightshift in emphasis on the background of the domain ex-pert in this stage of the domain-engineering process. In10Addressing design and implementation constraints relate toestablishing Context in the 3-C model.11Note: non-technical constraints such as documentation andtesting standards can also be addressed at this time.16

3.1.1 Define Software Constraints

A

A

A

A

3.1.2 Define Hardware Constraints

3.1.3 Define Performance Constraints

3.1.4 Define Design Constraints

3.1 Define Constraints on Architecture

A

3.2 Identify Relationships between Constraints and Concepts

A

3.3 Evaluate

FS

Figure 4: Stage 3: De�ne/Re�ne Domain-Speci�c Design and Implementation Constraintsprevious stages, the domain expertise was concentratedon the systems/requirements analysts or system engi-neer. In the stages to come, the software engineer playsan increasingly important role.Stage 3.1.1: De�ne Software Constraints1. What language or languages are implementationsto be written in?2. What operating system or run-time system mustthe software components interface with?3. What data-bases is the software to run o� of?4. What communication protocols is the software tofollow?5. What external software interfaces or software de-velopment standards must the software being de-veloped comply with?6. What documentation does the system customertypically require?7. How are the semantics of modules to be speci�ed(e.g., text, SEDL)?Stage 3.1.2: De�ne Hardware/Physical Con-straints1. What platforms are the applications in this domainlikely to run on?2. What does the user interface look like?

3. What hardware is the user likely to want applica-tions in this domain interface with?4. What space constraints exist on the individual el-ements that make up the applications in this do-main?5. What space constraints exist on the applications inthis domain?Stage 3.1.3: De�ne Performance Constraints1. What timing constraints exist on the individual el-ements that make up applications in this domain?2. What timing constraints exist on applications inthis domain?Stage 3.1.4: De�ne System Design Constraints1. What safety, fault tolerance, or other overall designconstraints could be applicable to applications inthis domain?Stage 3.2: Identify Relationships Be-tween Elements and ConstraintsThe goal of this stage in the domain-engineering processis to map the general design and implementation con-straints identi�ed in Stage 3.1 onto the domain-speci�c17

requirements and elements that were identi�ed in Stage2 { De�ne/Re�ne Domain-Speci�c Elements.If possible, issues, tradeo�s, and rationale should berecorded related to how the constraints a�ect the sub-sequent design and implementations of the domain-speci�c software architecture under development.1. What elements identi�ed in Stage 2 are a�ected bythe constraints identi�ed in the previous stages ofthis phase of the domain engineering process?2. How are these elements a�ected and what are thedesign and implementation trade-o�s that need tobe taken into consideration?Stage 3.3: Evaluate Results and Iterate ifNecessaryAgain, based on the goals of the domain-engineeringprocess, this stage may be iterated until the desired levelof detail in each requirement and element is achieved.Stage 3 Inputs1. Outputs from Stage 1, especially the block diagramand2. Outputs from Stage 2, especially the architecture,control and data ow diagrams, and rationale.Stage 3 Outputs1. List of constraints on the hardware used by appli-cations in the domain.2. List of constraints on the software used by applica-tions in the domain.3. List of constraints on the software developed aspart of applications in the domain.4. List of performance constraints on applications inthe domain.5. List of design constraints on applications in the do-main.6. List of implementation constraints on applicationsin the domain.7. A cross-reference of constraints to the functionalunits/elements in the domain.Stage 3 Validation ProcedureNote: design and implementation constraints are bothaddressed in this section. The domain engineer may �ndthat a system analyst is better able to comment on high-level design constraints, while an experienced software

engineer may be best suited to evaluate the low-leveldesign and implementation constraints. Validation thenbecomes one of establishing:1. concurrence of domain experts (system analystsand software engineers) on the completeness andaccuracy of the constraints identi�ed, and2. concurrence of potential customers or marketingpersonnel on the completeness and accuracy of theconstraints identi�ed.Stage 4: Develop Domain Archi-tectures/ModelsThe �rst three stages in this domain-engineering processhave focussed on domain analysis { explicitly capturingdomain-speci�c knowledge that oftentimes is implicitlyassumed as common knowledge by a domain expert.The last two stages deal with the design and analysisof a domain-speci�c software architecture and its re-alization through the population of the solution spacewith implementations (reusable software components).The unit of abstraction that is being manipulated atthis stage in the domain-engineering process is a modelor module. As in traditional top-down design, a high-level system design (or architecture) can be decomposedinto subsystems (or frameworks in the object-orientedparadigm) that themselves, in turn can be decomposedinto smaller subsystems, eventually resulting in the low-est level of abstraction the module. At each layer ofdecomposition, the architecture, subsystem, or modulecan be modeled, analyzed, and treated as a parameter-ized (con�gurable) black box.Di�erent architectures (high-level designs) may be re-quired for the same application domain because of cer-tain constraints placed on their realization (e.g., a mas-sively parallel host environment would be associatedwith a di�erent software architecture than a sequen-tial uni-processor host environment). Therefore, severaldomain-speci�c software architectures may have to bedesigned, within one application domain, to satisfy thepreviously identi�ed requirements and constraints.The goal of this stage in the domain-engineering processis to come up with generic architectures and to specifythe syntax and semantics of the modules or componentsthat form them.Figure 5 shows the individual steps in this process stage.18

A

4.1.3 Define Decision Taxonomy

A

4.1.4 Record Design Issues, Tradeoffs, and Rationale

A

4.1.1 Define Generic High−Level Design

A

4.1.2 Identify High−Level Components/Modules

4.1 Define Domain−Specific Software Architecture(s)

4.3 Link Models to Concepts and Requirements

A

4.2 Define Modules

A V

4.4 Evaluate

FS

Figure 5: Stage 4: Develop Domain Architectures/ModelsStage 4.1: De�ne Domain-Speci�c Soft-ware Architecture(s)Stage 4.1.1: De�ne a Generic High-Level Design1. What does a generic high-level design for appli-cations in this domain look like, based on theconstraints identi�ed in the previous stage of thedomain-engineering process?2. Are several architectures needed to address all theconstraints identi�ed in the previous stage of thedomain-engineering process?Stage 4.1.2: Identify High-Level Compo-nents/Modules1. What are the components that make up the high-level design(s)/architecture(s)?Stage 4.1.3: De�ne a Decision Taxonomy for Re-quirements and ConstraintsBased on the alternatives, options, and constraints iden-ti�ed in the previous stages of this domain-engineeringprocess, the domain engineer should construct a seriesof questions to allow the end-user to con�gure the ar-chitecture to meet the requirements and constraints ap-plicable to a particular context.Note: this decision taxonomy can be expressed in termsof \rules" in the form associated with expert systemknowledge representation.1. What is the �rst option that the end-user shoulddecide a value for?

2. What are the possible values to choose from?3. How does the selection of certain values constrainother decisions?4. What is the default value for this decision?5. How is the default value determined?6. What is the next design decision to be made?Stage 4.1.4: Record Design Issues, Trade-O�s,and Decision RationaleThe information recorded in this stage of the domain-engineering process should be a collection of the infor-mation gathered in previous stages in the process.1. Under what circumstances are certain choices bet-ter than other choices?2. What alternatives exist if a given choice is not avail-able?Stage 4.2: De�ne ModulesStage 4.2.1: Specify Interfaces For Each Module1. What are the operations associated with this mod-ule?2. What are the data types associated with the oper-ations in this module?3. What are the errors or exceptions associated withthis module?4. What are the constants associated with this mod-ule?19

5. What are the data objects associated with thismodule?6. What issues, decisions, rationale, etc. are associ-ated with this module?Stage 4.2.2: Specify Semantics of Each Module1. What is the functional behavior of this module?2. What are the entry and exit criteria for this mod-ule?3. What is the error or exception handling behaviorof this module?Stage 4.2.3: Specify Constraints on Each ModuleBased on information gathered in previous stages of thedomain-engineering process, one can recognize that thesolution space for each model is constrained by the var-ious types of conditions. The goal of this stage is toassociate those constraints to individual modules.Stage 4.2.3.1: Specify Performance/TimingConstraints1. What performance or timing constraints apply tothis module?Stage 4.2.3.2: Specify Dependency Constraints1. What modules/data need to be imported by thismodule?Stage 4.2.3.3: Specify Sequentiality/Order Con-straints1. What is the calling or timing sequence of operationswithin this module?2. What is the calling or timing sequence of operationsin this module with other modules?Stage 4.2.3.4: Specify Design Constraints1. What design constraints are associated with thismodule?2. What implementation standards need to be fol-lowed?

Stage 4.2.4: Specify Performance Characteris-tics of Each ModuleThe following information may be characteristic of thealgorithm selected. Since many algorithms may existthat provide the same semantic behavior, a family ofmodules may exist that can be di�erentiated by thischaracteristic.1. How much time do the operations in this moduletake to execute, based on certain data values?Stage 4.2.5: Identify Con�guration (Generic)Parameters For Each ModuleWhen creating a DSSA, a single-point solution is notdesirable. The goal of this process is to create multiple-point solutions to increase opportunities for reuse in dif-ferent contexts through adaptation and con�gurationparameters.1. Based on the decision taxonomy in Stage 4.1.3and the relationships identi�ed in Stage 2.1.5 Iden-tify Relationships Between Elements, how can thismodule be parameterized to increase its domain ofapplicability within the constraints of this applica-tion domain?2. Can the module interfaces be designed with special\hooks" to allow for future adaptability?Stage 4.2.6: Record Issues, Trade-O�s, and De-sign RationaleDepending on the domain analysis goals several modelsof the domain or portions of the domain may be createdas part of a study to determine optimal con�gurations oralgorithms based on certain assumptions, requirements,or constraints. The models, as well as the results orinsights gained from using these models or simulationsshould be incorporated into the knowledge base that isassociated with the DSSA environment.1. What issues were raised during interface design?2. What alternative approaches could have been takenand why?3. Why were things done the way they were done?Stage 4.3: Link Models to Elements andRequirementsThe goal of this stage in the domain-engineering processis to create a requirements cross-reference matrix show-ing what modules satisfy what requirements and whatportions of the problem space have been modeled.20

1. How do the modules relate to the elements de�nedin Stage 2?2. Which modules satisfy what requirements accord-ing to what constraints?3. Are all requirements satis�ed?4. Do all modules satisfy at least one requirement?5. What portions of the domain have been modeledfor what purposes?Stage 4.5: Evaluate Results and Iterate ifNecessaryAgain, based on the goals of the domain-engineeringprocess, this stage may be iterated until the desired levelof detail in each model/module is achieved.1. What subsystems can be further re�ned?2. What additional analysis needs to be performed orrecorded on the modules/models or architecturesthat currently de�ne the DSSA?Stage 4 InputsThe inputs to this stage consist of the inputs and out-puts of the previous stages.Stage 4 Outputs1. Domain-Speci�c Software Architecture(s)2. Domain-speci�c models and analysis results3. Mappings between models/modules/subsystemsand requirements identi�ed in Stage 2.4. Mappings between models/modules/subsystemsand elements identi�ed in Stage 2.5. Mappings between models/modules/subsystemsand terms that appear in the Dictionary de�nedin Stage 2.Stage 4 Validation Procedure1. Concurrence of domain experts (system analysts)on the completeness and accuracy of the modelsde�ned.2. Concurrence of domain experts (software engi-neers) on the completeness and accuracy of the in-terfaces to the modules described.3. Concurrence of domain experts on the issues raisedand rationale identi�ed.

Stage 5: Produce Reusable orGather WorkproductsThe last stage in this domain-engineering process fo-cuses on populating the domain-speci�c software archi-tecture(s) (high-level design(s)) with components thatmay be used to generate new applications in the prob-lem domain. If the goal of the domain analysis wasto build up a knowledge base in support of an exist-ing application, then clearly, this step is not needed.Because, in essence, this is a software development ef-fort, the domain experts who should be involved in thisstage of the process are the software engineers who pre-viously have created applications in this domain. Theyare best suited for identifying existing reusable com-ponents or components that can serve as a basis forcreating reusable components. Another option is toimport reusable components from some other domain.This is possible, especially in the case of low-level datastructures[1], utilities, and user interface software.Figure 6 shows the individual steps in this process stage.Stage 5.1: Develop/Collect the ReusableArtifactsThe issue being addressed at this stage in the domain-engineering process is how to determine the best sourceof components to populate the DSSAs. The options areto \make, buy, or modify" components that satisfy thesyntax and semantics of the interfaces de�ned in Stage4.2. Depending on the level of re�nement performedin Stage 4 and the availability of commercial o�-the-shelf software, or legacy code, interfaces may have to bemodi�ed, or the speci�cations modi�ed to account fordi�erences.Stage 5.1.1: Identify COTS Components1. What commercially available o�-the-shelf softwarecomponents are available that meet the module in-terface speci�cations de�ned in Stage 4.2?Stage 5.1.2: Identify In-House Components1. What existing in-house software components areavailable that meet the module interface speci�ca-tions de�ned in Stage 4.2?Stage 5.1.3: DetermineParameterization/Con�gurability Level1. What parameters make sense to have associatedwith certain modules based on the constraints iden-21

A

A

5.1.1 Identify COTS Components

5.1.2 Identify In−House Components

5.1 Identify Reusable Artifacts

A A

5.1.3 Determine Configurability

5.1.4 Determine Necessary Modifications

A

5.2 Develop Modules

A

5.3 Link Artifacts to Concepts/Requirements

S FFigure 6: Stage 5: Produce/Gather Reusable Workproductsti�ed in Stage 2 { De�ne/Scope Domain-Speci�cElements?Stage 5.1.4: Determine Necessary Modi�cations1. Do the candidate modules need to be modi�ed?If so how much will it cost to do so? What arethe impacts of changing the speci�cation de�ned inStage 4.2 instead?2. How do the constraints identi�ed in Stage 3 e�ectthe design and implementation of software compo-nents for the required modules.Stage 5.2: Develop Each ModuleStage 5.2.1: Implement Each Module1. What are the language or languages that moduleshould be implemented in?Stage 5.2.2: Test Each Module1. What test criteria exist for placing components intothe DSSA environment?Stage 5.2.3: Document Each Module1. What documentation criteria (e.g., on-line, Mil-Std., etc.) needs to be developed and incorporatedin the DSSA environment?Stage 5.2.4: Record Issues, Trade-O�s, and De-sign RationaleThis stage, as with stages of similar intent in otherphases of the domain-engineering process, poses theproverbial questions, \Why were things done they waythey were done?" and \Could they have been done dif-ferently?"

1. What tradeo�s were made in determining the im-plementations for the components?2. What tradeo�s were made in speed and complexityfor adaptability and con�gurability?Stage 5.3: Link Artifacts to Models, Ele-ments, and RequirementsThe domain engineer should create several cross-reference matrices correlating the reusable softwarecomponents that were implemented in this stage ofthe domain-engineering process with previous domain-speci�c resources (e.g., concepts, requirements, con-straints, and models/modules de�ned in the previousstages of the process).Note: it is important to point out that the softwareworkproducts created or gathered as part of this stagein the domain-engineering process do not always corre-spond one-to-one with the modules decomposed in Stage4 { Develop Domain Architectures/Models. For reasonsof e�ciency, or ease of implementation, module bound-aries may be crossed, but, these circumstances shouldbe adequately noted and justi�ed.1. How were the key elements identi�ed in Stage 2implemented?2. How were the requirements identi�ed in Stage 2met?3. How were the requirements identi�ed in Stage 2tested for?4. How were the constraints identi�ed in Stage 3 sat-is�ed?5. How were the semantics of the modules de�ned inStage 4 tested?Stage 5 InputsThe work e�orts for this stage of the domain engineer-ing process use the interface speci�cations generated in22

Stage 4 and related artifacts from existing systems iden-ti�ed in Stage 1.Stage 5 Outputs1. Reusable components and associated test cases anddocumentation2. Cross reference matrices of components to require-ments, constraints, and architectureStage 5 Validation Procedure\The proof is in the eating of the pudding."1. Consensus of software engineers on documentation,parameterization levels and implementation cor-rectness2. Prove that new applications can be readily gener-ated using the architecture and componentsConcluding RemarksThis document has presented a process for creating aDomain-Speci�c Software Architecture. Based on ex-perience, this process should be viewed as serving as aguideline that must be tailored to �t the characteristicsand resources available in each domain being analyzed.The ambitious nature of this process (i.e., long and de-tailed), re ect the desire for thoroughness as a tradeo�for timeliness. Therefore when applying any domainanalysis process, the user must evaluate the potentialreturn on investment for such activities and prioritizedthe level of detail and e�ort applied to meet their goals.References[1] G. Booch. Software Components with Ada. Ben-jamin/Cummings, 1987.[2] Ascent Logic Corporation. RDD-100 RequirementsDriven Design User's Guide. Technical Report Re-lease 3.0, Ascent Logic Corporation, San Jose, CA,August 1991.[3] K.C. Kang, S.G. Cohen, J.A. Hess, W.E. Novak,and A.S. Peterson. Feature-Oriented Domain Anal-ysis (FODA) Feasibility Study. Technical ReportCMU/SEI-90-TR-21, Software Engineering Insti-tute, November 1990.[4] W. Kunz and H.Q.J. Rittel. Issues as Elements ofInformation Systems. Technical Report WorkingPaper No. 131, Institut Fur Grundlagen Der Pla-nung I.A. University of Stuttgart, 1979.

[5] K.J. Lee and et al. An OOD Paradigm forFlight Simulators, 2nd Edition. Technical ReportCMU/SEI-88-TR-30, Software Engineering Insti-tute, 1988.[6] D.A. Marca and C.M. McGowan. SADT StructuredAnalysis and Design Technique. McGraw-Hill, NewYork, NY, 1988.[7] E.G. Mettala. Domain Speci�c Software Architec-tures, June 1990. Presentation at ISTO SoftwareTechnology Community Meeting.[8] D.L. Parnas. A Technique for Software ModuleSpeci�cation with Examples. Communications ofthe ACM, 15(5):330{336, May 1972.[9] R. Prieto-D�iaz. Domain Analysis for Reusabil-ity. In Proceedings of COMPSAC'87, pages 23{29,1987.[10] R. Prieto-Diaz. Reuse Library Process Model.Technical Report AD-B157091, IBM CDRL 03041-002, STARS, July 1991.[11] W. Tracz. A Conceptual Model for Megapro-gramming. ACM Software Engineering Notices,16(3):36{45, July 1991.[12] W.J. Tracz. Software Reuse Maxims. ACMSoftware Engineering Notes, 13(4):28{31, October1988.[13] P.S. Young and R.N. Taylor. Teamware: ProcessProgramming Support for Managers and Teams,July 1992..A Overview of STARS DomainAnalysis ActivitiesThe four high level stages in the STARS Domain Anal-ysis Process[10] are as follows.1. Prepare Domain Information� De�ne domain { do high-level functional anal-ysis (top-down)2. Classify Domain Entities� Identify and describe objects and operations(bottom-up) and construct thesauri.3. Derive Domain Models� consolidate top-down and bottom-up views tocreate a generic functional model based onreusable components.23

4. Expand Models and Classi�cation� apply and validate the models.Each stage in this process is described graphically usingthe Structured Analysis and Design Technique[6] usingSADT diagrams, which indicate the� inputs,� outputs,� controlling factors, and� mechanism { \agent that enable, conduct, performor execute the activity[10]".In addition, each stage contains a textual descriptionproviding rationale and goals as well as directions forcompleting the respective activity.The complete domain analysis process is outlined below:Stage 1 Prepare Domain InformationStage 1.1 De�ne domainStage 1.1.1 Select relevant informationStage 1.1.2 Bound domainStage 1.1.3 Establish global requirementsStage 1.1.4 Verify and validate de�nitionStage 1.2 Obtain domain knowledgeStage 1.2.1 Select sources of informationStage 1.2.2 Extract domain knowledgeStage 1.2.2.1 ReadStage 1.2.2.2 ConsultStage 1.2.2.3 StudyStage 1.2.2.4 LearnStage 1.2.3 Review acquired domain infor-mationStage 1.2.3.1 DiscussStage 1.2.3.2 EvaluateStage 1.2.3.3 IntegrateStage 1.2.3.4 ConsolidateStage 1.3 Do high level functional analysis (top-down)Stage 1.3.1 Identify major functional unitsStage 1.3.2 Find interrelationshipsStage 1.3.3 Specify generic subsystemsStage 1.3.4 Classify subsystemsStage 1.3.4.1 Analyze common featuresStage 1.3.4.1 Group and classifyStage 1.3.5 Select graphic representationmethodStage 2 Classify Domain Entities (bottom-up)Stage 2.1 Identify objects and operationsStage 2.1.1 Analyze elementsStage 2.1.2 Analyze requirements

Stage 2.1.3 Extract component descriptorsStage 2.1.4 Inspect documentationStage 2.1.5 Decompose statements by key-wordsStage 2.2 Abstract and classifyStage 2.2.1 Group termsStage 2.2.2 Give names to clustersStage 2.2.3 Arrange by facetsStage 2.2.4 Arrange by hierarchyStage 2.2.5 De�ne standard classi�cationtemplatesStage 2.2.5.1 Consult STARSstandardsStage 2.2.5.2 Check con- icts/duplication with other librariesStage 2.3 Expand basic classi�cationStage 2.3.1 Re�ne meaningsStage 2.3.2 Integrate new classes and termsStage 2.3.3 Group unclassi�ed termsStage 2.3.4 Give names to new clustersStage 2.3.5 De�ne new templatesStage 2.4 Construct thesauriStage 2.4.1 Find internal synonymsStage 2.4.2 Add external synonymsStage 2.4.3 Form thesaurus entriesStage 2.4.4 Verify entriesStage 3 Derive Domain Models (consolidate top-down and bottom-up)Stage 3.1 Group descriptors/classes under func-tional unitsStage 3.2 Review domain models (re�ne initialfunctional decomposition)Stage 3.3 Discover/de�ne new functional unitsStage 3.4 Rearrange structure (result: genericfunctional model)Stage 3.5 Select model representationsStage 4 Expand Models and Classi�cationStage 4.1 Apply models to applicationStage 4.2 Identify inconsistenciesStage 4.3 Update models and classi�cationStage 4.4 De�ne reusable structures24