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 / castano.ascii < prev    next >
Text File  |  1993-10-19  |  23KB  |  372 lines

  1. Castano - 1
  2.  
  3.  
  4. Requirements Specification Reuse
  5.  
  6.  
  7. Silvana Castano  and  Valeria De Antonellis
  8.  
  9. Dipartimento di Elettronica e Informazione
  10. Politecnico di Milano
  11. P.za Leonardo Da Vinci,32 - 20133 Milano - ITALY
  12. Tel: +39-2-23993651
  13. Email: deantone@ipmel2.elet.polimi.it
  14. Fax: +39-2-23993411
  15.  
  16.  
  17. Abstract
  18.  
  19. An environment to support reuse at the requirement specification level of 
  20. the application development lifecycle is presented.The reuse model is 
  21. introduced, and a methodology for defining reusable conceptual 
  22. components is illustrated. Finally, the architecture of the tools supporting 
  23. the reuse process is described.
  24.  
  25. Keywords: Conceptual Schema, Classification, Design-for-reuse, Design-
  26. by-reuse, Requirements Reuse, Requirements Specifications. 
  27.  
  28. 1  Introduction
  29. Reusability of previous artifacts is considered a fundamental aspect in the 
  30. application development life cycle, since it can shorten the development 
  31. process, from the early requirements engineering to the detailed design and 
  32. implementation [4,5,20,26,31]. For what concerns reusability of software 
  33. artifacts, problems related to the identification, classification, retrieval, 
  34. adaptation, and composition of components have been widely studied, and 
  35. solutions based on techniques and paradigms of the software engineering field 
  36. have been proposed [6,18,23,24,25]. Our research focuses on reusability of 
  37. requirement specifications during the Requirements Engineering activity of the 
  38. development life cycle[10,11,16,17,22,30]. Experimentation and validation of 
  39. our approach are being performed in the framework of the Esprit project 
  40. n.6612 F3 (From Fuzzy to Formal) aiming at defining a methodology and a 
  41. software environment that integrates into a coherent whole a selection of 
  42. adequate techniques, to manage and improve the requirements engineering 
  43. process.
  44. Two separate processes are required to enforce requirements reuse: design-for-
  45. reuse and design-by-reuse. Design-by-reuse is performed when a new conceptual 
  46. schema is constructed not from scratch, but tailoring reusable components 
  47. retrieved from a reuse repository. Design-for-reuse is necessary to populate the 
  48. reuse repository with reusable components, properly defined to encapsulate 
  49. the domain knowledge, exploitable for subsequently developing new 
  50. applications not from scratch. The reuse-based development process requires a 
  51. reuse engineer, who is responsible for the population of the reuse repository, 
  52. and several application designers, which utilize the reuse repository (Fig.1).
  53.  The reuse engineering team defines reusable conceptual components in the 
  54. form of generic components and associated guidelines, extracted from a 
  55. collection of existing application conceptual schemas, and stores them in a 
  56. reuse repository. Available components can then be retrieved and reused by 
  57. application designers to specify new schemas not from scratch, but 
  58. personalizing and tailoring retrieved components, according to the suggested 
  59. guidelines.
  60. The paper is organized as follows. In Sect.2, our reuse environment is described, 
  61. based on the development lifecycle presented in Fig.1, while in Sect.3 the 
  62. related research work is discussed.
  63.                                                         
  64. Fig. 1.  The reuse-based application development process
  65.  
  66. 2  An environment for requirements reuse
  67.  
  68. Within the F3 project, we propose models, methods, and tools to support both the design-for-reuse and 
  69. the design-by-reuse, specifically oriented to the requirement specifications reuse problem [10,13].
  70. In Sect.2.1 the reuse meta-model is described. In Sect.2.2 the reuse methodology is presented, and, 
  71. finally, in Sect.2.3, the architecture of the tools supporting the proposed methodology is illustrated.
  72. 2.1  Reuse meta-model
  73. In order to present in a systematic way the reuse model underlying both the 
  74. design-for-reuse and the design-by-reuse processes, we introduce a reuse meta-
  75. model, describing the key concepts characterizing our approach.
  76. The reuse meta-model has been defined using the Entity-Relationship model 
  77. [3] to give an integrated an coherent description of all the needed inputs and 
  78. results of the reuse environment. The reuse meta-model is shown in Fig.2. A 
  79. reusable component is defined as a Generic Component, with an associated 
  80. Guideline-Component. Reusable components are defined by analyzing existing 
  81. conceptual schemas of the applications in a given domain. We consider a 
  82. conceptual schema as a collection of (application) components, expressed in a 
  83. suitable conceptual model, describing the entities of the real world, their 
  84. relationships, properties, and, possibly, the associated processes [3,15,32]. 
  85. Schemas produced by application designers are selected, analyzed,clusterized, 
  86. and properly arranged inside the repository. Precisely, to each schema a set of 
  87. schema descriptors is associated [14]. In the repository, schemas are grouped 
  88. by similarity levels into clusters, on the basis of the shared schema descriptors. 
  89. For each schema cluster, affinity sets are defined, grouping the most similar 
  90. schema components, that are modified and engineered into reusable 
  91. components. For instance,in the Extended Entity-Relationship model, we 
  92. consider entities as reusable components,together with their attributes, their 
  93. relationships, which show how the component can be inserted in a schema, 
  94. and is-a relationships.
  95. In general, we assume to work within a given application domain, e.g.office 
  96. domain, air traffic control domain, banking domain, education domain. For a 
  97. domain is essential to identify and define the terms frequently used in the 
  98. domain (synonyms, homonyms, and so on), to determine both schema and 
  99. component similarity. Thus, werefer to a Thesaurus as the base for all this 
  100. information.
  101.  
  102.  
  103.                                                             
  104. Fig.2  The reuse meta-model
  105. 2.2  Reuse methodology
  106. In F3 we are specificallyconcerned with the design-for-reuse process. To this 
  107. purpose, a reuse methodology for the construction of reusable components and 
  108. their associated guidelines has been defined. Starting from properly selected 
  109. application schemas, common and similar conceptual components are 
  110. identified and classified; from these components generic components and 
  111. associated guidelines are extracted and stored in the reuse repository.
  112. The phases of the F3 reuse methodology are the following:
  113. Ñ    selection of candidate schemas
  114. Ñ    classification of candidate schemas
  115. Ñ    selection and classification of candidate components
  116. Ñ    design of reusable components
  117. Ñ    assimilation of reusable components
  118. Goals and characteristics of each phase are briefly described in the following.
  119. During the first phase, the reuse engineer selects the schemas judged significant 
  120. for both their design quality and prospect reuse. Criteria andmetrics to 
  121. evaluate the reuse goodness of a schema in a given domain are under study.
  122. The remaining methodological phases are based on the concept of 
  123. similarity[30,22]. It is widely accepted that, in order to be reusable, a 
  124. component should be apt to be used in more than one application, possibly 
  125. with adaptations and modifications according to the specific application 
  126. requirements. To minimize the required operations of adaptation and 
  127. tailoring, and to provide powerful components, similarities in different 
  128. application schemas should be identified, and commonalties abstracted into 
  129. generic components. To facilitate this process, we identify firstly similar 
  130. schemas, and secondly similar components within similar schemas. The 
  131. classification model adopted for schemas and components is based on 
  132. indexing criteria and clustering techniques, derived from the Information 
  133. Retrieval area [29].
  134. Schemas are indexed by means of schema descriptors, selected among the 
  135. names associated to the schema components, for their capability of describing 
  136. the schema subject [7,14]. Using the selected schema descriptors, the schemas 
  137. are properly clusterized according to their level of similarity, giving origin to 
  138. several schema clusters inside the repository, using information retrieval 
  139. clustering techniques [28,29]. 
  140. The schema clusters constitute the starting point for defining reusable 
  141. components. Selected a cluster, semantic affinity between schema components 
  142. is computed taking into accountthe structural and contextual properties of the 
  143. components (e.g.,attributes, generalization hierarchies, relationships). Schema 
  144. components presenting a semantic affinity greater than a predefined threshold 
  145. are grouped into affinity sets, i.e.,hierarchical structures whose leaves are the 
  146. examined components, and the intermediate nodes are numerical values 
  147. expressing the level of affinity for the corresponding components.
  148. Affinity sets are used by the reuse engineer to extract generic components, in 
  149. that the properties and relationships common to all the affinity set members 
  150. are identified and factored out into the corresponding generic component. For 
  151. each generic component the corresponding guidelines are defined, including 
  152. reuse suggestions to personalize the generic componentin specific contexts. 
  153. Adaptations and modification suggestions  are given in the form of design 
  154. operations, applicable to the generic component (e.g.,refinement, 
  155. specialization, aggregation operations) [15,9].
  156. Finally, newly created reusable components must be assimilated within the 
  157. reuse repository, to enrich the existing reusable components and to augment 
  158. their description capabilities. To this purpose, we are studying view integration 
  159. techniques to properly integrate the new components with the existing ones 
  160. [2].
  161. 2.3  Reuse tools
  162. A couple of tools characterize our reuse environment, precisely the EXTRACT 
  163. tool, supporting the design-for-reuse process and the RECAST tool supporting 
  164. the design-by-reuse process, interacting with the reuse repository, and with 
  165. other tools in the F3 requirement engineering support environment ( Fig.3).
  166.  
  167.                                              
  168.  
  169. Fig.3  Global F3architecture
  170.  
  171. The RECAST tool [1,17], developed first within the ITHACA ESPRIT project, and 
  172. now under refinement to be integrated within the F3 reuse environment, 
  173. supports the design-by-reuse process. Such a tool provides a workspace where 
  174. components are graphically represented and interconnected according to 
  175. composition rules [12]. More precisely, it enforces the retrieval of reusable 
  176. components from the reuse repository via browsing and querying 
  177. functionalities, providing also guidelines to tailor and compose, at various 
  178. refinement levels, the retrieved components, according to given strategies and 
  179. application contexts.
  180. The EXTRACT tool has been specifically designed and implemented to support 
  181. the reuse methodology described in Sect.2.2. In the following, its functionalities 
  182. are briefly described. Basically, EXTRACT is an interactive tool, such as the 
  183. reuse tools proposed in [30,22], assisting the reuse engineer in defining new 
  184. reusable components.
  185. In order to assist the reuse engineer during selection of candidate schemas, 
  186. EXTRACT will provide a functionality of retrieval and selection ofexisting 
  187. schemas, according to suitable reuse metrics and selection criteria. Selection 
  188. functionalities will be built on top of the browsing and retrieval functionalities 
  189. provided by the reuse repository (see [13] for further details about the reuse 
  190. repository implementation).
  191. To properly arrange selected candidate schemas within the repository, 
  192. EXTRACT provides a schema classification functionality, whereby the reuse 
  193. repository is populated in a systematic way. EXTRACT classifies reuse candidate 
  194. schemas according to the following steps:
  195. Ñ    automatic selection of schema descriptors, using the procedure detailed 
  196. in [10].The reuse engineer can adjust in an interactive way the threshold 
  197. value for descriptor selection according tothe schema contents, and can 
  198. force the inclusion of specific/meaningful descriptors, in order to 
  199. improve the quality of the  schema indexing;
  200. Ñ    computation of the schema similarity for all the indexed schemas;
  201. Ñ    definition of the similarity clusters, using the single link clustering 
  202. technique.
  203. Starting from the schema clusters, EXTRACT selects candidate components and 
  204. classifies them according to their semantic affinity. The following steps are 
  205. performed by EXTRACT:
  206. Ñ    pairwise semantic affinity comparisons for conceptual components that 
  207. are descriptors of schemas in a given cluster;
  208. Ñ    automatic definition of affinity sets, using the complete link clustering 
  209. technique [29] and the affinity coefficients. The reuse engineer can 
  210. examine the affinity sets, and interactively modify the affinity threshold, 
  211. to improve and/or refine their composition.
  212. The reuse engineer can then invoke the definition of reusable components 
  213. functionality of EXTRACT, to extract the reusable component for defined 
  214. affinity sets. Precisely, EXTRACT performs the following operations:
  215. Ñ    automatic definition of a Generic Component, by considering the 
  216. structural properties, and the contextual properties (relationships, 
  217. generalization hierarchies) common to all the affinity set components. 
  218. The reuse engineer can interactively modify the number of affinity set 
  219. components to be considered for the commonalities' extraction, in order 
  220. to refine the definition of the generic component;
  221. Ñ    interactive definition ofreuse guidelines for a Generic Component, in 
  222. form of design operations to be applied to the generic component to 
  223. adapt and tailor it to specific contexts.
  224.  
  225.  
  226. 3  Related work
  227. Several research efforts are currently in progress in the requirements reuse area. 
  228. They are mainly related to the design-by-reuse process, and most of the 
  229. currently available systems provide some form of support for the application 
  230. developer, in retrieving and tailoring selected reusable components, exploiting 
  231. either the analogy paradigm, or the artificial intelligence techniques. In 
  232. particular, in [16] a reuse analogy-based model is proposed, and the TRUE tool 
  233. based on that model is described, supporting the reuse of transaction 
  234. specifications. Starting from the target application requirements, a set of 
  235. reusable specifications are retrieved,exploiting different retrieval strategies, 
  236. based either on analogical reasoning, oron browsing of similar components. 
  237. Retrieved components can then be used through restructuring, editing, and 
  238. tailoring operations, to fit the new requirements. In [22] an analogy based 
  239. approach is proposed for reusing requirements specification, and reusable 
  240. specifications are given in form of abstract domain models, supporting reuse 
  241. across several applications. A prototype tool, called Ira, is described, enforcing 
  242. the design-by-reuse, by providing retrieval functionalities, and customization 
  243. guidance to tailor the retrieved candidate specifications to the target domain. 
  244. Abstract domain models proposed in [22] are similar to the clichÄ  proposed in 
  245. [27], where a tool to assist the acquisition of requirements is proposed, based 
  246. on artificial intelligence techniques to support the knowledge acquisition 
  247. process. Acquired requirements are matched against existing validated 
  248. clichÄ,describing the commonly occurring structures in one or more domains. 
  249. In [30] the concept of similarity is exploited to allow requirements reuse. Here 
  250. an interactive environment is described, where a set of tools helpapplication 
  251. designers in retrieving and reusing object-oriented requirements specifications 
  252. similar to the application at hand, properly selected among the stored 
  253. specifications, on the basis of their level of similarity. In [19] an approach is 
  254. proposed, to develop new information systems requirements making use of 
  255. generic structures properly instantiated to the current context, with more 
  256. emphasis for the engineering process rather than the definition process of 
  257. generic structures.
  258. Our research addresses the design-for-reuse process, and we propose a 
  259. constructive approach for defining reusable components, while this aspect of 
  260. reuse is sometimes given as a de facto. We cover the problem of repository 
  261. population, (generally left open or dealt with using examples), by building 
  262. reusable generic specifications for both static (see [7,8,10]), and dynamic 
  263. aspects (see [11,12,13]) of the application requirements, presenting generic 
  264. features like those of the abstract domain models proposed in [22], and the 
  265. clichÄ illustrated in [27].
  266.  
  267.  
  268. Acknowledgements
  269. Part of this work has been supported by the ESPRIT III Projectn.6612 F3 (From 
  270. Fuzzy to Formal) and by the Italian National Research Council ╥Progetto 
  271. Finalizzato Informatica e Calcolo Parallelo╙, L.R.C. Infokit.
  272.  
  273. References
  274. [1]    M.Ader, O. Nierstrasz, S. McMahon, G. Muller, A. K. Proefrock, "The 
  275. ITHACA Technology: a Landscape for Object-Oriented Application 
  276. Developement", Proc. ESPRIT'90 Conf. , Kluwer Academic Publisher, 
  277. November 1990
  278. [2]    C. Batini, M. Lenzerini, S.B. Navathe, ╥A Comparative Analysis of 
  279. Methodologies for Database Schema Integration╙, ACM Computing 
  280. Surveys, Vol.18, December 1986,pp.323-364
  281. [3]    C. Batini, S. Ceri, S.Navathe, Conceptual Database Design, Addison Wesley, 
  282. 1991
  283. [4]    D.Batory, S.O'Malley, ╥The Design and Implementation of Hierarchical 
  284. Software Systems with Reusable Components╙, ACMTOSEM, Vol.1,N.4, 
  285. October 1992, pp.355-398
  286. [5]    T.J. Biggerstaff, A.J. Perlins(eds.), ╥Software Reusability - Concepts and 
  287. Models╙, vol.I, ACM Press, Addison-Wesley, 1990
  288. [6]    G. Caldiera, V.R. Basili, "Identifying and qualifying reusable software 
  289. components", IEEE Computer, Vol. 24, N. 2, Feb. 1991
  290. [7]    S.Castano, V. DeAntonellis, B. Zonta, ╥Classifying and reusing conceptual 
  291. schemas╙, in Proc. of ER'92, Int.Conf. on the Entity-Relationship Approach, 
  292. LNCS n.645, Springer Verlag, Karlsruhe, October 1992
  293. [8]    S.Castano, V. DeAntonellis, ╥A Model for Reusable Requirements╙, F3 
  294. Report, F3.PdM.2-1-3-R1,November 1992
  295. [9]    S.Castano, V. DeAntonellis, ╥Reuse of Conceptual Requirement 
  296. Specifications╙, in Proc. of RE ╒93,ACM/IEEE Int. Conf. on Requirements 
  297. Engineering, San Diego, CA, January 1993
  298. [10]    S.Castano, V. DeAntonellis, ╥A Constructive Approach to Reuse of 
  299. Conceptual Components╙, in Proc. of 2nd ACM/IEEE Int. Workshop on 
  300. Software Reusability, Lucca, Italy, March1993
  301. [11]    S. Castano, V. DeAntonellis, ╥Reusing Process Specifications╙, in Proc. IFIP 
  302. Working Conference on Information System Development Process,IFIP WG 
  303. 8.1, Como, Italy, September 1993, North-Holland, pp.267-283
  304. [12]    S. Castano, V. De Antonellis, C.Francalanci, M.G. Fugini, B. Pernici, 
  305. R.Bellinzona, L. Vandoni, ╥Methodology for reuse╙, F3 Report, F3.PdM.2-1-
  306. 3-R2, Politecnico di Milano, April 1993
  307. [13]    S. Castano, V. DeAntonellis, P.Sanpietro, ╥Reuse of Object-Oriented 
  308. Requirements Specifications╙, to appear in Proc. ER '93, 12th Int. Conf.on 
  309. The Entity Relationship Approach, Dallas Arlinghton, TX, USA, December 
  310. 1993
  311. [14]    V. DeAntonellis, B. Zonta,╥A disciplined Approach to Office Analysis╙,  IEEE 
  312. TSE,Vol. 16, No. 8, 1990, pp. 822-828
  313. [15]    V. DeAntonellis, S. Castano, B. Pernici, A. Piovesana, ╥The ITHACA Object 
  314. Oriented Methodology: Application Developer Manual╙, ITHACA Report, 
  315. ITHACA.POLIMI-UDUNIV, 1992
  316. [16]    A.Finkelstein, ╥Reuse of Formatted Requirements Specifications╙, Software 
  317. Engineering Journal, September 1988,pp.186-197
  318. [17]    M.G. Fugini, O. Nierstrasz, B. Pernici, ╥Application Development through 
  319. Reuse: the Ithaca Tools Environment╙,  SIGOIS Bulletin, vol. 13, n. 
  320. 2,August 1992
  321. [18]    M.G. Fugini, S. Faustle, ╥Querying a Software Information Base for 
  322. Component Reuse╙, to apper in Proc. of 2nd ACM/IEEE Int. Workshop on 
  323. Software Reusability, Lucca, Italy, March1993
  324. [19]    G.Grosz, ╥Buiding Information System Requirements Using Generic 
  325. Structures╙, Nature Report Series N.92-06, 1992
  326. [20]    C.W.Krueger, ╥Software Reuse╙, ACM Computing Surveys, Vol.24, N.2, June 
  327. 1992, pp.131-183
  328. [21]    Y.S. Maarek, D.M.Berry, G.E. Kaiser, ╥An Information Retrieval Approach 
  329. For Automatically Constructing Software Libraries╙, IEEE TSE, Vol.17,No.8, 
  330. August 1991, pp.800-813
  331. [22]    N.A. Maiden, A.G. Sutcliffe,╥Exploiting Reusable Specifications Through 
  332. Analogy╙,Communications of the ACM, Vol.35, N.4, April 1992, pp.55-64
  333. [23]    J.W. Hooper, R. O. Chester, Software Reuse: Guidelines andMethods, 
  334. Plenum Press, Division of Plenum Publishing Corporation, NewYork, 1991
  335. [24]    E. Ostertag, J. Hendler, R. Prieto-Diaz, C. Braun, ╥Computing Similarity in 
  336. a Reuse Library System: An AI-Based Approach╙, ACM TOSEM, Vol.1, No.3, 
  337. July 1992, pp.205-228
  338. [25]    R. Prieto-Diaz, ╥Implementing Faceted Classification for Software  Reuse╙,  
  339. Comm. of the ACM,  vol. 34,n. 5, May 1991
  340. [26]    Proceedings of REBOOT Workshop on Reuse, Esprit Project 5327,Grenoble, 
  341. September 1991
  342. [27]    H.B. Reubenstein, R.C.Waters, ╥The Requirements Apprentice: Automated 
  343. Assistance for Requirements Acquisition╙, IEEE TSE, Vol.17, N.3, March 1991
  344. [28]    G. Salton, Automatic Textt Processing - The Transformation, Analysis and 
  345. Retrieval of Information by Computer ,  Addison-Wesley, 1989
  346. [29    G. Salton, Ch. Buckley, ╥Term Weighting Approachesin Automatic Text 
  347. Retrieval╙, Information Processing andManagement,  vol. 24, Nr. 5,  1989, 
  348. pp.513-523
  349. [30    G.Spanoudakis, P.Constantopoulos, ╥Similarity for Analogical Software 
  350. Reuse: A Conceptual Modelling Approach╙, inProc. of CAiSE '93, Int. Conf. 
  351. on Advanced Information Systems Engineering, Paris, June 1993
  352. [31]    W. Tracz ed., Software Reuse: Emerging Technology, IEEE Computer Society 
  353. Press, Washington D.C., 1988
  354. [32]    R. Wirfs-Brock, B. Wilkerson, L. Wiener, Designing Object-Oriented Software, 
  355. Englewood Cliffs, NJ,  Prentice Hall, 1990
  356.  
  357. 4  Biography
  358. Valeria De Antonellis is a professor of computer science at the Politecnico di 
  359. Milano, Engineering Faculty. Her major areas of research include conceptual 
  360. models, methodologies and tools for databases and information systems 
  361. design. She is coordinator of the AICA WG on Databases. She is co-author of 
  362. Relational Database Theory (Benjamin Cummings) and co-editor of Computer-
  363. Aided Database Design (North-Holland). She is currently responsible of the 
  364. research team from Politecnico di Milano in the ESPRITProject n. 6612 - F3 
  365. (From Fuzzy to Formal).
  366. Silvana Castano is PhD student at the Politecnico di Milano,Engineering 
  367. Faculty. Her major areas of research are related to models and methods for 
  368. database and information system design. She is currently member of the 
  369. research team from Politecnico di Milano in the ESPRIT Project n.6612 - F3 
  370. (From Fuzzy to Formal).
  371.  
  372.