Class Diagrams

The following sections present Class Diagrams for Model Composition Classes (core classes), built-in Variable Classes, Factory Classes, and Server Classes.

Model Composition Classes

The figure Class Diagram of Core Classes shows the classes that are the building blocks of a model. A model is a hierarchical structure with an Assembly at its root. Within the Assembly is some number of Components, and at least one Driver which is a special type of Component that iterates over a Workflow until some condition is met. A Workflow controls the execution order of the components that it references. The components have attributes that can be linked to attributes on other components. An Assembly is a Component, which means that it can be contained within another Assembly. This allows for the creation of hierarchical models with many levels of nested Assemblies. Workflows can contain Drivers. This allows for many levels of nested iteration within the same Assembly.


Class Diagram of Core Classes

Classes for Validation and Conversion of Component Attributes

Validation and conversion of Component attributes is done using the Traits package. You can define your own custom traits by inheriting from TraitType and overriding the validate() function. Traits also has built-in support for creation of graphical editors for each trait. The documentation claims that traits uses something called pyface to provide a sort of generalized UI layer that can be tied to various GUI libraries on the back end, but it’s not clear at this point whether this functionality will work in the context of a web GUI.

In the class diagram below, classes that are part of the enthought.traits package are gray, and our custom traits are white. Notice that there are two Float classes. One is Enthought’s and one is our version, which includes units and range checking.


Class Diagram of Built-in Traits

Factory Classes

It is important to give location transparency to the process of object creation, and using Factory classes lets users do that in an extensible way. The creation of an object with a specific type and version will be requested, and the framework will create the object. This creation process could involve spawning a remote process, instantiating a remote version of the object, and creating a local proxy to represent the remote object, or it could be a simple import and a constructor call. To the caller, it makes no difference. The call returns a local Python object, and the true location of the object requested doesn’t matter.


Class Diagram of Factory Classes

Server Classes

Simulations are run in one or more ObjServer processes, possibly distributed among multiple hosts. ObjServerFactory creates ObjServer processes either dynamically when the user starts a new simulation via the ServerManager (which acts as a portal), when a particular component type is needed that is not supported in the main simulation server, or by the user from the command line.

The base Server class provides a common mechanism for configuring network protocols and services, while the Simulation class contains the top-level component and the ResourceAllocationManager for this simulation object.


Class Diagram of Server Classes

OpenMDAO Home

Table Of Contents

Previous topic

Key Concepts

Next topic

Important Processes

This Page