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

×


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

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


Сообщения - Денис Иванов

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 »
211
Вопрос по статье.
Чем отличается запуск ВИ от инициирования ВИ?

Цитата из статьи
>> Стоит отметить, что спецификация UML не определяет способа представления ветвления и повторения в потоке.
Все есть.

Цитата из статьи
>>UML-стандарта для спецификации вариантов использования или прецедентов (кому, что нравиться) не существует.
1) UML-стандарта нет и быть не может. UML - это язык. Точно также нет стандарта для написания рассказов на русском языке или программ на C++.
2) Все, что написано в статье может быть нарисовано диаграммами UML (и будет выглядеть кстати понятнее, чем просто форматированный текст)
3) По поводу прецедента - сюда
4) В слове "нравится" мягкий знак не нужен:)

Bas, если статьи печатаются от имени членов сообщества (я именно так расцениваю логин - uml2.ru), то я бы минимум проводил review.

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

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

213
greesha, мне интересно посмотреть на вашу диаграмму последовательности, когда клиент посылает повторные сообщения, а особенно ситуацию, когда повторный запрос где-то там сталкивается с ответом на первый запрос.

Я бы так представил это. Есть ПРОТОКОЛ - конечный набор НЕЗАВИСИМЫХ хороших и плохих ситуаций, возникающих при взаимодействии нескольких элементов системы. Каждую такую ситуацию можно описать ДП. Некоторые ситуации можно описать и одной ДП, если они не сильно отличаются. Но в общем случае суперпозицию нескольких ситуаций нельзя описать ДП. Мы получим то, что вот тут изображали

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

214
Денис,
А можешь выложить пример ДП где внутри (где-то по середине процесса\протокола) есть встроенная ДП

http://blog.it-konsulting.spb.ru/?p=249

215
К сожалению, в это случае приходится повторять ДП основного потока для исключения, но по дрогу сделать нельзя. Или я не умею?
Можно нарисовать ДП, а потом на нее ссылаться в другой ДП. Встроенная ДП рисуется как рамка с тегом ref.

216
Протокол - ЗАРАНЕЕ определенная последовательность сообщений, которая может быть зафиксирована в модели, например, на диаграмме последовательности.

Вот смотрите. У вас есть клиент, который шлет запрос на сервер. Имеем два экземпляра чего-либо (клиент и сервер) и посылаем между ними сообщения.
Клиент может либо получить ответ, либо вылететь по тайм-ауту, либо еще как-то. Все это - отдельные диаграммы последовательности.

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

Вернее сделать-то это можно, но количество неадекватных действий очень велико и показывать их нет смысла.

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

217
Диаграмма последовательности описывает протокол взаимодействия. Ключевое слово - протокол.

Кстати Bas, во взаимодействии участвуют не действующие лица, компоненты и пр., а их экземпляры. Например, как заметила ida - объекты, т.е. экземпляры классов.

218
Я думаю, что делать надо так, чтобы всем было понятно, что происходит.
Единого мнения нет, а рекомендаций - сколько угодно.
Свои я написал:)

219
То есть получается, я внешнюю систему (действующее лицо) могу заменить интерфейсным классом, который реализует поведение внешней системы?
Этот вывод вы сделали из моего поста?

220
Да, да, и аппаратные решения тоже включаются.
А может быть подскажете еще вот по какому вопросу: ведь в принципе могут быть разные аппаратные реализации ввода пользователя (экран и клавиатура, либо просто экран, эммм... touchscreen), поэтому я подумал, что пока стадия реализации не началась стоит указать лишь форму ввода и не указывать монитор, клавиатуру. Или все таки надо указать их уже в качестве классов на диаграмме последовательности?

Именно по этой причине я бы выкинул "Интерфейс к ...". Зачем раньше времени предлагать детали реализации?
Детализировать диаграмму всегда успеете.

221
Так, кое-что начинаю понимать :)
1. По поводу принтера: ну допустим, будем писать драйвер, не суть. Все равно программу писать не надо :) Тогда это будет частью нашей системы, правильно?
Вы рисуете модель. Модель вашей СИСТЕМЫ. Прежде чем рисовать ответьте на вопрос - Что есть ваша система? Это важно, так как ДИ показывает что делает система, а для этого надо знать ее границы. То что за границами системы - действующие лица.
По поводу принтера. Если ваша система - набор программных и АППАРАТНЫХ решений (и принтер входит в список аппаратуры), то тогда он - часть системы.

222
2) А почему принтер - действующее лицо? Он же является частью системы.
Ну мне просто кажется, что ваша система - это ПО для терминала. Вряд ли вы будете писать драйвер для принтера, например. Скорее всего возьмете готовое аппаратно-программное решение. Поэтому принтер - вне вашей системы.
4) А почему интерфейс выбросить? Вадь должны же быть очерчены границы системы, разве нет? То есть у меня же ведь должен быть какой-то класс для связи двух систем. Или для этого спокойно можно использовать управляющий класс?
Ну во-первых границ много, а вы взяли только одну. Где драйвера клавиатуры, тогда? Или какие-нибудь диспетчеры для обработки событий от пользователя?
Во-вторых по этой диаграмме все  равно программист ничего не напишет путного. Зачем тогда такая детализация?
5) Ну просто задание такое, там все стереотипы надо указывать. Я бы тоже не применял, наверное, если бы опытнее был в этом деле. А пока вот применяю :)
Ну так вы автору этого задания скажите, что таких стереотипов нет в UML. По-моему RUP-овцы их придумали.

223
Комментарии по поводу последней диаграммы.

Я бы сделал следующее
1) добавил еще одно сообщение от Клиента к Форме (5-ое по счету) - "Выполнить запрос" (кто-то должен дать команду на выполнение), хотя можно считать, как это нарисовано, что все начинается после ввода даты, но для меня это не логично
2) Принтер терминала переделал бы в действующее лицо
3) "Управлять терминалом" переименовал бы в "Контроллер терминала" или "Менеджер терминала".
4) "Интерфейс к ..." выбросил бы
5) не применял бы нотации граничных и прочих классов, а рисовал бы нормальные прямоугольники. Понимаемость диаграммы только увеличится

Ну и в общем...
Есть взять целью отразить на диаграмме сценарий описанный в первом посте, то не понятно, почему не взять ту же диаграмму деятельности?

224
Я просто столкнулся с такой штукой. Некоторые диаграммы у меня из структурного подхода (IDEF0, 1X), некоторые из ОО (use case, классы, развертывания, последователности действий (sequence)).

Есть такая штука - SysML (http://www.omgsysml.org/)

225
Я вот вчера прослушивал доклад Александра Орлова. Презентация не даёт почти никакого представления о том, что он говорил на самом деле.

Так и должно быть (по моему мнению)

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 »