Skip to content

Come up with initial ideas for framework's modeling approach #47

Description

@sergefdrv

As discussed in the post on frameworks for implementing distributed protocols, the underlying system model adopted by a framework has a profound effect on the structure and shape of specifications and implementations of protocols within the framework, as well as on the operational aspects and verification for correctness. Therefore, it's crucial to carefully consider the modeling approach to be adopted.

The model is a framework for thinking about the reality of distributed systems and the foundation for developing distributed protocols. The model generally defines the entities and possible relations between those entities used for describing the corresponding part of reality. Models can focus on different aspects of the system and vary in terms of the level of abstraction and scale.

We need to figure out what modeling approach to initially adopt in our framework. It should cover the following aspects:

  • state of the system as a whole and of its parts;
  • interaction between different parts of the system and with the external world;
  • time, asynchrony, concurrency, and non-determinism;
  • failures.

The framework's modeling approach should:

  • represent well the actual properties of realistic environments where distributed protocols are executed;
  • closely reflect the natural logical connections and casual dependencies present within the system;
  • define different levels of abstraction to zoom in and out of different part and aspects of the system;
  • provide sufficient structure for describing distributed systems and protocols in a highly modular way;
  • guide towards high cohesion and low coupling between structures within the model;
  • ensure coherence and continuity in representation of modeled systems;
  • be possibly simple and flexible.

Defining the model of distributed systems is difficult because they consist of multiple nodes running largely independently and it involves time, concurrency, and non-determinism, as well as failures. It's also easy to get distracted by the operational aspects and shift the focus away from the functional and logical aspects. We should try to think beyond the conventional variations of the state transition system model.

The following discussion is for ideas concerning the framework's modeling approach:

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status
In Progress

Relationships

None yet

Development

No branches or pull requests

Issue actions