Mapping Rules

From OPENRESEARCH mk copy Wiki
Jump to navigation Jump to search

Introduction

Certain aspects of the software can be systematically implemented. If it is worth wile to work systematically then some rules should be applied. Otherwise ad-hoc decisions are possible which shall be documented in place. e.g the Source Code


Rules

Each rule boils down to the decision taken for the systematic working of things.

  • For each entity type there is a form with the same name. e.g Entity Event has Form:Event.
  • Each Entity needs to have 7 technical SMW pages:
    • List of
    • Help
    • Concept
    • Category
    • Template
    • Form
    • Properties(1 page per property)

List of

  1. Input form to allow adding new entities
  2. Number of entities should be shown. Can be queried with parameter |format=count
  3. List of all (query limit can be applied) instances of this entity
    1. List should contain all properties of the entity (sorted by index/sortPos)
  4. Show one rendered entity instance (should be hide-able)
  5. Must contain everything that the entity is involved in.

Examples

Concept

  1. A table containing important information about the structure of the entity.
  2. List of all properties of this entity.
  3. Optional:
    1. Documentation of the entity if available
    2. A section showing a uml diagram with the description of the entity, its attributes and links to other entities (but no details for those)
    3. Class diagram of the entity containig all primitive properties
    4. Properties with type Page are shown as edges
      1. outgoing edges for properties that link from this entity to another one
      2. incoming edges for properties that link another entity to this entity
      3. edges should show the cardinality (can be derived from Property:inputType)
      4. edges should have the property name as label
  4. List of all technical pages of this entity

Help

Rules

A help page consist of the following sections:

  1. A header showing Icon, Link to the Entity description Topic), name of the entity, plural name of the entity and the plain text documentation
  2. A documentation section showing the wiki documentation of the entity description(Topic)
  3. A section with up to 7 links for example instances for the entity
  4. A section showing a table of all properties for the entity. More explicit description of properties and support of multiple languages.
  5. Optional: A section showing a uml diagram with the description of the entity, its attributes and links to other entities (but no details for those)
    1. Class diagram of the entity containig all primitive properties
    2. Properties with type Page are shown as edges
      1. outgoing edges for properties that link from this entity to another one
      2. incoming edges for properties that link another entity to this entity
      3. edges should show the cardinality (can be derived from Property:inputType)
      4. edges should have the property name as label
    3. Other entities should not include there properties
  6. A list of links to the other technical SMW elements relevant for the entity

Links

Help-Example.png

UML Example

Event uml.png

Category

Rules

  1. Description on how to enter new instances of this entity
  2. Link to the Concept of the entity for further information
  • Category should list down all the pages in the entity involved. Each page marked with a Category tag of the entity will be available to view at the Category:Entity page.

Example

Template

Display the properties of the Entity in a structured way. May apply rules on when to show certain content based on the properties of the entity. If the form is strict the Template limits the set of properties that are stored on creation with the from.

Rules

  • noinclude part
    • Example usage of the template
  • Includeonly part
    • Displaying of the information based on the properties of the entity

See https://or.bitplan.com/index.php/Template:City

Screenshot 2021-03-22 Template City - or.png

Form

Rules

  • noinclude part
    • Description
    • Inputfield to create/edit new entity
    • Link to the help page of the entity
  • includeonly part
    • Input field for all properties of the entity

Properties

  • Structure of property shown to the user
  • A short description of what the property holds and its type.
  • A list of pages that use that property

Validation

  • validation approaches:
    • Manual check by comparing pages created with the rules and marking the rules with
    • Dynamic at runtime e.g using redlinks in the form showing that a property does not exist
    • Test pages and testcode with query which will check if there are some properties that are not used in a form.