Working examples of the interface described below can be found in this iPython notebook (and the underlying github repository).
Overview of Enterprise Architect database schema
The SysArch database underlying Enterprise Architect stores all of its data in a series of several dozen tables. Every datum entered into Enterprise Architect (i.e. every requirement on the telescope, every modeled piece of hardware, and every relationship between two requirements or pieces of hardware) is stored as a row in these tables. Each table stores a specific aspect of its rows, for example:
The table t_object stores the basic information ('Name', 'Version', 'Author') about each row, as well as any parent-child relationships between rows. If the requirement 'g-InBandLimits' refines the requirement 'g-band Response Envelope', then 'g-band Response Envelope' will be listed as the 'parent' of 'g-InBandLimits'.
The table t_objectproperties stores the properties associated with each row. Properties are effectively adjectives describing the rows in the table. Examples of what Enterprise Architect (or, at least, our use of Enterprise Architect) considers to be properties are: 'LSSTRequirements', 'isEncapsulated', 'isConjugated', and 'direction'.
The table t_attribute contains all of the quantitative values associated with its rows.
The table t_connector stores the descriptors defining the types of relationships connecting parents to children in t_object.
In order to completely describe any datum in the database, one must find it in each of these tables. Fortunately, each datum as a unique Object_ID associated with it. These Object_IDs are associated with the same data in all of the database tables. Thus, once you find an object's Object_ID in t_object, you can query for that same Object_ID in the other tables to find all of the quantitative values and inter-object relationships associated with it.
Advantages of using CatSim classes for access
CatSim defines a class DBObject which is, essentially, a thin wrapper of functionality provided by sqlalchemy for connecting to SQL databases. Once connected to a database, DBObject provides methods that allow a user to list the tables provided by the database, list the columns in each of those tables, and execute arbitrary SQL queries on any of those tables, returning structured numpy arrays of the results. This may be advantageous in that it provides users with means to interactively explore the somewhat convoluted schema of the database underlying Enterprise Architect.
Specific CatSim classes written to access the Enterprise Architect database
The github repository referred to above provides a module EADBWrapper.py which defines classes specifically designed to interface with the SysArch database underlying Enterprise Architect.
The first class defined in EADBWrapper.py is called SysMLObject. This class is designed to scrape the SysArch database for all of the attributes and properties associated with a specified Object_ID.
The class SysMLObjectList stores a list of SysMLObjects and then scrapes the t_connector table for the relationships between them.
Finally, the class EADBWrapper provides a connection to the database and then uses the functionality provided by SysMLObject and SysMLObjectList to write "family trees" – lists of SysMLObjects connected to each other by t_connector connections – starting from an object specified by the user.
In principle, we ought be able to use this functionality to recreate the relational flow charts which illustrate the connections between various requirements on our system.
Additionally, the script recreate_optics_files.py illustrates how we might use the SysMLObject class to recreate the system specification files expected by PhoSim.
Difficulties in querying SysArch
As demonstrated in this iPython notebook, there are some difficulties navigating the SysArch database as it is currently constructed. They are:
- Clarity of naming conventions – t_object contains 4 rows with the name "M1 Prescription" and 2 rows with the name "m1Prescription". It is unclear from t_object what the difference is between these rows. This makes it difficult for users to find the information they need without knowing the associated Object_ID in advance. There are also spelling errors in the object names. I believe "m3Presciption" occurs at least once in t_object.
- Incompleteness of data – while recreate_optics_files.py can recreate most of the configuration information required by PhoSim, it does not appear to contain information on the distances between optical elements in the telescope.
- Version control – our best understanding is that Enterprise Architect manages versions of projects by maintaining an SVN repository containing versions of the SysArch database. To work with a different version of the design, a user mush checkout that version from the repository, replacing the entire SysArch database in the process. This makes it impossible for multiple users to work with multiple versions of the design simultaneously.