History for PackageLayout

??changed:
-
!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":http://nsuml.sourceforge.net/ (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.