Professional data modeler.

            Metadata server.

                        Data dictionary.




    Logical Architecture

          ( Please scroll down. )

The following graphical image is a logical representation of the system architecture. It is not intended to convey a representation of the internal architecture of CoreModel nor does it adequately illustrate the functional aspects or external interfaces. It is intended only to present a logical internal image to assist the new operator in navigating through the system.

Dark blue defines the primary movement through the system and illustrates the fact that each module is independent of the others and that all module entry and exit is entirely via the main module. Light blue illustrates relationships to the autonomous servers in the system. Yellow indicates data flow. This data flow depiction is approximate. There are many instances of special cases where the data flow may be slightly different from that indicated.

The modules also have numerous utilities and tools, but they are not illustrated for the sake of simplicity. Those utilities and tools communicate through the system in patterns which do not necessarily follow those that are shown.

The main module, which includes the opening system screen, can be thought of as the foundation for the system, but other than that, it has little functionality. Sitting on top of the main module, there are five primary modules in the system which are accessed from the main module, each of which can be opened only when the others are closed.

Four of the modules are actualizations of the algorithmic constructs of four heirarchical abstraction levels of the modeling effort. From the top downward, they are conceptual, logical, physical, and implementation. It is in those four modules that the modeler does his work. The modeler can step each model abstraction down to the next level, as his work progresses. So much of a modeler's work takes place at the intellectual conceptual level that CoreModel is strictly architected to maintain strong conceptual images at all times. However, the architecture does not enforce itself and allows the modeler freedom to move about in the theoretical realm. To insure the ability to clean up discovered problems, each level allows the modeler to perform the functions of all the previous levels and he is even allowed to address his model at incorrect abstraction levels if he consciously decides to do so.

Sitting to the side of the four modeling modules is a fifth module which belongs to the system administrator. The administration module provides a means of supporting the many complex needs of the modeler so that he can devote his thought to creative modeling.

Within the CoreModel system, there are a number of sub-systems which are each designed to perform specialized tasks. Architecturally, those sub-systems are not necessarily identified entirely within any module; some are entwined throughout the larger structure of CoreModel, and some even protrude from the main body to affect a world-wide presence for a CoreModel installation. Unlike the module structure, it is not entirely necessary to be aware of sub-systems to operate CoreModel effectively and they can usually be thought of simply as utilities which are local to each module.

This web site was created with and is maintained with
Notepad and FTP from the DOS prompt.

Copyright 1999 - 2006 John Ragan.
CoreReader, CoreModel, and AxleBase are registered trademarks.