End-to-end modeling and implementation checklist
This page summarizes the stages of the model→xml process.
Deploy the tools
Identify scope and context
- Define the use-cases that your application schema will support.
Don't be too ambitious, don't attempt to model the universe - other communities have a greater claim on some elements than you, and may have already done those bits! Your use-cases should guide the scope of the information model.
Different parts of the model will usually be subject to different governance and maintenance regimes. These should be organized into different packages.
Packaging must take account of various considerations:
- stability - Some parts will be very stable, while others will be expected to be updated more frequently.
- For example, it is common for controlled concepts (vocabularies) to be updated more frequently than data-structures (schema).
- delegation - Some parts are locally governed, while others are under the control of a third-party, and will be adopted into the model.
- external dependencies must be managed carefully, and take account of the update cycle of the maintenance organization.
In some cases model elements belong in a package that is logically under the governance of another organization, but that organization has not (yet) assumed responsibility, or does not provide a convenient interface. In such a circumstance a proxy for the external package may be necessary, but you should be careful not to entangle the local model with the external package. The goal should be to be that replacing the local proxy with the authoritative package not require any other refactoring of your model.
Dependencies between model elements imply dependencies between their packages, which controls the maintenance cycle.
Mutual dependencies between packages under different governance arrangements should be avoided.
Design your model
Identify basic classes
- The main focus should be on the feature types in the application schema
In broad terms, these scope the packets of information that will be transferred between systems. They will often correspond to concrete 'real-world' feature types, but may not.
- Formalize the classes in UML - see ModelingUsingHollowWorld#Formalize_the_model
- apply the correct stereotype - see UmlGmlStereotypesAndTaggedValues
- Specify the relationships and attributes - paying particular attention to
- navigability and role-names
- only the association ends marked 'navigable' are encoded in the XML transfer format
- navigable associations are 'owned' by the source class, and you can't add outbound associations to a class you don't own
- an association end must have a role-name to be encoded - this follows from the GmlImplementation pattern
- associations typed as composition have a special encoding
- each association type must be a class in the model
- including any owned by the HollowWorld template and any other imported packages
- arrange the classes into packages where
- the high level packaging respects the governance arrangements
- sub-packaging can be used for convenience, particularly for thematic sorting
Details of the use of HollowWorld
in Enterprise Architect are given in ModelingUsingHollowWorld
Formal descriptions of the modelling patterns and restrictions are given in ModelingCheckList
Although we are using an o-o formalization, the goal is a static transfer encoding
, so we do not usually consider class operations.
- Enter scope notes for each
- navigable association end
- record other rules and logic using constraints (either informally or using OCL invariants)
- while these are not currently encoded, they are an important part of model documentation, and should be expressed as formally as possible
Both scope notes and constraints will be reported in the model documentation generated by FullMoon
Model harmonization and dependencies
- ensure that your model makes use of standard components and external classes wherever possible - see HollowWorld#Standard_classes
- formalize the model dependencies
Prepare for encoding
Set all required tagged values
- tags on packages are required to provide XML Namespace and document information required for encoding
- tags on attributes and associations are required
- to make the ordering of property elements in content models consistent between phases of schema generation
- to enforce inline or byReference encoding of properties - see GmlImplementation#Implementation_of_properties
- tags on classes control their encoding style, also dependant on class stereotype
Run through modeling checklist
to check the model is conformant.
Export the application schema
See Exporting the model
Process the model
- test that the model is conformant
- You modify your model until the conformance tests report no errors. You may choose to ignore some WARNINGS if you understand what they mean.
- generate a GML-conformant XML Schema implementation
- generate HTML documentation for your model