Difference between revisions of "Framework Realisation Pattern"
(→Architecture Framework Context View) |
m (→Framework Organisation Pattern) |
||
| (3 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
| − | = | + | =Framework Realisation Pattern= |
| − | This Pattern has been proposed by J Gladstone. | + | This Pattern has been proposed by J Gladstone. It has been augmented following some initial comments from S Perry and J Towers. |
==Architecture Framework Context View== | ==Architecture Framework Context View== | ||
| − | [[File: | + | [[File:Architecture_Framework_View_showing_Framework_Realisation_Aims.jpg | 960px]] |
| − | The main aim of the | + | The main aim of the Framework Realisation Pattern is to explain how to realise viewpoints within a Framework. For example, given a specific ontology element, how does one know how this element should be represented within the model itself? |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | The following use cases have been identified | |
| + | ===Realise Viewpoint=== | ||
| + | ====Goal==== | ||
| + | To provide the Systems Engineer with enough information to realise a viewpoint defined in the architecture framework. | ||
| + | ====Brief Description==== | ||
| + | The viewpoint describes which languages, diagram, symbols and tools should/could be used to create a view. i.e. Given an «ontology» element of "Component" viewpoints are defined that specify that this should be realised as a SysML Block on a SysML Diagram for one viewpoint , and a "Line Item" in a "BOM" in a PLM tool” | ||
| − | Model | + | ===Define Model Structure=== |
| + | ====Goal==== | ||
| + | To describe the expected model structure clearly and allow all Systems Engineers to add content to it in a consistent manner. | ||
| + | ====Brief Description==== | ||
| + | The expected organisational (package) structure of the model is defined. Systems engineers can view this expected structure and use it to decide where to place new model elements. A model reviewer can see the expected structure of the model and check that it corresponds to what was defined. | ||
| + | |||
| + | This use case may be constrained by the requirements to realise a particular viewpoint. | ||
| + | |||
| + | ===Present Model Structure=== | ||
| + | ====Goal==== | ||
| + | To present the current structure of the model to a Model Reviewer, to allow them to understand its organisation. | ||
| + | ====Brief Description==== | ||
| + | As the model develops and content is added, the Systems Engineer updates structural summary. Any model reviewers can use this top level picture to understand the parts that have been populated. | ||
| + | |||
| + | ===Support Model Navigation=== | ||
| + | ====Goal==== | ||
| + | To allow a Model Reviewer to locate information in different parts of the model, even if they have not been responsible for creating the content. | ||
| + | ====Brief Description==== | ||
| + | The model reviewer is provided with a navigable map of the model which allows them to locate related pieces of information quickly - without needing to know specifically what related elements exist. | ||
| + | |||
| + | This use case may be constrained/enhanced by modelling tool capabilities. | ||
| + | |||
| + | ===Accommodate Modelling Tool Strengths and Limitations=== | ||
| + | ====Goal==== | ||
| + | To ensure the limitations of the modelling tool are taken into consideration | ||
| + | ====Brief Description==== | ||
| + | The specific limitations and/or strengths of the modelling tool are identified to ensure that it is possible to create the views and model structure as defined by the framework. This may affect the ability of Systems Engineers to realise particular viewpoints and could hinder (or enhance) model navigation. | ||
| + | |||
| + | ===Comply with modelling language constraints=== | ||
| + | ====Goal==== | ||
| + | To observe the rules and constraints introduced by a modelling language | ||
| + | ====Brief Description==== | ||
| + | The rules governing the usage of model elements, their relationships with others and the structuring within the model are respected. This ensures that any model reviewers familiar with the modelling language will be able to understand the meaning based on their own knowledge of the standard. | ||
==Ontology Definition View== | ==Ontology Definition View== | ||
Latest revision as of 08:21, 22 September 2017
[edit] Framework Realisation Pattern
This Pattern has been proposed by J Gladstone. It has been augmented following some initial comments from S Perry and J Towers.
[edit] Architecture Framework Context View
The main aim of the Framework Realisation Pattern is to explain how to realise viewpoints within a Framework. For example, given a specific ontology element, how does one know how this element should be represented within the model itself?
The following use cases have been identified
[edit] Realise Viewpoint
[edit] Goal
To provide the Systems Engineer with enough information to realise a viewpoint defined in the architecture framework.
[edit] Brief Description
The viewpoint describes which languages, diagram, symbols and tools should/could be used to create a view. i.e. Given an «ontology» element of "Component" viewpoints are defined that specify that this should be realised as a SysML Block on a SysML Diagram for one viewpoint , and a "Line Item" in a "BOM" in a PLM tool”
[edit] Define Model Structure
[edit] Goal
To describe the expected model structure clearly and allow all Systems Engineers to add content to it in a consistent manner.
[edit] Brief Description
The expected organisational (package) structure of the model is defined. Systems engineers can view this expected structure and use it to decide where to place new model elements. A model reviewer can see the expected structure of the model and check that it corresponds to what was defined.
This use case may be constrained by the requirements to realise a particular viewpoint.
[edit] Present Model Structure
[edit] Goal
To present the current structure of the model to a Model Reviewer, to allow them to understand its organisation.
[edit] Brief Description
As the model develops and content is added, the Systems Engineer updates structural summary. Any model reviewers can use this top level picture to understand the parts that have been populated.
[edit]
[edit] Goal
To allow a Model Reviewer to locate information in different parts of the model, even if they have not been responsible for creating the content.
[edit] Brief Description
The model reviewer is provided with a navigable map of the model which allows them to locate related pieces of information quickly - without needing to know specifically what related elements exist.
This use case may be constrained/enhanced by modelling tool capabilities.
[edit] Accommodate Modelling Tool Strengths and Limitations
[edit] Goal
To ensure the limitations of the modelling tool are taken into consideration
[edit] Brief Description
The specific limitations and/or strengths of the modelling tool are identified to ensure that it is possible to create the views and model structure as defined by the framework. This may affect the ability of Systems Engineers to realise particular viewpoints and could hinder (or enhance) model navigation.
[edit] Comply with modelling language constraints
[edit] Goal
To observe the rules and constraints introduced by a modelling language
[edit] Brief Description
The rules governing the usage of model elements, their relationships with others and the structuring within the model are respected. This ensures that any model reviewers familiar with the modelling language will be able to understand the meaning based on their own knowledge of the standard.
[edit] Ontology Definition View
To be defined
[edit] View Relationship View
To be defined
[edit] View Context Views
To be defined
[edit] View Definition Views
To be defined
[edit] Rule Definition
To be defined
