Transcript SC32 FBM Study Group Report

ISO/IEC JTC1/SC32/WG2 N1801
SC32 FBM Study Group Report
Korea SC32 Meetings,
May 2013
Baba Piprani - Serge Valera
1
Agenda
1. Background & Study GroupTaskings
2. Setting the Stage – positioning modelling
methodologies
3. 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 Findings
5. Recommendation
2
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
3
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
4
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.
5
Mapping data modelling methodologies to different technologies
6
Mapping data modelling methodologies to different
technologies
• 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
7
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
8
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”
9
What are System Requirements?
An example from the European
Cooperation for Space Standardization
ECSS-E-ST-70-41C
10
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 subservice.
Requirement 2: Each parameter monitoring subservice shall belong to exactly one on-board
monitoring service.
11
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.
12
ECSS-E-ST-70-41C Use case
• 3 additional requirements:
Requirement 3: Each on-board monitoring service
may include exactly one functional monitoring subservice.
Requirement 4: Each functional monitoring subservice 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.
13
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.
14
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.
15
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.
16
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
17
ECSS requirement for registration
• Entity type:
on-board monitoring service
parameter monitoring subservice
functional monitoring subservice
requirements 1&2
requirement 3&4
requirement 5
• Relationship:
• Relationship end:
Relationship
requirements 1&2
relationship end : entity_role
on-board monitoring service
parameter monitoring subservice
min cardinality max cardinality
1
1
1
1
requirements 3&4
on-board monitoring service
functional monitoring subservice
0
1
1
1
requirement 5
functional monitoring subservice
0
1
18
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
19
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.
20
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
21
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.
22