Meta Resource Management System

Analysis Model

René Freude (707168)

Henry Hinze (681566)

Daniel Sadilek (707297)

Stephan Weiß (706830)

2003-10-06

Revision History
Revision 0.12003-05-19
Initial public release.
Revision 0.22003-06-09
Corrected some cardinalities, extended descriptions, added operations.
Revision 0.32003-06-15
Added "user logs in" sequence diagram.
Revision 0.42003-06-23
Extended from static model to analysis model.
Revision 0.52003-10-06
Incorporated optional feature "Resource Reservation" (see appendix of this document for the use cases derived from that feature); refined package structure; introduced distinction between physical resource containment hierarchy and resource usage.

Abstract

This document contains the class diagrams and class descriptions that resulted from the static analysis as well as sequence diagrams and state chart diagrams that we used to verify the class model.


Table of Contents

1. Overview
2. Package: model.entity
2.1. EntityType
2.2. ResourceType
2.3. EmployeeType
2.4. Entity
2.5. Resource
2.6. Employee
2.7. AttributeType
2.8. BooleanAttributeType
2.9. NumberAttributeType
2.10. TextAttributeType
2.11. Attribute
2.12. BooleanAttribute
2.13. NumberAttribute
2.14. TextAttribute
3. Package: model.linkage
3.1. LinkRule
3.2. Link
3.3. ResourceContainmentLinkRule
3.4. ResourceContainmentLink
3.5. ResourceUsageLinkRule
3.6. ResourceUsageLink
3.7. CardinalitySpec
4. Package: model.user
4.1. AuthenticationData
4.2. User
4.3. Role
4.4. AccessRight
4.5. ResourceAccessRight
4.6. AttributeAccessRight
4.7. LinkAccessRight
5. Package: model.filter
5.1. Filter
5.2. Constraint
5.3. AttributeConstraint
5.4. ContainmentConstraint
5.5. UsageConstraint
5.6. Sequence: Filter.getMatchingResources
6. Package: client
6.1. SessionState
6.2. MainController
6.3. AbstractUseCaseController
6.4. UI
6.5. Sequence: User logs in
7. Appendix: Use Cases
7.1. Create resource reservation
7.2. Delete resource reservation
7.3. Change resource reservation
7.4. Create filtered collection of resource reservation entries

1. Overview

This document is organized along the package structure of the MRMS. Every package describes one aspect of the system:

  • model.entity: The MRMS can handle resources and the employees; the attributes that are to be saved for each resource type and employee type can be configured by an administrator. This common functionality is pulled up to the super type Entity. The package model.entity contains the classes to handle entities (resources, employees) and their attributes (number, text, boolean).

  • model.linkage: Resources and employees do not exist detached. Resources can be organized in a physical containment structure (e.g. a room contains workplaces, workplaces contain a computer, and so on) and resources can be used by employees. The package model.linkage contains the classes that are necessary to represent these links.

  • model.user: The users of the system need different access rights according to the role they play in the business. The package model.user contains the classes that represent the rights users have to create and delete entities, edit their attributes and create links.

  • model.filter: Creating a filtered collection of resources is a complex function that is required in different use cases. The package model.filter contains the classes needed to configure a filter with constraints and execute it.

(The classes imported from others packages are colored yellow.)

2. Package: model.entity

The following diagram depicts the classes to handle entities (resources, employees) and their attributes (number, text, boolean).

Figure 1. Entity Classes

Entity Classes

2.1. EntityType

Description

An EntityType has a name and specifies (by composition) the Attributes that an Entity of this type has.

Attributes

name (String): the name of the EntityType

Operations

---

2.2. ResourceType

Description

A ResourceType is a specialised EntityType for defining Resources.

Attributes

parentRequired (Boolean): specifies whether instances of this ResourceType must have a parent Resource

Operations

---

2.3. EmployeeType

Description

An EmployeeType is a specialised EntityType for defining Employees.

