Methods, Resources, and Input and Output specification

The following is a description of methods and the information concerning methods

Note

A method is represented by a clip board, which symbolises the instruction sheet describing what to do.

../../../_images/method_4x3.png

Method icon

Method

video

Introduction

A Method is a way to define how to generate the data for a model. It is versionable, and can have formal and informal documentation associated with it in the form of Documents. These documents could be e.g. step-by-step instruction sheets, or a more informal best practise guide.

The intended usage type of the Method is declared with the MethodUsageType enumeration. The values of the enumeration are stored externally to the Business Object Model, but suggestions are: Generation, Checking and Visualization.

A Method can define the resources it needs, such as software, skills or Templates (for more information see SysML - Method and Resources).

It can also define the Inputs it needs to generate particular Outputs (for more information see SysML - Method IO Definition).

Once a Method has been defined, it can then be used in particular instances. Here the the Inputs and Outputs are declared with data flow objects. (for more information see Methods DataFlow)

Surrogate Methods

Some methods can be used instead of other methods in particular circumstances. These are usually statistically based methods to approximate the original Method for a certain range of input data, and are therefore much faster to execute. To identify a method as a surrogate of another method, the relationship “isSurrogateOf” is used. To define the limitations on the use of such a Method, the see “Input restrictions or limitations” below.

Resources for Methods

Resources can be defined for a Method using the “MethodResourceAssignment” class. This point to the Method and to the element which is the resource for the Method. Because this is a definition, and needs version management the Inputs must also be version managed and so cannot be instances. The resources can be:

  • Tool (or Software which is a specialisation of Tool)
  • ModelType (i.e. a template to use with the Method)
  • TypeOfPerson (i.e. what sort of person can execute the Method)

The resources can be named for the Method by adding a name to the MethodResourceAssignment.

../../../_images/method_with_resources.png

Method with resources

SysML Documentation

For more information see SysML - Method and Resources

Tools and Software

Note

A Tool is represented by a spanner.

../../../_images/tool_4x3.png

Tool icon

Software is represented by a Compact Disc

../../../_images/software_4x3.png

Software icon

Tools can be assigned as resources to a Method. Tools, like methods, are versionable, and can have formal and informal documentation associated with it in the form of Documents. Tools could be physical tools such as spanners, electrical multi-meters, or strain gauges. However for the BDA, they are most likely to be software tools. Therefore a class called Software has been included as a specialisation of Tool. The software class has some additional pieces of information to define how to call the software if it is to be automatically executable. These include:

  • Invocation path
  • Invocation Method
  • Hosting environments with IP Addresses, CPU, Operating System etc.

For more details on these, see the SysML Documentation: SysML - Method and Resources

Templates

Some methods include template resources. A typical example would be a Method to compute values using an Microsoft Excel spreadsheet which contains formulae. Here the spreadsheet is the template that is identified as a resource for the method. In this example it is likely that the resultant data (resultDocuments) for the ModelInstance is a copy of that spreadsheet with the input cell values populated.

Another example could be a Method that uses CATIA User Defined Features (UDF) to build up a geometrical model. Here the CATPart(s) which contain the UDF(s) is the template.

These template resources are defined as ModelTypes, where the actual template is associated to the ModelType as formal documentation Documents. The Documents are versionable and identifiable so they can be given names to identify them as the template data files.

Required skills

It may also be necessary to identify the skills needed by the person who is to execute the Method. For example someone with FE skills is needed to run a method using FE software, but a person with CAD skills is needed to run a method using CAD software.

TypeOfPerson is used as the resource, and a TypeOfPerson can have a name, a description, and zero to many skills.

A skill itself can also have a name and a description. As well as in SysML - Method and Resources, more information can be found at SysML - Organizations Actors Skills Diagram

Representation using Business Object Model classes

A diagram showing the resources for a Method. It includes:

  • The Software to use for the Method. This software is in a particular organisation, and also identifies the the invocation method and the hosting platform.
  • A ModelType to use as a template in the Method. This is a named resource called “excel template”.
  • The type of person, and hence the skills needed to be able to run the Method
