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



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



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

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

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



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

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

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



Потому что насколько я понимаю,  изначально 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 в одном флаконе. Фишка - развитый набор событий и логических переходов, но опять же весь этот набор так специфичен и на уровне описание бизнес-модели, как мне думается, опасен к использованию.

Кто продолжит :)?
« Последнее редактирование: 24 Декабря 2007, 21:04:46 от Galogen »



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



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



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



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



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



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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19