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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - lnew

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
166
Модель (а не диаграмма) UC должна отвечать на большинство вопросов, поставленных DinamoYA.
(Эта модель не должна отвечать, как устроена система.)

Но диаграмма UC - это только часть модели.

Выше в этой теме уже говорилось, что, в соответствии с UML, каждому UC соответствуют:
- краткое описание назначения этого UC (оно раскрывает название)
- описание последовательности взаимодействий участников (в виде диаграммы деятельности (тоже комментированной описаниями каждого узла) или в виде текстового описания).

Если вы хотите все это представить на одной диаграмме UC, Вам просто не хватит нотаций (два типа сущностей и до пяти типов отношений (вместе со стереотипами!))
Критике такого подхода Коберн посвятил почти половину своей книги.

Но мы уже начали "перепевать" тему по третьему разу. К сожалению, новые участники не читают дискуссию с начала.

167
По actor = субъект можно обратиться в IBM.

А если по русски, то в старом словаре по системотехнике я нашел такой термин: актор (от англ. actor) - субъект взаимодействия в системе. Правда, это было очень давно, и с тех пор человеческая фантазия родила "актера" и т.д.
М.б. IBM-овские переводчики нашим словарем воспользовались?

168
Спасибо, что помог сформулировать мне мой вопрос:)

Итак.
Должна ли диаграмма использования отражать ВСЕ эффекты использования системы?

А что такое эффекты? Тем более ВСЕ?

Диаграмм, обычно, рисуют много, каждая для иллюстрации чего-то:
- обзор главных use cases системы
- все use cases определенного ator-а
- контекст определенного use case

Для достаточно большой системы все use case на одной диаграмме никогда не рисуют.

Но
полный список всех use case должен охватывать цели обращения к системе всех actor-ов.

169
Ну, тут уж я додумываю. Я же не эту конкретную задачу решаю. Как я понимаю, мы с обсуждения совершенно абстрактной диаграммы начали, и цели разработки продукта, и даже требований, не ставили. Если это не так, извините.

Считается, что аналитик, по крайней мере в общем случае, не должен ограничивать проектировщика. Черт его знает сейчас, какие устройства там будут. Но что деньги будет брать приемное устройство, понятно. М.б., это будет манетоприемник, может - щель в крышке. То же и про деньги. Если там написано "купюры", значит я не о том думал, когда писал. Самое нейтральное, наверное, "дензнаки".

170
Во первых, не все так плохо.

Спецификация каждого use case, полученная с помощью диаграммы деятельности или по Коберну (я генерю спецификации по своему шаблону из диаграмм, и они получается точь в точь, как описания Коберна) - это почти готовый тесткейс (добавить, что ввести и что ждать). Почти готовое руководство пользователя.
Когда в диаграмме описываются взаимодействия, они могут описываться в термина граничных классов анализа (boandory).

Диаграмму последовательности многие используют как раз для поиска необходимых модельных элементов. Есть такая замечательная книжка Лармана: Применение UML и шаблонов проектирования. И в RUPе, насколько я помню, эта технология используется.

Откуда брать классы? Придумывать? Не метод для проектировщика, и тем более для аналитика! Смотрим на диаграмму Эдуарда. Там в описании написано:
- Система выводит сообщение о необходимости оплаты
- Пользователь вводит в приемное устройство купюры достоинством ...
      На диаграмме создаем линию жизни приемного устройства. Это экземпляр граничного класса. Думаем, создаем класс. От пользователя рисуем сообщение (принятьДеньги()) к созданной ранее линии жизни устройства. В классе ручками или автоматом создаем операцию с тем же именем.
      Скорее всего, устройство приема будет идентифицировать дензнаки и считать. Соответственно нужны приватные операции идентифицироватьДензнак() и т.д.
      Для хранения суммы создаем атрибут.

И т.д. по диаграмме деятельности (или по описанию Коберна).
Необходимые классы, их атрибуты и операции "вытекают" из логики use case. Use Case - очень продуктивная идея!

При реализации следующего use case какие-то элементы уже есть. Может быть, к ним надо добавить атрибуты и операции, или использовать уже имеющиеся.

Конечно, это еще не окончательные классы. Разные языки, платформы, особенности технологии! Но такую систему можно сделать!

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

Далее я предложу еще такую примитивную диаграммку.
Тут уже класс и его операции методы, а они суть его ответственности, которые выводятся возможно из вариантов использования, и возможно из деятельностей.

Или может следовало бы показать структуру этого автомата через его части?

Если есть разделение на аналитиков и разработчиков, то диаграмма классов - это уже реализация. Аналитик, как правило, не должен ограничивать разработчика в способах реализации требований.

К диаграмме деятельности эта новая диаграмма ничего не добавляет.

Если в жизни, дальше нужно создавать модель анализа или проектную модель, в которой для каждого use case создавать кооперацию use case realization и рисовать диаграммы последовательности, имея перед глазами соответствующую диаграмму деятельности.

Я иногда такой курс читаю в московском Интерфейсе. Правда, я основной упор делаю на "беззатратное" документирование проектов разработки ПО.

172
Вообще, спецификация UML подразумевает, что любой модельный элемент должен иметь краткое описание.
Этого описания д.б. достаточно только для принятия решения "делать-не делать". Но ничего о том, как делать.

В определении Use Case говорится, что это описание последовательностей (экземпляров) взаимодействий.
- UML предложил описывать с помощью диаграмм деятельности (элементы диаграммы тоже должны иметь описания!)
- Коберн, к тому времени не читавший UML, предложил шаблон текстового описания, вполне справедливо считая описание процессов с помощью UC diagram "блудом" (но этого в UML и не предлагалось). Все начало книжки этому посвящено!

