This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Requirements-CMETs"

From HL7Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by 2 users not shown)
Line 15: Line 15:
 
|
 
|
 
|-
 
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} Inheritance and aggregation
 
|}
 
|}
  
Line 32: Line 34:
 
|
 
|
 
|-
 
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} Inheritance and aggregation
 
|}
 
|}
  
Line 49: Line 53:
 
|
 
|
 
|-
 
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} Inheritance and aggregation
 
|}
 
|}
  
Line 66: Line 72:
 
|
 
|
 
|-
 
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Add stereotype and place CMETs into a package
 
|}
 
|}
  
Line 83: Line 91:
 
|
 
|
 
|-
 
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-Not Supported}} This appears to be a Methodology issue not modeling
 
|}
 
|}
  
Line 100: Line 110:
 
|
 
|
 
|-
 
|-
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-Not Supported}} Translations to other languages will require specific tool support
 +
 
|}
 
|}
  
Line 117: Line 131:
 
|
 
|
 
|-
 
|-
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Add stereotype and place CMETs into a package
 
|}
 
|}
  
Line 153: Line 170:
 
|}
 
|}
  
 
+
=Properties=
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  

Latest revision as of 16:34, 11 August 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
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"