Username:
Password:
Cradle is more than a requirements management tool. Cradle integrates a rich and powerful modelling capability with requirements, risk, issue, and test management. Cradle has a set of powerful and flexible modelling tools based on the concept of model hierarchies. These allow arbitrarily large hierarchies of models to exist in each domain in a Cradle database:
A model hierarchy is a hierarchy of models in a domain that can be used to show different:
Each domain can have any number of model hierarchies. All model hierarchies are linked to a single top-level placeholder called ModelHierarchy that is hidden inside Cradle. So, you can create any number of top-level models, and you can create any number of sub-models below each of them to create any number of model hierarchies that are large as you need them to be.
Each domain has a default model called Default. All model information (diagrams, data definitions and specifications) that are not explicitly created inside one of your models will be held in the Default model. The Default model also means that you can start to work with Cradle models immediately, without any need to first define a model hierarchy.
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. So this means that you can have any number of models in a domain, and any number of model hierarchies in a domain and any number of models in a model hierarchy, but these hierarchies of models can be at most 16 levels deep.
Each of the 16 model levels is given a name, such as:
for a product-orientated 4-level hierarchy, or more generically:
You don’t need to name all 16 levels. You only need to give names to the levels that you will use. So if you will only create hierarchies of models that are 3 levels deep, then you only need to give names to the first 3 model levels.
Please note that the number of model levels has nothing to do with the number of levels of diagram inside a model. A model can contain any number of diagrams and these diagrams can be in hierarchies of any depth, 10 levels, 20 levels or more. The limit of 16 only applies to the number of levels of models, not the diagrams inside each of the models.
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:
Internally, Cradle uses Model Unique Identifiers (MUIDs) for each model. Each model is identified by a MUID, an integer automatically assigned by Cradle when the model is first 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.
The Cradle tool UIs (and import/export files) refer to a model by its namespace which is 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:
Default
Battlespace
Battlespace.Air.UAV
A model namespace is entered by a user or 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 namespace will change, and its new 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.
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 will allow you to select use case specifications, but not equipment, class, process or function specifications.
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).
If a model is moved within a model hierarchy, or is moved between model hierarchies, the cross references from and to the items in the model are not broken because the cross references use the MUID to identify the model, not its name or namespace.
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.
Back to the newsletter archive.
