Required diagrams

Knut Jetlund edited this page Apr 5, 2016 · 14 revisions

Back to diagram design


ISO19103 - Conceptual Schema Language have rules and recomendations for documentation of models, including which diagrams that should be part of the documentation. In addition, there are some other useful diagrams that should be included.

Package diagrams

Package dependency diagrams

According to requirement 17 and requirement 21 in ISO19103, all package dependencies shall be shown in one or more package diagrams for each package, including external package dependencies.

Example package structure (from ISO19103:2015)

Class diagrams

The main best practice rule for class diagram, independent of rules in ISO19103 and ISO19109, is that all classifiers (classes, code lists, enumerations and data types) shall be presented in at least one diagram. Here's a script for controlling this rule. Further on, all attributes, associations, operations and constraints shall also be shown in at least one diagram.

High level overview diagrams

High level overview diagrams with only the main classes and associations is a good introduction to the model. In these diagrams, all attributes and role names should be hidden. Example of high level overview diagram for ISO19160-1:2015

Detailed overview diagrams

According to recommendation 16 in ISO19103, each package should have a overview diagram which shows all classes, without operations, attributes and role names. Some attributes, associations and role names may be shown if they are important to understand the context. Example of detailed overview diagram for ISO19160-1:2015

Perspective specific diagrams

Diagrams with focus on specific parts of the model and the major classifiers in this perspective are useful for understanding the model. Remember that less is more - few elements and few perspectives for one diagram improves readability. Do not show attributes and associations that are not relevant for the given perspective. Example of perspective specific diagram for data quality result (From ISO19157:2013)

Code lists, enumerations and data types

Specific diagrams with all code lists and enumeration or all data types in a package are also useful. These classifisers are often reused in different parts of a model, and it is much help in having them all collected in one diagram. Example of code list diagram (From ISO19160-1:2015)

Context diagram for each classifier

According to requirement 18 in ISO19103, all model classifiers shall be documented in a context diagram where all attributes, operations and all relationships that are navigable from the central classifier are displayed. Closely related classifiers may share context diagram, but remember that less is more here as well - few elements and few perspectives for one diagram improves readability.

Example of context diagram for DQ_EvaluationMethod (From ISO19157:2013)

Use case diagrams and sequence diagrams

Use case diagrams and sequence play an important role in the process of developing models.

TBD: Further description and examples of Use Case Diagrams

Object diagrams

Object diagrams with instances of classes play an important role in understanding and testing models. Examples of object diagrams in ISO/TC211 can be found in ISO19160-1. When developing a profile of ISO19160-1, object diagrams for a few sample addresses are mandatory.

The figure bellow shows an object diagram for the INSPIRE Profile of ISO19160-1. INSPIRE Address profile - object diagram

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.