SC32 FBM Study Group Report

1

SC32 FBM Study Group Report

Korea SC32 Meetings,May 2013

Baba Piprani - Serge Valera

ISO/IEC JTC1/SC32/WG2 N1801

2

Agenda

1. Background & Study GroupTaskings2. Setting the Stage – positioning modelling

methodologies3. Work Examples

a. Use Case1 – ECSS (European Cooperation for Space Standardization) Requirement Specification capture

b. (Use Case2 19763-12 UML model in FBM)

4. Use case Findings5. Recommendation

3

Background

Canada proposal SC32/WG2 N1577– Objective: Meta model for information models

using Fact Based Modelling– Canada submitted initial FBM WD in Greece Sep

2011 (SC32 WG2 N1612) using FBM notation

2011/09 : Greece decision:– FBM notation not accepted, produce UML notation

for registry– Canada submitted revised FBM WD in Berlin June

2012 (SC32 WG2 N1640) using UML notation

4

Background

2012/06 : Berlin decision– Canada proposal for a new 19763 part for FBM

model registrations is presented. – WG 2 question whether 19763 part 12 can be

used to register FBM models (ORM, CogNIAM, DOGMA, FCO-IM, NIAM)?

– Study group is formed to address that issue including other types of models, i.e. OWL and RDF.

report expected for SC32 Korea May 2013

5

Study report

• An assessment has been done on how to use part 12 for FBM.

• The conclusion is that this is possible, once an FBM model has been transformed into a Entity/Relationship model following the process of transforming the FBM conceptual model into a logical E/R model as shown in next slide.

6

Mapping data modelling methodologies to different technologies

7


• A conceptual data model specifies the semantics of the data relevant to a domain in some form of a formal modelling notation (e.g. Fact Based Modelling, SBVR, Predicate Logic etc.)

• A logical data model is expressed in terms of a particular data modelling methodology, for example attribute based modelling like ER as entities and attributes, or UML as classes and properties.

• A logical data model can be developed from a conceptual data model

8


• A physical data model is developed from a logical data model and is used to define the implementation details for storing the data objects on a computer, e.g. SQL

• Each transform between modelling methodologies needs to preserve the originally declared semantics

9

Part 12 can be used however

• Transforming a FBM model into a E/R (logical) model requires a process regimen:– adding technology specifics (i.e. E/R technology)

and rendering difficult the transformation toward other technologies (e.g. relational, hierarchical, realtime)

– incurring loss of semantics: using Part 12, the focus is put on entities and attributes while FBM’s focus is on “system requirements specifications”

10

What are System Requirements?

An example from the European Cooperation for Space Standardization

ECSS-E-ST-70-41C

11

ECSS-E-ST-70-41C Use case

• 2 requirements related to the “parameter monitoring service” specification specified in natural language:Requirement 1: Each on-board monitoring service shall include exactly one parameter monitoring sub-service.Requirement 2: Each parameter monitoring sub-service shall belong to exactly one on-board monitoring service.

12

ECSS-E-ST-70-41C use case• Using FBM graphical notation, these 2 requirements are

represented by the following diagram:

• Using FBM controlled natural language, these 2 requirements are represented as follows:1.Each on-board monitoring service includes exactly one

parameter monitoring subservice.2.Each parameter monitoring subservice belongs to

exactly one on-board monitoring service.

on-board monitoring serviceparameter monitoring subservice

includes / belongs to

13

ECSS-E-ST-70-41C Use case

• 3 additional requirements:Requirement 3: Each on-board monitoring service may include exactly one functional monitoring sub-service.Requirement 4: Each functional monitoring sub-service shall belong to exactly one on-board monitoring service.Requirement 5: Whether the on-board monitoring service includes a functional monitoring sub-service shall be declared when specifying that service.

14

ECSS-E-ST-70-41C use case• Using FBM graphical notation, requirements 3 and 4 are

represented by the following diagram:

• Using FBM controlled natural language, these 2 requirements are represented as follows:1.Each on-board monitoring service includes at most one

functional monitoring subservice.2.Each functional monitoring subservice belongs to

exactly one on-board monitoring service.

15

ECSS-E-ST-70-41C use case• Using FBM graphical notation, requirement 5 is represented by

the following diagram:

• Using FBM controlled natural language, requirement 5 reads:1.In each population of on-board monitoring service

includes a functional monitoring sub-service, each on-board monitoring service occurs at most once.

2.For each on-board monitoring service, that on-board monitoring service includes a functional monitoring sub-service if and only if that on-board monitoring service includes some functional monitoring subservice.

on-board monitoring servicefunctional monitoring subservice

includes / belongs to

includes a functional monitoring sub-service

16

ECSS requirement for registration

Only specify the WHAT, i.e. no implementation specific.

Findings:– Transformation to logical models is inadequate for

ECSS based on above constraint. – Let’s try to directly (i.e. without transformation)

model the ECSS requirements to 19763 Part 12.

17


• expectation and discovery out of the registration is not entities and attributes but stated ‘requirements’

• so the capability of FBM to model fact type readings is THE minimum and mandatory requirement for FBM discovery

• without that discovery requirement, there is no reason to perform any registration and subsequent discovery search

18


• Entity type:

• Relationship:• Relationship end:

on-board monitoring serviceparameter monitoring subservicefunctional monitoring subservice

requirements 1&2requirement 3&4requirement 5

Relationship relationship end : entity_role min cardinality max cardinalityrequirements 1&2 on-board monitoring service 1 1

parameter monitoring subservice 1 1

requirements 3&4 on-board monitoring service 0 1functional monitoring subservice 1 1

requirement 5 functional monitoring subservice 0 1

19

ECSS use case problems

• Modelling fact types using part 12 relationships is inadequate:– we can model some characteristics of binary fact

types, but we loose e.g. the capability to verbalise the fact type (the verbs, …)

– we cannot model unary fact types– we cannot model n-ary fact types

20

Conclusion from ECSS use case

• The fact type is THE key element of fact based modelling.

• If we cannot properly model a fact type using Part 12, using Part 12 for FBM is a NO-GO.

• If FBM models are to be registered using a 19763 approach, they require a separate 19763 part.

21

Similar Conclusion from TR9007

• TR9007 Concepts and Terminology for a Conceptual Schema and Information Base

• Use Case: Car Garage contains 47 Propositions• Appendixes contain how each Modelling approach models

these propositions + checklist• Appendix D – Entity Attribute Relationship Approaches:

Checklist shows 22 out of 47 propositions cannot be modelled in this method

• Appendix E – Binary Relationship Approach (FBM): shows 8 out of 47 propositions cannot be modelled in this method

22

Recommendation

1. If SC32 WG2 wants to include FBM registration in 19763 MFI, then there is a requirement for a new part as per use case proof demonstrating loss of semantics.

2. It is not recommended that 19763 Part 12 be used to register any FBM models due to loss of semantics, and inability to return to the user the lost semantics, during discovery.

3. Investigation of OWL and RDF suitability in Part 12 was not conducted at this time.

4. The work of the SC32 FBM study group is completed as they have completed their findings of whether 19763-12 is suitable to register FBM models.

Documents

SC32 FBM Study Group Report