Requirements-CMETs

Requirement	Model fragments that can be used by other model fragments (static models) are required. Expresses a common, useful, reuseable concepts expressed small model pieces (chunks)
Rationale	Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology"	HDF methodology, metadata
MIF
OMG Mapping	Inheritance and aggregation

Requirement	Message type fragment that can be used by other message type fragments (static models). Expresses a common, useful, reuseable concepts expressed small model pieces (chunks)
Rationale	Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology"	HDF methodology, metadata
MIF
OMG Mapping	Inheritance and aggregation

Requirement	May be referenced by both producing and other committees
Rationale	Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology"	HDF methodology, metadata
MIF
OMG Mapping	Inheritance and aggregation

Requirement	A registry of CMETs should be accessible by static model designers
Rationale	Promotes Re-use by providing a list of available CMETs to use, from a common library.
"Methodology"	Metadata. Is an interface specification that is bound to a static mode
MIF
OMG Mapping	Add stereotype and place CMETs into a package

Requirement	Provides robust binding to models both statically and dynamically (design or runtime). This must provide both early and late binding to model, including late binding to default/most recent model. Ability to choose between multiple class types in final message type is deferred until runtime
Rationale	Provides encapsulation, some degree of polymorphism, model independence.
"Methodology"	Metadata.
MIF
OMG Mapping	This appears to be a Methodology issue not modeling

Requirement	Ability of content of chunks to change without update/affecting referencing model. supports localization. provides abstractions. Allows model to be built with abstractions (literally).
Rationale	Users need to be able to develop sections of models that conform to local and realm-specific uses and regulations. Larger domain models can be constructed independently. Design of model components isolated - encapsulation
"Methodology"	metadata, use of interfaces and stubs.
MIF
OMG Mapping	Translations to other languages will require specific tool support

Requirement	Is available in local scope. Is available to multiple NE releases and models.
Rationale	Users need to be able to choose from available off-the-shelf components
"Methodology"	Interface file: realm-name-id, Binding by name, not identity. interface files that relate model to release, Indirection resolved by publishing process
MIF
OMG Mapping	Add stereotype and place CMETs into a package

Requirement	Derived from a single DMIM. Content is direct subset of class clones and attributes defined in that DMIM - does not span DMIMs
Rationale	Has model derivation using identical process to any static model. Keeps both users and modelers happy.
"Methodology"	HDF, metadata
MIF

Requirement	Has Semantic categories: attribution (level of property constraint), generalization (subsumption). Are derived by iterative refinement of a domain model
Rationale	Has model derivation using identical process to any static model. Keeps both users and modelers happy.
"Methodology"	metadata
MIF

Properties

Requirement	Always at least one variant (univeral)
Rationale	Equivalent to an unconstrained RMIM
"Methodology"	metadata
MIF

Requirement	Should be used to carry reference information only
Rationale	Guidelines for use
"Methodology"	publications
MIF

Requirement	Model fragments that can be used by other model fragments (static models) are required. Expresses a common, useful, reuseable concepts expressed small model pieces (chunks)
Rationale	Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology"	HDF methodology, metadata
MIF

Requirement	Message type fragment that can be used by other message type fragments (static models). Expresses a common, useful, reuseable concepts expressed small model pieces (chunks)
Rationale	Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology"	HDF methodology, metadata
MIF

Requirement	May be referenced by both producing and other committees
Rationale	Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology"	HDF methodology, metadata
MIF

Requirement	A registry of CMETs should be accessible by static model designers
Rationale	Promotes Re-use by providing a list of available CMETs to use, from a common library.
"Methodology"	Metadata. Is an interface specification that is bound to a static mode
MIF

Requirement	Provides robust binding to models both statically and dynamically (design or runtime). This must provide both early and late binding to model, including late binding to default/most recent model. Ability to choose between multiple class types in final message type is deferred until runtime
Rationale	Provides encapsulation, some degree of polymorphism, model independence.
"Methodology"	Metadata.
MIF

Requirement	Ability of content of chunks to change without update/affecting referencing model. supports localization. provides abstractions. Allows model to be built with abstractions (literally).
Rationale	Users need to be able to develop sections of models that conform to local and realm-specific uses and regulations. Larger domain models can be constructed independently. Design of model components isolated - encapsulation
"Methodology"	metadata, use of interfaces and stubs.
MIF

Requirement	Is available in local scope. Is available to multiple NE releases and models.
Rationale	Users need to be able to choose from available off-the-shelf components
"Methodology"	Interface file: realm-name-id, Binding by name, not identity. interface files that relate model to release, Indirection resolved by publishing process
MIF

Requirement	Derived from a single DMIM. Content is direct subset of class clones and attributes defined in that DMIM - does not span DMIMs
Rationale	Has model derivation using identical process to any static model. Keeps both users and modelers happy.
"Methodology"	HDF, metadata
MIF

Requirement	Has Semantic categories: attribution (level of property constraint), generalization (subsumption). Are derived by iterative refinement of a domain model
Rationale	Has model derivation using identical process to any static model. Keeps both users and modelers happy.
"Methodology"	metadata
MIF

Requirement	Should be used to identify the focal class that is the target of a trigger event.
Rationale	Guidelines for use
"Methodology"	publications
MIF

Requirement	Should not carry update values.
Rationale	Guidelines for use
"Methodology"	publications
MIF

Requirement	Should not be used to simplify a diagram/model
Rationale	Guidelines for use
"Methodology"	publications
MIF

Requirement	Cannot be individually constrained.
Rationale	Guidelines for use
"Methodology"	publications
"Note"	This is a deficiency.

Requirement	Behaves as a macro substitution..
Rationale	Guidelines for use
"Methodology"	metadata, publications
"MIF"