Attributes

---

Operations

---

2.4. Entity

Description

An Entity is composed of its Attributes and is an instance of an EntityType which specifies which Attributes the Entity may have.

Attributes

---

Operations

---

2.5. Resource

Description

A Resource is a specialised Entity for representing real-life-resources and is an instance of a ResourceType which specifies if this Resource must have a parent Resource within the Resources-Containment-Hierarchy.

Attributes

---

Operations

---

2.6. Employee

Description

An Employee is a specialised Entity for representing users of real-life-resources and is an instance of an EmployeeType.

Attributes

---

Operations

---

2.7. AttributeType

Description

Abstract base class for attribute types that an EntityType is composed of.

Attributes

name (String): the name of the AttributeType

onlyPredefinedValuesAllowed (Boolean): if true, the user may only select the predefined values for an Attribute that has this type; if false, he may enter another value as well

mandatory (Boolean): if true, the user must enter a value for Attributes of this type

frozen (Boolean): if true, the user may not change the value of Attributes of this type

Operations

---

2.8. BooleanAttributeType

Description

Concrete AttributeType for logical property characterisation of an Entity.

Attributes

value (Boolean): logical property characterisation of an Entity

Operations

---

2.9. NumberAttributeType

Description

Concrete AttributeType for NumericalAttributes.

Attributes

predefinedValues (Number[]): an array specifying predefined values for Attributes of this type

minValue (Number): the minimum value Attributes of this type may have

maxValue (Number): the maximum value Attributes of this type may have

Operations

---

2.10. TextAttributeType

Description

Concrete AttributeType for TextAttributes.

Attributes

predefinedValues (String[]): an array specifying predefined values for Attributes of this type

minSize (Number): the minimum number of characters Attributes of this type may have

maxSize (Number): the maximum number of characters Attributes of this type may have

Operations

---

2.11. Attribute

Description

Abstract base class for Attributes that an Entity is composed of.

Attributes

---

Operations

---

2.12. BooleanAttribute

Description

Concrete Attribute for a boolean property characterisation of an Entity.

Attributes

value (Boolean): numerical property characterisation of an Entity

Operations

---

2.13. NumberAttribute

Description

Concrete Attribute for a numerical property characterisation of an Entity.

Attributes

value (Number): numerical property characterisation of an Entity

Operations

---

2.14. TextAttribute

Description

Concrete Attribute for a textual property characterisation of an Entity.

Attributes

value (String): textual property characterisation of an Entity

Operations

---

3. Package: model.linkage

The following diagram depicts the classes that are necessary to represent the physical containment links between resources and resources and the usage links between resources and employees.

Figure 2. Linkage Classes

Linkage Classes

3.1. LinkRule

Description

A Link Rule defines the characteristics of a consistent Link. Both the physical containment structure of the resources as well as the usages of the resource by the users can be modelled as links. In both cases the corresponding link rules have the characteristic that the cardinality of one side is 1; for the physical containment links this side is the parent resource type and for the usage links this side is the employee type. The other side of the link rule can have an arbitrary cardinality (i.e. the number of children a parent has in the physical containment structure as well as the number of resources an employee may use is not constrained by the system but can be customized by the administrator); this cardinality is contained in the CardinalitySpec referenced by the LinkRule. A LinkRule can reference an BooleanAttributeType of the parent resource / using employee; in this case Links of this LinkRule can only be created for those Resources / Employees where the corresponding BooleanAttribute is true.

Attributes

name (String): name of the LinkRule

Operations

---

3.2. Link

Description

Base class for ResourceContainmentLink and ResourceUsageLink.

Attributes

---

Operations

---

3.3. ResourceContainmentLinkRule

Description

A ResourceContainmentLinkRule defines the characteristics of a consistent ResourceContainmentLink. It references two ResourceTypes which may be linked together by a ResourceContainmentLink.

Attributes

---

Operations

---

