A data model for software engineering databases is presented. On the basis of an entity-relationship-approach, the model provides special features for complex objects, consistency, vague or incomplete information, variants, and versions. A prototype of a database system based on this model is being implemented.Das Modell einer Datenbank für Anwendungen in der Softwaretechnik wird vorgestellt. Es basiert auf einem Entity-Relationship-Ansatz, enthält aber zusätzliche Modellierungsmittel für komplexe Objekte, Konsistenzsicherung, vage bzw. unvollständige Informationen, Versionen- und Variantenverwaltung. Ein Prototyp eines Datenbanksystems, welches mit diesem Modell arbeitet, wlrd implementiert

Glinz, Martin

Huser, Hansjörg

Ludewig, Jochen

OPUS Online Publikationen der Universität Stuttgart

SEED· A DATABASE SYSTEM FOR SOFTWARE ENGINEERING ENVIRONMENTS Martin Gllnz Hansj6rg Huser Jochen Ludewig ABSTRACT 8rown Boverl Research Center CH-540S Baden, Switzerland A data model for software engineering databases Is presented . On the basis of an entity-relationship-approach, the model provides special features for complex ob-jects, consistency, vague or Incomplete Infol"'111ation, val"iants, and versions. A pl"'Ototype of II database system based on this model Is being Implemented. ZUSAMMENFASSSUNG 081 Modell elne,. aalenb"nk fOr Anwendungen In der Softwaretechnlk wird verge-stellt. Es baslert auf .1nem Enuty-Relationshlp-AnsaU, enth»lt aber zusaUliche Modeilierungsmitte' fUr komplex. Oblekt., Konslslenzsleheruno, vag. bzw. unvoll-stlndlg. Informatlonen, Verslonen- und V"rlantenverwaltung . Eln Prototyp elnes Oatenbanksystems, welches mit dlesem Modell arbeltet, wlrd Implementiel"t. INTRODUCTION Every Software Engineering Environment needs a database as a central repository of InfonnatIon (Osterwell, 1981). The requirements for such a software engineering database differ significantly from the capabilities of commercially available database management systems, Including relational systems (Stennlng, 1983 Ind Dittrich et a!. 1984) . The most important requirements are: (1) storing complex objects (hierarchically structured, undetennlned size) and re-lationships between these objects together with their semantics (2) storing Incomplete or vague Infonnation (3) ensuring database consistency ~lInd supporting long transactions (4) acceSSing the database in a manner similar to abstract data types (5) managing versions and variants. Thul we must either bridge the gap between these requirements and the capabUl-ties of an available database system, or we must implement a new system that meets our requirements. In any case, we must express our needs by defining a conceptual schema and database operations on a high semantic level. However, the avaHable database models offer poor or even no concepts to model a schema and operations In a way thAt requirements (2) • (5) are met. Therefore we define a new database model that Is tAilored to software engineering appllcatlons. (For de-ulls see Gllnz and Ludewig, 1984. ) In an Implementation, this model may either be mapped onto an existing database system or be Implemented directly . For our proto" 122 type Implementation, we have chosen a direct, st .... Ightforward Implementation bV means of linked lists. The bas. abstract machine (see below) of the prototype Is operational since November , 1984 . THE SEED DATA MODEL Our SEEO (Software Engineering Environment Database) a Model Is based on an entity"relatlonshlp approach (Chen, 1976) . Instead of entities and attributes, we use the more general concept of hierarchically structured obJects . The latter allows for representation of entitles with att,.ibutes, hierarchical decomposition, arld hler-archlc.1 ordering. We Include semantics by: (1) a naming concept for objects that resembles Pascal record structures , (2) specifying the roles of the objects In relationships, and (3) defining cardinalities for all schema structures that classify relationships and de· pendent obJects . Any element In the database schema may have attached procedures that are exe· cuted when a data Item belonging to that schema element Is processed . This allows for an easy definition of dynamic consistency rules and short transactions . So we meet requirement (1). In object hierarchies, only the top object must be defined. Thus we can store incomplete Intormatlon . W. use generalization (Smith and Smith, 1977) of oblect classes and of associations (relationship classes) to create categories In the schema that allow to store vague Information . So we are lible to define and refine Infor· matlon on Objects and relationships Incrementally (requirement Z). From Intormation In the schema we derive conSistency rules that always must hold. and completeness rules that are checked on demand only . So we can .nsu,.. con· s lstency by automatic checks without excluding Incomplete and vague data from the database. Long tranSllctions (design steps lasting from minutes to hours) a,.e pro· tected by a write-lockout mechanism (requirement 3) . Access to the database Is provided through Ii set of iIIbstl'"act machines only . The procedures of the lowest level check all consistency rules derivable from the data · base schema , thus ensuring consistency . As any procedure In a higher abstract machine makes use ot procedures In lower ones, consistency Is guaranteed for IMy database access. So the database may be viewed as a set of abltract data types (requirements 4 and ,Iso 3). Our pattern concept (s .. next chapter) yields an elegant solution to the problem of managing variants. Furthermore, we support a history ot versions for objects and relationshIps by providing database operations that attach version tags to data, and reconstruct or delete versions on demand (requirement 5) . 123 Figure 1 shows a graphic representation of a SEED~schema . CARDINAL NumberOfWrites 1 .. 1 OutputData to '-____ ..JO .. . from InputData 0' '--------' .. Data at 1 . . • ':-;.----,..-', 1 .. 1 0 .. 64 Purpose ArrayBounds STRING Figure 1: Sample SEED Schema Description DATE STRING Modify : Illegal AfterModify ; Revise(Action . Revised,Date) Explanation : 'Oata' Is a hierarchically structured object class with classes 'Data. Pur pose' and ·Oata . ArrayBounds' as subclasses . The latter has again two sub-classes . 'Data . ArrayBounds . Lower' and 'Data . ArrayBounds . Upper'. Class 'Data. PUr"pose' may have objects of type STRING as instances . 'Data . ArrayBounds' has the cardinality O . • 64, specifying that any object of class 'Data' may have from zero up to 64 objects of class 'Oata . ArrayBounds'. Classes 'Data' and 'Action' are related by an association 'Access' with cardinalities 1 .. * and O .. *. '1 .. *1 means that any Instance of 'Data' should have at least one 'Access'-link with an Instance of 'Action ' , ther e is no upper bound for the number of such links . The ~ 'at' and 'by' ex.press that accesses take place at instances of 'Data' ~ instances of 'Action' . The association 'Contalned' imposes a tree structure on the objects that are in-stances of 'AcUon' by me,ns of thl!' attribute ACYCLIC and the cardinality 0 •• 1 for the role 'in' . 124 We. may define an object of class 'Data' by giving Its name only, •. g. 111'mlS', omitting any subobJec:t (Instance of subcll5s) definition. Such objects may b, added later, when more Is known about 'alarms', However, the cardinality 1 .. 1 of class 'Data. Purpose' Slys that we mUlt eventually supply " string giving the pur .. pose of alarms, I.e. we can formally detect Incompleteness . Class 'Oata' Is specialized to classes 'InputOata' and 'OutputOata' . Association 'Access' has speclillllz.tJons 'Read' and 'Wr-lte', or conversely : associations 'Read' and 'Wrlte' are generalized to 'Access'. This allows to store II vague 'nformatlon like NThe object 'a'lrms' Is I data object which Is accessed by the action 'sensor' II IS well as a precise Information like Nillarms' Is an output written twice by 'sen$Or't and writing Is repelted In case of error". More generally speaking, any Instance of 'OutputDlta' may hive the general en" vlronment described by class 'Data' (I.e . subobJects of cluse' 'Oau . Purpose' and 'Dau.ArrayBounds') plus the special environment described by 'OutputData' (I . e. a subobject of class 'OutputD.t •. NumberOfWrJtes' and relationships of kind 'Write') . Suppos., an object 'Sensor. Description' of elus 'Aetion.Desc,.lptlon' Is to be added to the database. p,.lor to the updlte execution , the following conSistency rules a,.. derived from the schema : (1) There must exist an action with name 'Sensa,.' I (2) the,.. must not already .xlst an object 'Sensor . Oese,.lptlon' (because the max c.,.. dlnility is 1), (3) the value of the object must be of type STRING, (4) atter the update, the procedure Revlse(Action . Revlsed,Dlte) must be execut~. The litter procedure may contain code generating the actual date .s .n object of cI.ss 'Action. Revised' , So every update of an Ictlon desc,.lptlon automatically updates the revision date, too. On the other hand, procedure IllIegl" attached to 'Action. Revised' prohibits any direct update of objects of this ellIS, Thus, pr-ocedures attached to elements In the schema provide additional semlntlcs that are checked when updates are made . PATTERNS - A POWERFUL NEW CONCEPT We cln ma,.k any data In the database to be a pattern. Such patte,.ns are invisible to any I"'etrieval operation and are not checked fa,. consistency unless they ar. Inherited by a 'nonnal' d.ta Item. The semantics of patterns and the Inherit opera .. tlon Is as follows: all retrieval op.,.atlons view patterns as macros , and l"he,.lt .. ope,.atlons as macro expansions, Howeve,., Instead of .. real e)Cpanslon we establish a special lnherlts"re'atlonshlp betwHn a pattern and .ny of Its Inheritors . Thus p.ttern information cannot be updated In the environment of the Inheritors, but only In the pattern Itself . Conversely, any update of .. pattern automatically prop" .gates to all Inheritors of that pattern . 125 These semantics a,.. extremely us.ful for managing variants : A family of variants, consIsting of • set of oblects and links that Is dIvided into a fixed and several variant parts (one for .ach va,.lant) can be modelled .s follows: Fixed and variant parts are described by normal Items. The connections between the fixed and the variant parts are establ1shed by patterns such that all varIants inherit the same links to the fixed part. In fig . 2, the fixed part, consisting of objects A and B Is connected to a pattern object PO by pattern links PLl and PL2, respectively. Both variants inherit this plttern. Thus, they both have (lnh.,.ited) Itnks to objects A and 8, I.e. they have the fixed part In common. The,.e are several other applications fOr patterns, e.g. for templates, user defined constraints, cr- standardized data environments . A PL1 PLZ B fixed par-t PO / ....... variant parts R l var-Iant 1 variant 2 C::> object dependent object -<>- link . ... . - inherits-relationship Figure 2: Defining variants by means of patterns CONCLUSIONS AND PLANS We have defined a dlta model that makes conceptual modelling for- software engineering easy .s It p.-ovldes features to handle complex str-uctures, vague and Incomplete Informltion, consistency, v.dants, and ver-sions that are vitally needed In this field. The realization of the new f •• tures leeds to powerful extensIons of the entity"r-elltlonshlp Ippr-oach. W. are ncw Investigating the problem of varl.nt/ver-slon m.n.gement and the opera-tlcn.1 Ispects of the database more in detail. By 1985, we plan to incorporate the database Into a prototype software engineering environment to show the feasibility and usefulness of our- Ideas In practice. '26 REFERENCES Chen, P . P . (1916) . The entity-relationship model" toward a unified view of data . ACM Transact. Database Syst . , 1, 1 (March 1976). 9-36. Dittrich, K.R" A . M. Katz, J.A. Mulle, P. C. LockermJlnn (1984). Datenbankkonzepte fUr Ingenleuranwendungen: elne Uebersicht abe" den Stand der Entwlcklung . 14 . Jahrestagung der GI, Braunschweig 1984. Glinz, M. and J . Ludewig (1984) . SEeD· Das Oatenbanksystem fa,. die Software-Entwicklungsumgebung SEEME. Brown Boverl Research Center, Research Report No. KLR 84-143 C. Oster-weil, L. (1981) . Software environment r.search : directions for the next five years . IEEE Computer 14,4 . 35-43. Smith, J . M. , and O. C . P . Smith (1977). Databas. abstractions : aggregation and generalization . ACM Transact. Database Syst . , g, 2 (June 19TI). 105-133 . Stenning, V. (ed . ) (1983) . Requirements for softwant engineering databases . Imperial Softwa,.e Technology Ltd . , London . 

SEED - a database system for software engineering environments

http://elib.uni-stuttgart.de/bitstream/11682/8266/1/lud29.pdf

SEED - a database system for software engineering environments

Abstract

Similar works

Full text

Available Versions

OPUS Online Publikationen der Universität Stuttgart