home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr4 / proceedings / detex / tracz.detex < prev    next >
Text File  |  1992-04-05  |  12KB  |  321 lines
  1.  [12pt] article 
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.   An Outline for a Domain Specific Software Architecture Engineering
  11. Process 
  12.  
  13.   Will Tracz Lou Coglianese 
  14. IBM Corporation 
  15. Federal Sector Division 
  16. MD 0210 
  17. Owego, NY 13827-1298 
  18.  
  19.    
  20.  
  21.  
  22.   
  23.  
  24.   
  25.    ``In order to reuse software, there needs to be software to reuse.'' 
  26.  
  27.  
  28.   .25in 
  29.  
  30. One of the dilemmas  that has prevented software developers from reusing
  31. software is the lack of software artifacts to use or the existence of
  32. artifacts that are difficult to integrate.
  33. Domain Specific Software Architectures (DSSAs) have been proposed in order
  34. to address these issues.
  35. A DSSA not only provides a framework for reusable software
  36. components to fit into, but captures the design rationale and provides
  37. for a degree of adaptability.
  38. This paper presents an outline for a Domain Specific Software Architecture
  39. engineering process.
  40.  
  41.   0.3in 
  42.  
  43.    Keywords:  Domain Analysis, Domain Specific Software Architecture,
  44. Domain Engineering
  45.  
  46.  
  47.  
  48.  
  49.   Introduction 
  50.  
  51. The purpose of this paper is to outline a process  Note:
  52. a process is a series of steps or stages with entry and exit criteria and
  53. tasks to follow at each phase as well as a way on verifying if
  54. what you are doing is any good. 
  55. currently under development,
  56. that can be used to generate a Domain-Specific Software Architecture (DSSA).
  57. It is based on the work of Ruben Prieto-Diaz  and
  58. Sholom Cohen .
  59. The fundamental premises of this work are that:
  60.   
  61.      an application can be defined by a set of needs that it fulfills,
  62.      user needs can be mapped into a set of requirements that meet
  63.          those needs,
  64.      requirements can be met in a number of ways,
  65.      implementation constraints limit the number of ways requirements
  66.          can be met.
  67.  
  68.  
  69. The goal of the process is to map user needs into system and software
  70. requirements that, based on a set of implementation constraints, define
  71. a DSSA.
  72. The separation of user needs from system requirements and implementation
  73. constraints differentiates this process from previous work.
  74. In particular most domain analysis processes do not differentiate between
  75. functional requirements and implementation constraints, but rather simply
  76. classify them under the heading of ``requirements''.
  77. Similarly, this process differentiates between the System Architecture
  78. and the Software Architecture that is part of it.
  79.  
  80.  
  81. Another difference between this approach to domain engineering and other
  82. domain analysis approaches (e.g., Prieto-Diaz ) is that
  83. case-based reasoning and reverse engineering are not central mechanisms for
  84. identifying reusable resources, but rather existing applications are used as
  85. vehicles to validate the architectures that are derived, top-down, from
  86. generalized user requirements  The reuse of existing artifacts is
  87. not the central goal of the proposed Domain Engineering process, but rather
  88. the development of a reusable architecture into which, well-specified
  89. components can be integrated. .  
  90.  
  91. At the top-most level there are 5 stages in the process.
  92. Each stage is further broken into sub-steps or stages.
  93. Furthermore, this process is concurrent, recursive, and iterative, therefore
  94. completion may require several passes through each stage with additional
  95. levels of detail being addressed, or new insights (or oversights) requiring
  96. further definition or analysis.
  97. For example, during    Stage 1: Defining/Scoping the
  98. Domain , one is concurrently identifies key aspects of the domain, which
  99. is part of    Stage 2.2: Defining a Domain Vocabulary .
  100.  
  101.  
  102.  
  103.  
  104. The five stages in the DSSA Definition Process are:
  105.  
  106.   
  107.         Define/Scope the Domain 
  108.      
  109.         Define what can be accomplished --- emphasis is on user's needs.
  110.     
  111.         Define/Refine Domain Specific Concepts/Requirements 
  112.      
  113.         Similar to Requirements Analysis --- emphasis is on problem space.
  114.     
  115.         Define/Refine Domain Specific Implementation Constraints 
  116.      
  117.         Similar to Requirements Analysis --- emphasis is on solution space.
  118.     
  119.         Develop Domain Architectures/Models 
  120.      
  121.         Similar to High-Level Design --- emphasis is on defining
  122.             module/model interfaces and semantics.
  123.     
  124.         Produce Reusable Workproducts 
  125.      
  126.         Implementation of reusable artifacts (e.g., code,
  127.             documentation, etc.).
  128.     
  129.  
  130.  
  131. The remaining material in this paper consist of a breakdown
  132. of the stages listed above.
  133. A detailed description of each stage is found in , which
  134. is currently under development.
  135. Each stage consists of a series of questions to be answered and a list
  136. of outputs to be generated.
  137.  
  138.   Domain Engineering Process Overview 
  139.  
  140. The proposed Domain Engineering process consists of the following steps:
  141.   
  142.      [Stage 1]    Define/Scope the Domain 
  143.      
  144.         [Stage 1.1] Define goals of domain modeling.
  145.         [Stage 1.2] Define the domain.
  146.         
  147.           [Stage 1.2.1] Identify what is    inside  the domain.
  148.           [Stage 1.2.2] Identify what is    outside  the domain.
  149.           [Stage 1.2.3] Identify what is on the    borders  of the domain
  150.               (input/output).
  151.       
  152.        [Stage 1.3] Define Domain Specific Resources
  153.         
  154.            [Stage 1.3.1] Define    who  you have to work with.
  155.            [Stage 1.3.2] Define    what  you have to work with.
  156.            [Stage 1.3.3] Define    how  you will verify the models.
  157.        
  158.         [Stage 1.4] Define the    domain of interest  (subset of
  159.              work that could be done).
  160.     
  161.      [Stage 2]    Define/Refine Domain Specific
  162.          Concepts/Entities/Requirements 
  163.       
  164.         [Stage 2.1] Define a block diagram architecture (E/R Diagram).
  165.         
  166.            [Stage 2.1.1] Identify concepts/entities (behavior, temporal,
  167.                and data) in the domain.
  168.            [Stage 2.1.2] Identify attributes of concepts/entities.
  169.            
  170.               [Stage 2.1.2.1] Identify required/essential/mandatory
  171.                   concepts/entities.
  172.               [Stage 2.1.2.2] Identify optional concepts/entities.
  173.               [Stage 2.1.2.3] Identify alternative concepts/entities.
  174.               [Stage 2.1.2.4] Identify requirements common from
  175.                   application to application
  176.               [Stage 2.1.2.5] Identify requirements that vary from
  177.                   application to application.
  178.           
  179.            [Stage 2.1.3] Identify relationship between concepts/entities.
  180.            
  181.               [Stage 2.1.3.1] Identify ``is a/a kind of'' relationships
  182.                   between concepts.
  183.               [Stage 2.1.3.2] Identify ``consists of'' relationships
  184.                   between concepts.
  185.               [Stage 2.1.3.3] Identify ``uses/needs'' relationships
  186.                   between concepts.
  187.           
  188.            [Stage 2.1.4] Classify and cluster common concepts.
  189.            [Stage 2.1.5] Record issues, trade-offs,  and rationale.
  190.            [Stage 2.1.6] Create a Domain Description Document.
  191.        
  192.         [Stage 2.2] Create a Domain Vocabulary Dictionary.
  193.         
  194.            [Stage 2.2.1] Create a Domain Thesaurus (list of synonyms).
  195.        
  196.         [Stage 2.3] Create a High-Level Requirements Specification
  197.             document.
  198.         [Stage 2.4] Refine concepts/entities already identified to reflect
  199.             desired level of detail.
  200.     
  201.      [Stage 3]    Define/Refine Domain Specific Implementation
  202.  Constraints. 
  203.      
  204.         [Stage 3.1] Define general implementation constraints on the
  205.  architecture.
  206.         
  207.            [Stage 3.1.1] Define general software constraints (e.g.,
  208.                programming language, run-time system, or
  209.                Operating System)
  210.            [Stage 3.1.2] Define general hardware/physical constraints
  211.                (e.g., platform, sensors, or appearance).
  212.            [Stage 3.1.3] Define general performance constraints (e.g.,
  213.                response time, accuracy).
  214.            [Stage 3.1.4] Define general mission constraints (e.g., fault
  215.                tolerance, security, or safety).
  216.        
  217.         [Stage 3.2] Identify relationships between concepts and constraints.
  218.     
  219.      [Stage 4]    Develop Domain Architectures/Models. 
  220.      
  221.         [Stage 4.1] Define a Domain Specific Software Architecture or
  222.  Architectures.
  223.         
  224.            [Stage 4.1.1] Define a decision taxonomy for requirements and
  225.  constraints
  226.                for each architecture.
  227.            [Stage 4.1.2] Record design issues, trade-offs, and decision
  228.  rationale.
  229.        
  230.         [Stage 4.2] Specify interfaces for each module (operations and
  231.  operands).
  232.         
  233.           [Stage 4.2.1] Specify semantics of each module (behavior).
  234.           [Stage 4.2.2] Specify constraints on each module (e.g., entry/exit
  235.  criteria).
  236.           
  237.              [Stage 4.2.2.1] Specify performance/timing constraints.
  238.              [Stage 4.2.2.2] Specify dependency (layering)  constraints.
  239.              [Stage 4.2.2.3] Specify sequentiality/order (operational)
  240.  constraints.
  241.              [Stage 4.2.2.4] Specify mission constraints.
  242.          
  243.           [Stage 4.2.3] Specify performance characteristics of each model.
  244.           [Stage 4.2.4] Identify configuration (generic) parameters for each
  245.  model.
  246.           [Stage 4.2.5] Record issues, trade-offs and design rationale.
  247.        
  248.         [Stage 4.3] Link models to concepts and requirements.
  249.         [Stage 4.4] Refine a Domain Specific Software Architecture or
  250.  Architectures to
  251.             reflect desired level of detail.
  252.     
  253.      [Stage 5]    Produce Reusable Workproducts. 
  254.      
  255.         [Stage 5.1] Develop the reusable artifacts (e.g., code,
  256.  documentation, test
  257.             cases, etc.)
  258.         
  259.            [Stage 5.1.1] Determine parameterization/configurability level
  260.  desired.
  261.            [Stage 5.1.2] Implement each module.
  262.            [Stage 5.1.3] Test each module.
  263.            [Stage 5.1.4] Document each module.
  264.            [Stage 5.1.5] Record issues, trade-offs and design rationale.
  265.        
  266.         [Stage 5.2] Link artifacts to models, concepts, and requirements.
  267.         [Stage 5.3] Link documentation to models, concepts, and
  268.  requirements.
  269.     
  270.  
  271.  
  272.   plain 
  273.  
  274.  
  275.   0.7in 
  276.  
  277.  
  278.       About the Authors  
  279.  
  280.   .4in 
  281.  
  282.  
  283.  
  284.      Will Tracz  
  285.  
  286.   .25in 
  287.  
  288. Will Tracz is a senior programmer at the Owego Laboratory of the IBM
  289. Federal Sector Division specializing in the technical and non-technical
  290. aspects of software reusability.  He is a member of IBM Corporate Reuse
  291. Council and IBM FSD Reuse Steering Committee as well as an editor for the
  292. IBM Corporate Programming Reuse Newsletter.  Tracz has written over 25
  293. publications on software reuse, programming languages, and microprogramming.
  294. He has given keynote addresses as several workshops and conferences on
  295. software reuse.  His book,    Software Reuse: Emerging Technology ,
  296. published by IEEE Computer Society Press, 1988, paints a broad picture of
  297. the technical, economic, pedagogical and social issues facing the transfer
  298. of software reuse technology into the work place.   Currently, Tracz is
  299. co-principle investigator for the DARPA Domain Specific Software Architecture
  300. project focusing on the Avionics application domain.
  301.  
  302.   .4in 
  303.  
  304.  
  305.       Lou Coglianese  
  306.  
  307.   .25in 
  308.  
  309. Lou Coglianese is a senior programmer at the Owego Laboratory of the IBM
  310. Federal Sector Division specializing in large-scale software reuse as
  311. it applies to Avionics and ESM real-time software development.
  312. He was the
  313. designer and developer of the Reusable Avionics Ada Software Proof-of-concept
  314. program as well as the developer of Owego Software Component Guidelines for
  315.  Domain
  316. Analysis and Large Scale Reusable Software.
  317. Coglianese is the former chair of the Owego Reusable Software Advisory Board.
  318. Currently he is co-principle investigator for the DARPA Domain Specific
  319. Software Architecture project focusing on the Avionics application domain.
  320.  
  321.