Modeling Activity Define the Meta-Model

Modeling Activity Define the Meta-Model

Description

Casewise Modeler is a repository-based modelling tool. This means that all data and diagrams are stored in an underlying database. A database has a "schema", or a "meta-model", which determines the structure of your data, e.g. how it is organised, classified, and relates.

The default meta-model is known as POLDAT, i.e. it is built around six core object types: Process, Organisation, Location, Data, Application, and Technology.

You can extend and modify this meta-model so your data is more closely aligned with the "things" (or "business entities") that are important to your business. You can, in effect, design your own meta-model.

These tasks are done in the "Model Explorer Design View".

Capabilities (that this Activity helps deliver)

Appears on

zzz1

Concepts (Key Casewise Concepts)

  • Association Types & "Interface" Associations
  • Data Modeling Techniques
  • Database
  • Entity Relationship Diagram
  • Information Architecture or Business Taxonomy
  • Many-to-Many Relationships \ Intersection Object
  • Methodology & Techniques
  • Model Design
  • Modeling Objectives
  • Naming Conventions (Meta-Model)
  • Object, Property, and Association Types
  • Other Reference Models (e.g. TOGAF, FEAF, ITIL)
  • POLDAT
  • Property Types & Data Types
  • Repository or Model
  • Stakeholders
  • The Design View
  • The Meta-Model
  • Use of Categories

zzz3

Software Capabilities \ Components (used for this Activity Area)

  • Model Explorer: Design View
  • Model Properties: Locking & Freezing

zzz4

Guideliness & Checks (Summary)

  • Association Types: avoid the temptation to associate "everything to everything"
  • Association Types: be wary of setting "All Object" Association Types as they are not fully supported in object visualization diagrams
  • Association Types: deletions and potential problems
  • Association Types: for same object type associations (e.g. Process to Process), make sure you give it an explicit direction
  • Association Types: give them clear descriptors so it is explicit to the end user exactly what the purpose of the association is
  • Association Types: give them clear names so they are easily identifiable in the repository and for reporting purposes
  • Association Types: Interface Associations: beware of limitations
  • Meta-Model maintenance: consider all impacts of any changes, especially in a multi-model envionment
  • Meta-Model maintenance: become familiar with what makes up the default meta-model - and hence, what you cannot delete
  • Meta-Model maintenance: consider the various ways of documenting the meta-model
  • Meta-Model maintenance: decide who is able to change the meta-model
  • Meta-Model maintenance: Freezing the meta-model, or components of it, and impacts of this
  • Meta-Model maintenance: you can re-name default object, association, or property types, but you cannot delete them
  • Object Types: avoid both "redundancy" and "overloading"
  • Object Types: give them a name in both singular and plural form (not necessary for an Association Type)
  • Property Types : group them into relevant Panes; however, this is irrelevant for publishing and reporting
  • Property Types: Will the chosen Data Type aid hinder use in published output or Shape Regions?

zzz5