General Object-Oriented Database for Software
Total Page:16
File Type:pdf, Size:1020Kb
The GOODSTEP Pro ject: General Ob ject-Oriented Database for Software Engineering Pro cesses The GOODSTEP Team Abstract 1 Ob jective of GOODSTEP The goal of the GOODSTEP project is The goal of the GOODSTEP pro ject is to enhance and improve the functionality of to develop a sophisticated database system a ful ly object-oriented database management dedicated to the supp ort of software develop- system to yield a platform suited for appli- mentenvironments SDEs and make the ba- cations such as Software Development En- sis for a platform for SDE construction with a software pro cess to olset and generators for vironments SDEs. The baseline of the graphical and textual integrated to ols imple- project is the O database management sys- 2 mented on top of it. tem DBMS. The O DBMS already in- 2 The GOODSTEP pro ject started Septem- cludes many of the features required by SDEs. b er 1992 and will last for three years. This The project has identifed enhancements to pap er mainly rep orts on the rst year of work O in order to make it a real software en- 2 within the pro ject. gineering database management system. The baseline of the pro ject is an exist- These enhancements are essential ly upgrades ing Europ ean commercially available ob ject- of the existing O functionality, and hence 2 oriented database pro duct: O [4]. Rather requirerelatively easy extensions to the O 2 2 than developing a new database manage- system. They have been developedinthe ment system from scratch, GOODSTEP will early stages of the project and are now ex- enhance and improve this pro duct. ploited and validated by a number of software Besides the enhancements and improve- engineering tools built on top of the enhanced ments of O which make it an admirably O database system. Toease tool construc- 2 2 suited system for SDEs, the pro ject pro- tion, the GOODSTEP platform encompasses vides a numb er of test cases and p erforms tool generation capabilities which al low for case studies to evaluate and justify the ap- generation of integratedgraphical and textual proach. This includes p orting and devel- tools from high-level speci cations. In addi- oping a numb er of existing software engi- tion, the GOODSTEP platform provides a neering to ols on top of the new platform, softwareprocess toolset which enables mod- the development of to ol generation capabili- eling, analysis and enaction of softwarepro- ties to exploit the features of a fully ob ject- cesses and is also built on top of the extended oriented system, and the developmentofad- O database. The GOODSTEP platform wil l 2 vanced software pro cess mo deling capabili- be validated using two CASE studies carried ties which, once again, exploit the provided out to develop an airline application and a features of O . business application. 2 The choice of an ob ject-oriented database This work has b een funded by the EU under con- management system as baseline of the tract No. 6115 ESPRIT-I I I pro ject GOODSTEP pro ject derives from the inadequacy of re- lational database systems for software engi- neering applications, which has b een recog- nized for quite some time [22,25]. This has resulted in a great e ort in b oth the indus- trial and research communities to extend the t database technology towards more curren Software Process Tool Construction werful and exible database management po toolset toolset systems. In particular, in this context we are interested in the work done on the develop- uses uses ment of ob ject-oriented database systems. The class of ob ject-oriented database sys- wo cat- tems can b e roughly classi ed in t O2 Additional functionalities egories: those o ering the full functionali- ted data mo del, which ties of the ob ject-orien O2 Kernel O2 database e will refer to from nowonas object w enhancement management system database systems ODBSs [10], and those o ering only a subset of the ob ject-oriented mo del, whichwe will call structural ly ob ject- oriented database systems. The main dis- Figure 1: The GOODSTEP SDE platform tinction b etween structurally ob ject-oriented databases and ob ject database systems, which is also the main drawback of the hances the functionalities o ered by O ,by 2 rst class, is that most of the structurally adding new functionalities to its kernel or on ob ject-oriented database systems, suchas top of it. Moreover, two to ol sets have b een PCTE/OMS [17], Damokles [12], assume a develop ed together with the enhanced O 2 certain level of granularity of the ob jects to system to constitute the GOODSTEP plat- b e stored and retrieved and that they further form. The rst to olset TCT supp orts the cannot de ne encapsulation of data struc- generation of new to ols. The other set of tures by op erations. These systems either to ols supp ort development, simulation and supp ort relations b etween coarse-grained ob- execution of software pro cesses SPT. In jects such as pro ducts of the SE life cycle particular it integrates the to ols generated e.g. A is the sp eci cation of B, A is owned by the rst to ol set. Both SPT and TCT sup- by develop er Q, etc., or else supp ort a rather p ort the development of a customized SDE. ne-grained level of ob jects suchassyntac- The rest of the pap er is structured as fol- tic units of programs or sp eci cations i.e. lows: In Section 2, we rst describ e the statements, variables, pro cedures, etc.. GOODSTEP platform in some detail. In In practice, many software engineering Section 3, we describ e the fundamental re- to ols require supp ort for b oth levels of granu- quirements for the underlying database sys- larity. By contrast, ob ject database systems tem as required by the GOODSTEP plat- are the b est approach to supp ort sophisti- form. In Section 4, we showhow these re- cated ecient storage and retrieval of ob jects quirements are addressed by O and we de- 2 at arbitrary levels of granularity [13]. scrib e the planned O extensions. Finally, 2 The pro ject amply demonstrates two im- Section 5 concludes the pap er while drawing p ortant features of an ob ject database sys- attention on ongoing and further work. tem. In the rst place, it enables much eas- ier implementations of SE-tools than when using conventional DBMSs. This is b ecause 2 Building the GOODSTEP Plat- the richer semantics of the ob ject oriented form for Software Develop- mo del is most suited to the complex data mentEnvironments handled in software engineering applications, and also b ecause there is no problem of xed The metho ds and languages to b e used for granularity of ob jects. In the second place, the development of a software application { it signi cantly improves the functionality of b e they graphical or textual languages { de- softwaretools which can bebasedupon it. p end on the application domain. For exam- The software architecture of GOODSTEP ple, real-time applications require di erent is illustrated in Figure 1. GOODSTEP en- sp eci cation and implementation languages than nancial or medical applications. More- it is p ossible to assign values to tokens and over, the pro cess mo dels that supp ort an ap- predicates to transitions, describing the con- plication development b est can not b e pre- straints on tokens consumed and pro duced de ned. They dep end not only on the appli- by transition rings. cation domain, but also on the organization and on the p eople who are running the pro- 2.1.1 SLANG cesses. Current SDEs su er from their se- We describ e SLANG by means of a simple lection of sp eci c combinations of languages example. A SLANG sp eci cation of a pro- and often assume a particular pro cess. Both cess fragment is presented in Figure 2. For usually do not completely cover the needs an elab orated discussion of SLANG, we refer of any software development and imp ose a to [7]. pre-sp eci ed development mo de. Instead, the software industry demands customiz- Executable Test Cases hmay b e easily adapted to able SDEs, whic Module * the evolving needs of software development. GOODSTEP addresses this need by provid- Start Test ing means to * de ne the pro cess used for developing Data for Test Cumulative Test ware system within the software a soft Execution Results (CTR) (DFTE) pro cess to ol-set and generate the to ols needed during the Test Cases Prepare Test Used Up course of a software pro cess using the to ol construction to ol-set. Executable Test (RET) Using the pro cess to ol-set a mo del tailored to the needs of a particular institution or Test Results Being Computed en pro ject can b e mo deled, analyzed and ev (TRBC) Execute Test later used for running a software pro ject. Test Results Using the to ol construction to ol-set, it will Summary (TRS) b e p ossible to de ne and generate concep- Test Results tual schemas and de ne and generate a set tegrated syntax-directed software devel- of in End Test Errors Found t to ols from appropriate sp eci cation opmen Add Test Result languages. Final Test Results 2.1 Software Pro cess Mo deling and Enactment Figure 2: A Mo del of a Pro cess Fragmentin Software pro cess mo deling and enactment SLANG is supp orted in GOODSTEP by the SPADE Software Pro cess Analysis Design and En- The example mo dels a pro cess activity to actment environment.