# Blueprint MBSE Repository Populator

This package transforms human readable text files describing an Executable UML model of a system into
a populated metamodel database. With your models loaded into this database it is now possible to produce
a variety of useful artifacts to support model execution and verification, code generation and anything else
that performs detailed analyis on the model components and their relationships.

The text files are expressed in an easy to read markdown format so you can browse through the classes, relationships,
states and transitions, actions and all other model components.

Here we support the Shlaer-Mellor variant of Executable UML exclusively.

## Command usage

`% modeldb -s elevator-case-study`

Assuming your system is named 'elevator-case-study' and is in the current working directory with the internal structure defined below, will output a file named `mmdb_elevator-case-study.ral`. This *.ral file is a text file serialization of a TclRAL database.

Your user model is loaded into the Shlaer-Mellor Metamodel and, if there are no errors, you know you have a Shlaer-Mellor Executable Model that doesn't break any of the rules defined by the metamodel.

You can load and view it using TclRAL or PyRAL or feed it to other downstream Blueprint tools such as the
Model Executor which among its tasks will generate a user model database.


## Input to the populator

Each system is defined in a single package broken down into standard hierarchy of folders like so:

    system
        domain
            subsystem
                class-model
                    classmodel.xcm
                types.yaml
                methods
                    m1.mtd
                    m2.mtd
                    ...
                state-machines
                    s1.xsm
                    ...
                external
                    EE
                        op1.op
                        ...
            subsystem2
            ...
        domain2
        ...
   
Here is a partial layout for The Elevator Case Study as an example:


    elevator-case-study // system
        elevator-management // application domain
            elevator // All defined in one subsystem
                class-model
                    elevator.xcm // the class model
                methods // methods for all classes in subsystem
                    cabin // methods on 'cabin' class
                        ping.mtd // the ping method
                        ...
                    ...
                state-machines // lifecycles and assigners for this subsystem
                    cabin.xsm // lifecycles named by class, assigners by association
                    transfer.xsm
                    R53.xsm // assigner state machine on association R53
                    ...
                external // external entities, each a proxy for some class
                    CABIN // proxy for 'cabin' class
                        arrived-at-floor.op // two ee operations
                        goto-floor.op
            types.yaml // data types for all subsystems in domain
        transport // two more domains (not broken down yet)
        signal io

Each modeled domain has its own folder. Above we just see one for the Elevator Managment domain.

Each domain requires at least one subsystem folder. Here we see only one and that is the Elevator domain.

Within a subsystem folder there is a class-model subfolder with one class model expressed as an .xcm (executable class model) file.

The following folders are optional:

* external – external entities and their operations, one subfolder per external entity
* methods – class methods each in a folder matching the class name with each method in a separate .mtd file
* state-machines – each state machine, assigner or lifecycle, in its own .xsm (executable state machine) file

Also within a domain you have a types.yaml file which specifies each domain specific type (Pressure, Speed, etc) and selects
a corresponding system (database) type. This is a stop gap measure as we have not yet provided a more robust typing
domain, so, for now we settle with what our database has to offer (int, string, float, etc). Unltimately, though,
a full featured typing facility will support a variety of types and operations on those types as well as a type
definition system. Note that the typing facility can be, but need not necessarily be a modeled domain.