2551
Системный Анализ и Требования / Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
« : 27 Ноября 2008, 12:57:47 »
Ну да, еще взяли ВИ и переименовали в функции

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Это все верно. Читал статейку ...А ссылку можно?
Дальше РУПа послать не могу, ближе тоже.Действительно, в РУП написано, что ПВИ - это часть ДВИ. Но про ПВИ сказано, что он служит только для группировки ВИ или ДЛ, но не сказано про то, что ДЛ могут быть связаны с ПВИ зависимостью:
Пакет вариантов использования (ПВИ) является одним из артефактов RUP. При его изучении мне доводилось встречать ПВИ на диаграммах вариантов использования для бизнес-моделирования и работы с требованиями.С ПВИ я согласен - это пакет со стереотипом <<use case>>, это никто не запрещает делать. Но что ПВИ - это артефакт РУП, я слышу впервые, можно ссылочку.
Указанная диаграмма из суперструктуры позволяет объединять варианты использования в ПВИ, насколько я могу разобраться.Вот тут я Вас не понял. Какая Д из какой суперструктуры?
Хочу немного своего мнения внести.Энто как ты будешь использовать Компоненты также?
Во-первых. Нужно определится в чем цель моделирования вариантов использования? Если цель в строгом соблюдении UML, то использование dependency между актором и пакетом нельзя, тк актор может быть связан только с ВИ, компонентами, классами и др акторами. В таком случае нужно использовать компоненты, точно также как пакеты, но на практике это не всегда удобно.
Я же, когда использую пакеты, пытаюсь достичь двух целей:1. Структурирование модели. 2. Понятность модели для команды разработки и заказчика.1. Я не против такого использования, но просто как правило ДЛ не участвует во всех ВИ данного пакета, а, во-вторых, ДВИ с Пакетами и ДЛ может получиться нечитаемой, т.к. одно или несколько ДЛ будет связано со всеми Пакетами, и поэтому данный вид Д нужно использовать осторожно (не все еще ДВИ одолели то).
Во-вторых. Я не первый кто это использует. Связь акторов с пакетами я подсмотрел в книге Podeswa "UML for the IT Business Analyst" (стр. 94-98) и просто оформил это как паттерн, потому что мне так удобно работать. Тот же Овергаард использует подобную связь в паттерне Lecacy System.
В-третьих. Современные CASE позволяют устанавливать такие связи, следовательно, про них можно сказать что они 100% не соблюдают правила UML.
ЗЫ Связь зависимости между акторами и пакетом показывает, что актор инициирует ВИ (участвует в ВИ), которые принадлежат пакету
Долго боролся с собой на предмет отвечать или нет. Решил, что закончу дискуссию со своей стороны.Жалко, что мы не пришли к единому мнению
По-моему, это уже похоже на холивар.Просто заведомо неправильное использование элементов и Д приводит к большему непониманию, чем к его облечению, где было уже обсуждение - зачем нужны стандарты ...
Как можно запретить использование каких-то элементов на диаграмме? Если они облегчают понимание - не вижу препятствий.
Мой пост о том, что на метамодели диаграммы не показываются.... и вывод, который сделал из рисунка о том, что Пакет не может использоваться на ДВИ (кстати правильно диаграмма использования, а не диаграмма вариантов использования) мне не ясенТы прочитал п. 16? Там есть хоть одно упоминание о пакете? Или где-то еще в спеке говориться, что Пакет можно использовать на ДВИ?
Use Case Diagrams are a specialization of Class Diagrams such that the classifiers shown are restricted to being either
Actors or Use Cases.
Более того никто не запрещает придумывать новые диаграммы. Просто надо следовать правилам о том, какие отношения между какими сущностями возможны, а какие нет.Так ты сам сказал, что "Сущности (например, ДЛ) могут либо принадлежать пакету, либо нет". Так как ты себе представляешь ДВИ с пакетом? Можешь пример привести.