День добрый. Вопрос идиотский есть, решил у Вас спросить . Около 2х месяцев назад поставили передо мной задачу по необходимости описания бизнес процессов деятельности штатного отделения одного из медицинских учреждений. Была оговорена цель моделирования, необходимая точка зрения и требуемые границы модели, а также конкретный субъект описания. Решил попробовать сделать по методичке от Золотухиной (скачал у Вас с сайта). Согласно ее рекомендациям, иерархия пакетов бизнес сущностей должна повторять соответствующую иерархию пакетов бизнес процессов (бизнес сущности моделируются в разбивке по бизнес процессам). Однако при построении иерархии бизнес процессов так получилось, что один и тотже object из колонки входной/выходной информации диаграммы потока работ упоминается в разных пакетах одновременно. Получается, что и при разработке моделей бизнес сущностей данный object также должен фигурировать в разных пакетах? Я планирую описать конкретный object только в одном пакете, а в остальные просто ссылки покидать на него. Так можно? В методичке это не упоминается, там конкретный пакет содержит только уникальные для него объекты.

Имхо - вполне можно. Главное, чтобы все товарищи, использующие Вашу модель, понимали принцип ее построения - одинаково.

Присоединяюсь к Irr и хочу от себя добавить.

В ходе моделирования у Вас появляется потребность использовать один и тот же объект в разных пакетах. Вы порождаете объект в одном пакете, а вдругом ссылаетесь на него. А таких ссылок может быть немало. Следовательно, можно общие объекты сгруппировать в некотором одном пакете: "Общие сущности", например. Тогда в каждом пакете будут содержаться только объекты внутренние для данного пакета + ссылки на объекты общего назначения.
Скажем История болезни может заводится в процессе Зарегистрировать больного, в процессе Назначить лечение разные врачи вносят туда изменения и т.п.

Советую посмотреть книгку Нейбурга и Максимчука Применение UML в проектировании баз данных (как-то так называется). Там есть сквозной пример как раз про медицинское учреждение.

Имхо - вполне можно. Главное, чтобы все товарищи, использующие Вашу модель, понимали принцип ее построения - одинаково.

Спасибо за мнение Только вот Ваш ответ заставил меня еще раз подумать о наболевшем... Почему UML не имеет четкой, исчерпывающе описанной методики описания бизнес процессов? Да, есть RUP, в пределах которого имеется некоторое описание методики описания бизнес-процессов, однако реализация строго в пределах данной методики может не позволить ответить на некоторые типы задач и целей, которые ставятся изначально перед бизнес аналитиком. Более того, само case Rational Rose не поддерживает четких синтаксических правил и соглашений. Возможно, в пределах моего круга лиц и будут понимать сделанную мной условность и  допущение, но если я захочу со временем продемонстрировать модель лицам "со стороны"? Поймут ли они меня? Мне кажется, что в работах такого рода использование "ИМХО" просто недопустимо. Должны быть четкие правила и следования им.

Присоединяюсь к Irr и хочу от себя добавить.

В ходе моделирования у Вас появляется потребность использовать один и тот же объект в разных пакетах. Вы порождаете объект в одном пакете, а вдругом ссылаетесь на него. А таких ссылок может быть немало. Следовательно, можно общие объекты сгруппировать в некотором одном пакете: "Общие сущности", например. Советую посмотреть книгку Нейбурга и Максимчука Применение UML в проектировании баз данных (как-то так называется). Там есть сквозной пример как раз про медицинское учреждение.

Спасибо. Идея с общим пакетом вполне осмысленна и логична.

Потому что насколько я понимаю,  изначально UML совершенно не заточен под бизнес-процессы, это изобретение архитекторов для разработчиков для описания внутренностей систем силами объекто-ориентированного анализа.
Для описания бизнес-процессов создавались нотация, используемая в Aris и BPMN.
Риск непонимания есть всегда. Если на этом форуме идет обсуждение, что есть Usecase, функция или сценарий использования, о каких единых правилах может идти речь?
Мы живем в эпоху апокрифов и религиозных столкновений, сейчас нет одной единственной истины на всех. И ни UML, ни Золотухина не осветят нам единственный правильный путь! Делай раз, делай два - не выйдет, все время приходится дуууууумать!

Ой, Остапа понесло...

Да, UML изначально создавался для решения задач другого характера, однако в настоящее время он (точнее, Rational Rose) активно предлагается и рекламируется и для решения задач по бизнес моделированию. Что до "думать", то это делать надо всегда и при решении задач любого характера . В All Fusion Process Modeler думать тоже часто приходится... Идея в том, что если каждый бизнес аналитик, работая с UML, будеть так вот "думать", то смогут ли они правильно понять сделанные друг другом модели?

