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 / solderitsch_1.detex < prev    next >
Text File  |  1992-04-05  |  15KB  |  307 lines
  1.  [12pt] article 
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.   Asset Library Open Architecture Framework --  
  11.              Sharing Reusable Assets 
  12.  
  13.   James Solderitsch  
  14.         John Thalhamer  
  15.          
  16.         Valley Forge Laboratories  
  17.         Unisys Defense Systems Inc.  
  18.         Paoli, PA 19301  
  19.         E-mail: jjs@prc.unisys.com  
  20.                 john@prc.unisys.com  
  21.  
  22.    
  23.  
  24.  
  25.   
  26. Reuse, along with software engineering environments and processes,
  27. is one of the primary software
  28. technical areas being addressed within the
  29. STARS (Software Technology for Adaptable, Reliable Systems) program.
  30. Under the envisioned paradigm called    mega-programming 
  31. by DARPA/SISTO program director Barry Boehm,
  32. applications will be built using a component based approach,
  33. rather than constructing them a line at a time.
  34. The chosen components will be reused
  35. and/or constructed from existing systems, rather than created from scratch.
  36. And the components used in the application construction
  37. will be based on domain-specific architectures and open interface standards.
  38. The STARS Asset
  39. Library Open Architecture Framework (ALOAF) addresses the exchange of
  40. reusable assets among diverse libraries, and the definition of an asset
  41. library platform upon which portable reuse tools may be constructed.
  42.  
  43.   0.3in 
  44.    Keywords:  library, architecture, software engineering environment, 
  45. standards, services, data model
  46.  
  47.  
  48.  * Introduction 
  49.  
  50. A reuse-based approach to software engineering places the emphasis on the
  51. reuse and integration of existing software components and systems, rather
  52. than the creation of software components from scratch.  To support this
  53. approach, automated reuse libraries have been, and are being, created.
  54. The concept of reuse of components is applicable to reuse libraries
  55. themselves.  Reuse libraries consist of a set of components that are
  56. suitable candidates for reuse and sharing.  These include the components
  57. (or assets) stored within a library as well as the components that make up
  58. an automated library system and reuse library tools.
  59.  
  60. The STARS (Software Technology for Adaptable, Reliable Systems) Asset
  61. Library Open Architecture Framework (ALOAF) addresses the exchange of
  62. reusable assets among diverse libraries, and the definition of an asset
  63. library platform upon which portable reuse tools may be constructed.  Asset
  64. interchange and asset service interfaces are critical elements in achieving
  65. a broader objective---asset libraries which interoperate to such an extent
  66. that the boundaries between individual libraries become invisible to the
  67. end user.  In general terms, this is the STARS vision of ``seamless''
  68. library interoperation.
  69.  
  70.  * Why ALOAF 
  71.  
  72. The ability to make effective use of previously
  73. created assets, be they software components, design artifacts, textual
  74. documents, etc., is viewed as a
  75. critical factor in the reduction of application development and maintenance
  76. costs, along with improved reliability.
  77. Many efforts both within and external to the STARS program
  78. have addressed
  79. the development and establishment of asset libraries
  80. (also referred to as reuse repositories, software depositories, ...).
  81. Each of these reuse projects has its respective merits and unique
  82. qualities.  The ALOAF does not seek to stifle the creativity
  83. nor inventiveness being exhibited in the development of new reuse methods,
  84. environments, and tools.
  85. Rather, the purpose of the ALOAF is to allow reuse projects to
  86. benefit cooperatively from each other's work.
  87. Examples of such cooperative benefit are:
  88.   
  89.     [] Assets stored within one asset library may be interchanged
  90.    with a completely different asset library,
  91.    with descriptive asset information being exchanged as well.
  92.    This allows diverse, heterogeneous asset libraries to share assets,
  93.    enabling the construction of applications which may make use of the
  94.    best and newest components that are available.
  95.  
  96.     [] A reuse tool created for one asset library system may be
  97.    easily ported to another asset library system when the reuse tool
  98.    and the asset library systems
  99.    conform to the ALOAF service model interface.
  100.    This allows asset library systems to be easily enhanced with
  101.    additional reuse-based tools.
  102.  
  103. Thus, reuse technology, methods, and assets as a whole may rapidly
  104. expand and
  105. facilitate a shift to reuse-based development and engineering.
  106.  
  107. The ALOAF focuses on the needs of STARS asset libraries, as well as
  108. other DoD-related asset/reuse systems with which STARS asset libraries
  109. will interoperate.
  110. Past, current, and near-term anticipated work related to the asset library
  111. systems of the STARS program serve as a primary basis for the ALOAF. 
  112. It is beyond the scope of the
  113. initial work of the ALOAF to address and consider all reuse issues
  114. associated with every existing and potential asset/reuse library.
  115. In future work, the scope of the ALOAF will be broadened to encompass
  116. additional relevant and appropriate asset/reuse libraries.
  117.  
  118.  * STARS Reuse 
  119.  
  120. Reuse, along with software engineering environments and processes,
  121. is one of the primary software
  122. technical areas being addressed within the STARS program.
  123. The vision of the STARS program   is that
  124. ``Software-intensive system development will evolve to a process-driven,
  125. domain-specific reuse-based, technology-supported paradigm.''
  126. The element of the STARS vision that explicitly applies to the ALOAF
  127. is    domain-specific reuse-based .
  128. Under this envisioned paradigm,
  129. applications will be built using a component based approach,
  130. rather than constructing them a line at a time.
  131. The chosen components will be reused
  132. and/or constructed from existing systems, rather than created from scratch.
  133. And the components used in the application construction
  134. will be based on domain-specific architectures and open interface standards.
  135.  
  136. In order to support DoD needs, a key STARS technology objective is
  137. the construction of engineering environments from commercially available
  138. environment frameworks and tools.  Asset library systems contain
  139. elements of both reuse frameworks and reuse tools.  The desire within STARS
  140. is the construction of modular reuse tools and frameworks that conform
  141. with an open architecture, hence the formulation of the asset library
  142.    open architecture  framework.  Environment assemblers may then pick
  143. and choose from a variety of commercial-off-the-shelf
  144. or company-proprietary tools and
  145. systems that conform to the STARS ALOAF, with the knowledge that all of these
  146. ALOAF-conformant
  147. components will interoperate and be plug-compatible.
  148. The resultant engineering environments are standards-driven and
  149. standards-based systems, which are tailorable, adaptable, and reliable.
  150.  
  151. Other STARS, reuse-related activities include the
  152. STARS Reuse Concept of Operations and STARS' participation
  153. in the Reuse Library Interoperability Group (RIG).
  154. The STARS Reuse Concept of Operations  
  155. articulates STARS concepts and
  156. expectations with respect to reuse of software related assets across
  157. system and software life cycles.
  158. Specifically, the document communicates the joint STARS perspective on
  159. such topics as
  160. the reuse vision, the goals for reuse, and reuse processes.
  161. The ALOAF concurs with and confirms these joint STARS perspectives put forth
  162. within the Concept of Operations.
  163. The purpose of the RIG is to facilitate the interoperability of
  164. government-sponsored software reuse libraries  .
  165. As STARS is a member of the RIG, relevant portions of the ALOAF
  166. will be put forward as suitable candidates for consensual
  167. standardization within the RIG.
  168.  
  169.  * Standards Activities 
  170.  
  171. One aspect of an open system is the adherence to and conformance with
  172. standards relevant to the technical application domain.
  173. A goal of the Asset Library    Open  Architecture Framework is the
  174. adoption of existing and/or emerging standards that are relevant to
  175. asset library systems.
  176. Standards activities that are relevant to the goals of the ALOAF
  177. are currently being tracked and analyzed.  Those standards activities
  178. that have direct bearing or possible secondary effects on the goals
  179. of the ALOAF will be seriously considered for adoption and incorporation
  180. into the ALOAF.   It is not the intent of the ALOAF to duplicate
  181. or reinvent work that has already been completed or is in progress.
  182.  
  183. The specification and promulgation of new and emerging standards is just
  184. as important as, if not more important than, the conformance to standards.
  185. Reuse technology is one area in which there are
  186. relatively few existing standards.
  187. A primary purpose of the ALOAF is the development and shaping of
  188. future reuse-based standards.
  189. A role of the ALOAF is to serve as initiator and catalyst in building
  190. and shaping consensus on reuse technology standards
  191. among asset library developers.
  192.  
  193.  * ALOAF Objectives 
  194.  
  195. The primary objectives of the STARS ALOAF are to facilitate the interchange
  196. of assets between asset libraries, and facilitate the construction of reuse
  197. tools that are portable between asset libraries.  The asset-interchange
  198. objective focuses the STARS ALOAF upon the information needed to
  199. systematically organize and describe assets stored within an asset library.
  200. The ALOAF addresses the interchange of assets and their associated asset
  201. descriptions and model information through the ALOAF Data Modeling and
  202. Asset Interchange Specification.  The portable-reuse-tools objective
  203. focuses the STARS ALOAF upon the asset library services and standard
  204. interfaces needed by reuse-based library tools.  The ability to create
  205. portable reuse-based library tools is addressed by the ALOAF Service Model
  206. along with their ALOAF Programmatic Interfaces.
  207.  
  208.  * Data Modeling Concepts and Asset Interchange Specification 
  209.  
  210. An asset library can contain a large amount of data.  This data may include
  211. the library's assets, descriptions or related information about the assets,
  212. as well as the organization of the assets and the manner in which the
  213. organization is described.  The ALOAF Data Modeling Concepts address all of
  214. these constituent pieces of data via three layers:  a data layer, a model
  215. layer, and the meta-model layer.  Data modeling is necessary in order to
  216. specify a common asset interchange mechanism, as well as a uniform set of
  217. services (the ALOAF Service Model) which operates upon the data.
  218.  
  219. The ALOAF Asset Interchange Specification supports the interchange of
  220. assets and asset descriptions among diverse asset libraries.  The emphases
  221. within asset interchange are upon the exchange of the asset descriptions
  222. and their organizational representation, and upon an open, non-restrictive
  223. interchange mechanism.
  224.  
  225. The STARS ALOAF Asset Interchange Specification provides a standard
  226. technique for representing library data models, a format for library data
  227. models, and a format for asset library data.  The Asset Interchange
  228. Specification is not dependent upon any particular library data model and
  229. may be used to represent the data models and data of a wide range of asset
  230. libraries.  The Asset Interchange Specification includes a Common Data
  231. Model.  The Common Data Model describes a basic data model that allows
  232. asset libraries to interchange a common subset of asset descriptions.  The
  233. Common Data Model encompasses information that is typically maintained by
  234. asset libraries.
  235.  
  236.  * Service Model 
  237.  
  238. The ALOAF Service Model describes a collection of services that asset
  239. library implementors are encouraged to provide to support interoperability
  240. among geographically dispersed, heterogeneous asset libraries and to
  241. support portability of tools across libraries.  The Service Model
  242. categorizes framework services and describes the interrelationship between
  243. categories and between individual services within and across category
  244. boundaries.  Individual services are described in terms of service protocol
  245. descriptions that are independent of implementation language.  The service
  246. protocols consist of abstract functional interfaces and data exchange
  247. specifications intended to meet requirements common to all language
  248. bindings to the ALOAF services.  STARS asset libraries will be required to
  249. conform to the ALOAF. Conformance descriptions and criteria for asset
  250. libraries will be specified as an extension of the ALOAF Service Model.
  251.  
  252.  * Programmatic Interface 
  253.  
  254. The ALOAF Programmatic Interface comprises a set of Ada package
  255. specifications defining interfaces to the services described in the ALOAF
  256. Service Model.  In particular, the Ada specifications provide an Ada
  257. instantiation of the implementation-language-independent service protocol
  258. descriptions articulated in the Service Model.  The Ada programmatic
  259. interface is only one of many potential language-specific instantiations of
  260. the service protocols and is provided by STARS as a recommended Ada
  261. standard interface.  However, ALOAF conformance is not predicated on
  262. provision of ALOAF services through Ada interfaces.
  263.  
  264.  * ALOAF Evolution 
  265.  
  266.   
  267. The ALOAF effort began in early 1991 with participation from all three STARS
  268. Prime participants -- Boeing, IBM, and Unisys.  The ALOAF is the result of the
  269. cooperation and confluence of reuse efforts of the three Primes, their
  270. subcontractors, and other STARS program participants.
  271.  
  272.  
  273. The initial ALOAF addresses the reuse goals of STARS asset libraries with
  274. both short term and long term solutions.  The short term solutions drive
  275. toward the immediate sharing of assets between the many diverse reuse
  276. libraries that are coming on-line in increasing numbers.  The long term
  277. solutions strive for the far reaching goals of interoperable heterogeneous
  278. asset libraries, able to share assets and asset descriptions, as well as
  279. the portability of a broad and rich set of library tools which operate
  280. within asset library systems.
  281.  
  282.   alpha 
  283.  
  284.  
  285.  
  286.  
  287.   About the Authors 
  288.  
  289. John A. Thalhamer is manager of the Software Technology group at Valley
  290. Forge Laboratories, Unisys Defense Systems.  He has been actively involved in
  291. the STARS program over the past four years as both a project leader and a
  292. technical manager.  He holds a M.S. in Computer Science from Cornell
  293. University, and a B.S. in Computer Science from Penn State University.  He is
  294. a member of IEEE and the IEEE Computer Society.
  295.  
  296. Jim Solderitsch is technical lead for the portion of the Unisys STARS Reuse
  297. task being performed at Valley Forge Laboratories, Unisys Defense Systems.
  298. He previously served as chief programmer for the Reusability Library Framework
  299. (RLF) project. Before coming to Unisys in 1986, he was an assistant professor
  300. in the Mathematical Sciences department of Villanova University.  He received
  301. his Ph. D. in Mathematics in 1977.  His current research interests include
  302. knowledge-based approaches to software reuse and program generation
  303. techniques.  He is a member of the ACM.
  304.  
  305.  
  306.  
  307.