3.4. ResourceContainmentLink

Description

A ResourceContainmentLink references two Resources that are linked together by it; one resource takes the parent role, the other is its child in the pysical containmet. Its consistency is checked against the ResourceContainment LinkRule references.

Attributes

---

Operations

---

3.5. ResourceUsageLinkRule

Description

A ResourceUsageLinkRule defines the characteristics of a consistent ResourceUsageLink. It references one ResourceType and one EmployeeType whose instances may be linked together by a ResourceUsageLink.

Attributes

---

Operations

---

3.6. ResourceUsageLink

Description

A ResourceUsageLink references one Resource and one Employee that are linked together by it. Its consistency is checked against the ResourceUsageLinkRule it references. There may be more than one ResourceUsageLink at a Resource; but only one of can be active at a certain time.

Attributes

startDate (Date): Time when usage starts.

stopDate (Date): Time when usage expires.

Operations

---

3.7. CardinalitySpec

Description

Specifies the minimum and maximum cardinality for a certain ResourceType, referenced by a ResourceUsageLinkRule or a ResourceContainmentLinkRule. Example: A ResourceContainmentLinkRule has two ends ResourceType1 (parent) and ResourceType2 (child). The ResourceType1 always has the cardinality 1 while ResourceType2 has the cardinality min=1 and max=4, this means that one specific Resource of ResourceType1 must have at least 1 and may have up to 4 Links to Resources of ResourceType2. The CardinalitySpec may also reference a NumberAttributeType of the ResourceType1.

Attributes

minCardinality (Number): value for the minimum cardinality; will be ignored when there is a “min”-reference to a NumberAttributeType, in this case the NumberAttribute's value will be used instead

maxCardinality (Number): value for the maximum cardinality; will be ignored when there is a “max”-reference to a NumberAttributeType, in this case the NumberAttribute's value will be used instead

Operations

---

4. Package: model.user

The following diagram depicts the classes for user and access rights management of the MRMS.

Figure 3. User and Access Rights Management Classes

User and Access Rights Management Classes

4.1. AuthenticationData

Description

Value class, encapsulating the authentication data of a user.

Attributes

userName (String): the user's name

password (String): the user's password

Operations

---

4.2. User

Description

Class for user accounts of the MRMS. Its instances may play Roles in the system.

Attributes

passwordExpirationDate (Date): date after which the user has to enter a new password

realName (String): real name of the user

Operations
  • static checkPasswordStrength(password: String): Boolean

    Effect

    Checks, if the given password String is strong enough (minimum length, mixed letters and numbers, ...) to be accepted by the system.

    Parameters

    password: the password to be checked

    Return

    The boolean value true, iff the password is strong enough.

    Exceptions

    ---

    Actor

    Control class of the use case “User changes password”.

  • static findUser(authData: AuthenticationData): User

    Effect

    Searches the system for a User matching the given AuthenticationData.

    Parameters

    authData: the AuthenticationData to search for

    Return

    If a matching User object could be found it is returned, otherwise the operation returns the null pointer.

    Exceptions

    ---

    Actor

    Control class of the use case “User logs in”.

4.3. Role

Description

A Role defines which AccessRights its players (Users) have.

Attributes

name (String): name of the Role

isAdministratorRole (Boolean): defines if Users of the Role have administration rights

Operations

---

4.4. AccessRight

Description

Abstract base class for access rights. If a Role references an AccessRight it has this AccessRight. Users have the AccessRights which the Roles they play have.

Attributes

---

Operations

---

4.5. ResourceAccessRight

Description

Concrete AccessRight that defines owner's authority of working with Resources that are of a specific ResourceType.

Attributes

canCreate (Boolean): defines if Resources of the referenced ResourceType may be created

canDelete (Boolena): defines if Resources of the referenced ResourceType may be deleted

Operations

---

4.6. AttributeAccessRight

Description

