PackageLayout

TransWarp's Package Layout

Modules/Packages which do not have a "Status" shown do not exist yet. Any modules or packages which exist in the software release but are not listed here should be considered experimental, transitional, and/or deprecated. All names are contained within the TW package.

• Aspects - The AOP microkernel

  Status: Robust and full featured, passes 109 excruciating unit tests

• Features - Standard and common FeatureDef classes and objects

  Status: Robust, but not many features yet. All current features are tested via the same unit test suite as for the TW.Aspects module.

• Recipes - Shortcuts to save typing when creating common mixes of aspects

  The idea behind this module is to avoid having to type things like: UML.Model.UML_Model + StructuralModel.Persistent.Persistent + XMI.Reading.XMIReading all the time when you want (for example) a persistent UML model with XMI reading capability. The module will contain functions which will import and add together various aspects for you, then return the result. Other Recipes modules will probably pop up in various places throughout TransWarp as time goes on.

• SOX - "Simple Objects from XML"

  A simple library for creating arbitrary Python object structures from XML using SAX.

  Status: only 4 unit tests, but heavy usage testing in previous incarnations of TransWarp

• StructuralModel - Interfaces and implementations for the ServicesElementsAndFeatures pattern. See StructuralModel? for details.

  Status: Under construction, do not enter without a hard hat... Mostly consists of fragments from a pre-AOP version of TransWarp.

  • InMemory - Implement an S/E/F framework in-memory
  • SetBased - Implement an in-memory S/E/F framework using sets (for increased querying speed)
  • Persistent - Implement an S/E/F framework using ZODB-compatible objects
  • Queries - Utility classes for search predicates and boolean logic

    Status: Mostly unchanged from a pre-AOP incarnation of TransWarp. Everything but the ModelQuerying aspect should hopefully still work...

• UML
  • MMX - "MetaModel eXchange"

    MMX is TransWarp's name for the simple XML format used by the NovoSoft UML Library (nsuml) to represent the UML meta-model. (The nsuml library does not explicitly name this format anything.) This TransWarp module reads an XMI-compatible metamodel from an MMX-format XML file and generates a StructuralAspect for it.

    Status: Effectively only "Smoke tested" at this stage, but based on code from a previous iteration that generated classes directly and worked well.

  • Model - The UML model as a StructuralAspect

    Status: Passes "smoke test", but can't actually be used until the rewrite of the StructuralModel? package is done.

  • Generators - Generate a StructuralAspect or other specialized output from a UML model
• XMI
  • Reading - Read a StructuralModel? from an XMI file

    Status: Broken, which is to say not yet rewritten from the library's pre-AOP incarnation.

  • Writing - Write a StructuralModel? to an XMI file
• Database
  • TWDDL - "TransWarp? Data Definition Language"

    TWDDL is a modelling construct for TransWarp's object-relational mapping pattern. It represents a physical rendering of an object model in terms of "data interfaces" for conversion into tables, views, stored procedures, permissions, and constraints. It is not a textual language, but rather a Service-Element-Feature model, designed for direct creation in Python code (primarily from UML models). TWDDL models can also contain "pragmas", possibly derived from "tagged values" in a UML model.

  • DIDDL - "Database-Independent Data Definition Language"

    DIDDL is an intermediate representation between TWDDL and actual DDL. It represents tables, views, stored procedures, constraints, and so on without any syntactical dependencies. Like TWDDL, DIDDL is an object model, not a textual language, intended for direct manipulation in Python. It is structured so that database-specific DDL can be generated through straightforward formatted output of a DIDDL model, but also to be reasonably close to TWDDL in concepts, so as to allow simple generation.

  • DDL - "Data Definition Language"

    This package contains modules or packages for DIDDL->DDL output for a variety of databases. Listed databases are ones we're most likely to tackle, but the actual order is likely to vary considerably depending on projects, and nothing is guaranteed.

    • Firebird
    • PostgreSQL
    • Oracle
    • Sybase
• UI - Reserved for user interface frameworks at a later date. Possible frameworks we may want to write would include HTML and wxPython.