Username:
Password:
Please type the Two words with a space between them to prove you are a real human being.
The most significant enhancement in Cradle-5.7 is the introduction of model hierarchies. These allow arbitrarily large hierarchies of distinct models to exist in each domain. All modelling-related tools in Cradle-5.7 have been extended to support model hierarchies.
A model hierarchy is a hierarchy of models in a domain that can be used to show different:
A domain has one model hierarchy. The top of the model hierarchy is called ModelHierarchy and unlike the rest of the hierarchy, is not a model, but a placeholder. Every model hierarchy has a default model called Default. All model information (diagrams, specifications, data definitions) from a domain in previous Cradle versions are stored in the Default model.
Each domain in a Cradle database can have a model hierarchy with any number of models organised into a hierarchy with at most 16 model levels. Each model level is given a name, such as:
for a product-orientated 4-level hierarchy, or more generically:
Models are created as children of an existing member of the model hierarchy, provided that a model level already exists for the new model. When a project defines its first model, it is a child of ModelHierarchy and the model level All already exists, so the new model (and other models at the same level) can be created without difficulty. A child of this model cannot be created until the second model level (below All) has been created. A project using a hierarchy of models will almost certainly rename the top model level All to a name that is more descriptive. For example:
Cradle-5.7 allows you to create any number of models in a hierarchy in each of the Essential and Implementation domains.
Internally, Cradle uses Model Unique Identifiers (MUIDs) for each model, but the Cradle tool UIs (and import/export files) refer to a model by its namespace. A namespace identifies the location of a model in a model hierarchy as a . (dot or period) separated list of the models from the top of the hierarchy down to and including the model itself.
Some example namespaces from the above model hierarchy are:
When you define a model, you can specify which diagram notations will be provided in that model.
This means that if, for example, you want an operational model, then you could decide that the model can only contain PFDs (Process Flow Diagrams). Similarly, if you want a model dedicated to the use cases for a system, then you could define that the model can only contain UCDs (Use Case Diagrams) and perhaps also SQDs (Sequence Diagrams).
Limiting the notations that can be used in a model allows Cradle to simplify the UI that it presents to you for each model. For example, if a model can only contain UCDs, then Cradle UIs will allow you to select use case specifications, but not equipment, class, process or function specifications.
All Cradle tools, including WorkBench, Web Access UIs, the Toolset main screen and all model-specific tools (such as Consistency Checker, Graphics Reporter, Diagram Editor, Animator and so on) have been modified to allow the selection of models and to show namespaces.
You can copy information from one model to another, in the same domain or between domains. You can export information from one model and import it into another model in the same or between domains. You can create cross references between the contents of one model and the contents of another model, in the same or between domains.
You can create cross references from any non-model information (such as requirements and user-defined items - system notes) to elements (specifications and data definitions) in any model in the model hierarchy of either or both of the Essential and Implementation domains.
You can create cross references between data definitions in different models, either in the same domain or between domains. Data definitions in the same model continue to be linked by pseudo cross references as defined by the data compositions of the data definitions (held in the data definitions’ COMPOSITION frames).
Model hierarchies are defined in Project Setup in WorkBench:
From here you can setup model levels and the model hierarchy.
A model namespace is the position of a model in a model hierarchy. It is a dot separated concatenation of the model names (excluding the root, ModelHierarchy) from the top of the model hierarchy down to and including the model itself.
A model namespace is data entered by a user or recorded in the project’s schema or database, it is a value that Cradle generates when needed for display and reporting purposes. Model namespaces are unique, for although it will be possible to have two models with the same name (albeit with different MUIDs), such models cannot both be children of the same parent model in the model hierarchy.
If a model is moved in a model hierarchy, its MUID doesn’t change, but its model namespace will change, and its new model namespace will be seen the next time that it needs to be generated.
A model is an inter-related collection of diagrams and their symbol’s descriptions (as data definitions and specifications) that are collectively a description of a part of (or all of) the system under study and within which consistency checking and other analyses can occur.
A model can only exist as part of exactly one model hierarchy.
Each model is identified by a MUID, an integer automatically assigned by Cradle when the model is created. All user-defined MUIDs are unique. MUIDs are never reused in a project. A model must also have a name, which does not have to be unique in a model hierarchy, but which must be unique (ignoring any differences in case) in the set of model names for the children of a given parent model in the model hierarchy.
Generally, the browsing structure provided with model hierarchies is:
The model hierarchy is presented as one or more top-level models and their children, to whatever depth and size has been defined by the project, so the model hierarchy would be:
The expansion of a model will be:
Each model is a distinct collection of diagrams and supporting specification and data definition descriptions. The contents of each model are completely separate from the contents of all other models.
This means that there is no need for users to adopt numbering or naming conventions inside any model. Each model can use exactly the same numbering and naming conventions as any or all other models, and the diagrams and their descriptions in each model will still be distinct and separate.
By creating completely distinct models, the model hierarchy ensures that the data definitions are no longer common to all models in a domain. Data definitions are still common to all diagrams (of all notations) within a model, so that a symbol called Target Data in one diagram will still share the same data definition item description with another symbol also called Target Data in another diagram, but only if these diagrams are in the same model.
In general, this is also believed to be a beneficial outcome.
Data definitions within a model will continue to be linked by their own pseudo cross references, but the isolation of data definitions within a model will mean that new types of cross reference are now required so that data definitions in different models in the same domain can be linked, and to allow data definitions in models of different domains to be linked.
Previously, cross references could refer to model information (specifications or data definitions), but this information could only exist in one model (ignoring the multiple notional models that could be created by adopting numbering conventions). With model hierarchies, specifications and data definitions can be in multiple, distinct, models in each domain, and cross references need to be able to reference them.
It is very likely that specifications in one model will need to be cross referenced to specifications in another model in the same domain, as well as in different domains. This will be needed to reflect the evolution of one model into another through the application of a process, and also to support models created to contain common or shared functionality, operations or architecture components.
The overall effect is that the domain and namespace will be needed to identify both the from and to parts of cross references referring to specifications.
It is also likely that data definitions in one model will need to be linked to data definitions in another model, particularly between domains. Within a model, pseudo cross references will continue to be used.
This inclusion of the domain and namespace in the from and to parts of cross references will be sufficient to represent both existing and new types of data definition-related cross references.
There are various changes to the UI to reflect model hierarchies by the addition of model and namespace. These are shown throughout the documentation set but as there are so many changes, they are not documented here.
Back to the newsletter archive.
