Modeling LID--The classes and associations of the model

From LID Wiki

Contents 1 The classes and associations of the model 1.1 IdentityData 1.2 IdentityDataItem 1.3 IdentityDataItemType 1.4 IdentityDataItemRole 1.5 IdentityDataEncoding

(How can i get the Wiki to number the headings in the TOC from two instead of the default one?)

Head page: Modeling LID

Previous page: Modeling LID--The rationale

Next page: Modeling LID--The objects of the model

{proposed} This is the current draft of identity data, a first step in development of a model of LID.

Please contribute

The classes and associations of the model

IdentityData

everyIdentityData is anIdentityDataItem

Following the GOF pattern, Composite.

IdentityDataItem

anIdentityData is composed of someIdentityDataItems

(Hmmm... It begins to feel like the composition should be a recursive relationship on IdentityDataItem. If not, then we need some other grouping mechanism.

(Here is an interesting question: is the association of anIdentityData to its IdentityDataItems the same association as the association of a group of identityDataItems to the identityDataitems in that group? The answer, if we follow Kilov-Ross, will be found by answering this question: are the invariants of those associations the same or differnt?)

IdentityDataItemType

anIdentityDataItem satisfies anIdentityDataItemType

(What?! Q: Isn't the problem that an item may satisfy several types? A: Hold on.)

Examples:

IdentityData

joaquin:IdentityData, you:IdentityData

IdentityDataItem

joaquinFN:IdentityDataItem, joaquinADDR:IdentityDataItem

IdentityDataItemType

commonName:IdentityDataItemType, deliveryAddress:IdentityDataItemType

anIdentityDataItem is composed of someIdentityDataItems

(?! Sorry folks, i got that lumpin' tendency; i tend to split only when truly necessary. Splitters will, of course, prefer to have an additional class, IdentityDataItemSubItem.)

IdentityDataItemRole

anIdentityDataItem plays someIdentityDataItemRoles

(I admit it: here i split between Type (see communityUML 5.4.1) and Role. Q: Why? A: Because a role, rather than telling us anything about the item itself (as a type does), tells us how the item is intended to be used: that's my short answer. A: For a slightly longer answer, note that RFC 2426 says that 'TYPE' is the name of a paramater; it does not refer to the category of MIME types, nor is it a new MIME type. (Naming this parameter 'TYPE' is confusing at best (but we are not here to criticize our betters).))

(The choice of 'role' reuses an excellent, if often somewhat muddled concept.)

Examples:

IdentityDataItemRole

home:IdentityDataItemRole parcel:IdentityDataItemRole

'home' is short for 'home address'; it means the address is a home address. 'parcel' means the address is an address for delivery of parcels. Either a delivery address or a telecommunication address can play the role, home, but only a delivery address can play the role, parcel.

IdentityDataEncoding

anIdentityData has aDefaultIdentityDataEncoding

anIdentityDataItem has anEncoding

(Notice the benefit of lumping: specifying that an identity data item has an encoding covers both the default encoding for an entire item as well as overriding the default in a subitem.)

Examples:

IdentityDataEncoding

jpeg:IdentityDataEncoding b:IdentityDataEncoding

Please contribute here. Thanks.

Joaquin Miller

Next page: Modeling LID--The objects of the model