RE: [plcs-dex] Scheme entry assignment or Activity method realization?

["Nigel Shaw" <nigel.shaw@eurostep.com>]

Title: Message

Tim

 

The models allow for many possibilities as a reflection of real life. In real life, when someone undertakes a piece of work they are often following a set of instructions AND one or more schedules AND a set of safety procedures AND organizational rules. On top of this, they may be subject to instructions on how to provide feedback on the work - what records to keep, which stages to sign-off, etc.

 

This is a marked contrast with the basic core STEP model for Activity which refers to a single chosen method.

 

Consider also that the chosen method could change  while the Activity is being planned  (same intended job but different plan or different approach) and tracking that change also may be important.

 

Hence from PLCS perspective I saw the existing required 1:1 between Activity and Activity_method as woefully inadequate. Activity_method_realization was intended to deal with both of these in that - with a suitable place holder method as the "chosen_method", multiple methods can be associated with the Activity and efffectivity can be applied to the Activity_method_realization.

 

So that was the first problem.

 

The second problem was to deal with plans and schedules.

Here the first thing to realise is that although people "follow" plans and schedules, the things in them are not Activity's. Why? - because the same Activity can appear in many schedules. So a scheme entry is a representation of an activity (or other things, such as change in resource availability). This makes it questionable as to whether it really is an Activity_method - but to get the interpretation to work, it had to become one.

Regrettably (and not the case in early versions), making it an Activty_method makes it possible to use activity_method_realization with it. I would not recommend this usage.

 

     Nigel

 

-----Original Message-----
From: Tim Turner [mailto:tjt@lsc.co.uk]
Sent: 16 January 2006 07:45
To: ''Plcs-Dex teams (E-mail) ' (plcs-dex@lists.oasis-open.org)'
Subject: [plcs-dex] 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