This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Requirements-CMETs"
Jump to navigation
Jump to search
Line 44: | Line 44: | ||
| "Methodology" | | "Methodology" | ||
| HDF methodology, metadata | | HDF methodology, metadata | ||
+ | | | ||
+ | |- | ||
+ | | ''MIF'' | ||
+ | | | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | |||
+ | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
+ | | '''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'' | ||
+ | | | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | |||
+ | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
+ | | '''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. | ||
| | | | ||
|- | |- |
Revision as of 17:42, 17 February 2010
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 |