Fragmented Data Model support in RTC
Does Rational currently support or have guidance on using RTC in an environment using a Fragmented Data Model Approach.
Fragmented data models are commonly used in Model Driven Development projects for both purposes of simplification and isolation of features/functionality. For example, Team A's data model is defined as 23 individual fragments that aggregate to a single composite model. Each of the 23 fragmented models has between 3-15 data types which aggregate to the composite/complete model which has 200+ data types.
Fragmented data models allow related components to be delivered in isolation (based upon their specific model) without having to understand the details of the components they interface with. As such, fragmented data models are a good way to enforce encapulation and isolation of the classes that you implement.
Fragmented data models are commonly used in Model Driven Development projects for both purposes of simplification and isolation of features/functionality. For example, Team A's data model is defined as 23 individual fragments that aggregate to a single composite model. Each of the 23 fragmented models has between 3-15 data types which aggregate to the composite/complete model which has 200+ data types.
Fragmented data models allow related components to be delivered in isolation (based upon their specific model) without having to understand the details of the components they interface with. As such, fragmented data models are a good way to enforce encapulation and isolation of the classes that you implement.
3 answers
Note that the the level of support depends on whether you want a
versionable object (branch/merge support) or just an auditable object
(linear history).
For versionable objects, although we experimented with composite objects
in the requirements incubator, that functionality did not become part of
the current versionable released features (which focus on files). I'll
let the SCM team comment on whether there is an underlying composite
object support available in the current system (I'm guessing not, beyond
the "folder" mechanism used to implement file system directories).
For auditable objects, you have the ability to define richly structured
objects (for example, the work item objects in RTC and the requirement
documents in RRC).
Cheers,
Geoff
shelbyph wrote:
versionable object (branch/merge support) or just an auditable object
(linear history).
For versionable objects, although we experimented with composite objects
in the requirements incubator, that functionality did not become part of
the current versionable released features (which focus on files). I'll
let the SCM team comment on whether there is an underlying composite
object support available in the current system (I'm guessing not, beyond
the "folder" mechanism used to implement file system directories).
For auditable objects, you have the ability to define richly structured
objects (for example, the work item objects in RTC and the requirement
documents in RRC).
Cheers,
Geoff
shelbyph wrote:
Does Rational currently support or have guidance on using RTC in an
environment using a Fragmented Data Model Approach.
Fragmented data models are commonly used in Model Driven Development
projects for both purposes of simplification and isolation of
features/functionality. For example, Team A's data model is defined
as 23 individual fragments that aggregate to a single composite
model. Each of the 23 fragmented models has between 3-15 data types
which aggregate to the composite/complete model which has 200+ data
types.
Fragmented data models allow related components to be delivered in
isolation (based upon their specific model) without having to
understand the details of the components they interface with. As
such, fragmented data models are a good way to enforce encapulation
and isolation of the classes that you implement.
I think the original question was not about composite items but rather about how various RTC components can define their own data models. Assuming I understand the question, currenly all the RTC components (SCM, Work Items, Reports, Build...) have their own data models defined using Ecore. The models are defined in separate files and the Foundation component dynamically discovers these data models which are contributed using plugins.
The individual data models can have dependecies between them though we try to avoid those.
The individual data models can have dependecies between them though we try to avoid those.