Page-7 [Back][Next] up.gif (995 bytes)

Models need to be structured. Besides just being broken into types, collaborations, refinements, you also need to allow teams to work on different parts, permit different views of some common objects, do configuration management and version control on structured units, and track dependencies across the structure.

A Package is such a structuring device. In a package you can introduce new Model Elements; you can also import another package, giving you visibility to its model elements; if you are not quite content with the imported ones, you can define additional properties on them within your package. A combination of what you introduce locally, import from elsewhere, and extend on top of imported things, defines the sum total of what is visible in your package (and hence, to someone who imports it).

The contents of a package include bits that are not formalized; narrative descriptions are part of a package, structured documentation is also part of a package, including diagrams of the model elements.

When you imports, you can use the source package as a template by substituting some of your elements for it. This facility is used to define frameworks.

Model elements include the familiar things: type, action, etc.; but can also include fancier things like code, incremental patches to code, test specs, test cases, test data.