Study Management and Associative Model Networks ############################################### This page describes the information surrounding studies, and how it can be structured to suit different management needs .. note:: A study is represented by a magnifying glass, which symbolises that something is being investigated. .. figure:: /objects/images/study_4x3.png :scale: 100% Study icon ================ Study Definition ================ A collaborative study is package of work that is launched by a Programme to drive the evolution and maturity of something. A study can be for many reasons e.g. * evolving the design * managing change * perofrming trade-off analysis * investigating sensitivity of a solution to |uncertainty| * performing |optimisation| * developing new methods and tools * combining results from other studies into a single baseline For more information see SysML - Study Diagram ================ Study Management ================ There are three main ways a study manages work. It can: * manage one or more "Associative Model Networks" * manage one or more other studies, though circularities are not permitted * manage both associative Model Networks and Studies .. figure:: /objects/images/study_inputs_amn.png :scale: 100% Study Management options When a study manages other studies, it means that the managing study has delegated the management and control of the some or all of the work to those studies. This can be used to build up a work breakdown structure ofr the Programme. A study can start from a blank sheet, or it can input a network from a previous study. This network can either be an Associative Model Network (see |AssociativeModelNetwork| for more details), or a Baseline as illustrated below. Study inputs Baseline or Associative Model Network A study will have a view of the models in the Associative Model Network that it is managing. A study may also be able to see the networks that are managed by studies that are providing its inputs, and be able to see the studies that need its own models are their inputs. Whether it can see these details will depend on the permissions agreed between the organisations owning the different studies, networks and models. =========================== Study Management Delegation =========================== If a study manages other studies, assuming the permissions allow, it could see the combined networks of the managed studies, and how they are using the elements of each others networks, and the elements of the overall input networks. The below image has the input baseline on the bottom left, with only the used elements visible. It shows where these elements are being used by the networks that are managed by the lower level studies, and also how they also use elements from each other. .. figure:: /objects/images/study_combined_cmts.png :scale: 100% View of the combined network .. note:: The network views are a simplification, and do not show all the elements needed to define an Associative Model Network An example including all the elements is shown at the end of this page. Illustrations of visibility of studies that are limited by permissions are shown below. It is assumed that the individual studies can see which studies are managing their input models, and which studies need the models that they have been tasked to provide. But the cannot see any other details that those studies are managing, nor other sibling studies. .. figure:: /objects/images/study_engine_view.png :scale: 100% View from the Engine .. figure:: /objects/images/study_nacelle_view.png :scale: 100% View from the Nacelle When a higher level study delegates an area to a lower level study, the controller of that lower level study may decide to expand on the network, adding elements that are only visible to themselves. These elements may represent detailed steps between the original elements which are only of interest to the local level. However it is still important that the traceability between the elements is maintained. This is achieve by allowing elements to have more than one identifier, and those identifiers are in the context of an organisation. .. figure:: /objects/images/nested_networks_with_additional_nodes.png :scale: 100% Global vs local networks and traceability =================================================== Study Management with Collaborative Model Templates =================================================== A Collaborative Model Template is a way to capture an Associative Model Network in a version managed template. When a study is first envisaged, it is possible to indicate which Collaborative Model Template(s) are to be used by saying that a Study "deploys" Collaborative Model Template(s). When the Associative Model Network is built for a study, these templates can be used singularly or in combination to create the network. It would also be possible to use an Associative Model Network as an input to a study, and indicate that this should be extended by the using a template. The image below shows single templates deployed by the different studies that are managed by a higher level study. It can be seen that the Model Types are duplicated in the different templates. This set of templates is designed so that only one template generates each Model Type and the duplicates are in fact inputs to the other templates. Therefore when they are used to create the networks as shown above, the duplicate Model Instances are not created and instead the instances from the other networks are referenced. .. figure:: /objects/images/study_hierarchy_cmts.png :scale: 100% Studies deploying Collaborative Model Templates .. note:: The network views are a simplification, and do not show all the elements needed to define an Collaborative Model Template An example including all the elements is shown at the end of this page. This scenario may not always be the case, and some combinations of templates could have different options for generating the same Model Type. Which option to use is not captured in the definition of the study. The choice could depend on decisions on delegation, methods, maturity or limitations, scheduling or planning etc. Template boundaries could be an indication of a suitable structure for delegation. This would be the case when the templates are owned, built and managed by different departments, companies or organisations. Those organisations would have the skills and tools needed to execute the models in the templates so indicating a suitable delegation structure. This is the case for the example above. ====================================== Concepts to be investigated in a study ====================================== Concept Definition - Concepts identify what is to be varied, added, investigated, recommended or decided by the study (e.g. shape, layout, technology standard, design concept, loading philosophy etc) Concepts can be specific values (e.g. "Try thickness of joint area = 200mm"), or specific models (e.g. "Investigate this DMU"). Or they can be textual descriptions such as "Thicken the joint area" or "Investigate alternative materials". When the concepts are specific values of models, they are intended to be part of the product definition, so these are in fact Key Values or Model Instances that are identified as the concepts for the study, and included in the Associative Model Network that is managed by the study. When the concepts are textual descriptions, they are not part of the product definition, so not included in the managed Associative Model Network. Instead they should be "implemented" by an element of the managed Associative Model Network. This type of concept can have associated supporting documents if needed, e.g. the technology standard, or graphs. ====================== Objectives for a study ====================== Study Objective Definition - The Objectives for a study are identified in terms of requirements to be met, targets to be achieved, simulation accuracy to be achieved (e.g. prove certification requirement XYZ is met, reduce weight by 10%, achieve thermal simulation results that are within 5% of test data) Study Objectives can be actual requirements, or they can be textual descriptions of what is expected. Requirements have definition text, and can also have associated documents to complement the definition. A study objective can have all the characteristics of a requirement, but is not expected to have been through any formal requirements management process. Once an Associative Model Network has been created for a study, elements (model instances or key values) in that network can be identified as something that should either satisfy the objective itself (e.g. an Engine Model Instance that must satisfy a thrust requirement) or be evidence of satisfying the requirement (e.g. Engine trust analysis model instance). See |Requirements and Verification| for more details It may also be that new requirements are identified as a result of work carried out in the course of a study. In this case the study can be identified as the source of a requirement ===================== Studies and Baselines ===================== The purpose of a study may be to integrate the work from several other studies into a single consistent set of models. This may mean doing some rework to bring all the models up to use the same release (i.e. ensuring they all use the instances). At the end of such a study it is possible to save a baseline. .. figure:: /objects/images/study_creates_baseline.png :scale: 100% Study creates Baseline .. rst-class:: expand ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Worked example using Business Object Model Classes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =========================================== Example using Business Object Model classes =========================================== The scenario is illustrated below. .. figure:: /objects/images/VSE_scenario.png :scale: 100% Very Simple Example The aim is to compute the deflection of a beam. The key features are: * Geometrical shape (planar surface) * Hollow beam, defined by Thickness * Beam length * Billet chosen from catalogue of fixed sizes * Machining time derived from differences in volumes of beam and billet * Material provides density property ofr Mass * Billet properties provide Young's Modulus E (impacted by billet roll direction etc) * Deflection of cantilever under evenly distributed weight of beam * Range derived from inner area (I.e. fuel volume) For more details see: Introduction to the |Very Simple Example| The scenario has two studies. The first study investigates a length concept, with the objective of achieving less than a particular deflection. The second study builds on the first study, investigating a new thickness concept with the aim of achieving the same objective as the first study, but this time using an alternative deflection analysis method. The use of this alternative method makes it sensible to delegate part of the network to a different controller, though in this example a separate study has not been set up. .. figure:: /objects/images/vse_ea_2x_study.png :scale: 100% Two studies ================================== Enterprise Architect Documentation ================================== For more information see |SysML - Study Diagram| .. sectionauthor:: |Judith Crockford| .. include:: /objects/documents/main/Keywords.rst