Introduction to the Business Object Model ######################################### The Business Object Model is a model of objects, properties, relationships and operations that represent business entities. The Business Object Model is the middle layer of the BDA Architecture, with the Business Concept layer above and the Data Model layer below. Introduction to the most commonly used objects ********************************************** ===== Study ===== .. figure:: /objects/images/study_4x3.png :scale: 100% Study icon 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, performing 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. A Study has: * Concepts to be investigated. * These can be models that are to be investigated, documents that describe the new concepts like Technology Standards, or Material Specifications etc. * Objectives to be met. * These can be a description of what is to be achieved, or references to requirements. * Inputs to start from. * These are existing results from earlier studies that are to be evolved during the course of this Study. Or they can be methodology objects to use as templates (see below). * Roles of people and organisations. * This allows the work in a Study to be assigned or delegated to other people, teams or organisations * The package of work to be controlled and managed * This is an Associative Model Network (see below) the defines the models to be created and their associativity .. figure:: /objects/images/intro_study.png :scale: 100% Study package of work The relationships are flexible allowing for many alternative |Study Management| configurations, including nesting studies and management of multiple, interconnected Associative Model Networks. =============================== Associative Model Network [AMN] =============================== .. figure:: /objects/images/AMN_4x3.png :scale: 100% AMN icon An AMN is a container that identifies the elements that together comprise a set of "results" for a Study. It includes the audit-trail of what is to be done, and what has been done, i.e. the associativity. Each element in the AMN has an understanding of its dependencies (what it is derived from), and so it makes up a network of associative models. These together allow the record of "who", "what", "where", "when", "how" and "why". The template version of the AMN is a Collaborative Model Template [CMT]; see Methodology Objects below for more details .. rst-class:: expand ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Associative Model Network vs. Workflow ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The work package is represented with an Associative Model network rather than a Workflow becuase it uses a |model based| approach with the following advantages: * The process elements do not have to be specified. Sometimes these are not known (e.g. for new development, or for a process that is informal or not automated), and only the model dependency needs to be recorded. * The information for a model dependency is "owned" by the model, (i.e. the relationships are from the model to the inputs, not from the inputs to the model). This means the owner of the model is in control of its dependencies. * There can be a choice of process elements, and these can be switched without disrupting the network view. * The resultant network is a set of product information with dependency audit trail which can directly be used for archiving The information surrounding the elements in an AMN implies a process flow, so a workflow could be extracted or visualised from the information. The information from the managing Study is linked to the Associative Model Network as follows: * Concepts to be investigated. * These are linked to the models and key values, for example it could be a new material specification that is to be investigated for its thermal behaviour in an existing design. * Objectives to be met. * These are linked to models, key values or methods to indicate what is to satisfy the requirement and what the evidence of satisfaction is. * Inputs to start from. * New models can be derived from these inputs, or the inputs could be models that are to be further evolved (i.e. new versions created). * Roles of people and organisations. * There are many different roles that can be assigned depending on the model, e.g. who is to manage, who is to execute, who wants to watch, who is to approve, who is to authorise release, etc. .. figure:: /objects/images/intro_amn.png :scale: 100% Associative Model Network content ============== Model Instance ============== .. figure:: /objects/images/MI_4x3.png :scale: 100% MI icon A Model Instance is the object that identifies specific content (numerical data, behavioural data, geometrical data etc) for the product. A model instance has a lifecycle, starting as a entity to plan the work to be done and concluding when the completed models are associated to the model instance using documents. It can be at any level of granularity, for example: * a single parameter value level * a 1-D line/curve/vector level * a 2-D/3-D matrix/surface/diagram/solid * a composite set of multi-dimensional data A Model Instance belongs to an Associative Model Network (AMN). It is derived from other model instances and key value instances (note these do not have to belong to the same AMN). It can also identify the model instance from which it is evolved. This evolution is similar to versioning, but allows an evolution tree to be constructed rather than just an evolution line as is implied by versioning. .. figure:: /objects/images/intro_evolutionTree.png :scale: 100% Model Instance Evolution Tree ================== Key Value Instance ================== A key value instances are significant values that need to be exposed in an Associative Model Network, e.g. for display on dashboards, or for monitoring and control of the network. Because it is not fixed which models they are extracted from, it allows different studies to compute the same key value with different levels of fidelity, or maturity, For example a component "weight" value can be computed using an approximation model in the concept phase Study, and another instance of the same component weight can be computed in a detail design phase using a complex geometric model. As with Model Instances, the key values do not have versions, but can specify their evolution. .. figure:: /objects/images/KVI_4x3.png :scale: 100% KVI icon ============================================================================= Methodology Objects (Collaborative Model Template, Model Type, Key Value Type ============================================================================= Methodology objects can be thought of as templates or definitions. Unlike the instances, they have contextual versioning. The main objects are: * Collaborative Model Template * This can be thought of as a template for an Associative Model Network. It is the context for associativity between Model Types and Key Value Types. It can have documentation for explaining the intended use of the template. * CMTs can be composed of other CMTs. This is useful where templates from several disciplines, teams, or organisations are being combined into a bigger package. The disciplines/teams/organisations can retain control of their own templates, and then these can be consolidated into a combined template. .. figure:: /objects/images/CMT_4x3.png :scale: 100% CMT icon * Model Type * This is the definition for a Model Instance. It has documentation to allow a descriptions, and examples or templates for the instances to combine to form as detailed as needed definition of the model * A Model Type can inherit from another Model Type. This allows the reuse of definition information when a specialisation is been created (e.g. Mesh > Thermal Mesh > Wing Thermal Mesh) * A Model Type can belong to more than one Collaborative Model Template, and so can have different associativity in the different template contexts. .. figure:: /objects/images/MT_4x3.png :scale: 100% MT icon * Key Value Type * A Key value Type is the definition of a Key Value Instance. As with Model Types, it can have documentation, can belong to more than one CMT, and so have alternative associativity. .. figure:: /objects/images/KVT_4x3.png :scale: 100% KVT icon In the diagram below, there are two CMTs that contain the same Model Type that is derived in different ways, and has different Key Value Types extracted from it. I.e. a single Model Type's associativity is in the context of the different CMTs. .. figure:: /objects/images/intro_cmt.png :scale: 100% Methodology Objects The links between all the objects once set up are retained. So when a package of work is set up for a Study, then all the definitions supplied by the Types are available as specifications for what is expected to be delivered. .. figure:: /objects/images/intro_amn_cmt.png :scale: 100% Study with Associative Model Network and Methodology Objects ===================== Requirements and VV&A ===================== .. figure:: /objects/images/requirement_4x3.png :scale: 100% Requirement icon Requirements are usually managed in official requirements management packages such as DOORs by IBM. In these packages strict procedures and business processes are embedded according to the needs of the organisation, and regulatory requirements. It is not the intention to replace these systems, but instead to keep the requirements stored in the systems as the source data, and add additional information to these references, information such as models that satisfy them, studies that meet them etc. However in order to use the requirements in a collaborative environment, sufficient of the source information needs to be available for dissemination. Therefore the requirements have a textual definition, and optional associated documents and properties. Relationships (e.g. Contradiction, Tracing, and Decomposition) between requirements can also be defined There are two parts to the verification of requirements: * Identification of the item that the requirement should be satisfied by .. figure:: /objects/images/satisfiedBy_4x3.png :scale: 100% Requirement Should-Be-Satisfied-By icon * identification of the evidence that will show (or has shown) that it has satisfied the requirement .. figure:: /objects/images/verification_4x3.png :scale: 100% Requirement Verification icon In the planning phase these can be identified even though the work has not been done. So it is possible to declare up front how a requirement is to be verified, and so this information can be used in planning. The values of the verification "status" property indicate whether this is yet to be verified, and after verification whether it has passed of failed etc. Depending on the requirement, different types of object can be used to satisfy it. For example: * Requirement that all items in the equipment bay must not exceed a surface temperature of x degrees * Satisfied by: Components (or their representative model instances) in the equipment bay. * Supporting Verification Evidence: Thermal Analysis model instances for all components in the equipment bay * Requirement that virtual test data is within tolerance of actual test data. * Satisfied by: Method. * Supporting Verification Evidence: the comparison of the virtual to actual test data. This could be a ModelInstance or a KeyValueInstance of the tolerance which is extracted from the comparison ModelInstance .. figure:: /objects/images/intro_vva.png :scale: 100% Illustration of the above Requirement Verification examples ====================================== Combined view of commonly used objects ====================================== .. figure:: /objects/images/2page_intro.png :scale: 100% The most commonly used objects .. sectionauthor:: |Judith Crockford| .. include:: /objects/documents/main/Keywords.rst