Concrete AccessRight that defines owner's authority of working with Atrributes of a specific AttributeType that belongs to a specific ResourceType.

Attributes

canRead (Boolean): defines if Attributes of the referenced AttributeType may be read

canWrite (Boolean): defines if Attributes of the referenced AttributeType may be written

Operations

---

4.7. LinkAccessRight

Description

Concrete AccessRight that defines owner's authority of creating and deleting Links according to a specific LinkRule.

Attributes

canLink (Boolean): defines if Links according to the referenced LinkRule may be created

canUnlink (Boolean): defines if Links according to the referenced LinkRule may be deleted

Operations

---

5. Package: model.filter

The following diagram depicts the classes needed to configure a filter and get a collection of Resources out of it.

Figure 4. Filter Classes

Filter Classes

5.1. Filter

Description

A Filter is used to get a subset of all Resources of the referenced ResourceType. The Filter is defined by the Constraints it is composed of.

Attributes

---

Operations
  • getMatchingResources(): Resource[]

    Effect

    Searches the system for Resources matching the referenced Constraints.

    Parameters

    ---

    Return

    An array of the matching Resources.

    Exceptions

    ---

    Actor

    Control class of the use case “Create filtered collection of resource entries”.

5.2. Constraint

Description

Abstract base class for constraints. Constraints are used by a Filter to describe a specific state that Resource must fulfill to pass.

Attributes

---

Operations
  • matches(resource: Resource): Boolean

    Effect

    Tests, if the given Resource matches this Constraint.

    Parameters

    resource: the Resource to be tested

    Return

    The boolean value true, iff the given Resource matches this Constraint.

    Exceptions

    ---

    Actor

    Class Filter.

5.3. AttributeConstraint

Description

An AttributeConstraint is a concrete Constraint that checks whether an Attribute of the referenced AttributeType is either equal to the referenced Attribute or lays between the two referenced min- and max-Attributes.

Attributes

---

Operations

---

5.4. ContainmentConstraint

Description

A ContainmentConstraint is a concrete Constraint that checks whether a Resource matches the physical containment state that is described by the following attributes. A ContainmentConstraint references the LinkRule it refers to. If in this LinkRule the ResourceType that is to be filtered has (1) the parent role minimum and maximum cardinality are taken from LinkRule's CardinalitySpec and refer to the number of children; if it has (2) the client role then min = max = 1 iff the field requiresParent of the ResourceType is true, min = max = 0 otherwise.

Attributes

underLinked (Boolean): cur < min

free (Boolean): cur = 0

linkable (Boolean): cur < max

unlinkable (Boolean): cur >= max

overLinked (Boolean): cur > max

Operations

---

5.5. UsageConstraint

Description

A UsageConstraint is a concrete Constraint that checks whether a Resource is used or unused in a given time period.

Attributes

used (Boolean): Defines whether the filtered Resources have to be used or unused in the given time period.

startDate (Date): Start time of the time time period.

stopDate (Date): End time of the time period.

Operations

---

5.6. Sequence: Filter.getMatchingResources

The following diagram shows how a filter determines the matching resources.

Figure 5. Sequence: Filter.getMatchingResources

Sequence: Filter.getMatchingResources

6. Package: client

The following diagram depicts the main classes needed to realize an interaction between the user and the MRMS. All use cases have a similar structure, so we have only included the AbstractUseCaseController that serves as a base class for all concrete use case controllers (which we have omitted in this analysis model).

Figure 6. Control and Boundary Classes

Control and Boundary Classes

6.1. SessionState

Description

A SessionState describes a session of interaction between the MRMS and a user. A User is logged in in a SessionState if it references that User.

Attributes

---

Operations
  • loggedIn(user: User): Boolean

    Effect

    Checks whether the given User is logged in in this SessionState.

    Parameters

    ---

    Return

    The boolean value true, iff the given User is logged in in this SessionState.

    Exceptions

    ---

    Actor

    All control classes.

