Username:
Password:
Cradle has a modelling capability that is fully integrated with the requirements management and other facilities in the Cradle environment. This allows requirements to be traced into models to explore:
Each Cradle database provides two modelling domains, called:
Each of these domains contains any number of models that can be organised into one or more model hierarchies. Each model is a collection of related diagrams that is intended to achieve a particular purpose. The diagrams in a model can be of one or more notations (such as Process Flow Diagrams, Function Flow Block Diagrams or Use Case Diagrams).
Diagrams contain symbols. Each symbol has a definition, which contains a description of the symbol. These definitions are separate items in the database, either specifications or data definitions. Specifications are specific to a diagram, but data definitions are common to all the diagrams in a model. The data definitions are also called Data Dictionary entries ( DD entries for short) and are collectively called the Data Dictionary (DD).
This can be represented:
Cross references can be created within and between the models, and between the models and all other items in the database. This allows the models to form:
The Cradle modelling tools automatically create hierarchical cross references within a model, creating decompositions of:
and so on. This allows Hierarchy Diagrams (HIDs) to be viewed for any hierarchy, that show relationships to related requirements and other data for full lifecycle traceability:
Some symbols have a common definition, so they can be used many times in many models, where all instances have a single definition. Examples are the eFFBD shared function and the PAD shared equipment. This allows families of models, with opportunities for reuse.
In the example, two architectures show the same physical equipments, albeit connected in different topologies. To avoid defining the equipments twice, we create a model for each equipment that is referenced from each architecture. This reuse of the equipment models is achieved by using:
There are implicit links between all elements in each model, called pseudo cross references. The pseudo cross references automatically exist when a reference to one item is included within another. For data definitions, these references are the data definition’s name. For specifications and diagrams, these references are the number.
Drawing a symbol that references a data definition called A on a diagram creates a pseudo cross reference between A (an item in the database) and the diagram (another item in the database), and vice versa.
Other references to data definitions are in COMPOSITION attributes that define the internal structure of a data definition, the lower-level data definitions of which it is composed. So, the COMPOSITION of a data definition Employee might be:
@ID + Name + Address + Dept ID + Grade + Salary + 0 { Deduction }
to show that an Employee has a unique ID ( @ means primary key), a Name (+ means AND), a membership of a department, a grade and salary, and zero or more salary deductions (the { and } mean an iteration with fixed or variable lower and upper bounds).
Pseudo cross references are automatically created between Employee and its components ID, Name, Address, Dept ID, Grade. Salary and Deduction.
Specifications hold the definitions of all non-data symbols, including:
Symbols are linked to specifications by number. A specification is equivalent to a diagram or symbol (and vice versa) if their numbers are the same. The numbers of symbols are always that of the diagram, followed by .N:
Some diagram symbols can be decomposed into other diagrams:
Specification definitions may exist for some or all symbols in all diagrams:
So a model contains two hierarchies:
with pseudo cross reference links between:
This use of number is central to the structure of a model. It eliminates the need that would otherwise exist for the adjustment of (for example) function names to create unique names at multiple points in a particular model, or multiple models.
The diagram hierarchy is a graphical alternative to the specification hierarchy (the function, component, activity or use case hierarchy), for example:
The specification hierarchy is an equivalent, alternate, representation:
Both can be used in combination:
Equivalent items have the same number. A diagram has an equivalent specification, which is the specification with the same number as the diagram. A specification has an equivalent diagram, the diagram (of any type) with the same number as the specification.
Equivalent items are essentially alternatives for each other:
Back to the newsletter archive.
