SC32 FBM Study Group Report

1. ISO/IEC JTC1/SC32/WG2 N1801 SC32 FBM Study Group Report Korea SC32 Meetings, May 2013 Baba Piprani - Serge Valera

2. Agenda • Background & Study GroupTaskings • Setting the Stage – positioning modelling methodologies • Work Examples • Use Case1 – ECSS (European Cooperation for Space Standardization) Requirement Specification capture • (Use Case2 19763-12 UML model in FBM) • Use case Findings • 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. Mapping data modelling methodologies to different technologies • A conceptual data model specifies the semantics of the data relevant to a domainin 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 UMLas classes and properties. • A logical data model can be developed from a conceptual data model

8. Mapping data modelling methodologies to different technologies • 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: • Eachon-board monitoring service includes exactly oneparameter monitoring subservice. • Eachparameter monitoring subservice belongs to exactly oneon-board monitoring service.

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: • Eachon-board monitoring service includes at most onefunctional monitoring subservice. • Eachfunctional monitoring subservice belongs to exactly oneon-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: • In each population ofon-board monitoring service includes a functional monitoring sub-service, eachon-board monitoring serviceoccurs at most once. • For eachon-board monitoring service, thaton-board monitoring service includes a functional monitoring sub-service if and only if thaton-board monitoring service includes somefunctional monitoring subservice.

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. ECSS requirement for registration • 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. ECSS requirement for registration • Entity type: • Relationship: • Relationship end:

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 47Propositions • 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 • 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. • 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. • Investigation of OWL and RDF suitability in Part 12 was not conducted at this time. • 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.