GPMSWiki/CoreDocumentation/Design goals and specification

Core Documentation - Design goals and specification

In this section we describe our concept for a GPMS and specify the basic elements. The system design was finally modeled using the Unified Modeling Language (UML).

Basic definitions for a GPMS

For the design of a GPMS several specific elements can be identified that represent real world objects or reflect the relationship between individual components involved in a project. These core objects are defined below in order to clarify their use in the following sections.

user

A user simply represents an individual person.

project

A project indentifies a specific scope for research or ongoing work, e.g. a project can be defined for the annotation of a newly sequenced bacterial genome. In most cases a project is defined for and related to a special software application, e.g. a genome annotation system.

member

A user has to become a member of a project for accessing a Project's data. Thus a project has a number of associated users and each user "knows" the projects she/he is involved in.

role

The level of access to a Project's data can be specified by assigning well-defined roles to each member. A role thus represents a set of access privileges or permissions.

gpmsright

Since most database management systems use their own access control mechanisms, access is not granted directly based on these privileges. The GPMS therefore features the definition of rights as free text descriptions that reflect a specific task for which a certain level of data access is required (e.g. "basic access" or "annotate").

projectclass

Since all data access control should follow the same rules for every project of the same application type, roles and rights are not defined for an individual project but for a projectclass.

dbprivs

dbprivs represent privileges that are used by a specific RDBMS for controlling access to individual databases.

datasource

A datasource describes a storage backend for project related data that is located on a host (e.g. a database server). This can be either a database (DB) stored on a RDBMS or an ApplicationServer that provides data e.g. via web services. A DB can be further specified by the type of the database management system (DBMS_Type).

datasourcetype

A special datasourcetype can be used to determine the specific type of a datasource. The datasourcetype contains information about the internal structures of a datasource (e.g. tables of a database) and thus all dbprivs refer to a corresponding datasourcetype.

affiliation

Affiliations allow to associate users and projects with an institution (e.g. CeBiTec). In the various web portals (e.g. MGE Portal) at the CeBiTec users may only request access to projects that belong to the same affiliation.

Specification of the GPMS

Based on the requirements described so far we have designed a GPMS that organizes application specific data into projects. We have also integrated the administration of users and modeled the relationship of users to projects as roles. Figure reffig:design illustrates the central components of the gpms and their relationships in UML.

Users and projects are two core objects, every other object is related to a specific project or user. Each project specifies a separate well defined scope that is uniquely identified by its name. Different DataSources that should be accessed in such a project are referenced by a project which allows several projects to share the same DataSources. In addition to individual projects a MetaProject can be used to group several project instances to a new project in order to correlate their data.

As another central component users were modeled in a very simple manner: They can be identified by their unique login name or email address and are thus organized as separate objects. Their individual roles in single projects are defined by associating a user, a project, and a role in a member object. In order to simplify the assignment of roles we have included an additional class (Project_Class) that can be used to group projects of the same type (these are normally used by the same type of application). Thus roles are only defined once for each Project_Class and not individually for each project. A role is further associated with a list of rights that specify the level of access a user with this role has for a project. Each gpmsright is defined by a comprehensive name which explains its semantics. It is associated with a list of dbprivs and thus mapped onto specific database privileges (e.g. select privilege in SQL).

Author: Lutz Krause