../../../_images/vse_simple_deflection_method_resources.png

Named resources for a method

Note

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

Input and Output specification

Inputs

The Inputs to a Method are identified using the “MethodInputAssignment” class. This points to the Method and to the element which is the input for the Method. Because this is a definition, and needs version management the Inputs must be “types” not instances.

The types of element can be:

  • KeyValueType
  • ModelType
  • AccessibleModelTypeConstituent
  • QualityGateType

These types define what the Method is expecting as the Inputs. The actual inputs can be types that “inheritFrom” these types. For example a simple Mass computation Method has a Solid as one of its Inputs. When it is used the actual input could be a WingSolid, a PylonSolid etc.

Normally the Inputs would be distinguishable from their type, but some methods may input two of the same base type, but handle them differently. Therefore the inputs to a Method need to be named so that the Method can distinguish between the them when it is not apparent which is which from their type.

This is achieved by making the MethodInputAssignment “identifiable” (i.e. specialisation of IdentifableObjec), so that it can have a “name” property. Because it is identifiable it can also have descriptions.

Input assignments can have property values. A Boolean property can be used to indicate if the input is optional

Illustrative Example of named inputs

The following is a simple, contrived example to explain why all the pieces of information are necessary.

Some methods are relatively generic, and can take Inputs of a base type (e.g. a curve).

In this example, a Method to make a lofted surface, takes in two curves, the profile and the guide curves.

../../../_images/cookiecuttermethoddefinition.png

Lofted Surface Method definition

The Method if the first curve is used as the profile, and the second the guide, one surface is obtained. When they are reversed, a completely different surface is obtained. Therefore they need to be named to inform the method which is the profile and which is the guide.

../../../_images/cookiecuttermethoduse.png

Lofted Surface Method usage

Description using a Visual Basic programming analogy

This analogy uses the same “lofted surface” example as described in the illustrative example above. In software programming a function or programme declares what the Inputs are. The image below shows a fragment of Visual Basic code showing a function called CreateLoftedSurface that has two inputs. The first of the inputs is called “profileCurve”. This is the equivalent of the name given to the MethodInputAssignment. The input has a type of “CurveMT”. This is the equivalent of the identified ModelType that the MethodInputAssignment.inputType relationship points to. The other input is handled similarly.

The output is also declared using “As LoftedSurfaceMT”. This is the equivalent of the ApplicableMethod.output pointing to a ModelType with the name LoftedSurfaceMT.:

