home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / unix / volume19 / shape / part30 < prev    next >
Text File  |  1989-05-31  |  50KB  |  1,314 lines
  1. Subject:  v19i043:  A software configuration management system, Part30/33
  2. Newsgroups: comp.sources.unix
  3. Sender: sources
  4. Approved: rsalz@uunet.UU.NET
  5.  
  6. Submitted-by: Axel Mahler <unido!coma!axel>
  7. Posting-number: Volume 19, Issue 43
  8. Archive-name: shape/part30
  9.  
  10.  
  11.  
  12. #! /bin/sh
  13. # This is a shell archive.  Remove anything before this line, then unpack
  14. # it by saving it into a file and typing "sh file".  To overwrite existing
  15. # files, type "sh file -c".  You can also feed this as standard input via
  16. # unshar, or by typing "sh <file", e.g..  If this archive is complete, you
  17. # will see the following message at the end:
  18. #        "End of archive 30 (of 33)."
  19. # Contents:  papers/lisbon.ms
  20. # Wrapped by rsalz@papaya.bbn.com on Thu Jun  1 19:27:19 1989
  21. PATH=/bin:/usr/bin:/usr/ucb ; export PATH
  22. if test -f 'papers/lisbon.ms' -a "${1}" != "-c" ; then 
  23.   echo shar: Will not clobber existing file \"'papers/lisbon.ms'\"
  24. else
  25. echo shar: Extracting \"'papers/lisbon.ms'\" \(46807 characters\)
  26. sed "s/^X//" >'papers/lisbon.ms' <<'END_OF_FILE'
  27. X.IZ
  28. X.sp -0.9di
  29. X.ND
  30. X.nr UX 1
  31. X\" --- cut here --- 
  32. X.AM
  33. X.ds Rf References
  34. X.ds Un \\s-1\\f(HBU\\s-2NI\\s+2B\\s-2ASE\\fR\\s+3
  35. X.ds Co \\s-2\\f(HBCOMA\\fR\\s+2
  36. X.ds Da \\s-2\\f(HBDAMOKLES\\fR\\s+2
  37. X.ds Th \\s-2\\f(HBTHESEUS\\fR\\s+2
  38. X.ds Mk Make
  39. X.ds sh \\s-1\\f(HBshape\\fR\\s+1
  40. X.ds Af AFS
  41. X.TL
  42. XAn Object Base for Attributed Software Objects\(dg
  43. X.FS
  44. X\(dg in \fIProceedings of the EUUG Autumn '88 Conference\fR
  45. X.br
  46. X(Cascais, 3-7 October 1988), pp. 95-105, European UNIX Users Group, London 1988
  47. X.FE
  48. X.AU
  49. XAndreas Lampen, Axel Mahler
  50. Xandy@coma.uucp, axel@coma.uucp
  51. X.AI
  52. XTechnische Universit\*:at Berlin
  53. XSekretariat FR 5-6
  54. XFranklinstr. 28/29
  55. XD-1000 Berlin 10
  56. X.AB
  57. XThe
  58. X.UX
  59. Xfilesystem supports a fixed set of attributes for filesystem
  60. Xobjects, stored in inodes and directory entries.
  61. XThe (path-)name attribute is the sole means to identify
  62. Xand access a filesystem object.
  63. XThis turns out to be a rather severe limitation for certain
  64. Xcomplex applications such as large scale software development,
  65. Xwhere software objects typically evolve in a considerable number of
  66. Xversions.
  67. X.LP
  68. XAn approach to improve the situation
  69. Xis introduced by the \fIattribute filesystem\fR (\*(Af),
  70. Xthe system described in this paper.
  71. XThe \*(Af combines the notion of immutable objects (versions)
  72. Xwith the possibility to attach any number of user-definable
  73. Xattributes to any attributed software object (ASO).
  74. X\*(Af objects can be identified by specifying any set of
  75. Xattribute value(s) as retrieve pattern.
  76. XThe \fIname\fR of an \*(Af object is treated as \fIjust another attribute\fR.
  77. XThe \*(Af is equipped with a proper retrieve interface that allows
  78. Xnon-unique identification of \fIsets of objects\fR and provides
  79. Xoperations on those sets.
  80. X.LP
  81. XThe \*(Af is a significant extension to the
  82. X.UX
  83. Xfilesystem interface providing applications with a unified,
  84. Xconsistent view of attributed filesystem objects comprising
  85. Ximmutable versions and ordinary
  86. X.UX
  87. Xfiles.
  88. XThe concept of \fIpersistent objects\fR makes \*(Af a basis
  89. Xfor object oriented applications in an
  90. X.UX
  91. Xenvironment. 
  92. XWe used \*(Af as a basis for the implementation of the \*(sh toolkit,
  93. Xa collection of programs supporting
  94. Xsoftware configuration management in multi-programmer software
  95. Xdevelopment projects.
  96. X.LP
  97. XOne important objective of \*(Af is to abstract from the actually
  98. Xunderlying data storage system. This paper will briefly discuss
  99. Xtwo different implementations of \*(Af \- one on top of the
  100. X.UX
  101. Xfilesystem and the other based on \*(Da, a dedicated software
  102. Xengineering database.
  103. X.AE
  104. X.NH 1
  105. XIntroduction
  106. X.LP
  107. XThe context of this work was the design of a software configuration
  108. Xmanagement system to be part of a kernel of an open
  109. X.UX
  110. Xbased software engineering environment.
  111. XLarge scale software development requires a system
  112. Xcapable to store a big number of software objects, typically
  113. Xevolving in a considerable number of versions.
  114. X.LP
  115. XThe
  116. X.UX
  117. Xfilesystem is a good basis for this job but it has
  118. Xsome severe limitations.
  119. XIt supports only a fixed set of attributes for filesystem
  120. Xobjects, stored in inodes and directory entries.
  121. XThe (path-)name attribute is the sole means to identify
  122. Xand access a filesystem object.
  123. XVersion control systems had to be introduced as auxiliary tools,
  124. Xto avoid name clashes and to store multiple versions
  125. Xof files in an space efficient manner.
  126. XHowever, they do not overcome the fundamental shortcomings
  127. Xof the
  128. X.UX
  129. Xfilesystem.
  130. XThey represent partial solutions to particular problems
  131. Xand integrate poorly with
  132. X.UX
  133. Xtools such as \*(Mk [2].
  134. X.LP
  135. XAs a try to overcome these limitations we designed the \fIattribute
  136. Xfilesystem\fR (\*(Af), the system described in this paper.
  137. XWe use the name attribute \fIfilesystem\fR mainly for historical
  138. Xreasons (because we are used to it and we haven't found a better
  139. Xname yet).
  140. XSo don't be confused when we subsequently refer to
  141. X\*(Af as an \fIobject base\fR rather than a filesystem.
  142. XAccordingly we will use the term \fIsoftware object\fR instead of
  143. X\fIfile\fR throughout this paper.
  144. X.LP
  145. XAn object base is a hybrid of filesystem and database trying
  146. Xto combine the advantages of both types of data storage systems.
  147. XThe advantages of an object base over a filesystem
  148. Xlie in its
  149. X.IP \(bu 0.2i
  150. Xmore general object identification scheme,
  151. X.IP \(bu
  152. Xability to store multiple versions of objects,
  153. X.IP \(bu
  154. Xsupport for the management of arbitrary attributes for objects and
  155. X.IP \(bu
  156. Xabstraction from the physical representation of objects.
  157. X.RE
  158. X.LP
  159. XImprovements in respect to database systems are
  160. X.IP \(bu 0.2i
  161. Xthe concept \fIobject\fR
  162. Xas manageable, user identifyable, interchangeable piece of data
  163. Xand a common understanding of how data looks like (a basis for integration
  164. Xof existing and new tools),
  165. X.IP \(bu
  166. Xno need for a schema (i.e. no problems with schema updates),
  167. X.IP \(bu
  168. Xbetter network support (\fIobjects\fR are quite easyly interchangeable
  169. Xbetween different machines) and
  170. X.IP \(bu
  171. Xbetter performance (in most cases)
  172. X.RE
  173. X.LP
  174. XFor a detailed discussion on how a persistent object base should
  175. Xlook like, see [6].
  176. X.LP
  177. X\*(Af is designed as basis for the \*(sh-toolkit, described in  [4]
  178. Xand [5].
  179. XThe \*(sh-toolkit is a configuration management toolkit
  180. Xintegrating a dedicated version control system and \*(sh, a
  181. Xsignificantly enhanced \*(Mk program.
  182. XEnhancements include full access to the version control system.
  183. X\*(sh's procedure of identifying
  184. Xappropriate component versions that together form a meaningful system 
  185. Xconfiguration may be completely controlled by user-supplied \fIconfiguration
  186. Xselection rules\fR. Selection rules are placed in the \fIShapefile\fR,
  187. X\*(sh's counterpart to the Makefile.
  188. X.LP
  189. XThe next chapter gives an overview of the basic concepts of \*(Af.
  190. XIn chapter 3, we briefly describe the interface and have a
  191. Xlook at two different implementations.
  192. XThe last chapter contains an outlook on current development
  193. Xefforts to make \*(Af a basis for object oriented applications.
  194. X.NH 1
  195. XGeneral design
  196. X.LP
  197. X\*(Af is a system to store software objects as 
  198. Xa complex of (from the AFS' point of view) unstructured
  199. Xcontent data and an arbitrary
  200. Xnumber of associated attributes.
  201. XWe call these objects \fIattributed software objects\fR (ASOs).
  202. X\*(Af has a built-in version control system that supports the storage
  203. Xand identification of different versions of \fIdesign objects\fR.
  204. XA design object consists of a group of
  205. Xsuccessive versions evolving by taking snapshots of the current
  206. Xdevelopment state from time to time.
  207. XThroughout this paper we also use the term \fIline of development\fR
  208. Xsynonymously to \fIdesign object\fR.
  209. XEach version of a design object is an attributed software object on its own.
  210. XFor a more detailed discussion of software engineering terms see [10].
  211. X.LP
  212. XDue to the requirements of a multi programmer software
  213. Xdevelopment environment we introduced
  214. Xa mechanism for reserving update rights for design objects
  215. Xby setting a lock on this object.
  216. XReserving the update right has
  217. Xthe effect, that updates can only be stored by the user
  218. Xcurrently holding the lock.
  219. X.LP
  220. X\*(Af was designed to be a basis for integration of a large spectrum
  221. Xof different software development tools.
  222. XThese may be editors, compilers, formatters,
  223. Xa software configuration management system, tools for
  224. Xproject planning and status accounting, test support, specification
  225. Xand design tools \(em a potentially very long list.
  226. XIn respect to tool integration, an
  227. Xengineering environment has to offer some form of
  228. Xintelligent support for the user in order to improve
  229. Xthe situation presented by mere toolbox systems.
  230. XHowever, it is not feasible for the object
  231. Xmanagement part of such an environment to understand the
  232. Xformal semantics contained \fIin\fR the various types of
  233. Xobjects it manages.
  234. XThe functional behavior of an environment's object manager
  235. Xshould rather be guided by simple information \fIabout\fR the
  236. Xmanaged objects.
  237. XAttributes enable each \*(Af application program to store information
  238. Xabout a software object persistently either for later use or
  239. Xleaving them for interpretation by other \*(Af applications (or both).
  240. X.LP
  241. XIt is likely that the number of needed attributes will grow with each new
  242. Xtool using \*(Af.
  243. XAs we cannot foresee which new \*(Af applications will be
  244. Xintroduced in the future, we are not able to define a fixed set of
  245. Xattributes serving all needs.
  246. XInstead, we decided to keep the number of attributes
  247. Xfor each stored object dynamically extensible.
  248. XBesides some standard attributes (such as name, size or version), 
  249. Xeach software object is stored with a potentially infinite number of
  250. Xapplication-defined attributes.
  251. X.LP
  252. XAnother important design goal was the introduction of a
  253. Xconcept for the integration of standard
  254. X.UX
  255. Xtools and off\-the\-shelf tools that operate on regular files.
  256. XFor this purpose, \*(Af is designed to be able to coexist with the
  257. X.UX
  258. Xfilesystem.
  259. XIt allows regular
  260. X.UX
  261. Xfiles to be treated as \*(Af objects and to be accessed through the \*(Af
  262. Xinterface.
  263. XThis opens a way to exchange data between existing tools that operate on
  264. X.UX
  265. Xfiles and tools on top of \*(Af (such as the \*(sh toolkit).
  266. XFigure 2.1 illustrates the tool integration on base
  267. Xof \*(Af. \*(Af is a C\-language interface that abstracts from the
  268. Xunderlying data storage system (e.g. a filesystem or a database).
  269. X.KF
  270. X.sp 5p
  271. X.PS
  272. X    boxht=0.6i
  273. X    move right 0.9i
  274. XDs: box wid 2.2i "Data Storage System" "(e.g. Filesystem or Database)"
  275. X    box wid 1.9i "UNIX filesystem"
  276. X    move to Ds.nw; move up 0.3i; move right 0.2i;
  277. XAf: box wid 2.6i "Attribute File System"; move up 0.3i; right
  278. X    box ht 1.2i wid 1i "other" "programs:" "Editors" "Compilers" "Formatters"
  279. X    move to Af.nw; move up 0.3i; move right 0.2i
  280. X    box wid 0.8i "Version" "Control" "Commands"
  281. X    box wid 0.8i "\*(sh"
  282. X    box wid 0.8i "other" "AFS" "Applications"
  283. X.PE
  284. X.sp 5p
  285. X.ce
  286. X\fBFig. 2.1:\fR The AFS and its applications
  287. X.sp 5p
  288. X.KE
  289. X.LP
  290. XApart from versions and attributes, \*(Af looks very much like the
  291. X.UX
  292. Xfilesystem with a hierarchical directory structure, special files and so on.
  293. X.LP
  294. X.NH 2
  295. XSource objects and derived objects
  296. X.LP
  297. X\*(Af manages \fIlines of development\fR. A line of development
  298. Xconsists of a \fIbusy object\fR and a number of saved versions.
  299. XThe busy object is an ordinary alterable
  300. X.UX
  301. Xfile.
  302. XIt can be accessed via \*(Af \fIand\fR
  303. X.UX
  304. Xfilesytem operations.
  305. XVersions come into being by making a copy of the current state of
  306. Xthe busy object.
  307. XThey can be stored as source objects or as derived objects.
  308. X.LP
  309. XSource objects are typically composed manually (e.g. by use of a
  310. Xtext editor).
  311. X\*(Af stores source objects as immutable objects.
  312. XOnce saved, they cannot be modified any longer.
  313. XThey can only be explicitly removed by their owner or author.
  314. XSource objects can be uniquely identified by the attribute values
  315. Xfor \fIhostname, system path, name, type, generation number,
  316. Xrevision number\fR and \fIvariant\fR.
  317. X.LP
  318. XDerived objects are typically derived automatically (e.g. by a
  319. Xcompiler) from a source object and thus be reproducible at any time.
  320. XThey are kept in a \fIderived object pool\fR ( see also [3]
  321. X), a data store of limited
  322. Xsize that is administered in a cache fashion. The oldest (access
  323. Xdate) derived objects get removed if space runs short in the binary
  324. Xpool. Unlike source objects, the tupel (\fIhostname, system path, name,
  325. Xtype, generation number, revision number, variant\fR) does not necessarily
  326. Xhave to be unique for derived objects. Derived
  327. Xobjects may differ only in user defined attributes !
  328. X.LP
  329. X\*(Af makes no assumptions whether a copy of a busy object shall be
  330. Xstored as source object or as derived object.
  331. XThis has to be decided by the application.
  332. X.NH 2
  333. XAttributed Software Objects
  334. X.LP
  335. XAttributes have the general form \fIname=[value [value ...]]\fR.
  336. XFigure 2.2 illustrates the term attributed software object.
  337. X.KF
  338. X.PS
  339. X    move right 1.1i
  340. XDa: box ht 2i wid 1.5i "\s+9\f(HBDATA\fR\s-9"
  341. X    line from Da.nw - 0,0.1 to Da.nw + 0.1,0
  342. X    line from Da.nw - 0,0.2 to Da.nw + 0.2,0
  343. X    line from Da.nw - 0,0.3 to Da.nw + 0.3,0
  344. X    line from Da.nw - 0,0.4 to Da.nw + 0.4,0
  345. X    line from Da.nw - 0,0.5 to Da.nw + 0.5,0
  346. X    line from Da.nw - 0,0.6 to Da.nw + 0.6,0
  347. X    line from Da.nw - 0,0.7 to Da.nw + 0.7,0
  348. X    line from Da.nw - 0,0.8 to Da.nw + 0.8,0
  349. X    line from Da.nw - 0,0.9 to Da.nw + 0.9,0
  350. X    line from Da.nw - 0,1.0 to Da.nw + 1.0,0
  351. X    line from Da.nw - 0,1.1 to Da.nw + 1.1,0
  352. X    line from Da.nw - 0,1.2 to Da.nw + 1.2,0
  353. X    line from Da.nw - 0,1.3 to Da.nw + 1.3,0
  354. X    line from Da.nw - 0,1.4 to Da.nw + 1.4,0
  355. X    line from Da.nw - 0,1.5 to Da.nw + 1.5,0
  356. X    line from Da.nw - 0,1.6 to Da.ne - 0,0.1
  357. X    line from Da.nw - 0,1.7 to Da.ne - 0,0.2
  358. X    line from Da.nw - 0,1.8 to Da.ne - 0,0.3
  359. X    line from Da.nw - 0,1.9 to Da.ne - 0,0.4
  360. X    line from Da.nw - 0,2.0 to Da.ne - 0,0.5
  361. X    line from Da.sw + 0.1,0 to Da.ne - 0,0.6
  362. X    line from Da.sw + 0.2,0 to Da.ne - 0,0.7
  363. X    line from Da.sw + 0.3,0 to Da.ne - 0,0.8
  364. X    line from Da.sw + 0.4,0 to Da.ne - 0,0.9
  365. X    line from Da.sw + 0.5,0 to Da.ne - 0,1.0
  366. X    line from Da.sw + 0.6,0 to Da.ne - 0,1.1
  367. X    line from Da.sw + 0.7,0 to Da.ne - 0,1.2
  368. X    line from Da.sw + 0.8,0 to Da.ne - 0,1.3
  369. X    line from Da.sw + 0.9,0 to Da.ne - 0,1.4
  370. X    line from Da.sw + 1.0,0 to Da.ne - 0,1.5
  371. X    line from Da.sw + 1.1,0 to Da.ne - 0,1.6
  372. X    line from Da.sw + 1.2,0 to Da.ne - 0,1.7
  373. X    line from Da.sw + 1.3,0 to Da.ne - 0,1.8
  374. X    line from Da.sw + 1.4,0 to Da.ne - 0,1.9
  375. X    move to Da.se + 0.5,0
  376. XAt: line up 2.1i; line right 1.5i; line down 2i
  377. X    move left 1.45i; line right 1.5i; down
  378. X    arc from Here - 0,0.2i to Here rad 0.1i; move down 0.2i
  379. X    line left 1.5i; up; ellipsewid = 0.1i; ellipseht = 0.2i; ellipse
  380. X    move to Da.ne + 0.6i,0; move down 0.1i
  381. X    "name=otto" ljust; move down 0.12i
  382. X    "type=c" ljust; move down 0.12i
  383. X    "generation=4" ljust; move down 0.12i
  384. X    "revision=3" ljust; move down 0.12i
  385. X    "variant=" ljust; move down 0.12i
  386. X    "state=saved" ljust; move down 0.12i
  387. X    "author=andy" ljust; move down 0.12i
  388. X    "mode=0644" ljust; move down 0.12i
  389. X    "mdate=881001-12:22:34" ljust; move down 0.12i
  390. X    "sdate=881002-22:44:16" ljust; move down 0.12i
  391. X    "project=shape" ljust; move down 0.12i
  392. X    "testlevel=low" ljust; move down 0.12i
  393. X    "do_next=fix retrv-bug" ljust; move down 0.12i
  394. X    "..." ljust
  395. X
  396. X    line from Da.ne - 0,0.9 right 0.5i up 0.1i
  397. X    line from Da.ne - 0,1.1 right 0.5i up 0.1i
  398. X.PE
  399. X.sp 5p
  400. X.ce
  401. X\fBFig. 2.2:\fR An Attributed software object
  402. X.sp 5p
  403. X.KE
  404. X.LP
  405. X\*(Af supports a set of standard attributes for each ASO.
  406. XThese are
  407. X.IP \(bu 0.2i
  408. Xhostname, system path, name, type,
  409. X.IP \(bu
  410. Xgeneration number, revision number, variant name, version state,
  411. X.IP \(bu
  412. Xowner, author,
  413. X.IP \(bu
  414. Xsize,
  415. X.IP \(bu
  416. Xaccess permissions, lock,
  417. X.IP \(bu
  418. Xdate of last modification, \- last access, \- last status change,
  419. X\- saving and \- last lock change
  420. X.RE
  421. X.LP
  422. XThe \fIsystem path\fR attribute is used to describe the (logical)
  423. Xposition of an ASO in a complex, hierarchically structured
  424. Xsystem. \fISystem path, name\fR and
  425. X\fItype\fR are currently mapped to
  426. X.UX
  427. Xpathnames where they take the place of path prefix, filename (without suffix)
  428. Xand filename suffix. For example: the system path \fC/usr/axel\fR,
  429. Xname \fCfoo\fR and type \fCc\fR are mapped to the
  430. X.UX
  431. Xfilename \fC/usr/axel/foo.c\fR.
  432. XAdditionally to the \fIowner\fR attribute known from
  433. X.UX
  434. Xfiles ASOs also have an \fIauthor\fR attribute.
  435. X\*(Af distinguishes the \fIowner\fR of an entire design object
  436. Xand the \fIauthor\fR of a particular version. 
  437. X.LP
  438. XIn addition to the standard attributes, an application may attach any
  439. Xnumber of \fIuser defined attributes\fR to any ASO.
  440. XInterpretation and use of these attributes is left to the application
  441. Xthat uses them.
  442. X\*(Af manages user defined attributes as a structure containing
  443. Xthe attribute name and a (possibly empty) set of strings
  444. Xholding the associated attribute value(s).
  445. X.LP
  446. XAttributes can be used for very different purposes.
  447. XThe standard attributes are used mainly for ordering and 
  448. Xidentifying software objects and for general management.
  449. XUser defined attributes will be used to store application
  450. Xspecific information with an ASO.
  451. X.LP
  452. XA typical example for the use of user defined attributes
  453. Xcan be found in the \*(sh program.
  454. XFor each derived object (e.g. an object file that is produced by
  455. Xcompiling a C source file), the name of the transformation tool
  456. Xand all given flags and parameters are protocoled in an
  457. Xattribute.
  458. XBesides the description of the transformation process, the name(s)
  459. Xand version(s) of the involved source
  460. Xobject(s) are recorded as list of values in another attribute.
  461. XThis enables \*(sh to handle recompilations in a much more
  462. Xsophisticated way than Make.
  463. X.LP
  464. XAnother example might be a tiny program that allows a user
  465. Xto associate any number of keywords with his software objects.
  466. XSuch a program would allow a grouping of ASOs via keywords
  467. Xindependently of the directory structure.
  468. XUser defined attributes can also be used to model references
  469. Xbetween ASOs.
  470. XAttaching the identification of the corresponding source object
  471. Xas attribute to a derived object actually \fIis\fR a reference.
  472. X.LP
  473. XThe full power of the concept of user defined attributes is hardly 
  474. Xused yet but we feel that there \fIis\fR a lot of power in this approach.
  475. XOur first application programs use this mechanism in a
  476. Xstraightforward manner (illustrated in the examples above) and it works fine.
  477. XUser defined attributes may also be used in a more exotic way
  478. Xsuch as to store patches (e.g. ed scripts generated by \fIdiff\fR)
  479. Xto source objects.
  480. X.LP
  481. XOn the basis of user defined attributes it will further be quite
  482. Xeasy to construct a general object class manager that
  483. Xprovides an interface for the storage of typed software
  484. Xobjects with type specific attributes.
  485. XThis will be discussed in greater detail in chapter 4.
  486. X.NH 2
  487. XIdentification and Object-Keys
  488. X.LP
  489. XDue to the introduction of versions, ASOs cannot be uniquely
  490. Xidentified by just giving their (path-)name (like in the
  491. X.UX
  492. Xfilesystem).
  493. XFor the identification of attributed software objects, all attributes
  494. Xare considered equally qualified.
  495. X\*(Af is equipped
  496. Xwith a retrieve interface for nonunique identification of sets of ASOs.
  497. XA retrieve operation is driven by an attribute pattern containing
  498. Xall desired attribute values.
  499. X.LP
  500. XOnce identified, an ASO is represented by a unique \fIObject-key\fR
  501. Xby which it can be accessed further on.
  502. XObject keys can be fetched from a set, delivered by a retrieve
  503. Xoperation.
  504. XSelecting an object key from a set is supported by operations
  505. Xfor sorting sets by attribute values, recursive retrieve (a retrieve
  506. Xoperation with a set as search space) and building unions,
  507. Xintersections, or differences between two sets.
  508. X.KF
  509. X.sp 5p
  510. X.PS
  511. X    boxwid = 0.6i; boxht = 0.6i; circlerad = 0.3i;
  512. X    circle "set of" "required" "attrs."; arrow right 0.15i
  513. X    box "AFS" "retrieve"; arrow right 0.15i
  514. X    circle "set of" "object" "keys"; arrow right 0.15i
  515. X    box "SELECT" "OBJECT" "KEY"; arrow right 0.15i
  516. XSo: circle "single" "object key"
  517. XGa: box "AFS" "get" "attributes" at So + 0.7i,0.4i
  518. XAo: box "AFS" "open" at So + 0.7i,-0.4i; arrow right 0.15i
  519. X    circle "FILE" "descriptor"; arrow right 0.15i
  520. X    box "file-" "system" "I/O"
  521. X    arrow from So to Ao chop 
  522. X    arrow from So to Ga chop
  523. X.PE
  524. X.sp 5p
  525. X.ce
  526. X\fBFig. 2.3:\fR Access principle for ASOs
  527. X.sp 5p
  528. X.KE
  529. X.LP
  530. XAccess to the attributes as well as the contents on an ASO is also
  531. Xestablished via object keys.
  532. XTo access its contents, an ASO has to be opened.
  533. XOnce opened, the content data of an ASO can be read and written
  534. Xas regular
  535. X.UX
  536. Xfiles (see fig. 2.3).
  537. X.NH 2
  538. XVersion Control
  539. X.LP
  540. X\*(Af maintains a sequence of \fIrevisions\fR (successive versions)
  541. Xfor each design object.
  542. XThe numbering of revisions in a line of development is under control of
  543. Xthe \*(Af. Every time when a new revision is generated by saving
  544. Xa copy of the busy object, it is assigned a version identification of the form
  545. X\fIgeneration.revision\fR (e.g. 1.0 or 4.3).
  546. XGeneration numbers indicate major development steps that
  547. Xare common to all components of a complex system.
  548. XThe revision number serves as an update sequence number for individual
  549. Xcomponents within a generation.
  550. X.LP
  551. XBesides revisions, a version control system has to be able to store
  552. X\fIvariants\fR \- qualitatively equivalent versions differing in a
  553. Xcertain property \- of source objects.
  554. XA typical example for variants is a user interface module
  555. Xthat deals with different window systems.
  556. XUnlike the identification of revisions, where a generation.revision
  557. Xnumbering scheme turned out to be common sense, there is no
  558. Xusual variant naming scheme.
  559. XWe know systems, where variants are numbered, named (with single
  560. Xor multiple names) or both.
  561. X.LP
  562. XThe general management of variants is a major conceptual problem.
  563. XThe idea of variants sounds quite simple, but
  564. Xto actually handle them can be an extremely difficult task.
  565. XUp till now there doesn't seem to be a tool that conducts
  566. Xthe development of system variants in a really satisfying manner.
  567. XNevertheless we want to establish a reasonable basis for
  568. Xsuch a tool by providing an instructive and flexible
  569. Xvariant identification mechanism.
  570. X\*(Af supports a \fIvariant\fR attribute (a string) for each ASO.
  571. XThe variant attribute is totally independent from the revision
  572. Xnumbering, i.e. each variant is stored in its own line of development
  573. Xwith independent revision numbering.
  574. XAny structure of the variant string (e.g. multiple variant names)
  575. Xhas to be maintained by the application(s) [5].
  576. X.NH 3
  577. XBranches
  578. X.LP
  579. XOne major difference between the \*(Af builtin version control system
  580. Xand classical systems like RCS [9]
  581. Xand SCCS [8] 
  582. Xis, that \*(Af establishes a user oriented view of versions
  583. Xthat abstracts from the physical derivation graph.
  584. XIn contrary to RCS and SCCS,
  585. Xversion histories in \*(Af are essentially linear.
  586. XLogically, new versions are always appended to the end of the
  587. Xversion history.
  588. XUpdates of older versions can be attached as leaves (not branches)
  589. Xto the line of development (see fig 2.5).
  590. XVariants are stored in parallel lines of development.
  591. X.LP
  592. XAt first glance, it looks like a loss of functionality of the \*(Af
  593. Xversion control system
  594. Xcompared to systems like RCS or SCCS (where are the branches).
  595. XA closer look shows, that there is only a different identification
  596. Xscheme.
  597. X.LP
  598. XFigures 2.4 and 2.5.
  599. Xshow the same number of revisions/variants developed in the same way.
  600. XThe first figure shows a RCS version tree and the second
  601. Xshows its \*(Af pendant.
  602. X.KF
  603. X.sp 5p
  604. X.PS
  605. X    circlerad = 0.25i;
  606. X    box ht 3.1i wid 5.8i; move to 0.3i,0;
  607. XC1: circle "1.1"; arrow right 0.5i
  608. XC2: circle "1.2"; arrow right 0.5i
  609. XC3: circle "1.3"; arrow right 0.5i
  610. XC4: circle "2.1"; arrow right 0.5i
  611. XC5: circle "2.2"
  612. XC6: circle "1.1.1.1" at C1 + 0.5i,0.6i; arrow from C1 to C6 chop
  613. XC7: circle "1.2.1.1" at C2 + 0.5i,0.6i; arrow from C2 to C7 chop
  614. XC8: circle "1.3.1.1" at C3 + 0.5i,0.6i; arrow from C3 to C8 chop
  615. XC9: circle "1.2.3.1" at C2 + 0.5i,-0.6i; arrow from C2 to C9 chop
  616. X    move to right of C9; arrow right 0.4i;
  617. XC0: circle "1.2.3.2"; arrow right 0.4i; circle "1.2.3.3"
  618. XCa: circle "1.2.2.1" at C2 + 0.3i,1.2i; arrow from C2 to Ca chop
  619. X    move to right of Ca; arrow right 1.8i; circle "1.2.2.2"
  620. XCb: circle "1.2.3." "2.1.1" at C0 + 0.4i,-0.6i; arrow from C0 to Cb chop
  621. X.PE
  622. X.sp 5p
  623. X.ce
  624. X\fBFig. 2.4:\fR RCS version tree
  625. X.sp 5p
  626. X.KE
  627. X.KF
  628. X.sp 5p
  629. X.PS
  630. X    circlerad = 0.25i;
  631. X    move to 0,0.3i; box ht 1.3i wid 5.9i
  632. X    move to 0,1.4i; box ht 0.7i wid 5.9i
  633. X    move to 0,-1.1i; box ht 1.3i wid 5.9i; move to 0.3i,0;
  634. XC1: circle "1.0"; arrow right 0.5i
  635. XC2: circle "1.1"; arrow right 0.5i
  636. XC3: circle "1.2 / 2.0"; arrow right 0.5i
  637. XC4: circle "2.1"; arrow right 0.5i
  638. XC5: circle "2.2"
  639. XC6: circle "1.0" "fix1" at C1 + 0.5i,0.6i; arrow from C1 to C6 chop
  640. XC7: circle "1.1" "patch1" at C2 + 0.5i,0.6i; arrow from C2 to C7 chop
  641. XC8: circle "1.2" "fix1" at C3 + 0.5i,0.6i; arrow from C3 to C8 chop
  642. X    circle "1.0" "X" at C2 + 0.3i,1.4i; arrow right 1.8i; circle "1.2" "X"
  643. XC9: circle "1.1" "NeWS" at C2 + 0.5i,-1.4i; arrow right 0.4i;
  644. XC0: circle "1.2 / 2.0" "NeWS"; arrow right 0.4i; circle "2.1" "NeWS"
  645. XCb: circle "1.2" "NeWS" "fix1" at C0 + 0.5i,0.6i; arrow from C0 to Cb chop
  646. X.PE
  647. X.sp 5p
  648. X.ce
  649. X\fBFig. 2.5:\fR AFS lines of development
  650. X.sp 5p
  651. X.KE
  652. X.LP
  653. XThe version identification scheme of \*(Af abstracts from the
  654. Xphysical evolution of the single versions
  655. X(nevertheless, the physical links are there and maintained in
  656. Xa way similar to RCS).
  657. XRCS and SCCS present a data structure oriented view
  658. Xof version histories to the user.
  659. XSome nasty problems arise from mixing
  660. Xlogical and physical derivation graph in respect to numbering/naming
  661. Xof revisions.
  662. XFirst, version numbers in branches get very complex (four or more numbers)
  663. Xwhich is not very instructive. Second, although there are \(lqso many
  664. Xnumbers\(rq there is no generation number in branches !
  665. X.LP
  666. XConceptually, \*(Af does not support arbitrary branching.
  667. XBranching off the main line of development happens most of the time 
  668. Xbecause a developer wants to
  669. X.IP \(bu 0.2i
  670. Xcreate a variant or
  671. X.IP \(bu
  672. Xstore modifications of older versions (bug-fixes or customizations) or
  673. X.IP \(bu
  674. Xmake experimental changes that should not necessarily
  675. Xgo into the main line of development.
  676. X.RE
  677. X.LP
  678. XThe first case should be realized by parallel lines of development.
  679. XThe latter two cases are not explicitly supported by
  680. X\*(Af itself.
  681. XA solution has to be given by an application program
  682. Xeither based on an extended use of
  683. Xthe \fIvariant\fR attribute or on storing patches in
  684. Xuser defined attributes.
  685. X.NH 3
  686. XThe version status model
  687. X.LP
  688. XAs a consequence of the original design of \*(Af as part of a
  689. Xsoftware development environment,
  690. X\*(Af provides a status model for saved source objects to support the
  691. Ximplementation of a general project organization scheme.
  692. XThe project organization scheme we have in mind
  693. Xdistinguishes between private workspaces for each participating
  694. Xprogrammer, and a central project database, where all the serious
  695. Xresults of the programmers' efforts are collected.
  696. X.LP
  697. XThe basic status model that is built into the version control system
  698. Xrecognizes the following states:
  699. X.IP \fBbusy\fR 0.8i 
  700. XThe object is under development and its contents may
  701. Xbe changed.
  702. X.IP \fBsaved\fR 
  703. XThe object is saved and may be used for later backup.
  704. X.IP \fBproposed\fR
  705. XThe object has been submitted for publication by the developer
  706. Xbut still needs formal approval by a quality assurance board
  707. Xto become publically visible and accessible in the official
  708. Xdatabase.
  709. X.IP \fBpublished\fR
  710. XThe object has passed the formal approval and is now accessible to
  711. Xevery member of the project. It is not yet accessed and may therefore
  712. Xbe withdrawn if necessary.
  713. X.IP \fBaccessed\fR 
  714. XThe object has been published, and is now 
  715. Xaccessed by some members of the project.
  716. X.IP \fBfrozen\fR
  717. XThe object may be part of a system configuration
  718. Xthat has been released to the outside world. This means it must under
  719. Xno circumstances be destroyed.
  720. X.RE
  721. X.NH 1
  722. XRealization
  723. X.LP
  724. XCurrently, we have two different implementations of \*(Af (in 
  725. Xdifferent development stages).
  726. XOne on top of the
  727. X.UX
  728. Xfilesytem and another one on top of \*(Da,
  729. Xa dedicated software engineering database [1].
  730. XBoth are written in C and provide a library interface.
  731. XFurther developments will be made in C++ and we will implement
  732. Xa new interface in C++.
  733. X.LP
  734. XThe interface of both implementations is nearly identical.
  735. XDifferences exist only in marginal routines concerning the data
  736. Xmanagement. For example has the \*(Da implementation additional
  737. Xroutines for opening and closing the database.
  738. X.NH 2
  739. XThe Interface
  740. X.LP
  741. XThe main datatypes of \*(Af are:
  742. X.IP \(bu 0.2i
  743. XThe \fIobject key\fR that uniquely identifies a software object.
  744. XThe structure of this type is different in the two different
  745. Ximplementations. Consequently, application programs should handle
  746. Xthis type as opaque type and should not access single fields
  747. X(unfortunately this is a little bit clumsy in C \- an implementation
  748. Xas C++ class would be more appropriate).
  749. X.IP \(bu
  750. X\fISet descriptors\fR represent a set of object keys.
  751. XA set descriptor contains information about the number of keys
  752. Xin the set and a pointer to a list of object keys.
  753. X.IP \(bu
  754. XAn \fIAttribute buffer\fR which is capable to hold all attributes of a
  755. Xsoftware object (standard attributes and user defined attributes).
  756. XAttribute buffers have two different purposes.
  757. XFirst, they can hold a retrieve pattern, i.e. they
  758. Xmay be (partially) filled with \fIdesired\fR attribute
  759. Xvalues and then be passed as argument to a retrieve operation.
  760. XSecond, an attribute buffer is used to return all attributes of
  761. Xan identified ASO on demand.
  762. X.RE
  763. X.LP
  764. XThe names of all operations of the \*(Af are preceded by \fIaf_\fR
  765. X(e.g. \fIaf_saverev\fR).
  766. XIn the following sections, the most important (most interesting)
  767. Xfunctions of \*(Af are described.
  768. X.NH 3
  769. XRetrieval
  770. X.LP
  771. X\*(Af provides two different retrieval operations, \fIaf_find\fR and
  772. X\fIaf_bpfind\fR. The first does retrieval of source objects and
  773. Xthe second of derived objects.
  774. XBoth have to be parameterized with an attribute buffer containing
  775. Xa retrieve pattern and both return a set holding the keys of all
  776. XASOs matching the specified attribute pattern.
  777. X.LP
  778. XDue to the possibility to uniquely identify source objects by the
  779. Xattributes \fIhostname, syspath, name, type, generation, revision\fR
  780. Xand \fIvariant\fR, there is a shortcut (faster) operation to get the
  781. Xkey of well known object by specifying values for these seven
  782. Xattributes. The name of the function is \fIaf_getkey\fR and it returns
  783. Xan object key if the sought software object exists.
  784. X.NH 3
  785. XSets
  786. X.LP
  787. X\*(Af contains a considerable number of operations on sets.
  788. XAlthough a set contains \fIobject keys\fR and not complete
  789. Xobjects, we speak of \(lqobjects in a set\(rq throughout this
  790. Xchapter for reasons of simplicity.
  791. X.LP
  792. X\fIAf_sortset\fR sorts the objects in a set in respect to the
  793. Xvalue of a single or compound attribute.
  794. XFor example, objects can be ordered alphabetically by their
  795. Xname attribute which is a single attribute.
  796. XA typical compound attribute is the \fIversion number\fR
  797. Xconsisting of generation number and revision number
  798. X(generation.revision).
  799. XBesides standard attributes one can pass any name of a user defined
  800. Xattribute as argument to \fIaf_sortset\fR.
  801. XThis works, even if the attribute is not defined for every
  802. Xobject in the set.
  803. X.LP
  804. XThe call \fIaf_subset\fR performs a recursive retrieve operation on
  805. Xan existing set. \fIAf_subset\fR is (like \fIaf_find\fR)
  806. Xparameterized with an attribute buffer containing a retrieve pattern.
  807. XIt results in a subset of the original set.
  808. X.LP
  809. XOther set commands provide
  810. Xadding and deleting single objects to/from sets as well as
  811. Xbuilding intersections, unions and differences of two existing sets.
  812. X.NH 3
  813. XReading and Manipulating Attributes
  814. X.LP
  815. XThe manipulation of standard attributes for software objects
  816. Xis under strict control of \*(Af.
  817. XMany standard attributes can only be modified implicitly
  818. Xby performing a \*(Af operation.
  819. XThe other standard attributes can only be manipulated in
  820. Xa well defined manner.
  821. X.LP
  822. XThe attributes \fIhostname, system path, name\fR and \fItype\fR
  823. Xare immutable for saved objects (source or derived).
  824. XThey are set once (at saving time) as inherited from the filesystem 
  825. Xlocation of the file the object evolved from.
  826. XAs busy objects are regular
  827. X.UX
  828. Xfiles, they can be renamed by linking them to another place in
  829. Xthe filesystem.
  830. X.LP
  831. XVersion number and the version state are only relevant
  832. Xfor source objects. 
  833. XA source object is automatically assigned a version number and state
  834. X\fIsaved\fR when it is
  835. Xgenerated. The version number can subsequently only be increased
  836. X(set to a logically bigger number, e.g. from 1.2 to 1.4 or from
  837. X2.3 to 3.0).
  838. XThe version state can be set to the logically following or
  839. Xpreceding (see states list in 2.4) state but it can never be
  840. Xreset to \fIbusy\fR. 
  841. XBusy objects have no version number
  842. Xand are always in state \fIbusy\fR.
  843. XVersion number and state
  844. Xof derived objects can be set arbitrarily (but \*(Af does not
  845. Xcare about their values).
  846. X.LP
  847. XThe management of user defined attributes is entirely controlled by
  848. Xthe application program.
  849. XAn application program called by the owner
  850. Xor the author of an ASO can arbitrarily add, delete and modify
  851. Xthese attributes.
  852. X\*(Af supports the management of user defined attributes
  853. Xby storing them as name/value(s) pairs.
  854. XA name (string) is associated with any number (zero to infinite)
  855. Xof values (strings).
  856. XThe function \fIaf_sudattr\fR allows the addition and deletion
  857. Xof whole attribute entries and single values.
  858. X.NH 3
  859. XLocking
  860. X.LP
  861. XThe locking mechanism for reserving update rights in a line
  862. Xof development is reflected by the functions \fIaf_lock, af_unlock\fR
  863. Xand \fIaf_testlock\fR.
  864. XCalling the function \fIaf_lock\fR, causes the identified ASO
  865. Xto be locked by the caller, provided the object was available
  866. Xfor locking.
  867. X.LP
  868. X\fIAf_testlock\fR returns the user ID of the lock holder (if present). 
  869. XLocks can either be released by the lock holder of the design
  870. Xobject or be broken by the owner by means of \fIaf_unlock\fR.
  871. X.NH 3
  872. XVersion Control
  873. X.LP
  874. XThe version control system has been described in detail earlier in this paper.
  875. XThe most important operations are \fIaf_saverev\fR and \fIaf_savebinary\fR
  876. Xwhich create a copy of the given, busy, ASO and store it as
  877. Xnew source resp. derived version.
  878. X.LP
  879. X\fIAf_newgen\fR increases the generation number in a line of development.
  880. XIt creates a pseudo revision which is identical to the last saved revision
  881. Xand attaches a new version number to it.
  882. XThe generated pseudo revision has the character of an alias (see also
  883. Xfigure 2.5).
  884. XThe new version number is generated by increasing the generation number by 1
  885. Xand resetting the revision number to 0 (e.g. 1.4 becomes 2.0).
  886. X.LP
  887. XIf the busy object of a line of development was replaced by another file,
  888. Xfor example an older version or a variant,
  889. X\fIaf_setbusy\fR should be called with the key of the
  890. Xold busy object and that of the new one, to inform \*(Af about the change.
  891. XThis is necessary to keep track of the physical derivation structure of
  892. Xa line of development which is substantially for an efficient delta
  893. Xtechnique.
  894. X.NH 3
  895. XFilesystem Primitives
  896. X.LP
  897. X\fIAf_open\fR and \fIaf_close\fR are
  898. Xfilesystem primitives analogous to the
  899. X.UX
  900. Xcalls \fIfopen\fR and \fIfclose\fR.
  901. XThe only difference is, that \fIaf_open\fR takes an object key instead
  902. Xof a pathname as input parameter.
  903. X\fIAf_open\fR returns a pointer to a \fIFILE\fR structure, so that
  904. Xthe application program can use the whole
  905. X.UX
  906. Xstdio interface on ASOs.
  907. X.LP
  908. XAdditionally, ASOs can be created and removed (unlinked).
  909. XDerived files residing in a binary pool can be restored
  910. Xat their former position with \fIaf_restore\fR.
  911. X.LP
  912. XThe interface is completed by a number of miscellaneous
  913. Xroutines.
  914. XThese are routines for error reporting and cleaning up
  915. X(removing tmp files and freeing memory) as well as functions
  916. Xfor splitting up
  917. X.UX
  918. Xpathnames in the \*(Af attributes syspath, name and type.
  919. X.NH 2
  920. X\*(Af on top of the
  921. X.UX
  922. Xfilesystem
  923. X.LP
  924. XThe first implementation of \*(Af was done on top of the
  925. X.UX
  926. Xfilesystem.
  927. XThis implementation is ready and in use.
  928. X.LP
  929. XSaved ASOs are stored in archive files (like SCCS and RCS). \*(Af
  930. Xmaintains two archive files for each line of development of source
  931. Xobjects \- one holding the attributes and the other holding the data.
  932. X\*(Af stores its archives in a subdirectory called \*(Af. If the
  933. Xarchives shall be stored elsewhere but not in a subdirectory, an \*(Af
  934. Xapplication can set an \fIarchive path\fR to specify the name of a
  935. Xdirectory where all subsequently accessed or created archives are
  936. Xstored. In this case, the application program
  937. Xis responsible for maintaining the relative\-path relationship
  938. Xbetween a busy object and the corresponding archive.
  939. X.LP
  940. XTo save disk space,
  941. XSuccessive versions in a line of development are stored as deltas
  942. X(differences to the previous version).
  943. XFor generating file deltas a new delta technique,
  944. Xdescribed in [7]
  945. Xis employed.
  946. XDeltas computed by this method are about 30 percent smaller than deltas
  947. Xgenerated by \fIdiff\fR (the standard
  948. X.UX
  949. Xfile comparison tool).
  950. XThis delta technique uses characters rather than lines as atomic symbols.
  951. X.LP
  952. XWe use a backward delta technique (like RCS),
  953. Xi.e. only the most recent version of each line of development is
  954. Xstored completely.
  955. XOlder versions can be reconstructed by successively applying
  956. Xall deltas from the most recent to the desired version.
  957. XIn the filesystem implementation, deltas between parallel lines of
  958. Xdevelopment are not supported (conceptually, they should be there).
  959. XThis is because different lines of development are stored in
  960. Xdifferent archive files and we consider it too risky
  961. Xto spread delta chains across different
  962. X.UX
  963. Xfiles.
  964. XIf the coherence of the two files gets lost (this may happen by simply
  965. Xmoving one file) and the chain gets broken, some revisions may
  966. Xnot be reproducible any more.
  967. X.LP
  968. XDerived files are stored physically unchanged.
  969. XTests with our delta technique showed, that it makes not much
  970. Xsense to build deltas between binary files.
  971. XOn calling \fIaf_savebinary\fR, the identified file is linked into the
  972. X\*(Af subdirectory.
  973. XAdditionally, the attribute buffer containing all the attributes
  974. Xfor the derived file is stored in a \fIndbm\fR Database.
  975. X.LP
  976. XIf a saved source object shall be opened,
  977. Xit is reconstructed and stored in a temporary file.
  978. XDue to the unalterability of saved ASOs, the temporary file is simply
  979. Xremoved on closing (changes have no effect on the stored ASO).
  980. XIf one really wants to reconstruct a file, one has to create a
  981. Xbusy object, read the data from the tmp file and write it to the
  982. Xcreated busy object.
  983. X.NH 2
  984. X\*(Af on top of \*(Da
  985. X.LP
  986. XThe \*(Af implementation on top of \*(Da, is currently
  987. Xunder development.
  988. XIn this implementation, saved revisions and binary pools are stored
  989. Xin the database.
  990. X.LP
  991. XIn the current implementation, the database is only used for storing the
  992. Xinternal data (archives and binary pools) of \*(Af.
  993. XBusy objects and temporary files (containing the data of reconstructed
  994. Xolder versions) are still stored in the
  995. X.UX
  996. Xfilesystem.
  997. X\*(Af applications have no direct access to the database.
  998. XSimilar to the filesystem implementation, the contents of an ASO
  999. Xhas the form of a byte stream.
  1000. XUp till now, there is no substantial difference of this impementation
  1001. Xto the filesystem implementation except that it will be slower.
  1002. X.LP
  1003. XThe actual enhancement of \*(Af on \*(Da will be the possibility for
  1004. Xapplications to use the structuring facilities of the database
  1005. Xfor their internal data (the content data of ASOs).
  1006. XBut how shall a specific ASO be created, copied, or opened, and how
  1007. Xshould a delta between two versions be constructed ?
  1008. XQuestions that can only be answered when the contents structure of the
  1009. Xcorresponding ASO is known.
  1010. XThis problem can only be solved satisfactorily by following an
  1011. Xobject oriented approach.
  1012. XAn \*(Af implementation taking this approach will provide a mechanism
  1013. Xfor the definition of ASO classes, defining specific attributes
  1014. Xand virtual operations (e.g. compute delta, open, linearize)
  1015. Xon instances of these classes.
  1016. X.LP
  1017. XAnother very practical problem is extensibility. In the current
  1018. Xstate, a \*(Da database has \fIone\fR schema where all database
  1019. Xobject types have to be defined.
  1020. XAddition of a new application with the necessity of schema
  1021. Xupdates requires the generation of an entire new database and the
  1022. X(troublesome)
  1023. Xtransfer of all the data from the old database to the new one.
  1024. X.NH 1
  1025. XThe future of \*(Af
  1026. X.LP
  1027. XWhen we made the first design of \*(Af,
  1028. Xaimed primarily at facilitating the implementation of the
  1029. X\*(sh\-toolkit,
  1030. Xwe were not aware of the power of this approach.
  1031. XEspecially the mechanism of user defined attributes
  1032. Xinspired us to think of applications that go far beyond
  1033. Xthe tasks \*(Af was originally designed for.
  1034. X.LP
  1035. XHowever, it is still a problem to make consistent use of user
  1036. Xdefined attributes. Each application has to set them explicitly.
  1037. XThe exchange of information via user defined attributes
  1038. Xhas to be subject of special agreements and naming conventions.
  1039. XA good improvement will be the introduction of some kind of
  1040. XASO definition language.
  1041. XThis would be the input for a general class manager
  1042. Xthat manages the storage of objects of well defined object classes.
  1043. XThe definition of an object class contains a specification
  1044. Xof all attributes attached to an object of this class.
  1045. XThe object classes will be part of a
  1046. Xclass hierarchy with attribute inheritance.
  1047. XThis makes
  1048. X\*(Af a basis for object\-oriented software engineering applications
  1049. Xthat deal with software objects.
  1050. XThese are able to store
  1051. Xtheir objects persistently, identify them (uniquely) and share them
  1052. Xwith other applications.
  1053. X.LP
  1054. XSubsequently we want to give an idea,
  1055. Xhow a possible class hierarchy might look like.
  1056. XExamples for classes are \fIsoftware object\fR, 
  1057. X\fIsource object\fR, \fIderived object\fR or \fIrevisible object\fR.
  1058. XThe class \fIsoftware object\fR is the basic class.
  1059. XAll other classes are derived classes inheriting the attributes
  1060. Xof \fIsoftware object\fR.
  1061. X\fISource objects\fR and \fIderived objects\fR
  1062. Xare direct subclasses of \fIsoftware object\fR.
  1063. X\fIRevisible source object\fR would be a subclass of
  1064. X\fIsource objects\fR  with the additional attributes 
  1065. X\fIgeneration number, revision number\fR and \fIversion state\fR.
  1066. XAn example for defining a class hierarchy
  1067. Xfor an object oriented database can be found in [11].
  1068. X.LP
  1069. XAnother important topic is support for \*(Af
  1070. Xapplications distributed over a local area network.
  1071. XTo support this, we need \fIpersistent keys\fR.
  1072. XUnlike the current realization of object keys which are
  1073. Xonly valid during the lifetime of the application process,
  1074. Xpersistent keys are interchangeable between processes
  1075. Xand machines.
  1076. X.NH 1
  1077. XConclusion
  1078. X.LP
  1079. XProperly speaking, \*(Af was invented by accident.
  1080. XWe needed a basic data storage system capable to hold the
  1081. Xsoftware objects we deal with, plus some information about them
  1082. Xfor use by our software configuration management toolkit.
  1083. XAfter having made about 200 attempts\(dg
  1084. X.FS
  1085. X\(dg Actually we made only four or five, but 200 sounds better
  1086. X.FE
  1087. Xto finally fix the set of attributes necessary to hold
  1088. Xsufficient information about
  1089. Xsoftware objects, we gave up and invented the user
  1090. Xdefined attributes instead.
  1091. XOne important inspiration for user defined attributes was the
  1092. Xenvironment concept known from the
  1093. X.UX
  1094. Xshell.
  1095. XOnce available, the environment is extended by some new variable
  1096. Xalmost each time a new tool is added to the system.
  1097. X.LP
  1098. XSo we defined \*(Af as an internal interface.
  1099. XWhile writing our first \*(Af applications, we got aware of
  1100. Xthe power and the insufficiencies of the mechanism of
  1101. Xapplication defined attributes.
  1102. XWe believe that many applications might benefit from this concept,
  1103. Xand that it is too valuable to be just an internal interface.
  1104. XFurther development of \*(Af will primarily go into the direction
  1105. Xdescribed in the previous chapter.
  1106. XWe are curious, where this way will lead us to.
  1107. X.NH 1
  1108. XAcknowledgement
  1109. X.PP
  1110. XThis work is part of the \*(Un project. The project is supported by the
  1111. XBundesministerium f\*:ur Forschung und Technologie 
  1112. X(Federal Ministry for Research and Technology) under grant ITS 8308.
  1113. X.KS
  1114. X.]<
  1115. X.\"Dittrich.K-1986-1
  1116. X.ds [F 1
  1117. X.]-
  1118. X.ds [A Klaus Dittrich
  1119. X.as [A ", Willi Gotthard
  1120. X.as [A ", and Peter C. Lockemann
  1121. X.ds [T DAMOKLES. A Database System for Software Engineering Environments
  1122. X.ds [J International Workshop on Advanced Programming Environments
  1123. X.ds [P 351-371
  1124. X.nr [P 1
  1125. X.ds [I IFIP WG2.4
  1126. X.ds [I Springer Verlag
  1127. X.ds [C Trondheim, Norway
  1128. X.ds [D June 1986
  1129. X.nr [T 0
  1130. X.nr [A 0
  1131. X.nr [O 0
  1132. X.][ 1 journal-article
  1133. X.\"Feldman.S.I.-1979-2
  1134. X.ds [F 2
  1135. X.]-
  1136. X.ds [A Stuart I. Feldman
  1137. X.ds [T MAKE - A Program for Maintaining Computer Programs
  1138. X.ds [J Software - Practice and Experience
  1139. X.ds [V 9,3
  1140. X.ds [P 255-265
  1141. X.nr [P 1
  1142. X.ds [D March 1979
  1143. X.nr [T 0
  1144. X.nr [A 0
  1145. X.nr [O 0
  1146. X.][ 1 journal-article
  1147. X.\"Leblang.D.B.-1985-3
  1148. X.ds [F 3
  1149. X.]-
  1150. X.ds [A David B. Leblang
  1151. X.as [A " and Gordon D. McLean, Jr.
  1152. X.ds [T Configuration Management for Large-Scale Software Development Efforts
  1153. X.ds [P 122-127
  1154. X.nr [P 1
  1155. X.ds [I GTE Laboratories
  1156. X.ds [J Workshop on Software Engineering Environments for 
  1157. X.as [J " Programming-in-the-Large
  1158. X.ds [C Harwichport, Massachusets
  1159. X.ds [D June 1985
  1160. X.nr [T 0
  1161. X.nr [A 1
  1162. X.nr [O 0
  1163. X.][ 1 journal-article
  1164. X.\"Mahler.A-1988-4
  1165. X.ds [F 4
  1166. X.]-
  1167. X.ds [A Axel Mahler
  1168. X.as [A " and Andreas Lampen
  1169. X.ds [T shape \- A Software Configuration Management Tool
  1170. X.ds [J Proceedings of the International Workshop on Software Version and Configuration Control
  1171. X.ds [I German Chapter of the ACM
  1172. X.ds [I B.G. Teubner
  1173. X.ds [P 228-243
  1174. X.nr [P 1
  1175. X.ds [C Grassau, West-Germany
  1176. X.ds [D January 1988
  1177. X.nr [T 0
  1178. X.nr [A 0
  1179. X.nr [O 0
  1180. X.][ 1 journal-article
  1181. X.\"Mahler.A-1988-5
  1182. X.ds [F 5
  1183. X.]-
  1184. X.ds [A Axel Mahler
  1185. X.as [A " and Andreas Lampen
  1186. X.ds [T A Toolkit for Software Configuration Management
  1187. X.ds [J Proceedings of the Spring 1988 EUUG Conference
  1188. X.ds [I European Unix systems User Group
  1189. X.ds [P 185-202
  1190. X.nr [P 1
  1191. X.ds [C London, UK
  1192. X.ds [D April 1988
  1193. X.nr [T 0
  1194. X.nr [A 0
  1195. X.nr [O 0
  1196. X.][ 1 journal-article
  1197. X.\"Nestor.J.R.-1986-6
  1198. X.ds [F 6
  1199. X.]-
  1200. X.ds [A John R. Nestor
  1201. X.ds [T Toward a Persistent Object Base
  1202. X.ds [J International Workshop on Advanced Programming Environments
  1203. X.ds [J Lecture Notes in Computer Science
  1204. X.ds [C Trondheim, Norway
  1205. X.ds [P 372-394
  1206. X.nr [P 1
  1207. X.ds [I Springer Verlag
  1208. X.ds [D June 1986
  1209. X.nr [T 0
  1210. X.nr [A 0
  1211. X.nr [O 0
  1212. X.][ 1 journal-article
  1213. X.\"Obst.W-1987-7
  1214. X.ds [F 7
  1215. X.]-
  1216. X.ds [A Wolfgang Obst
  1217. X.ds [T Delta Technique and String-to-String Correction
  1218. X.ds [J Proceedings of the 1st European Software Engineering Conference
  1219. X.ds [J Lecture Notes in Computer Science
  1220. X.ds [P 69-73
  1221. X.nr [P 1
  1222. X.ds [I Springer Verlag
  1223. X.ds [C Berlin
  1224. X.ds [D September 1987
  1225. X.nr [T 0
  1226. X.nr [A 0
  1227. X.nr [O 0
  1228. X.][ 1 journal-article
  1229. X.\"Rochkind.M.J.-1975-8
  1230. X.ds [F 8
  1231. X.]-
  1232. X.ds [A Marc J. Rochkind
  1233. X.ds [T The Source Code Control System
  1234. X.ds [J IEEE Transactions on Software Engineering
  1235. X.ds [V SE-1
  1236. X.ds [P 364-370
  1237. X.nr [P 1
  1238. X.ds [D 1975
  1239. X.nr [T 0
  1240. X.nr [A 0
  1241. X.nr [O 0
  1242. X.][ 1 journal-article
  1243. X.\"Tichy.W.F.-1985-9
  1244. X.ds [F 9
  1245. X.]-
  1246. X.ds [A Walter F. Tichy
  1247. X.ds [T RCS - A System for Version Control
  1248. X.ds [J Software - Practice and Experience
  1249. X.ds [V 15,7
  1250. X.ds [P 637-654
  1251. X.nr [P 1
  1252. X.ds [D July 1985
  1253. X.nr [T 0
  1254. X.nr [A 0
  1255. X.nr [O 0
  1256. X.][ 1 journal-article
  1257. X.\"Tichy.W.F.-1988-10
  1258. X.ds [F 10
  1259. X.]-
  1260. X.ds [A Walter F. Tichy
  1261. X.ds [T Tools for Software Configuration Management
  1262. X.ds [J Proceedings of the International Workshop on Software Version and Configuration Control
  1263. X.ds [P 1-20
  1264. X.nr [P 1
  1265. X.ds [I B.G. Teubner
  1266. X.ds [I German Chapter of the ACM
  1267. X.ds [C Grassau, FRG
  1268. X.ds [D January 1988
  1269. X.nr [T 0
  1270. X.nr [A 0
  1271. X.nr [O 0
  1272. X.][ 1 journal-article
  1273. X.\"Zdonik.S.B.-1986-11
  1274. X.ds [F 11
  1275. X.]-
  1276. X.ds [A Stanley B. Zdonik
  1277. X.ds [T Version Management in an Object-Oriented Database
  1278. X.ds [J Lecture Notes in Computer Science
  1279. X.ds [J International Workshop on Advanced Programming Environments
  1280. X.ds [C Trondheim, Norway
  1281. X.ds [P 405-422
  1282. X.nr [P 1
  1283. X.ds [I Springer Verlag
  1284. X.ds [D June 1986
  1285. X.nr [T 0
  1286. X.nr [A 0
  1287. X.nr [O 0
  1288. X.][ 1 journal-article
  1289. X.]>
  1290. X.KE
  1291. END_OF_FILE
  1292. if test 46807 -ne `wc -c <'papers/lisbon.ms'`; then
  1293.     echo shar: \"'papers/lisbon.ms'\" unpacked with wrong size!
  1294. fi
  1295. # end of 'papers/lisbon.ms'
  1296. fi
  1297. echo shar: End of archive 30 \(of 33\).
  1298. cp /dev/null ark30isdone
  1299. MISSING=""
  1300. for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 ; do
  1301.     if test ! -f ark${I}isdone ; then
  1302.     MISSING="${MISSING} ${I}"
  1303.     fi
  1304. done
  1305. if test "${MISSING}" = "" ; then
  1306.     echo You have unpacked all 33 archives.
  1307.     rm -f ark[1-9]isdone ark[1-9][0-9]isdone
  1308. else
  1309.     echo You still need to unpack the following archives:
  1310.     echo "        " ${MISSING}
  1311. fi
  1312. ##  End of shell archive.
  1313. exit 0
  1314.