Форум Сообщества Аналитиков

×


use-case. Реализация продукции хлебопекарни.(Прочитано 27779 раз)
Назрел ещё вот такой вопрос. Можно ли делать так с экстендами, как показано на диаграмме?
« Последнее редактирование: 02 Октября 2016, 13:26:11 от execto »



Назрел ещё вот такой вопрос. Можно ли делать так с экстендами, как показано на диаграмме?

"Так" - это как?

В данном случае гораздо важнее "зачем".

Основное предназначение ДВИ - это визуализировать отношения между акторами и сценариями. Как только вы пытаетесь описать с ее помощью бизнес-процесс и взаимодействие акторов в нем, то ДВИ становиться запутанной и нелогичной. Если диаграмма становится графически некрасивой - верный признак того, что имеет место попытка ломом забить гвоздь.

На вашем примере акторы не связаны, общих use case у них нет, через extend и include вы пытаетесь отразить вызовы подпроцессов, выполняемых  другими акторами. Для отражения взаимодействий есть interaction diagram.

Конкретно в этом случае я бы использовал диаграмму последовательности

« Последнее редактирование: 02 Октября 2016, 14:09:48 от Humbert »



Т.е. лучше будет убрать линии ассоциаций от расширений?



Критерий этого лучше/хуже неясен.

Если стоит задача построить некую универсальную диаграмму "все в одном", то их лучше оставить. Если рассматривать эту диаграмму как часть постановки или часть общего потока моделирования,  то то ДВИ лучше упростить. А процессы взаимодействия и вложенности сценариев отразить другими способами.
« Последнее редактирование: 02 Октября 2016, 15:52:28 от Humbert »



Т.е. лучше будет убрать линии ассоциаций от расширений?
Их убирать нельзя.
Ваш преподаватель полагает, что на диаграмме ВИ все ВИ нужно связать друг с другом.
Общий подход состоит в том, что связи между ВИ рисуются только между теми ВИ, описания которых ссылаются друг на друга. Но описаний ВИ у Вас (и у Вашего преподавателя?) нет. Возможно, что они просто не предъявлены, хотя кажется, что до описаний дело не доходит вообще. Но без описаний нет возможности адекватно оценивать диаграммы, которые Вы постите.
[...и улетело НЛО.]



а если не учитывать требования преподавателя? диаграмма останется верна с точки зрения правил нотации?



а если не учитывать требования преподавателя? диаграмма останется верна с точки зрения правил нотации?

Нарушения нотации с точки зрения размещения графических элементов нет. А сказать про соблюдение нотации при визуализации сценариев нельзя за неимением самих сценариев.



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

Красным покрашены "мужики", которых на диаграмме быть не должно.
Так вот, если учитывать всё это, то диаграммы про пекарню моделируют X = пекарня - менеджер - бухгалтер - кладовщик - экспедитор (здесь "-" -- это "минус"). По-моему, X -- это пекари, тестоместы и т. д. Вряд ли можно ожидать, что для бухгалтера они будут оформлять накладную, а для кладовщика вести учёт остатков.
Возможно Вы моделируете какую-то систему, автоматизирующую деятельность пекарни, связанную с реализацией её продукции. Тогда работники пекарни могут быть её "мужиками". Но сомнительно, как мне кажется, что клиент сам с помощью этой системы будет организовывать свои денежные расчёты. Для расчётов есть банки.
Аналогично можно рассмотреть модель про бюро. Если из него вычесть упомянутые на диаграмме отделы, то что останется? Если моделируется система, автоматизирующая работу, то вряд ли её пользователем будет отдел целиком, но сотрудник отдела может быть.
Укажите, какая перед Вами стоит задача! Вы просите рассмотреть ответы, не открывая, решениями чего они являются. В результате нам остаётся лишь гадать, чего от Вас требуется.
P. S. Всё то, что Вы включили в оформление накладной скорее является включениями в работу с заказом. Например, без "внесения характеристик и количества продукции" в заказ нельзя выполнить проверку наличия товара. Мне представляется, что большая часть накладной -- это сведения из заказа.
« Последнее редактирование: 03 Октября 2016, 01:49:56 от [прилетело НЛО и...] »
[...и улетело НЛО.]



Задача стоит вот такая "Разработка информационной системы поэтапной сборки шкафа автоматики управления выключателем"



Задача стоит вот такая "Разработка информационной системы поэтапной сборки шкафа автоматики управления выключателем"

А цели разработки информационный системы определены? Если этого не сделать, описание предметной области и  разработка требований   к системе будет трудно отделить друг от друга.



цель автоматизация



Задача стоит вот такая "Разработка информационной системы поэтапной сборки шкафа автоматики управления выключателем"
К этой задаче относятся 4 "яйца" в левом нижнем углу диаграммы. Если толковать расширительно, то м.б. + "яйца" правой половины. Да и то, возникают вопросы как может быть автоматизирована сборка, программирование, исправление монтажа. Закупка и моделирование могут рассматриваться как этапы "жизненного цикла", но не сборки как таковой.
Предлагаю дать другие имена "мужикам"-отделам: "специалист по качеству", "специалист по сборке".
Совет по стилю: "мужиков" расставить по границам диаграммы, "яйца" сложить в её середину. Стараться рядом с "мужиком" класть те яйца, с которыми он связан. Избегать по возможности пересечения связей.
[...и улетело НЛО.]



цель автоматизация

Автоматизация процесс.  Он не может быть целью.

Википедия :

Цитировать
Автоматизация — одно из направлений научно-технического прогресса, использующее саморегулирующие технические средства и математические методы с целью освобождения человека от участия в процессах получения, преобразования, передачи и использования энергии, материалов, изделий или информации, либо существенного уменьшения степени этого участия или трудоёмкости выполняемых операций.



как тогда правильнее будет сформулировать задачу? если расставить акторов по краям, и ВИ по центру то уж очень запутанно получится.
« Последнее редактирование: 03 Октября 2016, 15:05:45 от execto »



Добрый день. Вернулся к документообороту реализации продукции пекарни.
Оцените пожалуйста схему, может что то не учтено или что то нелогично?




 

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