Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: execto от 25 Сентября 2016, 15:58:30
-
Добрый день. Прошу оценить схему с точки зрения правильности построения, соблюдения правил построения.
-
Добрый день!
Если вы хотите нарисовать именно схему работы пекарни с точки зрения бизнес-процесса, воспользуйтесь лучше BPMN нотацией.
Если вы хотите нарисовать диаграмму вариантов использования некоей системы в хлебопекарне, то для начала учитывайте только тех акторов, кто в этой системе работает.
Складывается впечатление, что цель моделирования вам самому не ясна, оттого делаете не то и не в той нотации.
-
нет, всё верно, я на этой диаграмме хотел показать кто задействован и их функции при реализации готовой продукции хлебопекарни
-
преподаватель сделал вот такое замечание: "Нет связей между функциями. Функции не конкретны."
Что значит функции не конкретны? И как их связать друг с другом?
-
1. С формальной точки зрения, процесс заключения договора и процесс контроля реализации исполнения, находятся за рамками предметной области процесса "Реализация продукции"
2. Обработки заказов точно нет никакой ? То есть клиент, независимо от наличия договора, приезжает когда хочет и берёт всё, что сможет ?
3. "Погрузка" - точно будет автоматизируемой функцией ? То есть вот прямо в момент погрузки будет использоваться какое-то устройство типа сканера/тсд с передачей каких-то данных ?
-
нет, всё верно, я на этой диаграмме хотел показать кто задействован и их функции при реализации готовой продукции хлебопекарни
Значит вам нужна другая нотация.
Диаграмма вариантов использования из UML для этого совсем не подходит, т.к. описывает полезные функции некоей автоматизированной системы и сущностей с ней взаимодействующих.
А вам нужно отобразить бизнес-процесс реализации готовой продукции. Используйте BPMN.
-
Нотация не виновата. Метод H. E. Eriksson'а and M. Penker'а позволяет использовать нотацию и [конкретно] диаграмму вариантов использования для бизнес-моделирования.
-
Нотация не виновата. Метод H. E. Eriksson'а and M. Penker'а позволяет использовать нотацию и [конкретно] диаграмму вариантов использования для бизнес-моделирования.
А не могли бы привести примеры или указать на ссылку?
-
"Rational Edge" (http://www.ibm.com/developerworks/rational/library/content/RationalEdge/nov02/BusinessModelingWithUML_TheRationalEdge_Nov2002.pdf) 11.2002
-
"Rational Edge" (http://www.ibm.com/developerworks/rational/library/content/RationalEdge/nov02/BusinessModelingWithUML_TheRationalEdge_Nov2002.pdf) 11.2002
Спасибо, но разве это метод H. E. Eriksson'а and M. Penker'а У них нотация обозначения вроде бы совершенно иная?
-
"Rational Edge" (http://www.ibm.com/developerworks/rational/library/content/RationalEdge/nov02/BusinessModelingWithUML_TheRationalEdge_Nov2002.pdf) 11.2002
Спасибо, очень занимательное руководство.
Но во первых там целый комплекс диаграмм, а не только ДВИ
А во вторых, при всём уважении к парням из Rational, похоже на инструкцию "Как правильно забивать гвозди нашим микроскопом":)
-
Спасибо, но разве это метод H. E. Eriksson'а and M. Penker'а У них нотация обозначения вроде бы совершенно иная?
Я не сразу поняло, о чём Вы. Признаю за собой заблуждение относительно E&P-метода, полистав ссылку (http://www.dsc.ufcg.edu.br/~sampaio/Livros/Wiley-Business-Modeling-with-UML-Business-Patterns-at-Work.pdf). Полагало, то рейшеналовские "мужики с гвоздями в голове и треснутые яйца" являются развитием идей E&P. Добавлю, что и за E&P признаю заблуждение. Полагать, что их Process-диаграмма является размеченной стереотипами диаграммой деятельности, сейчас не осталось никакой возможности. А представить её юз-кейс-диаграммой можно вполне.
-
Спасибо, очень занимательное руководство.
Но во первых там целый комплекс диаграмм, а не только ДВИ
А во вторых, при всём уважении к парням из Rational, похоже на инструкцию "Как правильно забивать гвозди нашим микроскопом":)
А в-третьих, ю-к-диаграмму можно таки использовать как перечень бизнес-процессов предприятия. О чём изначально и шла речь.
А в-четвёртых, известно, что в IBM/Rational -- все малахольные, но возможности использования нотации из-за этого не сужаются.
А в-пятых, основные проблемы автора топика не связаны с выбором нотации. Выбора у него, собственно и нет.
-
Переделал схему, но всё таки кажется чего то не хватает. Не могу никак полностью осознать саму суть use-case диаграмм, отсюда и проблемы со связями функций и актеров, может чего то не хватает, или где то что то не связанно?
-
Переделал схему, но всё таки кажется чего то не хватает. Не могу никак полностью осознать саму суть use-case диаграмм, отсюда и проблемы со связями функций и актеров, может чего то не хватает, или где то что то не связанно?
Мне понравился такой образ: диаграмма вариантов использования - это кладбище сценариев :) Яйцо - памятник, сам сценарий под ним, акторы - связанные между собой родственники :)
Суть ДВИ - не более чем отражение связей акторов и сценариев между собой.
Если брать Вашу ДВИ я бы сделал следущие изменения:
1) Использовал бы Boundary для группировки UC . Например Фирма, или Автоматизированная система для того чтобы отделить UC которые происходят внутри них или за их границами
2) Развел бы акторов по разным сторонам диаграммы. Работники фирмы налево, клиенты и прочие внешние сущности направо
3) Ввел бы актора Сотрудник, остальных акторов , кроме клиента наследовал бы от него. А может быть вообще ввел актора Лица.
-
Назрел ещё вот такой вопрос. Можно ли делать так с экстендами, как показано на диаграмме?
-
Назрел ещё вот такой вопрос. Можно ли делать так с экстендами, как показано на диаграмме?
"Так" - это как?
В данном случае гораздо важнее "зачем".
Основное предназначение ДВИ - это визуализировать отношения между акторами и сценариями. Как только вы пытаетесь описать с ее помощью бизнес-процесс и взаимодействие акторов в нем, то ДВИ становиться запутанной и нелогичной. Если диаграмма становится графически некрасивой - верный признак того, что имеет место попытка ломом забить гвоздь.
На вашем примере акторы не связаны, общих use case у них нет, через extend и include вы пытаетесь отразить вызовы подпроцессов, выполняемых другими акторами. Для отражения взаимодействий есть interaction diagram.
Конкретно в этом случае я бы использовал диаграмму последовательности
-
Т.е. лучше будет убрать линии ассоциаций от расширений?
-
Критерий этого лучше/хуже неясен.
Если стоит задача построить некую универсальную диаграмму "все в одном", то их лучше оставить. Если рассматривать эту диаграмму как часть постановки или часть общего потока моделирования, то то ДВИ лучше упростить. А процессы взаимодействия и вложенности сценариев отразить другими способами.
-
Т.е. лучше будет убрать линии ассоциаций от расширений?
Их убирать нельзя.
Ваш преподаватель полагает, что на диаграмме ВИ все ВИ нужно связать друг с другом.
Общий подход состоит в том, что связи между ВИ рисуются только между теми ВИ, описания которых ссылаются друг на друга. Но описаний ВИ у Вас (и у Вашего преподавателя?) нет. Возможно, что они просто не предъявлены, хотя кажется, что до описаний дело не доходит вообще. Но без описаний нет возможности адекватно оценивать диаграммы, которые Вы постите.
-
а если не учитывать требования преподавателя? диаграмма останется верна с точки зрения правил нотации?
-
а если не учитывать требования преподавателя? диаграмма останется верна с точки зрения правил нотации?
Нарушения нотации с точки зрения размещения графических элементов нет. А сказать про соблюдение нотации при визуализации сценариев нельзя за неимением самих сценариев.
-
Можно отметить общее свойство обоих Ваших диаграмм, похожее на ошибку. Если полагать, что Вы моделируете бизнес-процесс, и читать их по стандарту, то неясно, что именно лежит внутри границ "сабжекта", подвергаемого моделированию. На диаграмме ВИ "мужиками" (действующими лицами) изображают внешние элементы контекста, лежащие за границами "сабжекта". Т. е., если Вы моделируете пекарню, то те, кто в пекарне работает, не могут быть "мужиками" на диаграмме. Они внутри границ, а не вне. Их помещают на диаграммы классов, диаграммы взаимодействия как исполнителей. Функции исполнителей моделируют как их операции, а не как ВИ. "Мужики" пекарни -- это покупатели продукции, сборщики налогов, пожарники и т. п. (все они не работают в пекарне!).
Аналогично, если в модели конструкторского бюро Вы считаете инженера "мужиком", то это какой-то "заграничный" инженер, которому, к примеру, лень что-то конструировать и он подписал бюро на субподряд.
Подобная ошибка проиллюстрирована на сайте (http://www.uml-diagrams.org/use-case-subject.html), куда Вас однажды я уже направляло. Вот такая картинка:
(http://www.uml-diagrams.org/use-case-diagrams/use-case-business-error.png)
Красным покрашены "мужики", которых на диаграмме быть не должно.
Так вот, если учитывать всё это, то диаграммы про пекарню моделируют X = пекарня - менеджер - бухгалтер - кладовщик - экспедитор (здесь "-" -- это "минус"). По-моему, X -- это пекари, тестоместы и т. д. Вряд ли можно ожидать, что для бухгалтера они будут оформлять накладную, а для кладовщика вести учёт остатков.
Возможно Вы моделируете какую-то систему, автоматизирующую деятельность пекарни, связанную с реализацией её продукции. Тогда работники пекарни могут быть её "мужиками". Но сомнительно, как мне кажется, что клиент сам с помощью этой системы будет организовывать свои денежные расчёты. Для расчётов есть банки.
Аналогично можно рассмотреть модель про бюро. Если из него вычесть упомянутые на диаграмме отделы, то что останется? Если моделируется система, автоматизирующая работу, то вряд ли её пользователем будет отдел целиком, но сотрудник отдела может быть.
Укажите, какая перед Вами стоит задача! Вы просите рассмотреть ответы, не открывая, решениями чего они являются. В результате нам остаётся лишь гадать, чего от Вас требуется.
P. S. Всё то, что Вы включили в оформление накладной скорее является включениями в работу с заказом. Например, без "внесения характеристик и количества продукции" в заказ нельзя выполнить проверку наличия товара. Мне представляется, что большая часть накладной -- это сведения из заказа.
-
Задача стоит вот такая "Разработка информационной системы поэтапной сборки шкафа автоматики управления выключателем"
-
Задача стоит вот такая "Разработка информационной системы поэтапной сборки шкафа автоматики управления выключателем"
А цели разработки информационный системы определены? Если этого не сделать, описание предметной области и разработка требований к системе будет трудно отделить друг от друга.
-
цель автоматизация
-
Задача стоит вот такая "Разработка информационной системы поэтапной сборки шкафа автоматики управления выключателем"
К этой задаче относятся 4 "яйца" в левом нижнем углу диаграммы. Если толковать расширительно, то м.б. + "яйца" правой половины. Да и то, возникают вопросы как может быть автоматизирована сборка, программирование, исправление монтажа. Закупка и моделирование могут рассматриваться как этапы "жизненного цикла", но не сборки как таковой.
Предлагаю дать другие имена "мужикам"-отделам: "специалист по качеству", "специалист по сборке".
Совет по стилю: "мужиков" расставить по границам диаграммы, "яйца" сложить в её середину. Стараться рядом с "мужиком" класть те яйца, с которыми он связан. Избегать по возможности пересечения связей.
-
цель автоматизация
Автоматизация процесс. Он не может быть целью.
Википедия :
Автоматизация — одно из направлений научно-технического прогресса, использующее саморегулирующие технические средства и математические методы с целью освобождения человека от участия в процессах получения, преобразования, передачи и использования энергии, материалов, изделий или информации, либо существенного уменьшения степени этого участия или трудоёмкости выполняемых операций.
-
как тогда правильнее будет сформулировать задачу? если расставить акторов по краям, и ВИ по центру то уж очень запутанно получится.
-
Добрый день. Вернулся к документообороту реализации продукции пекарни.
Оцените пожалуйста схему, может что то не учтено или что то нелогично?