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 / wirsing.detex < prev   
Text File  |  1992-04-05  |  19KB  |  521 lines

  1.  [12pt] article 
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.   Spectrum:
  12. A Formal Approach to Software Development with Reusability 
  13.  
  14.   Martin Wirsing 
  15. Bayer. Forschungszentrum f ur Wissensbasierte Systeme 
  16. Universit at Passau 
  17. wirsing@forwiss.uni-passau.de 
  18.  
  19.    This research has been partially sponsored by the DFG-project Spectrum,  
  20.    the BMFT-project Korso and the ESPRIT working group COMPASS.  
  21.  
  22.    
  23.  
  24.  
  25.   
  26. A formal approach to software development is presented which
  27. integrates reuse as an essential part: the Spectrum approach.
  28. Based on type-theoretic, algebraic and functional methods, the
  29. Spectrum project aims at studying methodical aspects, language
  30. issues, theory and support tools of software reuse in an
  31. integrated way. A central concept is the notion of software
  32. component which represents software at different levels of
  33. abstraction and gives access to multiple views of software
  34. objects. The type-theoretic meta-language serves for specifying
  35. exactly the properties of such components, algebraic methods are
  36. used for carrying out formal developments of specifications.
  37.  
  38.   0.3in 
  39.   
  40.    Keywords: 
  41.   algebraic specification,
  42.   reusable software components,
  43.   software development,
  44.   type-theory
  45.  
  46.  
  47.  
  48.   Introduction 
  49.  
  50. The increasing demand for more and more complex software systems
  51. makes it necessary to change the process of software development.
  52. It is important to reuse already developed software systems for
  53. different applications. In order to achieve this goal and to get
  54. the confidence of the system developers, reuseable software must
  55. be of high quality.
  56.  
  57. Therefore formal methods become an integrated part of the
  58. software construction process: formal methods provide abstract
  59. language concepts for supporting the certification of software;
  60. language specific theory of reuse provides the foundations for
  61. computer aided development with reuse and formal methods support
  62. the evolution of reusable objects and other reuse activities such
  63. as construction, search and classification, integration and
  64. configuration of reusable components. Moreover the integration of
  65. formal methods into the software life cycle is becoming an
  66. important research issue  .
  67.  
  68. In the following a formal approach to software development will
  69. be presented which integrates reuse as an essential part: the
  70. Spectrum approach has its roots in the CIP project 
  71.   and several ESPRIT projects such as METEOR (on algebraic
  72. specification and development), PROSPECTRA (on transformational
  73. techniques) and DRAGON (on reusability).Based on type-theoretic,
  74. algebraic and functional methods, the Spectrum project aims at
  75. studying methodical aspects, language issues, theory and support
  76. tools in an integrated way.
  77.  
  78.  
  79.   Methods 
  80.  
  81.   Software components 
  82.  
  83. A central aspect of the Spectrum approach is the notion of
  84. software component which represents software at different levels
  85. of abstraction and gives access to multiple views of software
  86. objects. Starting from a simple model of the software development
  87. process where a development consists of a sequence of
  88. descriptions beginning with a requirement specification and
  89. ending with the final program, we define a software component to
  90. be a finite graph whose nodes are software objects such as
  91. specifications and programs and whose edges represent relations
  92. between such objects. Then each development sequence can be
  93. understood as a particular software component.
  94.  
  95.   Objects 
  96.  
  97. Software objects are specifications of functional and
  98. non-functional properties, programs and components themselves. In
  99. general, objects are structured. In particular, structured
  100. specifications can be considered as software components related
  101. by operations such as inheritance, clientship or instantiation.
  102.  
  103. Objects come together with associated attributes such as examples
  104. of instances, theorems, meta- theorems, simulations and different
  105. syntactical representations  .
  106.  
  107.   Relations between software objects 
  108.  
  109. There are different kinds of relations: 
  110.  
  111.   
  112.  [a)] Refinement and implementation relations relating objects at
  113. different levels of abstraction.
  114.  
  115.  [b)] Translations between expressions in different
  116. languages. Translations are especially important for the
  117. transition from specifications to programs and for the reuse of
  118. results from other languages. For example, for a development in a
  119. first-order logic it might be interesting to use results obtained
  120. in equational logic with a narrowing-based theorem prover.
  121.  
  122.  [c)] Multiple views of software objects describe functional
  123. properties (such as input-output behaviour, invariants and
  124. theorems) and non-functional properties (such as concurrency
  125. aspects, complexity mesures and access control)  .
  126.  
  127.  
  128. Relations are classified according to their abstract properties.
  129. Most important are transitivity and monotonicity which insure the
  130. correctness of a sequence of development steps as well as of
  131. local development steps  .
  132.  
  133.   Development for and with reuse 
  134.  
  135. Software development is understood as the development of a (part
  136. of a) sofware component.  Software components can be manipulated
  137. from three different views  :
  138.  
  139.   
  140.  [a)] The reuse supervisor maintains the reuse components and is the
  141. only one who has "write" access to the component library.
  142.  
  143.  [b)] The reuse consultant knows about the content of the whole
  144. library and is able to share his knowledge with "ordinary"
  145. reusers.
  146.  
  147.  [c)] Each reuser has a partial view of the library and constructs
  148. particular applications using his view. The approach also
  149. supports the development of software by a group of reusers.
  150.  
  151. For each view different operations are allowed:
  152.  
  153.   
  154.  [a)] The reuse supervisor has the right to release new views of the
  155. component. He may extend existing views and replace parts within
  156. a view.
  157.  
  158.  [b)] A reuse consultant may inspect the whole library and tell the
  159. supervisor that a view needs restructuring.
  160.  
  161.  [c)] Ordinary reusers may produce new versions of their view by
  162. extending, combining and changing views and may prepare a new
  163. version for submission to the supervisor. Cooperation between
  164. several reusers is achieved by formal support for the integration
  165. of software objects and by formal support for conversation
  166. between different developers  .
  167.  
  168.  
  169.   Language 
  170.  
  171. In Spectrum three different language styles are studied: Type
  172. theory, algebraic specification and functional programming.
  173.  
  174.   Type theory 
  175.  
  176. As a meta-language for formally expressing components and
  177. software developments an extension of ECC   is used. This
  178. is a very powerful calculus in which module concepts and
  179. polymorphism can be expressed adequately with the help of
  180. dependent products and dependent sums. A hierarchy of universes
  181. allows to describe programming and meta- programming as well as
  182. reasoning and meta-reasoning in the same framework.
  183.  
  184.   Algebraic specification 
  185.  
  186. For describing design specifications in an algebraic style the
  187. kernel language ASL  
  188. and their dialects RAP
  189.   
  190. and OS  
  191. are used. ASL provides a few
  192. simple but powerful specification operators for writing
  193. specifications in a structured way and posesses a well developed
  194. theory for transforming specification expressions and proving
  195. properties in a structured way. RAP allows to write hierarchical
  196. specifications and is embedded in a convenient development
  197. environment. OS integrates object oriented features into ASL and
  198. is well-suited for specifying object oriented programs.
  199.  
  200. Algebraic specifications do not support dependent types and
  201. therefore are less expressive than type theoretic descriptions.
  202. Advantages of algebraic specifications are that they are
  203. abstract, easy to manipulate and that they have a well-developed
  204. theory together with good programming environments.
  205.  
  206.   Functional programming 
  207.  
  208. SML  
  209. is used as functional programming
  210. language. SML supports modular and high-level functional
  211. programming and integrates non-functional programming styles
  212. (such as references, assignments and concurrency) in a clean and
  213. transparent way. SML structures correspond to algebras and can
  214. therefore be understood as models of equational specifications.
  215. Moreover its module concepts can be easily expressed in the type
  216. theoretic framework. SML is used for constructing prototype
  217. implementations of specifications.
  218.  
  219.   Theory 
  220.  
  221. The theoretical background of Spectrum can be divided into two
  222. main streams: Foundational studies and theory of reuse.
  223.  
  224.   Foundational studies 
  225.  
  226. The foundational studies concern semantical properties of
  227. specification and type-theoretic languages.
  228.  
  229.   Algebraic specifications 
  230.  
  231. For algebraic specifications a well-developed theory supporting
  232. formal developments is available  . In particular, the
  233. fundamental implementation relation is transitive and monotonic
  234. and therefore satisfies the horizontal and vertical composition
  235. property. Using the equations of "module algebra" structured
  236. specifications can be transformed into various normal forms and
  237. structured proof calculi allow one to verify the correctness of
  238. implementations in a structured way  .  Context
  239. induction provides a new method for verifying behavioural
  240. implementations  . Most of these results can be
  241. extended to object oriented specifications  . 
  242.  
  243.   Non-functional specifications 
  244.  
  245. For non-functional specification two basic methods are available:
  246. In   a performance measure is associated with the
  247. abstract syntax of program. Then any non-functional specification
  248. is given as the conjunction of preorder assertions between
  249. performance expressions.   advocates the abstract
  250. interpretation of specification expressions in order to perform
  251. complexity analysis or measurements and benchmarks.
  252.  
  253.   Integration of formalisms 
  254.  
  255. For relating programs and specifications there are two basic
  256. semantic approaches. By considering "programs as specifications"
  257. one defines a translation from a subset of specification
  258. expressions to programs. For example, equational specifications
  259. with axioms in the form of structural recursive definitions can
  260. be directly transformed into functional programs. In the
  261. type-theoretic approach it seems appropriate to consider programs
  262. as "realizers" of specifications, i.e. the semantics of a program
  263. is considered as a model of the specification.
  264.  
  265. More generally, type-theoretic descriptions are well-suited for
  266. integrating different styles of specifications and programs as
  267. has been shown by the DEVA project  .
  268.  
  269.   Theory for reuse 
  270.  
  271. Based on the results of the foundational studies the theory of
  272. reuse provides formal support of most reuse activities. In the
  273. Spectrum project we are mainly interested in the follwing issues.
  274.  
  275.   Reuse of components 
  276.  
  277. The construction of reusable components is based on the theory of
  278. structured algebraic specifications. In  
  279. a notion of
  280. reusable component is developed that represents specifications at
  281. different levels of abstraction by a tree of specifications where
  282. two consecutive nodes are related by the implementation relation.
  283. Due to the fact that the nodes are ASL specifications these
  284. components can be normalized and enjoy vertical and horizontal
  285. composition properties. We are currently studying how these results
  286. can be extended to software components consisting of graphs of 
  287. specifications and how functional and non-functional properties 
  288. can be expressed in a type-theoretic framework.
  289.  
  290. Signature matching and the classificaton of specifications by the
  291. implementation relation help in retrieving components from a
  292. library. After matching a given abstract problem specification SP
  293. with a specification in the library, an implementation of SP can
  294. be automatically constructed from the implementation found in the
  295. library. If the matching is correct then due to the composition
  296. properties the new implementation is correct without requiring
  297. any further proof.
  298.  
  299. In  
  300. a formal method has been developed for
  301. integrating several module implementations to a consistent
  302. configuration of the whole system.
  303.  
  304.   Reuse of developments 
  305.  
  306. For the reuse of development steps there are two main approaches.
  307.   and  
  308. use meta-descriptions of
  309. transformations written in a first order language whereas 
  310.  
  311. take the introduction and elemination rules of the
  312. lambda-typed lambda- calculus underlying DEVA. Baxter studies the
  313. difficult problem of pruning development histories in order to
  314. delete non-reusable steps. Then the sequence of development steps
  315. is repaired by integrating socalled "maintenance deltas". 
  316.  
  317. uses the object oriented design language Telos for formally
  318. describing the design decisions occurring in a development.
  319.  
  320.  
  321.   Support tools 
  322.  
  323. Up to now only tools for the development of specifications have
  324. been implemented in the Spectrum project.
  325.  
  326. The RAP TIP system is an environment for prototyping hierarchical
  327. algebraic specifications; moreover it includes an inductive
  328. theorem prover for equational formulas  .
  329.  
  330. The ISAR system gives support for the correctness proof of
  331. behavioural implementations [4]  .
  332. The main technique is
  333. context induction which is performed with the help of TIP.
  334.  
  335. Components of RAP specifications can be designed interactively
  336. with the help of the Specifiers Notepad  .
  337.  
  338.  
  339.  * Acknowledgement 
  340.  
  341. Thanks go to Stefan Gastinger, Michael Gengenbach, Rolf
  342. Hennicker, Robert Stabl (reusability group of Spectrum) and to
  343. Bernhard Reus, Thomas Streicher (semantic group of Spectrum) for
  344. inspiring discussions and many ideas which are reflected in this
  345. paper. Thanks go also to the working group on formal methods of
  346. the First Int. Workshop on Software Reuseability (Dortmund 1991)
  347. and in particular to Rene Jaquart and Larry Latour for many new
  348. insights into formal support for software reuse.
  349.  
  350.  
  351.  
  352.    baue91 
  353.  
  354.  B. Bauer: Ein interaktives System fuer
  355. beobachtungsorientierte Implementierungsbeweise. Diplomarbeit,
  356. Universitaet Passau 1991.
  357.  
  358.  
  359.  F.L. Bauer, M. Broy, W. Dosch, R. Gnatz, B.
  360. Krieg-Brueckner, A. Laut, M Luckmann, T.A. Matzner, B. Moeller,
  361. H. Partsch, P. Pepper, K. Samelson, R. Steinbrueggen, M. Wirsing,
  362. H. Woessner: Programming in a wide spectrum language: a
  363. collection of examples.  Science of Computer Programming 1, 1981,
  364. 73-114.
  365.  
  366.  
  367.  I.D. Baxter: Transformational maintenance by reuse of
  368. design histories, Ph.D.  Thesis, University of California,
  369. Irvine, Tech. Report 90-36, 1990.
  370.  
  371.  
  372.  R. Breu: Algebraic specification techniques in object
  373. oriented programming environments. Dissertation, Universitaet
  374. Passau, 1991, also to appear in Springer Lectures Notes of
  375. Computer Science.
  376.  
  377.  
  378.  R. Breu, H. Windl: The specifiers notepad - a
  379. hypertext system tailored to the design of algebraic
  380. specification, Tech. Report, Universitaet Passau, MIP-9007, 1990.
  381.  
  382.  
  383.  M. Broy, H. Partsch, P. Pepper, M. Wirsing:
  384. Semantic relations in programming languages. In: S. Lavington
  385. (ed.): Proc. IFIP World Congress - Information Processing 80,
  386. Amsterdam: North Holland 1980, 101-106.
  387.  
  388.  
  389.  J. Cazin, P. Cros, R. Jacquart, M. Lemoine, P.
  390. Michel: Construction and reuse of formal program developments.
  391. In: S. Abramski, T.S.E. Maibaum (ed.): TAPSOFT 91, Springer
  392. Lectures Notes in Computer Science 494, 1991, 120-136.
  393.  
  394.  
  395.  W. Schaefer (ed.): Proc. First Int. Workshop on
  396. Software Reusability, Dortmund, 1991.
  397.  
  398.  
  399.  U. Fraus, H. Hussmann: A narrowing-based
  400. theorem prover. In: Proc.  RTA 91, Springer Lectures Notes in
  401. Computer Science 488, 1991.
  402.  
  403.  
  404.  A. Geser, H. Hussmann: Experiences with the
  405. RAP system - a specification interpreter combining term rewriting
  406. and resolution. Proc. European Symposium on Programming. Springer
  407. Lecture Notes in Computer Science 213, 1986, 339-350.
  408.  
  409.  
  410.  R. Hennicker: A proof principle for behavioural
  411. abstractions. In: A. Miola (ed.): Proc. DISCO 90. Springer
  412. Lecture Notes in Computer Science 429, 1990, 101-110.
  413.  
  414.  
  415.  R. Hennicker: Consistent configuration of modular
  416. algebraic implementations.  Tech. Report, Universitaet Passau,
  417. MIP-9102, 1991.
  418.  
  419.  
  420.  R. Jacquart: Reuse of formal developments. In: [Dortmund 91]
  421.  
  422.  
  423.  L. Latour: In: [Dortmund 91] .
  424.  
  425.  
  426.  Z. Luo: A unifying theory of dependent types. Tech.
  427. Report, University of Edinburgh, ECS-LFCS-91-154, 1991.
  428.  
  429.  
  430.  R. Milner, M. Tofte, R. Harper: The definition
  431. of Standard ML. London: MIT Press, 1990, 101 p..
  432.  
  433.  
  434.  
  435. H. Partsch, N. Voelker: Another case study
  436. on reusability of transformational developments - Pattern
  437. matching according to Knuth,Morris and Pratt. In: M.  Broy, M.
  438. Wirsing (eds.): Methods of Programming, Springer Lecture Notes in
  439. Computer Science, to appear.
  440.  
  441.  
  442.  T. Rose: Entscheidungsorientierte Versionen- und
  443. Konfigurationenverwaltung.  Dissertation, Universitaet Passau,
  444. 1991.
  445.  
  446.  
  447.  D. Sannella, M. Wirsing: A kernel language
  448. for algebraic specification and implementation. In M. Karpinski
  449. (ed.): Colloquium on Foundations of Computation theory. Springer
  450. Lecture Notes in Computer Science 158, 1983, 413-427.
  451.  
  452.  
  453.  R. Stabl: Personal communication, September 1991.
  454.  
  455.  
  456.  M. Wirsing: Algebraic description of reusable
  457. software components. In: Proc.  COMPEURO '88, Computer Society
  458. Press of the IEEE, no. 834, 300-312, 1988.
  459.  
  460.  
  461.  M. Wirsing: Algebraic specification. In: J.van
  462. Leeuwen (ed.): Handbook of Theoretical Computer Science, Vol. B,
  463. Amsterdam: North-Holland, 1990, 675-788.
  464.  
  465.  
  466.  M. Wirsing: Stuctured specification: syntax,
  467. semantics and proof calculus. In: H.  Schwichtenberg (ed.): Proc.
  468. International Summer School Marktoberdorf 1991, to appear.
  469.  
  470.  
  471.  
  472.  
  473.   About the Author 
  474.  
  475. Prof. Dr. Martin Wirsing studied Mathematics at the University of 
  476. Paris and at the 
  477. Technical 
  478. University of Munich. From 1975 until 1983 he worked as a research and 
  479. teaching 
  480. assistant at the Sonderforschungsbereich  ``Programmiertechnik'' at the 
  481. Technical 
  482. University of Munich. During this time he had been a member of the Munich 
  483. CIP group 
  484. that worked on program specification and transformation. He wrote his 
  485. dissertation at the Technical University of Munich (with the title 
  486. ``Das Entscheidungsproblem der ``adikatenlogik 
  487. erster Stufe mit Funktionszeichen in 
  488. Herbrandformeln'') 
  489. and his habilitation (1984 with the title ``Structured algebraic 
  490. specifications: a kernel language''). 
  491. Since 1985 he is full professor for Computer Science 
  492. at the Faculty of 
  493. Mathematics and Computer Science at the University of Passau. He is 
  494. working in the ESPRIT projects METEOR, DRAGON and in the ESPRIT Working 
  495. Group 
  496. COMPASS. From 1986 to 1988 he had been the chairman (Dekan) of the Faculty 
  497. of Mathematics 
  498. and Computer Science of the University of Passau, and from 1988 till 
  499. 1990 he was the 
  500. vicechairman (Prodekan) of the faculty.
  501. Martin Wirsing 
  502. has published more than 90 scientific papers in the areas of mathematical 
  503. logic, programming methodology, semantics of programming languages, program 
  504. transformation and program development, formal specification and algebraic 
  505. specification languages.
  506. Since 1990 he is one of the directors of the ``Bavarian Research Center of 
  507. Knowledge-based Systems'' (FORWISS).
  508. He is member 
  509. of the editorial board of several scientific journals including Theoretical 
  510. Computer Science, Technique et Science Informatique, 
  511. RAIRO-Informatique Theorique 
  512. et Applications and Research Notes in Theoretical Computer Science.
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519. -- 
  520.  
  521.