Т. о. становится понятно, что должна делать система в ответ на действия пользователя, но ничего о том, как она должна работать. Там может и не быть упоминания "монетоприемника", но там должно быть написано, что система берет деньги, считает, дает сдачу и т.п. (диаграмма, которую представил Эдуард).
Работа аналитика (роли) на этом заканчивается, если не считать поддержку в актуальном состоянии в связи с изменением взглядов пользователя или разработчиков.

К стати, именно эта часть бизнес-процесса (не до конца) представлена на моем фрагменте выше.

Ну, и так далее.

Резюме: фактически перечень прецедентов - это несколько иное представление целей всех потенциальных пользователей. А их описания представляют функциональные (что должна делать) требования к системе.

Спасибо тем, кто прочитал эту нудятину до конца! 

173
я еще не так могу выражаться :о))) поверьте на слово. а если серьезно, мы же говорим о некоем конкретном процессе  получения билета. соответственно, в данном случае должна идти речь о конкретном результате: "билет получен" (в данном случае наличие сдачи несущественно, ибо это как раз один из вариантов) или "билет не получен, деньги возвращены" (мало ли передумал или денег не хватило).

IMHO будет лучше не "варианты", а "элементы","функции","составляющие" и т.п., т.е. то, из чего процесс состоит. но может и весть процесс описывать.

Я опять неточно выразился: use case (класс) описывает все возможные варианты (в том числе - неудачные) достижения цели. Под вариантом я здесь понимаю совокупность "одинаковых" экземпляров (в смысле "пути" выполнения).

Что касается "билет получен", то цель пользователя системы состоит только в этом: корректно получить билет (со здачей и т.п.) Но цель обращения к системе одна, и Use Case один! (Если не плодить UCE и/или UCI). И Эдуард правильно поступил, нарисовав диаграмму деятельности. Скорее всего, этот небольшой Use Case не будет иметь существенных (сложных, требующих отдельного описания и планирования, частей.

Примечание: В RUP имеется ввиду архитектурная существенность.

174
Эдуард, не нашел как в личных сообщениях вставить картинку.
Не всем это интересно.

Это фрагмент описания бизнес процесса (в RUP - синоним BUC) ("белый ящик").
Диаграммы представлены с целью показать использование некоторых новых (относительно UML1) элементов диаграммы деятельности UML2.

175
Извини.
Я невнимательно прочитал. Увидел слово Субъект. А в русском переводе RUP 7.x Субъект = Actor.
Наверное, нужно использовать английские слова.

Если пассажир - actor, а манетоприемник - system, то все правильно.

Такие системы стоят, например, в церкви для сбора пожертвований прихожан. Но это же вырожденный случай.

Я сейчас попробую тебе выложить две диаграммки про Merge и Fork.

176
Нет не поясняет (в смысле не полностью поясняет), нет не устраняет (необходимость и корректность второй UC пока не очевидна).


Обоснование?

177
Я-таки, не понял :)
Может быть вариантом использования: вернуть деньги, выдать сдачу, выдать билет, принять деньги?

Да и вопрос, а если Actor = Пассажир, а Субъект = Монетоприемник, чья единственная функция - принимать монеты

Будет ли это правильно?

Выражаю свое мнение по второму вопросу (по первому повторяться смысла нет).

Если у монетоприемника есть цель, и он может привлечь пассажира, то можно, только у ассоциации нужно стрелку поставить, что манетоприемник инициирует взаимодействие.
В жизни ситуация нереальная. Он что, в зале ожидания будет человека за руку хватать?
Иначе это будет "проход через турникет", см. выше все обсуждения.

178
А нарисовать? Что много буковок и трудно понять о чем речь

Рисовать не умею.
Могу диаграмму прислать по почте.

Merge обозначается таким же ромбиком, как Decision, но Decision имеет один вход и много выходов по условию, а Merge- много входов и один выход.
В UML1 Merge небыло, а Decision допускал много входов и много выходов. Любой сигнал проскакивает без задержки.

Fork и Join. В UML1 была "полоса синхронизации" (не помню, как элемент назывался) для распараллеливания потоков. Сколько из первой полосы вышло, столько должно войти во вторую. Пока не войдут все, курсор дальше не идет.
В UML2 Fork - это элемент, обозначающий разветвление: один вход и множество (безусловных) выходов. Каждая нить может выполняться, и может либо объединиться с другими потоками управления в элементе Join, либо завершиться узлом Activity Final (завершается весь процесс) или Flow Final (прекращается только эта нить управления).
Элемент Join: много входов и один выход. Те потоки, которы прибежали раньше, ждут, пока не придут все.

179
В общем случае, процесс может и не иметь выраженной цели. Пример: "Это вполне естественный природный процесс!"

Экземпляр UC описывает процесс взаимодействия (у Коберна - Actor & Actor, в UML - Actor & System). UС - это совокупность всех возможных вариантов процесса (в том числе - неудачных) для достижения цели первичного субъекта (primary actor) в UML и всех взаимодейстующих субъектов (у Коберна).

В книжке Коберна (русский перевод): глава 2, Вариант использования как соглашение о поведении, раздел 2.1, Взаимодействие действующих лиц, имеющих цели.

В RUP - рекомендации по именованию: название должно раскрывать цель первичного актера.

Что прецедент описывает варианты процесса, я думаю, сомнения не вызывает.
Но в принципе, критика правильная: то, что написал аналитик, не должно допускать толкований.
 

180
неее, не надо путать отождествлять процесс и use case.

Не понял критики?

Безусловно, Use Case описывает некоторый особый процесс, определенный в UML. М.б. я выразился некорректно.
А что по смыслу неверно?

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »