Re: Вдогонку

Вопросы, которые вы задаёте, очень интересны -- и на каждый из них можно отвечать долго и пространно (но, увы, это не формат комментов в ЖЖ). 1. Процессы (физические работы, "конструкция") против Функций (логические работы) -- это традиционное архитектурное разделение. В одном случае указывается назначение (цель), но не делается никакой связи с физической реализацией (неважно, речь идет о физической работе или вещи), а в другом случае как раз указывается на что-то, из чего можно создать конструкцию. ArchiMate это прихватил из DEMO, ибо Jan Dietz много и долго занимался архитектурой в связи с enterprise engineering, и у него диаграммка различий "функция-конструкция" принципиально важная. Есть много разных традиций разговора на эту тему. Так, в системной инженерии многие школы призывают обсуждение функций максимально дистанцировать от обсуждения конструкций (т.е. что делать обсуждать отдельно от вопроса как делать). А есть прямо другой подход: "функциональный физический объект" и "физический объект" в ISO 15926 связаны как 1:1 (то же в RLFP подходе ENOVIA, где всегда можно выделить "функцию" на 3D модели). При ближайшем разбирательстве выясняется, что у слова "функция" пять разных значений, и начинаются нюансы... Так что вся архитектурная традиция рассматривает и "функции" и "конструкцию", и "работы" тут просто частный случай. 2. Да, функциональная декомпозиция вполне представима как декомпозиция целей. Только функциональная декомпозиция обычно связывается с "назначением" (purpose), а слово "цель" имеет некоторые другие оттенки смыслов (и в орг.инженерии его передают иногда даже не как objective, а как motive -- ср. Busniess Motivation Model, OMG BMM). На практике это, конечно, всё страшно путается: цели, назначения, функции, задачи... Терминология существенно зависит от "школы мысли", и тут все школы путаются по своему :-) 3. Традиция процесса, как последовательности смены состояний распространена только в среде программистов, а в оргпроектировании по факту не применяется. Но вы правы, среди программистов этот подход крайне популярен. Поглядите на разнообразие стандартов, это всё только "разный XML": http://xml.coverpages.org/bpm.html -- и там формальных машин состояний много. Конечно, этот подход и BPMN 2.0 родственники, вплоть до неразличимости (формально там, кажись, до сих пор сам движок -- BPMS -- работает как машина состояний). 4. Я обычно говорю так, что "в учебниках по воркфлоу нет экземпляров, но есть в документации к софту. В учебниках по проектам нет шаблонов, но есть в документации к софту". Так что ответ на вопрос зависит от того, софт вы рассматриваете, или "теорию" :-) Но есть еще более правильный ответ: подумайте еще и над "различалками" из ISO 24744 -- там WorkKind и Work связаны через Powertype pattern. Т.е. отношение между ними -- класса и экземпляра, и оба рассматриваются и "в реализации", и "в теории". Это и есть правильный подход: не "или", а "и". Обязательно (и в учебниках, и в софте) рассматривать и классы, и экземпляры -- что, правда, не соответствует традиции "процессников ISO 9000" и "проектников PMBoK". Но мы-то понимаем, в чем фишка, и поэтому плохую традицию игнорируем, равно как и изготовители соответствующего софта.