На мой взгляд, перемудрили. В текстовом виде вы описали понятно, а схема содержит ошибки.
1. Первая ваша ветка "ожидание обытия" пустая и является веточным циклом. То есть работа по этому алгоритму зайдёт в тупик, в бесконечный цикл. Здесь нужна конкретика: "о каком событии идёт речь?". Или же можно пойти от обратного: "в каком случае этот алгоритм не нужно выполнять?". Ответ на какой-либо из этих вопросов станет развилкой в вашей схеме (в зависимости от контекста), а точнее - станет циклом (либо с предусловием, либо с постусловием)
Вложение:
Ответ1.png [ 22.92 КБ | Просмотров: 1888 ]
Вложение:
Ответ2.png [ 67.14 КБ | Просмотров: 1888 ]
2. Оформление кнопок в виде ветвей силуэта - это интуитивно понятно, но противоречит правилам ДРАКОНа. Ветви силуэта - это всё равно последовательность действий, только разбитая на смысловые блоки. Это значит, что выполнение вашего алгоритма заключается в последовательном нажатии каждой кнопки. В вашей ситуации логичнее заменить силуэт переключателем. К тому же вы перемешали в названии ветвей объекты и события - это плохо...
Вложение:
Ответ3.png [ 18.07 КБ | Просмотров: 1888 ]
И вот на этом этапе я затрудняюсь вам помочь дальше, потому что перестал понимать суть. В теме вы пишете, что кнопок три, а в вашем алгоритме их две. В силуэте у вас есть ветви "Лист изменился", "Книга закрывается", но на эти ветки нет ссылок, нет икон "Адрес" с аналогичными названиями. Вам надо разобраться с этим. Пока складывается впечатление, что диаграммы состояний вам ближе, но дракон-схемы - это диаграммы последовательностей (подробнее о видах здесь: https://worksolutions.ru/blog/why-use-uml/).
3. У вас есть повторяющиеся по смыслу и немного отличающиеся по оформлению фрагменты: это переключатель "Форма с конпками" из ветки "Кнопка Список проектов" и действия "Оповещение об ошибке". У вас есть и развилка "Лист изменён", и ветвь "Лист изменился" - снова неоправданный повтор. Нужен ли вам вариант "НЕ грузить лист на сервер", в смысле есть ли действительно эта кнопка в вашем проекте? Череда условий не соответствует принципу "царской дороги". Самым зрительно удобным исходом в вашей схеме является неудачная авторизация. Надо всё сделать с точностью наоборот, а там глядишь и появятся способы сделать вашу запись компактнее. Могу пока предложить такой вариант:
Вложение:
Ответ4.png [ 47.87 КБ | Просмотров: 1888 ]
4. Я бы с языковой точки зрения внёс изменения. Повторюсь, что дракон-схемы - это диаграммы последовательности действий. В таких диаграммах элементы говорят сами за себя. Икона "Вопрос" должна содержать вопрос: не "Авторизация", а "Пользователь успешно авторизован?" либо "Авторизация прошла успешно?". Икона "Действие" должна содержать действие: не "Форма список проектов", а "Загрузить форму "Список проектов" . И так как это действие, то логичнее начать инструкцию с глагола: не "Форму скрыть" - а "Скрыть форму", не "Книгу сохранить" - а "Сохранить книгу". Сначала действие, потом объект. В диаграммах другого вида (например, DFD) ваш подход был бы уместен - там объект главнее, а действие промежуточно. Но вы строите дракон-схему.
В общем не могу назвать вашу дракон-схему удачной. Она не отражает логику работу проекта, есть отдельные ясные фрагменты про загрузку форм, но общая картина - увы. В картинках выше я предложил исправлния. Если их склеить в кучу, то получится обыкновенный (хоть и широковатый) примитив. Я вижу ваш алгоритм, как примтив, начинающийся с вопроса, продолжающийся телом в виде переключателя в зависимости от нажатой кнопки и дальнейшими операцияями по открытию форм, изменений листов, закрытию кник, блокировками и разблокировками кнопок, и зацикливанием в конце снова к иконе "Вопрос".
|