Scheme entry assignment or Activity method realization?

[Tim Turner <tjt@lsc.co.uk>]

Title: Scheme entry assignment or Activity method realization?

Dear All,

Prior to Christmas I sent out an email regarding the relationship between a Scheme_entry and Task_method_version, both of which are subtypes of Activity_method).

An Activity_method_realization can be used to relate a Scheme_entry to a Task_method_version, as detailed briefly in C032 - Representing_activity.

However, there is also the possibility of using Scheme_entry_assignment (a subtype of applied_activity_method_assignment - which would appear to be designed for this) and allows a greater set of items to be assigned than through Activity_method_realization.

Through various conversations I understood that it was expected that we use the former over the latter. However, I cannot fully appreciate the reasoning behind this, especially when one seems to be more tailored for the purpose (i.e. the latter). Either usage is valid in the EXPRESS (i.e. there are no rules which enforce one over the other as far as I'm aware)... The rules (only on Scheme_entry_assignment) just redefine the types or inhibit a recursive relationship.

The former is also just a binary relation (1:1), whereas the latter provides for a set [1:?] of items. Hence I can see more advantage in using the latter, were a number of tasks required to represent a scheme_entry.

I had begun to think that the Activity_method_realization was part of a lifecycle view, but this is hard to appreciate since the entities made available by the two select types overlap, but are different (the latter enables greater number). Hence there can be no 1:1 across such a view.

Scheme_entry_assignment is described within C062 - Representing Scheme and is pulled in to the capabilities EXPRESS usage area. However, Activity_method_realization is NOT pulled into the usage of C032 - Representing_activity, where it would naturally fit and is briefly described. This is perhaps an issue for C032.

I would appreciate modeller views on this asap so we can document a consistent approach.

Many thanks,
Tim

NB. WRT Activity_method_realization,  C032 - Representing_activity says "If the typical activity [activity_method] is described by a Task_method, or scheduled by a Scheme, then it is related to the Activity_method by an Activity_method_realization. This is described in the capabilities C015: representing_task and C062: representing_scheme". However, there is no further description of this, and the statement is ambiguous since there is no clarification whether any subtypes of activity_method can also play in the role of a "typical activity".

PS. It also seems odd that none of the versioning entities for this area of the model (e.g. scheme_version, task_method_version) have an .id - is it therefore, valid (consistent) to create ids as reference data for such entities, where no such attribute ever existed in ap239?

<<...OLE_Obj...>>

*************************************************************************
*
* Mr. Timothy J. Turner BSC(Hons) MSc, MBCS
* Executive Consultant, Enterprise Integration Technologies
* LSC Group, Lincoln House, Wellington Crescent, Fradley Park, LICHFIELD, Staffordshire WS13 8RZ, ENGLAND
* UK Switchboard: +44-1543 446800 Fax: +44-1543 446900
* Mobile (US) telephone: +1-843-4759179
* Mobile (UK) telephone: +44-7885-393225
* e-mail: tjt@lsc.co.uk <mailto:tjt@lsc.co.uk> Internet: <http://www.lsc.co.uk/>
*
*************************************************************************
<<Tim Turner (Tim Turner).vcf>>

DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED***   The information in this message is confidential and may be legally privileged. It is intended solely for the addressee.  Access to this message by anyone else is unauthorised.  If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful.  Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG

Tim Turner (Tim Turner).vcf