plcs-dex message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [plcs-dex] Scheme entry assignment or Activity method realization?
- From: Tim Turner <tjt@lsc.co.uk>
- To: "'nigel.shaw@eurostep.com'" <nigel.shaw@eurostep.com>, Tim Turner <tjt@lsc.co.uk>
- Date: Fri, 20 Jan 2006 05:00:07 -0000
Title: Message
Here is a short .ppt which puts the basic model
together for this approach.
It is not complete in terms of life cyc. opp, ref data,
approvals & the like - but should give general picture to the previous
email.
Kind regards,
Tim
(NB - this cuts across several Dexs, but I wanted to
put baseline together for common use.
- Also task structure provided here are just for
example only)
Nigel,
thanks for your helpful comments. It's not pretty, though
it helps to separate out the reasons for why the model is the way it is.
However, there
are still some confusing aspects for me, which I have tried to drive out in the
following.
I appreciate that the 1:1 link between Activity and
Activity_method is inadequate. However, I don't think
Activity_method_realization CAN address this specific issue as it does not
relate an Activity to Activity_method.
It relates an Activity_method with one of the
following;
However, in C032 I note Activity_method is refered to as
a "typical activity", so typical activities could be used in this [bent]
fashion - (though it strikes me that maybe typical_activity is a missing
subtype). Hence the activity_method (classified as a typical activity) can be
related to another activity_method (this time a subtype such as scheme,
scheme_version, task_method task_method_version or task_element). However, the
relationship is again a 1:1, which requires a new relationship each time to
represent the instructions, schedules, safety_procedure etc.. Presumably this
would have been better as a list of 1:? to achieve the scenario
discussed below.
But then the question is does this also work for a
<planned> activity? Clearly, the select type above does not allow for this
(I just double-checked that activity is not in the select type list from the
latest corrected version of 239). The other possibility is to use the
activity.chosen_method but this is again inadequate since only one of the tasks
can be linked where we may have several (as you
indicated).
There are thus, only two other ways to resolve
this.
i) that the <planned> activity references
the <typical activity> activity_method through the activity.chosen_method,
thereby linking the typical to the planned.
ii) to use an applied_activity_assignment on the
<planned> activity - this provides a set of [1:?]
activity_item & this select type subsumes those entities of the
Activity_realization_select type of Activity_method_realization
entity.
Taking each of these in
turn;
Case i) then allows (the simplest case) for
the typical activity, to be linked to the planning stage, without having to
redefine all the relationships (of typical activity) when using a
<planned> activity. Hence, activity can thus be defined as a planned
occurrence of a typical activity. The approval of the activity would signify
approval of all the typical tasks. Likewise for rejection /
dis-approval.
Case ii) allows each of the relationships defined
within the typical case to be repeated, but this time in a simpler fashion (a
one to many relation), and each relationship could be assigned an approval
independantly of the typical activity's approval. However, this could
also be shown implicitly by only providing the relationships which are
effective for the given approval of the <planned> activity. That is, the
relations then show which are planned to be taken up. As
the activity.chosen_method attribute, is
mandatory it should then point to the typical activity refered to in i).
C032 only refers to approval at the activity level so I
presume that in case i) we approve / reject the whole typical activity, or, if
separate relationships have been provided from the <planned> activity to
certain tasks identified within the typical activity, that only those are
approved / rejected. Of course, the logic can work in either direction (i.e. are
those that are not classified as dis-approved, approved?) Note, we will have to
create a precedence table for these and other approvals at other
levels.
Lastly, an activity_actual can be seen as a realized
occurrence of a typical activity (rather than <planned>, as the
.chosen_method cannot point to this) and can (like in case ii) be either just
accepting the whole thing or just adding the relations to those undertaken. In
addition, we can then add the activity relationship activity_happening between
the <planned> and the actual_activity.
I see two things which come from this
approach;
1. That should there be no typical activity defined for
the tasks which a planned activity would normally identify (though the
applied_activity_assignment), there will be no straight-forward solution to what
the <planned> activity.chosen_method attribute points to. We will
have to (in these cases) define activities on a 1:1 basis with respect to the
tasks identified and drop the use of the applied_activity_assignment (which will
be repeating the .chosen_method link & so is redundant). This also provides
an opportunity to either reference a task, or to redefine/extend one if
necessary.
2. Conversely, I also note that by using
activity_method for the typical case, it means that a life cycle opportunity
cannot be defined as described within C020 (it specifies that it has to be an
activity). However, we could provide a dummy activity for this purpose,
which then allows the rest of the work package to be defined.
On the second issue, I appreciate the difference
between an activity and an occurrence of one as an entry in to a scheme of work.
I presume that when you say "a scheme entry is a representation of an activity"
that this does not infer that the scheme_entry replaces the need for an
activity. Yes, the fact that a scheme_entry is a type of activity_method does
make this model questionable (un-intuitive at least), but if it's a necessary
evil....
Just to wrap this last aspect up then, the scheme_entry
should thus, be related to the typical, <planned> or actual_activity via a
scheme_entry_assignment, which covers all these and more. What is less certain,
is whether each should have a separate scheme_entry for it, or a single one
which is re-used by the 3 assignments. I would favour the latter to keep the 3
aspects together which would be useful where other un-related entries could
collate their activities together.
On a related aspect, I
also see no reason why the directed_activity for a
work_order should not also be used as the activity for the
life cycle opportunity model. Indeed, having several opportunities for support,
several activities may be relevant, but only one should be authorized for the
activities identified. The directed_activity should be the one approved and
should not need another activity assigned (through applied_activity_assignment
and activity_method) to achieve
this.
There are many other aspects of the model which can
serve to distract from the logical use, which are no doubt there to allow
flexibility for compatibility and/or specific usages, but hopefully the
above is not too far from a basis to work
from.
I apolpogise for the length of this, and I hope it
makes sense, but as no doubt you'd appreciate, it's a complex beast to
understand and takes time to walk
through...
Kind regards,
Tim
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
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
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
Model1.ppt
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]