UML и Rational Rose по-моему сильно разные вещи, одно нотация моделирования, другое продукт, это как теплое и мягкое. Да, IBM большая фирма, которая может широко рекламировать свои продукты, но это не значит, что у них есть единый на всех учебник, в котором все написано. Кстати, если сравнивать RUP как точку зрения IBM на бизнес-моделирование и курс Золотухиной - это таки тоже разные вещи :-) Нет пророка в этом мире!
Приходится смиряться, рисовать методику моделирования и быть готовым к критике своих моделей.
У меня единственная надежда в этом смысле на BPMN: если оттуда возможна трансформация в исполняемые процессы, то там все-таки намного строже все. И валидаторы есть. Но информации по тому же BPMN достаточно мало, в результате опять каждый может придумывать свой вариант...

Вот тут недавно перечитывал свой пост, много дельных мыслей в нем высказано:
http://www.uml2.ru/forum/index.php?topic=71.0

Единственное, что можно сказать, что все приходит с опытом, сначала Вы метаетесь в поисках лучшего, а потом просто делаете, т.к. знаете что это правильно, т.е. модель адекватна.
А вообще сейчас моден Агиле, кот. говорит - минимум артефактов, максимум коммуникаций. Прочтите например Коберна, Agile Software Development, глава Russian Programmers, мне очень понравилось.

З.Ы. А вообще, Золотухина далеко не истина в последней инстанции.

Прочтите например Коберна, Agile Software Development, глава Russian Programmers, мне очень понравилось.

Саша, хочу, хочу. Сделай мне подарок на Новый год, а? Отскань главку

Irrунь, ты прям трибун.

Вообще, у меня есть такое желание что-то написать, типа: "Назад в будущее UML или "бизнес" - это мы не проходили!".

IDEF0, делает ставку на минимализм средств отображения. Фишкой, кажется, считается строгость нотации и наличие разных видов входов: собственно вход-сырье, вход-управление, вход-механизм. Строгость и сила, и слабость. Возникает потребность искуственной декомпозиции, иногда сложно разделить управление и вход, плохо согласуется с ОО

IDEF3, как мне, кажется, используется редко и часто совершенно неверно. Думаю, связано с тем, что появились более приемлемые решения в виде диаграмм видов деятельности и им подобным. Представитель направления workflow

DFD - интересная нотация, активно поддерживается до сих пор, однако кроме Калянова даже и не знаю, кто использует для описание бизнес-процессов

ARIS- штука интересная, но мною не изучалась глубоко. Однако, MS пытается сделать ее стандартом, что может иметь большие последствия

Расширения UML Эриксона-Пенкера, хороший переход от IDEF0 к использованию инструментов c UML. Наверное именно так и задумывался, поскольку сами авторы утверждают - никаких новых идей, никаких новых подходов.  Business Modeling with UML: Business Patterns at Work by Hans-Erik Eriksson and Magnus Penker ISBN: 0471295515 John Wiley & Sons © 2000 (459 pages). Опять же кроме как в Enterprise Architect больше и не встречал

BPMN - насчитывает 3 года торжественного шествия, часто реализуется в UML tools, в той или иной степени строгости. При этом явно утверждают - мы лишь язык описаний ничего большего, все правила использования полностью на отвественности автора. Регламентируется лишь стадия перехода от BPMN к конструкциям BPEL, по-моему. А это уже фактически программирование, тут без строгости не обойтись. Сам язык, не что иное как таже диаграмма активности, IDEF3, немного ARIS, чуточку IDEF0 в одном флаконе. Фишка - развитый набор событий и логических переходов, но опять же весь этот набор так специфичен и на уровне описание бизнес-модели, как мне думается, опасен к использованию.

Кто продолжит ?

В общем, в каждой избушке свои погремушки.
А мы, бедные, медитируем и пытаемся по коанам познать истинное Дао. Только монахам обычно легче, там учитель рядом, а не книги на иностранных языках или в не всегда корректных переводах

UML и Rational Rose по-моему сильно разные вещи, одно нотация моделирования, другое продукт, это как теплое и мягкое.

Железно, с этим трудно не согласиться. В целом, направление Ваших мыслей мне вполне понятно, хотя и не могу сказать, что полностью с ними согласен.
Кстати, а есть где-нибудь описание методики бизнес моделирования по RUP на русском языке? Пока-что видел и читал только на оригинальном...

Кстати, а есть где-нибудь описание методики бизнес моделирования по RUP на русском языке? Пока-что видел и читал только на оригинальном...

Дык нет в свободном доступе перевода RUP на русский язык. По-моему, за деньги такое делал CMConsult с Новичковым, но результатов я не видела.

А перевод того же Новичкова части книги Введение в RUP от Кратчена? По моему где в нашем архиве есть

А перевод того же Новичкова части книги Введение в RUP от Кратчена? По моему где в нашем архиве есть

Есть, но он не сильно помогает постичь истинное Дао. Вопросы-то по правилам и логике использования конкретных элементов, т.е. более касаются моделирования. А введение в RUP - это все-таки общие слова, а не UML, не глубже, чем декларация политики партии. Хотя конечно лучше прочитать и введение :-)

Чтобы постичь кун-фу, нужен долгий путь совершенства. Практика - основа движения по пути.
В общем надо просто больше моделировать, обсуждать модели на форумах и с друзьями. Стараться моделировать задачи из разных областей. С ростом количественных признаков порождаются качественные. Насколько я помню Гегель установил