Function CreateLoftedSurface(profileCurve As CurveMT, _
                                                        guideCurve As CurveMT, _
                                                        As LoftedSurfaceMT

'internals of the function

End Function

The following similar analogy uses the example from the Business Object Classes representation in the section below. The Method is named “Defln_formulaic_method” and has the following Inputs:

  • a ModelType - BilletProperties_csvMT named “E_csv”
  • a KeyValueType - BeamMassKVT named “M”
  • a KeyValueType - Beam2ndMmtAreaKVT named “I”
  • a KeyValueType - BeamLengthKVT named “L”

The output is a ModelType - Defn_workbook_MT:

Function Defln_formulaic_method(E_csv As BilletProperties_csvMT, _
                                                                M As BeamMassKVT, _
                                                                I As Beam2ndMmtAreaKVT, _
                                                                L As BeamLengthKVT) _
                                                                As Defn_workbook_MT

'internals of the function

End Function
../../../_images/vse_simple_deflection_method_io.png

Equivalent using Business Object Classes

Representation using Business Object Model classes

This shows the Method with the Inputs defined using MethodInputAssignment. It has four inputs, three of which are KeyvalueTypes and the fourth a ModelType. In the example they are given names on the assignment objects, though this is not strictly necessary because all of the inputs are different types, and as key values cannot inherit from other key values there is no possibility that these will be confused when the Method is used with instances.

../../../_images/vse_simple_deflection_method_inputs.png

Method inputs with names

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.

Optional Inputs

Input assignments can have property values. A Boolean property can be used to indicate if the input is optional

Alternative Inputs for different usage

Sometimes a single Method can be used in different ways. In one way it may need specific Inputs to generate a specific output, but in another way use alternative inputs to generate different Outputs. If this is the case, then instead of assigning the Inputs to the Method, they are assigned to ApplicableMethod. see Outputs below for more details on ApplicableMethod.

Representation using Business Object Model classes

This shows alternative Inputs for a Method to produce different Outputs. There is a single FE method and depending on the Inputs it can either produce a deflection result, or an internal stresses result.

Both usages have a common input of the mass, but have different meshes depending on whether it is to compute the deflection or the internal stresses.

../../../_images/vse_fe_deflection_method_io.png

Different sets of inputs for a method

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.

Outputs

The Outputs from a Method are identified using the “ApplicableMethod” class. This points to the method and to the element which the method can generate.

Note

It is called ApplicableMethod because originally it was a simple relationship called “applicableMethod”, that went FROM an element TO the method. I.e. the element “owned” the relationship.

However subsequently it was found that other information needed to be associated with the relationship, so it needed to be converted to a class. However it is still the intention that the element “owns” the relationship so the name was retained. The types of element can be:

  • ModelType
  • QualityGateType

The ModelType can have Properties, and AccessibleModelTypeConstituents, and as these are part of the ModelType definition, it is expected that the Method will be able to generate these at the same time.

Note

KeyValueTypes are not outputs to a method, because they are associated with the ModelType (extractedFrom). They are not properties of the model, but a conscious decision of which model they are extracted from in a specific scenario.

Representation using Business Object Model classes

This shows the Method being assigned as applicable to a Model Type.

../../../_images/vse_simple_deflection_method_output.png

Method output (method is ‘applicable’ for Model type)

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.

Input restrictions or limitations

A Method may have restrictions, or limitations on the Inputs. These can be defined by adding PropertyValues to the MethodInputAssignment objects. The properties can be numerical values, for example defining the acceptable range of input values. They can also be strings to describe the limitations. This information can be used to determine the “Domain of Validity” of a Method, or an ApplicableMethod.

../../../_images/vse_simple_deflection_method_domain_of_validity_ppt.png

Representation using Business Object Model classes

The Inputs and Outputs defined for a Method, with one of the Inputs having an lower limit restriction.

../../../_images/vse_simple_deflection_method_domain_of_validity.png

Limitations on inputs

Sensitivities for e.g. “change propagation” and “rework duration impact”

If it is known how a Method is sensitive to changes in the Inputs, this can be captured by attaching a sensitivity to the different MethodInputAssignments, and optionally also indicating which output is impacted.

The Sensitivity class can be classified to declare the type of the sensitivity, e.g. a sensitivity to duration of the Method, or a sensitivity to propagation of change. Each sensitivity can have PropertyValues to define the sensitivity value. These properties can be e.g. numerical for known values, or string enumerations if it is more an indication of sensitivity (e.g. None, Low, Normal, High, Extreme). Because the properties have a definition, the string enumerations can be agreed up front.

Representation using Business Object Model classes

This shows a single Method that can be used in two different ways to produced two Outputs. Both usages have a common input of the mass model, but changes to this have a “Normal” impact on the duration in one usage, and a “Low” impact in the other usage.

The diagram also shows a change propagation sensitivity, where the output has a different sensitivity to the changes in the two Inputs.

../../../_images/vse_fe_deflection_method_sensitivity.png

Duration and Propagation sensitivities on inputs and outputs

The above example is rather contrived because there is only one output at a time to the methods. However some methods have more than one output, and then it is possible to identify the impact of each input on each output. The diagram below shows the different impact of a change in one input (the other Inputs are hidden for clarity) on four Outputs.

../../../_images/ucam_ex_sensitivities.png

An example with multiple ouputs

SysML Documentation

For more information see SysML - Method IO Definition

Section author: Judith Crockford