6.2. MainController

Description

This controller requests the UI to display the main dialog to get the use case the user wants to perform next. It invokes the concrete use case controllers according to the user's choice.

Attributes

---

Operations

---

6.3. AbstractUseCaseController

Description

Base class for all concrete use case controllers. Encapsulates the common control flow.

Attributes

---

Operations
  • invoke(): void

    Effect

    Constructor operation that starts this controller and requests the UI to show the appropriate form for the concrete use case.

    Parameters

    ---

    Exceptions

    ---

    Actor

    MainController.

  • private validateUserInput(input: Object): String

    Effect

    Validates the input the user made.

    Parameters

    input: The input the user has made.

    Return

    If not valid, a String describing the input errors; otherwise the null pointer.

    Exceptions

    ---

    Actor

    this

The following diagrams show the control flow of an invocation of a concrete use case controller and the states it passes through.

Figure 7. Sequence: Concrete Use Case Controller

Sequence: Concrete Use Case Controller

Figure 8. State Chart: Concrete Use Case Controller

State Chart: Concrete Use Case Controller

6.4. UI

Description

The UI is responsible for providing all facilities the MRMS needs to interact with a user.

Attributes

---

Operations
  • informAboutError(text: String): void

    Effect

    The user is informed about an error that occured in the system.

    Parameters

    text: the description of the error that occured

    Return

    ---

    Exceptions

    ---

    Actor

    Any control class.

  • requestConfirmation(text: String): Boolean

    Effect

    The user is requested to confirm or cancel an action.

    Parameters

    text: the question to be answered by the user

    Return

    The boolean value true, iff the user confirmed

    Exceptions

    ---

    Actor

    Any control class.

  • requestAuthenticationData(): AuthenticationData

    Effect

    Requests authentication data (username and password) from the user.

    Parameters

    ---

    Return

    An AuthenticationData object holding the values for username and password provided by the user.

    Exceptions

    AuthenticationAbortedException if the user cancelled the operation

    Actor

    Control class of the use case “User logs in”.

  • showMainDialog(): void

    Effect

    The user is shown the main dialog for interaction with the system. There he selects which use case he wants to perform next.

    Parameters

    ---

    Return

    The use case that the user wants to perform next.

    Exceptions

    ---

    Actor

    MainController.

  • showUserForm(io_user: User): void

    Effect

    The user is shown a form for editing a User's attributes.

    Parameters

    io_user: the User to be edited

    Return

    ---

    Exceptions

    ---

    Actor

    Control class of the use case “Create user account”.

  • showPasswordForm(io_password: String): void

    Effect

    The user is shown a form for editing a User's password.

    Parameters

    io_password: the password String to be edited

    Return

    ---

    Exceptions

    ---

    Actor

    Control class of the use case “User changes password”.

  • showRoleForm(io_role: Role): void

    Effect

    The user is shown a form for editing a Role's name.

    Parameters

    io_role: the Role to be edited

    Return

    ---

    Exceptions and

    ---

    Actor

    Control class of the use case “Create role”.

  • showRoleAssignmentForm(io_user: User): void

    Effect

    The user is shown a form for editing a User's role assignment.

    Parameters

    io_user: the User whose role assignment should be edited

    Return

    ---

    Exceptions

    ---

    Actor

    Control class of the use case “Edit role assignment of user account”.

  • showRoleAccessRightsForm(io_role: Role): void

    Effect

    The user is shown a form for editing a Role's access rights.

    Parameters

    io_role: the Role to be edited

    Return

    ---

    Exceptions

    ---

    Actor

    Control class of the use case “Edit rights for role”.

  • showResourceTypeForm(io_resourceType: ResourceType): void

    Effect

    The user is shown a form for editing a ResourceType's name and the AttributeTypes it is composed of.

    Parameters

    io_resourceType: the ResourceType to be edited

    Return

    ---

    Exceptions

    ---

    Actor

    Control class of the use case “Define resource type”.

  • showLinkRuleForm(io_linkRule: LinkRule): void

    Effect

    The user is shown a form for editing a LinkRule's attributes.

    Parameters

    io_linkRule: the LinkRule to be edited

    Return

    ---

    Exceptions

    ---

    Actor

    Control class of the use case “Define link rule”.

  • showResourceOverviewForm(resources: Resource[]): void

    Effect

    The user is shown a list of the given Resources.

    Parameters

    resources: the Resources to be shown

    Return

    ---

    Exceptions

    ---

    Actor

    MainController and control class of the use case “Create filtered collection of resource entries”.

  • showResourceForm(io_resource: Resource): void

    Effect

    The user is shown a form for editing a Resource's Attributes.

    Parameters

    io_resource: the Resource to be edited

    Return

    ---

    Exceptions

    ---

    Actor

    Control classes of the use cases “Create resource” and “Edit resource”.

  • showFilterForm(): Filter

    Effect

    The user is shown a form for specifying a Filter.

    Parameters

    ---

    Return

    A Filter configured according to the users input.

    Exceptions

    ---

    Actor

    Control class of the use case “Create filtered collection of resource entries”.

