Templates and Instances

Templates and Instances

This page describes how Methodology objects can be used as templates for Instance (or Programme) objects, and also how those same Methodology objects are the definition of the Programme objects.

The most commonly used Methodology objects are shown below with their corresponding Programme objects:

../../../_images/methodology_programme_icons.png

Icons for corresponding Methodology and Programme Objects

In general Methodology objects are versionable, and Programme objects are evolved. The versioning is a (context) string to allow for business rules to be imposed, and for the same object to have different versions in different contexts. For example, an object can be owned by an organisation, and have many versions internal to that organisation. When it is published to a collaboration environment, other organisations can assign their own version to the same object.

Methodology Libraries

A Methodology Library version is a collection of Methodology object versions that can be deployed to a Programme. In this way the Programme dictates the approved methodologies to use on the studies that are managed by the programme. Note: a Methodology object can belong to more than one Methodology Library, though business rules may add more restrictions. A library can be composed of other libraries, and this can be used to structure the libraries, and to assist in the management. However, again there are no restrictions or proposals on how to structure and manage the libraries, but business rules can be imposed if needed.

Representation using Business Object Model classes

The diagram showing the Methodology Library. It is very simple, having one library for the complete example.

../../../_images/vse_ea_MethodologyLibrary.png

Methodology Library of Very Simple Example in EA

This library is deployed to a programme

../../../_images/vse_ea_programme_lib_study.png

Programme that deploys a Methodology Library, and manages Studies

Use of Type definition for Instances

The Model Type and Key Value Type can be thought of as the (versioned) definition or specification of the expected/delivered content for Model Instances and Key Value Instances. The instances have one isAnInstanceOf relationship pointing to the Type version. Formal or Informal documentation is used to describe the definition. These can be any documents, so what ever is most appropriate to be able to specify the Type. For example, they could be an example file with a description of the compulsory content, or detailed specification documents, or a procedure to be followed to sign off the model.

Model Types also allow:

  • Multiple “inheritance”

    • This is so that a generic definition can be defined in one Model Type, and that built on by other definitions. E.g. a generic “Excel Workbook” model type is inherited by workbooks for computation of mass, deflection etc.

    • Property Definitions
      • These are definition for pieces of information about the model that are to be made available. Unlike Key Values, they are not significant to the overall Associative Model Network management and control. They are more likely to be quality properties e.g. numerical error.
    • Constituents
      • Model types can declare accessible constituents. Unlike properties, these do not have values, but are constituents of the model that are accessible. For example, in geometrical models these are usually known as Publications, for Excel spreadsheets these are named cells etc.
      • They are themselves versionable, and can have documentation.
      • The constituent is identified by a name. Tools can use this name to access the constituent inside the model.
    • Types of Approver and Authoriser
      • This is the declaration of the TypeOfPerson(s) who can approve or authorise the model type. This is an indication to the ModelInstance that the Actors who are approver(s) and authoriser(s) should be of this TypeOfPerson. Not this is not enforced by the Business Object Model, though could be a business rule.

Key Value Types include the units (e.g. m/s, kg), and the format of the value (e.g. string, double).

../../../_images/vse_MT_KVT_inheritance_and_doc.png

Documentation for the definition of Model Types and Key Value Types, including inheritance

Representation using Business Object Model classes

A diagram showing:

  • Model Type
    • has a name “2ndMmt_workbook
    • inheritsFrom a generic excel workbook model type
    • has formal documentation pointing to Document that describes the content
    • has a property definition for Numerical Error, with units of mm4 and type of Double
    • has a constituent of a published cell called H6
  • Key Value Type
    • has a name of BeamDefn
    • has formal documentation pointing to Document that describes how this is measured (e.g. parallel to the root attachment plane)
    • has units of mm
    • has type of Double
../../../_images/vse_type_as_definition.png

Model Type with inheritance, documentation, constituents and property definitions

Associativity between Types in context of library or template

The associativity between Model Types is specified by declaring for a given Model Type, which other Model Types or Key Value Types it is derived from. The relationship direction is from the “result” to the “inputs” because when defining a model type, people generally know what the required inputs are, they do not know who is going to use result, therefore the “owning” object is the from object, so the relationship is called isDerivedFrom. For example, the deflection for a beam is derived from the length, shape, material properties etc. the word “derived” is used, because in the early stages, it may not be known how to generate the model, but just known what impacts the model.

It is also not compulsory to have a method associated to the model, because the whole purpose of a study may be to develop a suitable method.

Methods are described in more detail under Method Definition and Methods DataFlow.

Key Value Types are extracted from model types. The word “extracted” is used specifically as it implies no further computation is needed.

../../../_images/vse_mt_derivedFrom.png

Model Type and Key Value Type associativity.

However, there can be more than one way to derive a model type, and key value types can be extracted from more than one model type. Therefore these relationships are in a context. Because some model types are always derived the same way, the simplest context is a Methodology Library.

Alternative associativity can be defined using a Collaborative Model Template [CMT].

../../../_images/cookie_cutter_cmts.png

Using CMTs to define different ways to derived the same model

Representation using Business Object Model classes

The diagram below shows a CMT to create the BeamDeflection KeyValueType using simple deflection models and methods.

../../../_images/vse_ea_xls_defln_cmt.png

BeamDefn using simple models and methods

The second template creates the same BeamDeflection KeyValueType, but this time using Finite element based model and methods.

../../../_images/vse_ea_fe_defln_cmt.png

BeamDefn using FE based models and methods

Note

There are classes between the instances and types rather than direct relationships. This is because the link between needs to be referenced when the data flows are identified, and it also needs to specify a name, therefore the link cannot be a simple relationship and must be a class.

Optimisation Templates

Another type of template is the Optimisation template (or D2XTemplate). This identifies the variables and constraints and their distribution, the objective(s) with their target and resolution, and also the constants and additional things to observe during the Optimisation.

It is also possible to define the Correlation between two variables, including how it was computed. This is explained in more detail in Optimisation and the SysML - D2XTemplate documentation