GPMSWiki/CoreDocumentation/Design goals and specification - Revision history

Admin: 6 revisions

2011-10-26T06:17:05Z

6 revisions

← Older revision	Revision as of 08:17, 26 October 2011
(No difference)

imported>JomunaChoudhuri at 15:07, 24 August 2005

2005-08-24T15:07:02Z

← Older revision		Revision as of 17:07, 24 August 2005
Line 77:		Line 77:
	is uniquely identified by its name. Different DataSources that should be		is uniquely identified by its name. Different DataSources that should be
	accessed in such a project are referenced by a project which allows		accessed in such a project are referenced by a project which allows
	several projects to share the same [[DataSources]]. In addition to individual		several projects to share the same DataSources. In addition to individual
	projects a MetaProject can be used to group		projects a MetaProject can be used to group
	several project instances to a new project in order to correlate their		several project instances to a new project in order to correlate their

imported>JomunaChoudhuri at 15:06, 24 August 2005

2005-08-24T15:06:30Z

← Older revision		Revision as of 17:06, 24 August 2005
Line 51:		Line 51:
	data that is located on a host (e.g. a database server). This can be either		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		a database (DB) stored on a RDBMS or an
	[[ApplicationServer]] that provides data e.g. via web services. A		ApplicationServer that provides data e.g. via web services. A
	DB can be further specified by the type of the database management		DB can be further specified by the type of the database management
	system (DBMS_Type).		system (DBMS_Type).
Line 60:		Line 60:
	structures of a datasource (e.g. tables of a database) and thus all dbprivs		structures of a datasource (e.g. tables of a database) and thus all dbprivs
	refer to a corresponding datasourcetype.		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 ==		== Specification of the GPMS ==
Line 72:		Line 75:
	Users and projects are two core objects, every other object is related to		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		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		is uniquely identified by its name. Different DataSources that should be
	accessed in such a project are referenced by a project which allows		accessed in such a project are referenced by a project which allows
	several projects to share the same [[DataSources]]. In addition to individual		several projects to share the same [[DataSources]]. In addition to individual
	projects a [[MetaProject]] can be used to group		projects a MetaProject can be used to group
	several project instances to a new project in order to correlate their		several project instances to a new project in order to correlate their
	data.		data.

imported>LutzKrause at 14:46, 18 April 2005

2005-04-18T14:46:23Z

← Older revision		Revision as of 16:46, 18 April 2005
Line 68:		Line 68:
	components of the gpms and their relationships in UML.		components of the gpms and their relationships in UML.

	~~attachement~~:GPMS_ClassDiagramWithBorder.png		[[Image:GPMSWiki$$CoreDocumentation$$Design_goals_and_specification$GPMS_ClassDiagramWithBorder.png]]

	Users and projects are two core objects, every other object is related to		Users and projects are two core objects, every other object is related to

imported>LutzKrause at 14:45, 18 April 2005

2005-04-18T14:45:20Z

← Older revision		Revision as of 16:45, 18 April 2005
Line 68:		Line 68:
	components of the gpms and their relationships in UML.		components of the gpms and their relationships in UML.

	~~beginfigure[H]~~		attachement:GPMS_ClassDiagramWithBorder.png
	~~begincenter~~
	~~includegraphics[width=0.95columnwidth]uml/~~GPMS_ClassDiagramWithBorder
	~~endcenter~~
	~~caption[UML design of the gpms.]The gpms described in UML~~.
	~~labelfig:design~~
	~~endfigure~~

	Users and projects are two core objects, every other object is related to		Users and projects are two core objects, every other object is related to

imported>LutzKrause: q

2005-04-18T14:42:55Z

← Older revision	Revision as of 16:42, 18 April 2005
(No difference)

Unknown user at 00:00, 1 January 1970

1970-01-01T00:00:00Z

New page

__NOTOC__
= 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.

== 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.

beginfigure[H]
begincenter
includegraphics[width=0.95columnwidth]uml/GPMS_ClassDiagramWithBorder
endcenter
caption[UML design of the gpms.]The gpms described in UML.
labelfig:design
endfigure

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: [http://www.cebitec.uni-bielefeld.de/~lkrause Lutz Krause]