6.5. Sequence: User logs in

This diagram shows the interactions of a successful log in.

Figure 9. Sequence: User logs in

Sequence: User logs in

7. Appendix: Use Cases

These are the use cases derived from the additional functionality “Resource Reservation”.

7.1. Create resource reservation

Goal

A new reservation for a resource is created.

Category

Primary

External Actors

User

Precondition

A user is logged in who has proper access rights to create the new resource reservation.

Triggering Event

The user requests the system to create a new resource reservation.

Postcondition Success

A new resource reservation has been created according to the users input.

Postcondition Failure

No new resource reservation has been created.

Description
  1. The system requests the user to choose the resource, start-, endtime of the reservation and the customer.

  2. The user determines resource reservation and submits his input.

  3. The system creates a new resource reservation.

Extensions

---

Alternatives

---

Additional Requirements

---

Annotation

---

7.2. Delete resource reservation

Goal

The reservation for a resource is deleted.

Category

Primary

External Actors

User

Precondition

A user is logged in who has proper access rights to delete the resource reservation.

Triggering Event

The user requests the system to delete a resource reservation.

Postcondition Success

The resource reservation has been deleted.

Postcondition Failure

The resource reservation has not been deleted.

Description
  1. The system requests the user to choose a resource reservation.

  2. The user determines the resource reservation to delete and submits his input.

  3. The system deletes the resource reservation.

Extensions

---

Alternatives

---

Additional Requirements

---

Annotation

---

7.3. Change resource reservation

Goal

The reservation for a resource is changed.

Category

Secondary

External Actors

User

Precondition

A user is logged in.

Triggering Event

The user requests the system to create a filtered collection of resource reservations.

Postcondition Success

The user is shown a collection of resource reservations that passed the filter he created.

Postcondition Failure

---

Description
  1. The system requests the user to choose a resource reservation for changing.

  2. The user determines the resource reservation to change and submits his input.

  3. The system changes the resource reservation.

Extensions

---

Alternatives

---

Additional Requirements

---

Annotation

---

7.4. Create filtered collection of resource reservation entries

Goal

Collect a set of resources reservations meeting a specific criterion and offer it to the user for further processing.

Category

Secondary

External Actors

User

Precondition

A user is logged in who has proper access rights to change the resource reservation.

Triggering Event

The user requests the system to change a resource reservation.

Postcondition Success

The resource reservation has been changed.

Postcondition Failure

The resource reservation has not been changed.

Description
  1. The system requests the user to configure a filter listed resource reservations will have to pass

  2. The system collects all resource reservations passing the specified filter and offers them to the user for further processing.

Extensions

---

Alternatives

---

Additional Requirements

---

Annotation

---