Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Bidonne от 13 Июня 2016, 17:08:59
-
Народ, посмотрите пожалуйста на мои жалкие попытки описать логику ИС. Буду рад любым замечаниям.
https://drive.google.com/file/d/0B0TjxZfnsbu5aEhZS0Z1VzFCWVU/view?usp=sharing
-
Если стояла цель добавить в работу иллюстрации, которые трудно читать по существу, зато на которых легко разглядеть элементы UML-нотации, то попытку можно зачесть.
Если была нужна модель, то вот перечень сомнительных мест:
1) На диаграмме ВИ в ВИ Просмотр документа участвуют два действующих лица Руководитель и Сотрудник. Вероятно Вы хотели показать, что просматривать могут и тот и другой (странно, что другим нельзя), но получилось, что в любом просмотре должны участвовать и тот и другой. То есть в сценарии этого варианта по Вашей версии будут шаги системы, шаги руководителя и шаги сотрудника. И если сотруднику захочется просмотреть документ, то придётся отвлекать от работы руководителя. Аналогичные замечания можно сделать ко всем ВИ, связанным с 2мя или 3мя действующими лицами.
2) На диаграмме деятельности есть дорожка действующего лица Ответственный, которого не было на диаграмме ВИ.
3) В отдельных местах диаграммы деятельности за узлом действия Отправка уведомления следует узел Получение уведомления, но почему-то так происходит не всегда.
4) Диаграмма деятельности громоздка и не соответствует никакому отдельному ВИ. Разумнее для каждого отдельного ВИ составлять отдельную диаграмму деятельности. Каждая такая диаграмма будет меньше, проще для чтения. Общую обзорную диаграмму деятельности также можно составить, но из более крупных блоков, ссылающихся на поддиаграммы для отдельных ВИ.
5) Отсутствие стрелок на диаграмме деятельности добавляет двусмысленность. Например, неочевидно, что в узел действия Заполнение шаблона входят два потока управления и выходит один, а не наоборот.
-
Спасибо огромное за отзыв. Все по делу. Я не могу понять, как можно корректно отразить в ВИ использование одного и того же элемента несколькими участниками.
-
Спасибо огромное за отзыв. Все по делу. Я не могу понять, как можно корректно отразить в ВИ использование одного и того же элемента несколькими участниками.
Что значит одного и того же элемента?
По существу, у каждого варианта использования должен быть единственный эктор: основное действующее лицо, интерес которого удовлетворяется этим вариантом использования. Грубо - есть ВИ: Найти книгу - эктор: Искатель книги.
-
Что значит одного и того же элемента?
По существу, у каждого варианта использования должен быть единственный эктор: основное действующее лицо, интерес которого удовлетворяется этим вариантом использования. Грубо - есть ВИ: Найти книгу - эктор: Искатель книги.
А если вариант использования может быть использован разными экторами в своих интересах?
Или непременно нужно вводить под такой ВИ общего пользования специального эктора и еще придумывать, как его связать с каждым из интересантов?
Ну типа Искателя книг ассоциировать с Читателем, Библиотекарем и со всеми , у кого может возникнуть ВИ Найти книгу?
И если можно дайте ссылочку на то , что две ассоциации между двумя акторами и ВИ интерпретируются как то, что два актора должны участвовать в ВИ обязательно вдвоем. Актор в ВИ - инициатор. Почему две ассоциации не могут быть интерпретированы, что каждый из акторов может иницииировать ВИ?
-
А если вариант использования может быть использован разными экторами в своих интересах?
Или непременно нужно вводить под такой ВИ общего пользования специального эктора и еще придумывать, как его связать с каждым из интересантов?
Да, Вы правы, конечно ДЛ - это множество логически взаимосвязанных ролей. Я лишь пытался ответить на вопрос и одновременно понять, что имел в виду Bidonne. Если мы рисуем один ВИ и два и более ДЛ, то тут возможны варианты:
1. все ДЛ играют какую-то единую общую роль в этом ВИ - т.е. являются инициаторами этого ВИ и инициаторами единичными (хотя можно найти задачу, в которой инициаторов может быть несколько). В это ситуации мы можем мысленно заменить ДЛ некой ролью. Иначе может получиться, что ВИ Искать книгу Читателем может как-то отличаться от этого же ВИ Библиотекарем. Это я имел в виду
2. Одно ДЛ основное, остальные вспомогательные, т.е. один инициирует ВИ, другие помогают достичь его цели.
Ну типа Искателя книг ассоциировать с Читателем, Библиотекарем и со всеми , у кого может возникнуть ВИ Найти книгу?
В определенной ситуации это было бы полезно. Но на самом деле ДЛ важны лишь до определенной степени.
И если можно дайте ссылочку на то , что две ассоциации между двумя акторами и ВИ интерпретируются как то, что два актора должны участвовать в ВИ обязательно вдвоем. Актор в ВИ - инициатор. Почему две ассоциации не могут быть интерпретированы, что каждый из акторов может иницииировать ВИ?
Не дам. Более того, я при ответе на пост Bidonne такого вывода не делал явно. Однако,
Пусть мы рассматриваем вариант Искать книгу и определили основных действующих лиц: Читатель и Библиотекарь. Требуется записать основной поток, какой из ДЛ Вы будете использовать в описании шагов?
-
Пусть мы рассматриваем вариант Искать книгу и определили основных действующих лиц: Читатель и Библиотекарь. Требуется записать основной поток, какой из ДЛ Вы будете использовать в описании шагов?
В зависимости от ситуации:
1 вариант
Если ВИ некритичный по безопасности, то вешал бы всех собак на Пользователя (какого-нибудь предка Читатель и Библиотекарь). Пусть там сами разбираются, нужен им этот ВИ или нет.
2 вариант
Выделить специального актора , а в Читателя и Библиотекаря сделать генерализацию
3 вариант
Если ВИ редкоиспользуемый, то в описании ДЛ так и определить: ДЛ - Библитекарь или Читатель
-
По-моему у нас гармония в понимании :)
-
4й вариант: [по последней моде] указывать мощности и др. ограничения на ассоциациях с диаграмм ВИ.
-
4й вариант: [по последней моде] указывать мощности и др. ограничения на ассоциациях с диаграмм ВИ.
А можно примерчик? Как отразить через мощности, что Читатель и Библиотекарь ищут книгу каждый сам по себе, а уточняют задолженность Читателя только вдвоем?
-
Чувствую себя студентом на комиссии.
-
Чувствую себя студентом на комиссии.
Спасибо большое. IMHO с точки зрения выразительности важна даже не мощность, а уточнения отношения между самими ассоциациях (и, или / или, и/или)
Кстати в силу чего считается, что по умолчанию И?
-
Оказывается не так у редко такой прием встречается
(http://www.intuit.ru/EDI/25_12_15_1/1450995683-14467/tutorial/92/objects/6/files/6-3.gif)
-
Кстати в силу чего считается, что по умолчанию И?
Начиная с какой-то версии UML появилось дурацкое правило, что неуказанная мощность полюса равна 1 (т. е. 1..1).
Авторы примера про счета неточны. Минимальные мощности на полюсах возле юрика и физика должны быть 0. В текущем виде диаграмма не допускает ни одной конфигурации экземпляров и соединений, соответствующих ей.
-
Начиная с какой-то версии UML появилось дурацкое правило, что неуказанная мощность полюса равна 1 (т. е. 1..1).
Да вот с мощностями проблем нет. Редко сталкивался с необходостью использования системы группой лиц по предварительному сговору:)
А вот втыкал две ассоциации в один ВИ частенько... Искренне считая, что по умолчанию xor
-
Да вот с мощностями проблем нет. Редко сталкивался с необходимостью использования системы группой лиц по предварительному сговору:)
А вот втыкал две ассоциации в один ВИ частенько... Искренне считая, что по умолчанию xor
Надо заметить, что попытки сделать диаграмму ВИ подвидом диаграммы классов мало продуктивны, на мой взгляд. Но почему-то подкреплены стандартом. Того гляди, у ВИ вырастут квалификаторы, появятся N-арные связи и другая чертовщина. Именно превращение туманных коммуникаций в подвид ассоциаций и применение к ним дефолтных единиц и определяет трактовку "И". А по дефолту лучше бы пошёл 0..1 и XOR.
-
Скажите, а в таком виде, корректна диаграмма?
(http://s017.radikal.ru/i440/1606/25/aefe460e442d.png)
-
Скажите, а в таком виде, корректна диаграмма?
Может она конечно и корректна. Но большие сомнения, что кому - то нужна.
Создание диаграммы вариантов использования имеет следующие цели:
Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы
Сформулировать общие требования к функциональному поведению проектируемой системы
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей
Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями
Какие из этих целей преследует эта диаграмма? Насколько она их достигает?