Acm Sigsoft Software Engineering Notes Vol 17 No 3 Jui 1992 Page 27 Domain Analysis Working Group Report -first International Workshop on Software Reusability Previous Workshop Results Domain Analysis Purposes Representations --a Layered Approach Domain Analysis Methodology Domain Analysis Perspecti
Acm Sigsoft Software Engineering Notes Vol 17 No 3 Jui 1992 Page 27 Domain Analysis Working Group Report -first International Workshop on Software Reusability Previous Workshop Results Domain Analysis Purposes Representations --a Layered Approach Domain Analysis Methodology Domain Analysis Perspecti
复制标题
Acm Sigsoft 软件工程笔记第 17 卷第 3 期 Jui 1992 第 27 页 领域分析工作组报告 - 第一届软件可重用性国际研讨会 以前的研讨会结果 领域分析目的 表示——分层方法 领域分析方法论 领域分析视角
DOI：
--
复制
发表时间：
--
期刊：
影响因子：
--
通讯作者：
Brock Motta
中科院分区：
文献类型：
--
作者：
W. Tracz;Guillermo Arango;bullet Kim;Harris;Prieto;Brock Motta
本报告记录了工作组在推进软件重用技术方面取得的进展(或缺乏进展)。因此，它的目的是作为未来领域分析研讨会的垫脚石。本着研讨会主讲人彼得·弗里曼的精神，这份报告提供了一个参照点，这样其他人就可以“站在我们的肩膀上，而不是绊倒我们的脚趾”。本报告的编排如下。首先，对研讨会组织者(Pat Hall)和协调员(Rub6n Prieto-Diaz)提出的研究问题进行了总结，并结合一些背景材料进行了说明。然后是对领域分析工作组成员所确定的问题的说明。工作组讨论的主要问题包括：·最近的讲习班成果、·领域分析的目标/目的、·所涉代表性和·领域分析方法/过程比较。上述每一问题依次加以论述，包括工作组成员对每一问题的意见。我要感谢下面列出的领域分析工作组成员在工作会议期间的积极贡献(工作组成员经常发现自己存在激烈的分歧)，以及他们在编辑本报告方面的帮助：工作组Challenging Pat Hall在研讨会开始时的全体会议上，向研讨会(和潜在的工作组成员)提出了以下一系列关于领域分析的问题：·它是什么？·它的范围是什么？·我们应该使用什么表示法(符号和形式主义)？·什么方法和过程将对您有所帮助？他提出了领域分析的工作定义，源于Jim Neighbors的博士论文[8]：“(领域分析是)在特定问题领域中识别一类类似系统的对象和操作的活动。”Rub6n Prieto-Diaz将领域分析定义为“识别、捕获和组织开发软件系统中使用的信息的过程，目的是在创建新系统时使其可重用[10]。”注：作为领域分析作为一个研究领域出现的反映，目前还没有一致的领域分析定义或过程。Rub6n Prieto-Diaz观察到[L 1]，域分析通常是一个特别的过程，人们只有在通过构建几个“同类”系统并使用这种经验来识别和隔离重复操作来获得域经验之后才能执行。一旦实现了这一点，就可以将操作封装为…
This report documents the progress (or lack-thereof) made by the Working Group in advancing the state of art of software reuse. As such, it is intended to serve as a stepping stone for future workshops on Domain Analysis. In the spirit of the workshop's keynote speaker Peter Freeman, this report provides a reference point so that others may "stand on our shoulders, not stumble over our toes." The organization of this report is as follows. First the research questions raised by the workshop organizer (Pat Hall) and coordinator (Rub6n Prieto-Diaz) are summarized and placed in context with some background material. This is followed by a description of the issues identified by the Domain Analysis Working Group members. The key issues addressed by the working group included: • Recent Workshop Results, • Goals/Purpose of Domain Analysis, • Representation Implications, and • Domain Analysis Methodology/Process Comparison. Each of the above issues are addressed in turn, including observations on each issue made by members of the working group. I would like to thank the Domain Analysis working group members listed below for their spirited contributions (working group members often found themselves in violent agreement) during the working sessions and their assistance in editing this report: Working Group Challenge Pat Hall, in a plenary session at the beginning of the workshop, challenged the workshop (and potential working group members) with the following list of questions on Domain Analysis: • What is it? • What is its scope? • What representation (notations and formalism) should we use? • What methods and process will help you? He presented a working definition of Domain Analysis derived from the Ph.D. dissertation of Jim Neighbors[8]: "(Domain Analysis is) the activity of identifying objects and operations of a class of similar systems in a particular problem domain." Rub6n Prieto-Diaz defined Domain Analysis as "a process by which information used in developing software systems is identified, captured, and organized with the purpose of making it reus-able when creating new systems[10]." Note: As a reflection of the emergence of Domain Analysis as a research area, there currently exists no consensus Domain Analysis definition, or process. Rub6n Prieto-Diaz has observed[l 1] that Domain Analysis is often an ad hoc process one can perform only after gaining domain experience by constructing several "same kind" systems and using this experience to identify and isolate recurring operations. Once this is achieved, the operations can be encapsulated …