[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Core Component Analysis - SWIFT's Comments
Jacques, Nigel et al First let me start by thanking Jacques for his excellent paper. It has one or two minor errors, the most critical of which is the claim that dependencies are not allowed for in the metamodel (see 1.3). They are, but they are not recorded in the entity use area but in the Context related parts of the model. (They are there because they are modifiers of the datatyping rules and models.) Now let me come on to a point Nigel made: > Our core component dictionary can then concentrate on defining and > agreeing semantic meaning for common business data e.g. Transaction > Effective Date - it is important that we have an agreed understanding of the > meaning for this data. It is important that we realise that there are two types of "core components": abstract core components and context-specific core components. There needs to be an AbstractDateTime component that forms the basis for all dates. This should form the basis for specific applications of dates, such as the TransactionEffectiveDate required by Finance and Insusrance applications. In other words, TransactionEffectiveDate is a synonym for AbstractDateTime that applies to a named st of "domains". The same goes for AbstractParty, which has synonyms such as Buyer, Seller, Client and Insurer. It is important that we clearly identify when a context-specific core component is really a synonym for an abstract core component. It is also important that we record the constraints that apply to the use of an abstract core component within a particular context. For example, there may be a constraint that times may not be recorded as part fo the TransactionEffectiveDate, even though they form part of the definition of the AbstractDateTime. It was for this reason that the complete data capture forms allowed for the assigning of both "local names" and constraints when applying an abstract core component within another core component. Unfortunately the switch to spreadsheets has "lost" this functionality. We still need to develop a language for describing model constraints. Unfortunately this work is running behind schedule. But the analysis team must work on the presumtion that a suitable technique will be defined by the end of the Vancouver meeting. Martin
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC