Skip to content

Warehouse Tutorial 1 ‐ Basics

Introduction to DMLA

In this tutorial, we introduce the core features of Dynamic Multi-Layer Algebra (DMLA) by modeling a general-purpose warehouse domain, similar to those used by large-scale enterprises like Amazon. DMLA is designed to improve upon traditional two-level modeling methodologies (like UML) by supporting multi-level modeling, reducing complexity, and offering flexibility for complex models.

With DMLA, you can define concepts, enrich them with features, connect them, and progressively refine the entire model step by step. This top-down approach ensures that even as details are incrementally added, the model remains rigorous and consistent. DMLA aims to provide a high level of flexibility and at the same time a rigorous validation mechanism during refinement. In this tutorial, we’ll follow this methodology: we'll start at a high level of abstraction and refine the model as we go.

Prerequisites

  • Basic understanding of modeling and programming concepts

Getting Started

Before we dive into modeling the warehouse domain, let’s briefly introduce the fundamental building blocks of DMLA and the modeling methodology it follows.

In DMLA, the main concepts are:

  • Entities are analogous to classes in object-oriented programming, entities represent core concepts in your domain.
  • Slots are similar to fields or attributes, representing internal properties of entities.
  • Operations represent methods that define behaviors or validations for entities.
  • Annotations describe metadata that adds constraints or behavior, similar to annotations in languages like Java.

Entities describe their internal structure using slots, and can be further enhanced with operations to customize the validation of the entity and also to add functionality to interact with the entity. Annotations are used to impose restrictions or enable functionality on entities or slots. While operations are specific to the given entity, annotations tend to describe a universal behavior or mechanism, which is applicable to many entities. For example, a type constraint can be attached to a slot to enforce what type of data the value of the slot can hold. Similarly, cardinality constraints dictate how many values a slot may have (e.g. handling optional values or lists) in its refinements.

When an entity is refined, the original (~meta) entity is referred to as the classifier, while the new (~instance) entity as its refinement. From a practical point of view, refinement gradually constrains the domain concepts. Refinement relates a DMLA entity to its classifier and the framework automatically validates if there is indeed a valid refinement relationship between the two entities. At the topmost abstraction level, we do not usually have much information about the exact structure and details of an entity, therefore slots are often used as placeholders. Further down, we can refine the entity: add new slots, refine slots or omit them (if their cardinality allows this). Refining a slot means adding annotations to it, modifying existing annotations (e.g. further restricting its type constraint), or setting the value of the slot. When an entity is refined, slots and annotations are implicitly inherited from its classifier meaning that the entity has the exact same slots, slot values and behavior (operations) as its classifier.

The next step is creating the structure of the Warehouse.