EBC Architecture Information Model

EBC architectures define software systems. We don´t want to talk of applications too often because the term is so overloaded. Rather you should think of software simple as hierarchical systems of functional units.

The functional units of an EBC based software system are parts and boards. Both are components of the systems but with different purposes.


A component is a functional unit providing some service to its environment. It communicates with the environment via output (delegate) and input pins (method).

Components are wired together by connecting output pins with input pins.

All components are independent of each other.


A part is the atomic component of an EBC architecture. It implements some application logic, be it functional or non-functional logic.


A board is the composit component of an EBC architecture. It does not implement logic itself but "hosts" other components and wires them together.

Boards, although functionally independent of other components, depend on the components placed on them. They are statically dependend on their contracts in order to be able to wire them up.

From the outside boards and parts are indistinguishable. Both are components with output/input pins for communication.

Basic Component Hierarchy

An EBC software system is a hierarchy of functional units with a board as its functional root. Most simply it can be expressed as:

SoftwareSystem ::= Board .
Board ::= Component { Component } .
Component ::= Board | Part .

Since boards are wholes as they are composed of parts, and at the same time are constituents of larger wholes they can be called holons. A software system thus is a holarchy.

Software is a recursive structure and EBCs make it easily possible to manifest this nature of software in code.

Information Model

In order to be able to define system architectures the basic component hierarchie needs to be augmented with further information leading to the following information model:

SoftwareSystem(name) ::= 
    [ Includes ]
    [ References ]
    Board .

Includes ::= // other system definitions to include; this is to enable building libraries of components; to be defined in the future
References ::= // references to .NET assemblies which contain message types to be used for output/input pins; to be defined in the future

Board(name) ::= 
    [ Definitions ]
    Wires .

Definitions ::= // definitions of components local to this board and nested boards
    Namespace |
    Board |
    Part .
Namespace(name) ::= // component definitions can be organized in a hierarchy of namespaces
    Namespace |
    Board |
    Part .

Part(name) ::= Pins .

Components ::= // references to components to place on a board
    ComponentReference { ComponentReference } .
ComponentReference(name [, id]).

Wires ::= Wire { Wire } .
Wire(fromPin, toPin).

Pins ::= Pin { Pin } .
Pin ::= OutputPin | InputPin .
OutputPin(id, outputType, responseType [, name]).
InputPin(id, inputType, responseType [, name]).

The information model can be translated into different more concrete representations, eg. an XML Schema.

Informatin Model Syntax

The syntax of the above information model is based on EBNF. However the notion of attributes has been added to non-terminals:

Nonterminal(attribute0, attribute1, ...) ::= ... .

This seemed more natural to distinguish between nested data (e.g. Part in Namespace in Definition) and "attached data" (e.g. the name of a Part). This

Board(name) ::= 
    [ Definitions ]
    Wires .

should be more readable than that

Board ::= 
    [ Definitions ]
    Wires .

Last edited May 12, 2010 at 12:13 PM by ralfw, version 10


No comments yet.