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 / wisr6 / proceedings / ascii / tracz3.ascii < prev    next >
Text File  |  1993-10-19  |  17KB  |  587 lines
  1.  
  2.  
  3.  
  4.  
  5.           Design  Records:  A  Way  to  Organize Domain  Knowledge
  6.  
  7.  
  8.  
  9.                                  Will Tracz - Steve Shafer - Lou Coglianese
  10.  
  11.  
  12.  
  13.                                          IBM Federal Systems Company
  14.  
  15.                                            MD 0210, Owego, NY 13827
  16.  
  17.                                    Tel:  (607) 751-2169, fax:  (607) 751-6025
  18.  
  19.                                             Email: tracz@vnet.ibm.com
  20.  
  21.  
  22.  
  23.                                                          Abstract
  24.  
  25.  
  26.  
  27.            This  document  describes  the  Design  Records  being  develop ed as  part  of  the  Domain-
  28.        Specific Software Architecture Avionics Domain Application Generation Environment (DSSA-
  29.        ADAGE) Project1.  A design record aids in the generation of new avionics applications as well
  30.        as the maintenance of existing systems built using ADAGE. The purpose of a design record is
  31.        to serve as a vehicle for software understanding by functioning asa collection point for domain-
  32.        specific knowledge about the components that make up a Domain-Specific Software Architecture
  33.        (DSSA),
  34.  
  35.  
  36.            There are three kinds of design records used by ADAGE to describe the avionics software
  37.        architecture and components [1, 2 ].
  38.  
  39.           1.  Domain Model Design Record defines a collection of realms2 ,
  40.  
  41.           2.  Realm Design Record defines the interface for a collection of components, and
  42.  
  43.           3.  Component Design Record representsan (alternative) implementation or design choice.
  44.  
  45.  
  46.  
  47.        Keywords:Domain Analysis, Knowledge Representation, Software Reuse.
  48.  
  49.  
  50.        Workshop Goals: Facilitate the technical interchange of ideas and experience related to the
  51.        development and use of software components.
  52.  
  53.  
  54.        Working Groups: Knowledge Representation, Design for Reuse.
  55.  
  56.  
  57.  
  58. ___________________________________________________1
  59.      This effort is sponsored by the US Department of Defense Advanced Research Projects Agency in cooperation
  60. with the US Air Force Wright Laboratory Avionics Directorate under contract F33615-91-C-1788.
  61.    2 See Batory's [3 , 4] for a detailed treatment of creating layered designs using realms and type expressions.
  62.  
  63.  
  64.  
  65.                                                           Tracz- 1
  66.  
  67.  
  68. 1      Background
  69.  
  70.  
  71.  
  72. IBM  FSC  as  part  of  ARPA Domain-Specific  Software  Architecture  Program  has  been  actively
  73. pursueing the developement of tools and processes to support the generation and application of
  74. software architectures. One of the major focusses of this effort has been the creation of a "design
  75. record".  The  purpose  of  a  design  record  is  to  serve  as  a  vehicle  for  software  understanding  by
  76. functioning as a collection point for domain-specific knowledge about the components that make
  77. up a Domain-Specific Software Architecture (DSSA).ADAGE design records play a central role in
  78. 1) describing the avionics domain-specific software architecture and 2) integrating the tools that
  79. comprise the ADAGE environment.
  80.  
  81.  
  82. Two points merit distinction in their bearing on the design record:
  83.  
  84.  
  85.  
  86.     1. the  contents  of  the  ADAGE Component  Design  Record  (i.e., its  "data  elements")  are
  87.        patterned after those initially proposed by Bill Scherlis in [5].
  88.  
  89.     2. While a design record serves as a collection point for:
  90.  
  91.  
  92.            ffldomain-specific knowledge about components or design alternatives and
  93.            fflimplementation-specific knowledge about alternate implementations,
  94.  
  95.  
  96.        it does not provide information about their application, instantiation, or configuration. This
  97.        type of information, though similar in nature, is part of an application's design history.
  98.  
  99.  
  100.  
  101. 2      Position
  102.  
  103.  
  104.  
  105. The goal of a design record is to adequately describe a domain-specific software architecture and
  106. its software software components such that design decisions and component selections can be ac-
  107. complished without looking at implementations.
  108.  
  109.  
  110. Asset capture and re-capture is supported in ADAGE bythe design record, hypermedia browsing
  111. capability, and the domain engineering process [6].  The design record provides a "common data
  112. structure for system documentation and libraries [5]".
  113.  
  114.  
  115. The basic design record data elements, as proposed by Scherlis and arranged according to phases
  116. in the software life cycle, include:
  117.  
  118.  
  119.  
  120.     1. name/type,
  121.  
  122.     2. description,
  123.  
  124.     3. requirement specification fragments,
  125.  
  126.     4. design structure,
  127.  
  128.     5. design rationale,
  129.  
  130.     6. interface and architecture specifications and dependencies,
  131.  
  132.     7. PDL texts,
  133.  
  134.     8. code,
  135.  
  136.     9. configuration and version data, and
  137.  
  138.   10.  test cases.
  139.  
  140.        In addition to the "primary" lifecycle elements listed above, the following "secondary" ele-
  141.        ments aide in the (re-)use of the components by capturing additional information:
  142.  
  143.  
  144.  
  145.                                                           Tracz- 2
  146.  
  147.  
  148.   11.  metric data,
  149.  
  150.   12.  access rights,
  151.  
  152.   13.  search points,
  153.  
  154.   14.  catalog information,
  155.  
  156.   15.  library and DSSA links, and
  157.  
  158.   16.  hypertext paths.
  159.  
  160.        For  the  avionics  domain, the  ADAGE design  records  contain  the  basic  data  items  listed
  161.        above (with some domain-specific clarifications) in addition to some DSSA-ADAGE specific
  162.        items including:
  163.  
  164.   17.  models
  165.  
  166.   18.  constrants, and
  167.  
  168.   19.  data quality.
  169.  
  170.  
  171.  
  172. The  reader  should  note  that  because  the  design  record  is  a  dynamic  entity  in  that  its  contents
  173. grow as a component goes through the various stages in the software development life cycle, all
  174. component design records do not contain the same amounts of information.  In addition, certain
  175. design record elements may "inherit" values for other records they may be associated with (e.g., a
  176. realm component design record inherits the constraints of therealm it is a member of ).
  177.  
  178.  
  179.  
  180. 2.1     Types of Design Records
  181.  
  182.  
  183.  
  184. The goal of design records are to organize information associated with a domain-specific software
  185. architecture.  There are three kinds of design records usedby ADAGE to describe the avionics
  186. domain software architecture and components [1 , 2]:
  187.  
  188.  
  189.  
  190.     1. Domain Model Design Record defines a collection of realms,
  191.  
  192.     2. Realm Design Record defines the interface for a collection of components, and
  193.  
  194.     3. Component Design Record represents an (alternative) implementation or design choice.
  195.  
  196.  
  197.  
  198. The "component interface" found in a Realm Design Record includes not only the entry points,
  199. type definitions and data formats (e.g., Ada package specification), but a description of its function-
  200. ality, side effects, performance expectations, degree and kind ofassurance of consistency between
  201. specification and implementation (reliability), and appropriate test cases.
  202.  
  203.  
  204.  
  205. 2.1.1     Domain Model Design Record
  206.  
  207.  
  208.  
  209. The Domain Model Design Record defines a collection of realms. These show up as a list in the
  210. library and DSSA links element of the design record. The Domain Model Design Record
  211. has, as a minimum: a name, a description, and an interface/architecture specification, as well as
  212. a collection of administrative information (e.g., version number, catalog information, access rights,
  213. etc.).
  214.  
  215.  
  216.  
  217. 2.1.2     Realm Design Record
  218.  
  219.  
  220.  
  221. The Realm Design Record defines the interface for a collection of comp onents.  These show up
  222. as a list in the library and DSSA links element of thedesign record.  ARealm Design Record
  223.  
  224.  
  225.                                                           Tracz- 3
  226.  
  227.  
  228. defines either design decision or options (e.g., a list of sensors to choose from), or implementation
  229. alternatives (e.g., a list of stack implementations).
  230.  
  231.  
  232.  
  233. 2.1.3     Component Design Record
  234.  
  235.  
  236.  
  237. The Component Design Record may be used to describe three kinds of components:
  238.  
  239.  
  240.  
  241.     1. Domain Specific - map into problem space,
  242.  
  243.     2. Implementation Specific - map into solution space, and
  244.  
  245.     3. Domain Independent - general components that may be used in other domains.
  246.  
  247.  
  248.  
  249. Component Design Records normally have some sort of execution capability. This can take the form
  250. of an Ada package specification and body,  an executable SEDL specification, or a parameterized
  251. LILEANNA make statement indicating howsuch a component could be constructed.
  252.  
  253.  
  254.  
  255. 2.2     Design Record Creation
  256.  
  257.  
  258.  
  259. As  part  of  the  domain  engineering  process  described  in  [6], a  Comp onent  Design  Record  is
  260. created for each component in DSSA. As the DSSAreference architecture is configured and extended
  261. to meet the requirements of a new application using the Architecture-Based Development Process
  262. [7], additional information is recorded as part of a Design  History  Record (i.e., configuration
  263. data and design decision rationale). In addition, new design records are generated to account for
  264. extensions to the architecture, addition of components with unprecedented functionality, or new
  265. implementations of existing components.
  266.  
  267.  
  268.  
  269. 2.3     Design Record Evolution
  270.  
  271.  
  272.  
  273. Each generic component in the avionics DSSA has a design record with pointersto instances of
  274. the  design  record  (via  the  DSSA link  data  element).  The  design  history  records  for  instances
  275. of components "inherit" the elements of the generic while specializing those that are application
  276. specific. In particular:
  277.  
  278.  
  279.  
  280.     fflconfiguration  and  version  data indicate parametric values used to instantiate the com-
  281.        ponent and
  282.  
  283.     ffldesign rationale describe the reasons for their selection.
  284.  
  285.  
  286.  
  287. The resulting chain or information web is what hasb een called the "Design History" in ADAGE
  288. [8].
  289.  
  290.  
  291.  
  292. 3      Design  Record  Comparisons
  293.  
  294.  
  295.  
  296. This section compares the ADAGEdesign record data elements to the reusable software component
  297. information proposed by STARS (Software Technology for Adaptable, Reliable Systems), ASSET
  298. (Asset  Source  for  Software  Engineering  Technology),  RIG (Reuse  Interoperability  Group), and
  299. IBM's internal reuse repository.
  300.  
  301.  
  302.                                                           Tracz- 4
  303.  
  304.  
  305. 3.1     STARS Comparison
  306.  
  307.  
  308.  
  309. According to the STARS Reuse  Concept  of  Operations, Volume  I  [9], the following asset
  310. information "may be required for asset acceptance:"
  311.  
  312.  
  313.  
  314.     fflabstract,
  315.  
  316.     fflauthor/ownership information,
  317.  
  318.     fflauthor certificate of originality,
  319.  
  320.     fflcopyrights/patents,
  321.  
  322.     ffldistribution rights,
  323.  
  324.     ffldistribution restrictions,
  325.  
  326.     fflliability statements for use/misuse,
  327.  
  328.     fflmaintenance agreements,
  329.  
  330.     fflenvironmental dependencies, and
  331.  
  332.     ffldependencies on other assets.
  333.  
  334.  
  335.  
  336. The ADAGE design record completely supports the inclusion ofthis information.
  337.  
  338.  
  339.  
  340. 3.2     ASSET Comparison
  341.  
  342.  
  343.  
  344. According  to  the  ASSET Submittal  Guidelines  [10 ], the  following  documentation  is  recom-
  345. mended for asset acceptance into the ASSET Repository:
  346.  
  347.  
  348.  
  349.     ffl"an abstract,
  350.  
  351.     ffla user's guide or instructions on how to use,
  352.  
  353.     ffla list of files making up the asset (preferably in compilation order),
  354.  
  355.     fflinstallation/implementation instructions,
  356.  
  357.     fflsample input/output,
  358.  
  359.     ffldesign and/or requirements documents,
  360.  
  361.     ffltest programs, procedures an/or results,
  362.  
  363.     ffldescription of the environment under which the asset was develop ed/tested,
  364.  
  365.     fflknown limitations of the software,
  366.  
  367.     ffla list of tools needed to interpret or used the asset,
  368.  
  369.     fflwarranties or disclaimers,
  370.  
  371.     fflstatement of distribution rights/licenses, and
  372.  
  373.     ffllist of special formats of files (e.g., Postscript, InterLeaf, SGML)."
  374.  
  375.  
  376.  
  377. The ADAGE design record completely supports the inclusion ofthis information.
  378.  
  379.  
  380.  
  381. 3.3     RIG Comparison
  382.  
  383.  
  384.  
  385. The Reuse Interoperability Group (RIG), a defacto standards organization, whose goal is to facili-
  386. tate cross reuse repository information exchange, in A BasicInteroperability Data Model for
  387. Reuse Libraries [11 ] identified the following subset of the "Uniform Data Model", which defines
  388. the minimal set of information that reuse libraries should be able to exchange about assets in order
  389. to interoperate:
  390.  
  391.  
  392.                                                           Tracz- 5
  393.  
  394.  
  395.     fflabstract,
  396.  
  397.     ffladdress of contributor/owner,
  398.  
  399.     fflcost/fee to use  ,
  400.  
  401.     ffldate of information,
  402.  
  403.     ffldistribution statement,
  404.  
  405.     ffldomain,
  406.  
  407.     fflelement type (e.g., code, test suite, make file),
  408.  
  409.     fflemail address where asset resides ,
  410.  
  411.     fflfax # where asset resides ,
  412.  
  413.     fflidentification number ,
  414.  
  415.     fflkeywords,
  416.  
  417.     ffllanguage,
  418.  
  419.     fflMedia asset is obtainable in ,
  420.  
  421.     fflname,
  422.  
  423.     fflrestrictions (e.g., legal),
  424.  
  425.     fflsecurity/classification,
  426.  
  427.     ffltarget environment,
  428.  
  429.     ffltelephone # where asset resides ,
  430.  
  431.     fflunique identifier ,
  432.  
  433.     fflversion, and
  434.  
  435.     fflversion date.
  436.  
  437.  
  438.  
  439. This  Basis  Interoperability  Data  Model  (BIDM) is  derived  from  the  Common  Data  Model  de-
  440. fined in the Asset Library OpenArchitecture Framework (ALOAF) [12 ] and the STARS Repository
  441. Guidelines and Standards [13 ].
  442.  
  443.  
  444. With the exception of those items indicated with an " ", the ADAGE design record supports the
  445. inclusion of the RIG local "attributes" for component classes.
  446.  
  447.  
  448.  
  449. 3.4     IBM Corporate Reuse Environment (CRE) Comparison
  450.  
  451.  
  452.  
  453. IBM's internal use only software reuseto ol,CRE (Corporate Reuse Environment) is a sophisticated
  454. repository of tools for managing libraries of reusable softwarecomponents.  The "Software Element
  455. Types" required for entry into the repository include:
  456.  
  457.  
  458.  
  459.     fflabstract,
  460.  
  461.     fflchange history,
  462.  
  463.     ffldependencies,
  464.  
  465.     ffldesign,
  466.  
  467.     fflinterfaces,
  468.  
  469.     ffllegal,
  470.  
  471.     fflload module,
  472.  
  473.     fflmetrics,
  474.  
  475.     fflmiscellaneous project information,
  476.  
  477.     fflob jectmo dule,
  478.  
  479.     fflperformance analysis,
  480.  
  481.  
  482.                                                           Tracz- 6
  483.  
  484.  
  485.     fflproduct documentation,
  486.  
  487.     fflreferences to other documents or components,
  488.  
  489.     fflrequirements for use and adaptation,
  490.  
  491.     fflrestrictions and side-effects,
  492.  
  493.     fflreuse,
  494.  
  495.     fflsample use,
  496.  
  497.     fflsource code,
  498.  
  499.     fflspecification (formal),
  500.  
  501.     ffltest materials,
  502.  
  503.     fflusage information, and
  504.  
  505.     fflvariations:
  506.  
  507.  
  508.  
  509. References
  510.  
  511.  
  512.  
  513.   [1] S. Shafer and L. Coglianese, "Avionics Type Expressions:  RealmDefinitions and an Exam-
  514.       ple  System," Tech.  Rep.  ADAGE-IBM-93-07, IBM  Federal  Systems  Company, April  1993.
  515.       Preliminary Version.
  516.  
  517.  
  518.   [2] D. Batory, "A Domain Model for Avionics Software," Tech. Rep. ADAGE-UT-93-03, Univer-
  519.       sity of Texas at Austin, May 1993.
  520.  
  521.  
  522.   [3] D. Batory and et al., "GENESIS: An Extensible Database ManagementSystem," IEEE Trans-
  523.       actions on Software Engineering, March 1986.
  524.  
  525.  
  526.   [4] D. Batory and S. O'Malley, "The Design and Implementation of Hierarchical Software Sys-
  527.       tems," Tech. Rep. TR-91-22, University of Texas, 1991.
  528.  
  529.  
  530.   [5] W. Scherlis, "DARPA Software Technology Plan," in Proceedings of ISTO Software Technology
  531.       Community Meeting, June 27-29 1990.
  532.  
  533.  
  534.   [6] W. Tracz and L. Coglianese, "DSSA Engineering Process Guidelines," Tech. Rep. ADAGE-
  535.       IBM-92-02A, IBM Federal Systems Company, December 1992.
  536.  
  537.  
  538.   [7] L. Coglianese and W. Tracz,"Architecture-Based Development Process Guidelines for Avionics
  539.       Software," Tech. Rep. ADAGE-IBM-92-02, IBM Federal Systems Company, December 1992.
  540.  
  541.  
  542.   [8] W. Tracz and L. Coglianese, "DSSA-ADAGE Operational Scenarios and System Vision," Tech.
  543.       Rep. ADAGE-IBM-92-01B, IBM Federal Systems Company, April 1992.
  544.  
  545.  
  546.   [9] "STARS Reuse Concepts Volume I - Conceptual Framework for Reuse Processes,"Tech. Rep.
  547.       STARS-TC-04040/001/00, The  Boeing  Company, IBM FSC,  and  Paramax  Systems  Corp.,
  548.       February 1992.
  549.  
  550.  
  551. [10]  "ASSET Submittal Guidelines Version 1.0," Tech. Rep. SAIC-92/7625&00, Asset Source for
  552.       Software Engineering Technology and IBM FSC, December 1992.
  553.  
  554.  
  555. [11]  R.  T.  C.  .  (TC2), "A  Basic  Interoperability  Data  Model  for  Reuse  Libraries,"  Tech.  Rep.
  556.       SDS-0001 v.2, Reuse Library Interoperability Group (RIG), February 1993.
  557.  
  558.  
  559. [12]  "Asset Library Open Architecture Framework,"  Tech. Rep. Contract No. F19628-88-D0031,
  560.       Publication No. GR-07670-1317,  Boeing Company,  IBM  FSC, and UnisysDefense Systems,
  561.       Inc., April 1992.
  562.  
  563.  
  564.                                                           Tracz- 7
  565.  
  566.  
  567. [13]  "Repository  Guidelines  &  Standards  for  the  STARS Contract," Tech.  Rep.  Contract  No.
  568.       F19628-88-D-0032, CDRL No. 0460, IBM System Integration Division,March 1989.
  569.  
  570.  
  571.  
  572. 4      Biography
  573.  
  574.  
  575.  
  576. Will Tracz isa senior programmer at the Owego Laboratory of the IBM Federal Systems Company
  577. where he is currently a DARPA PI (Principal Investigator) on the DSSA-ADAGE Project. He is a
  578. member of IBM Corporate Reuse Council and IBM FSC Reuse Steering Committee as well as editor
  579. of the IBM Corporate Programming Reuse Newsletter and column editor for IEEE Computer.  His
  580. book, Software Reuse: Emerging Technology, published (1988) by IEEE Computer Society Press,
  581. paints a broad picture of the technical, economic,p edagogical and so cial issues facing the transfer
  582. of software reuse technology into the workplace.
  583.  
  584.  
  585.  
  586.                                                           Tracz- 8
  587.