Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Действия в ISO 15926

Решаем первую задачу: как выразить в 4D практику (practice) в ее традиционном для management framework понимании -- как некоторую совокупность действий, которая появляются вовремя в ходе работы (как только сложатся обстоятельства для ее использования), тесно переплетаясь с разными другими деятельностями. Практики -- не из процессов или проектов, что делает работу с ними особо интересной. Например: практика парного программирования в eXtreme Programming, практика управления буферами в управлении проектами им.Голдратта, практика использования карт действий и результатов (aka strategy and tactic tree) из того же Голдратта.

В самом верхушке RDL ISO 15926-2 находим activity и пытаемся понять:
<Действие> -- это <возможный индивид>, который приносит изменение, вызываемое <событием>, которое отмечает <начало> или событием, отмечающим <конец> <возможного индивида>. Действие состоит из временнЫх частей тех членов <возможного индивида>, которые участвуют в действии. Участвующие временнЫе части будут отнесены к <участвующей роли и домену> который указывает роль временнОй части в <действия>.
ПРИМЕР: Прокачка жидкости механическим насосом может быть представлена экземпляром <активности>.
Оригинал (http://www.tc184-sc4.org/wg3ndocs/wg3n1328/lifecycle_integration_schema/lexical/activity.html -- причем правильный способ смотреть это в фрейме со страницы http://www.tc184-sc4.org/wg3ndocs/wg3n1328/lifecycle_integration_schema.html) не лучше:
An <activity> is a <possible_individual> that brings about change by causing the <event> that marks the <beginning>, or the <event> that marks the <ending> of a <possible_individual>.
An activity consists of the temporal parts of those members of <possible_individual> that participate in the activity. The participating temporal parts will be classified by the <participating_role_and_domain> that indicates the role of the temporal part in the <activity>.
EXAMPLE Pumping a fluid with a mechanical pump can be represented by an instance of <activity>.
<Действие> ссылается также на <причину события> через атрибут "причина", <вовлечение по ссылке> через атрибут <вовлекатель>, <участие> через атрибут "целое", <возможный индивид> как подтип, <признание> через атрибут "признавая".

Интересно, что учет встроен в эту онтологию на самой верхушке: он дан атрибутах корневого класса <вещь>: id, record_copy_created, record creator, record_logically_delited, why_delited -- и это наследуется всеми остальными понятиями!

Итого: сложность освоения RDL вполне сравнима со сложностью освоения любого языка программирования (ибо суть дела та же, что и у любого другого программирования -- получить формальную модель куска действительности, и царских путей тут нет). Нужно трижды подумать, использовать ли для записи своих заметок этот конкретный язык программирования (в варианте ISO 15926, а не ISO 18629, например), или ограничиться грязным и корявым псевдокодом, который придумывать и уточнять по ходу дела.

За программирование: не попишешь, не поймешь про 4D.
За псевдокод: для сравнения разных организационных систем жесткого онтологического кодирования и не нужно (до тех пор, пока не пишешь поддерживающий софт).
За мы пойдем другим путем: неоднократное напоминание Отставнова, что все эти онтологии вещные (т.е. процессы в них тоже пытаются выразить вещами), и поэтому никакие рассуждения о деятельности в такого сорта онтологии не помещаются -- все это будет теми или иными изводами кооперации (процессного и проектного подходов), без всякого понятия о коллаборации. И тут мы опять возвращаемся к практикам типа парного программирования, аспектному программированию как дальнему родственнику таких описаний и абсолютно непаханой целине.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 0 comments