Lehrgebiet Informationssysteme

In large product development projects a shared database should be used in order to support cooperation and reuse of design. Usually, a repository is more sufficient than a pure DBMS, because repositories enhance database systems by value added services.
We want to provide a framework for building customized repository managers, which are able to cope with the needs of different domains, instead of one universal (???) repository manager. Since SERUM is a framework and not a "stand-alone"-system, it comes along with a set of methods, tools, techniques and half-fabricated components used for building customized repository managers.
Figure 1 gives an informal graphical presentation of SERUM and the steps needed for customizing a repository manager.

If the repository designer has to create a new repository manager or needs to modify an existing one, he first has to choose the half-fabricated components, which provide sufficient solutions for the particular domain section. We call such a half-fabricated component a framework.
The designer must customize the framework by adapting, refining, completing and specializing it's components (1). As a result of the customizing process a specification of the new repository manager is stored in the SERUM metadata database (2). We use the metamodel of the unified modeling language (UML) as the metamodel for SERUM repositories. The resulting UML specification is used as the input for the SERUM repository generator (3), which generates the repository database schema, the customized tool API and (several) repository servers (4). Because we are using an ORDBMS the repository database schema will not only consists of tables but also include User-Defined-Types (UDT) and User-Defined-Functions (UDF).
One of the goals of the SERUM approach is to provide value added database services. Hence, the tool APIs must be tailored to the needs of the tools in the domain and allow for adequate access to the services provided by the repository. Furthermore, additional functionality, which can not (or should not) be implemented in the API or at the database server, is realized in specialized repository servers. The process of repository instance generation is based upon generic components. These provide a base functionality. Customizing repository managers takes advantage of object oriented concepts, as, for example, subclassing (specialization), overloading, late binding of interfaces, etc.