Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Rom от 21 Января 2011, 11:04:45
-
Здравствуйте.
Необходимо дополнить ТЗ диаграммой. Что это за диаграмма будет - непонятно.
Подскажите, пожалуйста, нотацию и пример диаграммы для описания сценария функционирования разрабатываемой формы.
-
Последовательностей или деятельности
-
Да. То, что выше - в UML
-
Диаграмма состояний - она же конечный автомат.
Способов много.
-
На мой взгляд, форма сама поведения не имеет. Поведение "рождается" при взаимодействии с кем-то.
Т.к. этот "кто-то" - внешний, ближе - диаграмма деятельности.
Если нужно очень детально, структура формы м.б. представлена диаграммой классов. Тогда диаграмма деятельности может содержать нужных участников (потоки).
У диаграммы последовательности есть маленькое ограничение по использованию элемента аctor: actor не может иметь операций, а значит не может принимать сообщений, кроме возвратных.
Диаграмма состояний, на мой взгляд, плоха (в этой ситуации) тем, что форма, в отличие от контроллера, не генерирует событий, она их только принимает. Т.е., нарисовать-то можно, наверное, будет понятно, но не шибко корректно.
-
На мой взгляд, форма сама поведения не имеет. Поведение "рождается" при взаимодействии с кем-то.
Форма генерирует события, что все-таки можно назвать поведением, кроме того форма может содержать первичную логику для проверки данных, которые вводятся.
Т.к. этот "кто-то" - внешний, ближе - диаграмма деятельности.
Если нужно очень детально, структура формы м.б. представлена диаграммой классов. Тогда диаграмма деятельности может содержать нужных участников (потоки).
На диаграмме деятельности трудно показать асинхронное взаимодействие, а пользователь ведь общается с формой асинхронно.
Если показывать как пользователь по событиям ходит от формы к форме, то диаграмма состояний подходит лучше всего.
У диаграммы последовательности есть маленькое ограничение по использованию элемента аctor: actor не может иметь операций, а значит не может принимать сообщений, кроме возвратных.
Если Actor - человек, то конечно у него нет никаких операций. Операции должны быть у другого действующего лица (Дисплей, Устройство выводы, называйте как хотите). Конечно если нужна такая степень детализации.
Диаграмма состояний, на мой взгляд, плоха (в этой ситуации) тем, что форма, в отличие от контроллера, не генерирует событий, она их только принимает. Т.е., нарисовать-то можно, наверное, будет понятно, но не шибко корректно.
Она их именно генерирует и некоторые даже обрабатывает. Например, выделение мышью текста в текстовом окне.
-
Ну, все зависит от используемой технологии.
Давно тому назад описание формы включали прямо в текст большой программы, и внутри делалось все. Потом граничные классы придумали, которые только принимают и передают на обработку контроллеру. Потом этого показалось мало, и стали обработчики в форму включать. Потом еще чего-нибудь будет!
У меня возражений нет.
Что касается субъекта на диаграмме, то замена его на дисплей вряд ли сделает ее корректнее. Дисплей, скорее всего, не сумеет принять решение в ответ на сообщение формы. К тому же, нужно в нем (в классе, например, который представляет этот дисплей, создать операцию, выполняющую запрос (сообщение).
Но из моей практики, то ограничение, о котором я написал, действительно не является ужасным: субъект реагирует на возвратные сообщения, среди которых м.б. и диагностика о неправильных действиях.
Но все эти рассуждения в пользу бедных. Те, кто регулярно занимаются разработкой, постоянно решают вопросы, как передать ту или иную мысль, и, как правило, успешно, не нарушая синтаксиса и семантики.
-
Надо сказать, что при описании формы и её поведении одной диаграммы мало.
Необходимо описать структуру, поток данных и связи между "соседними" формами приложения, и уже после приступить к описанию сценария функционирования.
Как мне всё это видится в рамках нотации UML:
1. Каждый элемент управления может быть описан как класс со своим стандартным набором атрибутов и методов. Таким образом, структуру формы можно изобразить диаграммой классов, со связями типа ассоциации или агрегации.
2. Потоки данных между смежными формами можно, на мой взгляд, изобразить с помощью той же диаграммы классов или диаграммы потока данных.
С первыми двумя пунктами как будто бы проблем нет.
3. Описание схемы функционирования мыслилось следующим образом: Диаграмма классов пункта 1 описывает начальное состояние формы после загрузки (если не требуется параллельный запуск каких-либо процедур), т.е. это состояние можно детально не расписывать. Далее форма реагирует на действия пользователя, т.е. в системе возникают инициированные пользователем события, на которые форма (система) реагирует запуском процедур (в том числе и генерацией системного события) и/или изменением атрибутов других элементов управления внутри формы. Получается, что форма меняется от одного состояния к другому. Предполагаю, что для каждого события нужно будет показывать начальное и конечное состояние, между которыми будут помещены блоки процедур, триггеров и запросов. Сами состояния, как мне кажется, следует характеризовать набором классов (элементов управления), для которых будут изменяться их атрибуты.
Вроде бы всё понятно, а когда дело доходит до реализации... непонятны конкретные механизмы связывания объектов, непонятно как будет все это выглядеть, если необходимо учитывать разграничение ролей системных пользователей. И потом, если будет много элементов управления, то описание классами и событиями делает диаграмму ненаглядной. Дробить на несколько частей?
А самое главное: мне как новичку в этом деле хотелось бы видеть конкретные примеры из Вашего опыта, если таковые существуют.
-
Какая-нибудь книжка по UML под руками есть?
Если сейчас начать все описывать "от Адама"...
Опыта больше, чем нужно. По запросу:
1. Совершенно правильно
2. Первый вариант неверный. В UML2 есть "постепенно забываемая" диаграмма коммуникаций. Очень похожа на диаграмму классов, но вместо классов - экземпляры классов, а вместо ассоциаций - сообщения, которые нумеруются в порядке выполнения. Получается очень запутанная паутина, если взаимодействий много.
Диаграммы потоков данных в UML нет.
3. Совершенно неправильно.
Выше предлагались три варианта для UML: Диаграммы деятельности (activity), последовательности (sequence) или состояний (state machine).
С точки зрения теории, правильнее всего (в данной ситуации) рисовать диаграмму последовательности. Но она получается почти необозримой, если много участников и, особенно, много "if-ов". Есть способы "проваливаться" в поддиаграммы, но за один день их точно не освоить.
Можно использовать диаграмму деятельности. Там есть понятие "дорожки" (partition), каждая дорожка - участник. Диаграмма позволяет перекидывать мячик между участниками. Мячиком могут быть данные. А действия - операциями. Все понятно и просто, но не очень корректно.
Для формы м.б. составлена диаграмма состояний, но на ней трудно показать участников. Скорее всего, она не подходит.
В любом случае, книжку посмотреть надо. Там примеры есть.
-
Спасибо за содержательный ответ, Inew.
Пункт 2 - соглашусь с Вами, а вот по 3-му...
Согласен, проблем нет отображать сценарий для отдельных пользователей в виде пулов и дорожек на диаграмме. Проблема в другом. Все предлагаемые в качестве решения диаграммы - не подходят в том плане, что не отображают наглядно изменение атрибутов элементов управления при переходе от состояния к состоянию формы. Единственное... диаграмма последовательностей... надо подумать.
По поводу книжки - я потому и обратился к сообществу, что примеров изображения сценариев функционирования для пользовательских форм ни в книгах, ни в интернет-статьях покамест не встречал.
-
Согласен, проблем нет отображать сценарий для отдельных пользователей в виде пулов и дорожек на диаграмме. Проблема в другом. Все предлагаемые в качестве решения диаграммы - не подходят в том плане, что не отображают наглядно изменение атрибутов элементов управления при переходе от состояния к состоянию формы. Единственное... диаграмма последовательностей... надо подумать.
Для того чтобы описывать изменения состояний объектов в UML существует диаграмма состояний.
Форма - это как композитный объект, он содержит в своей структуре другие объекты имеющие свои состояния и правила перехода между ними.
Диаграмма последовательности мне кажется тут возможно, но вам придется делать их столько сколько возможных протоколов взаимодействия.
В случае же диаграммы состояний - вы строите сложную вложенную машину состояний.
Верхняя - это сама форма с ее возможными состояними - например документ может быть в состояниях - новый объект, Черновик, Проведен
Вложенные машины могут отображать изменения состояний контролов (объектов формы) в зависимости от тех или иных событиях (изменений значений других контролов, нажатия на кнопки и т.п.)
Весь вопрос - вам это действительно нужно? Может просто предоставить скриншоты форм с выделением ключевых моментов и оисанием порядка изменения, типа слайдшоу?
-
Коллеги, не нужно усложнять жизнь .... для начала нужно понять, зачем вообще нужны "картинки", кроме этого речь идет о ТЗ, а не о дизайне .... или есть желание в ТЗ описать дизайн, а не требования??? А так, Ида все сказала.
-
Согласен с Юрием, что в ТЗ на систему никакая из таких диаграмм (для отдельной формы), в принципе, не нужна, и никто из аналитиков на практике ее рисовать не будет! Но здесь студент! Может, это главная фишка в работе!
С другой стороны, если он все же хочет это сделать:
Rom меня не понял. Я не советовал "отображать сценарий для отдельных пользователей в виде пулов и дорожек на диаграмме". Я писал, что если нарисовать диаграмму классов, то в виде участников (дорожек) допустимо изобразить экземпляры классов, в виде действий - операции классов, а в виде параметров операций - объекты данных, содержащие атрибуты классов.
Многие скажут, что так не делают, но, смею вас заверить, ни один валидатор UML не увидит здесь ошибки!
Информация в точности соответствует информации диаграммы последовательности, только форма необычная.
Диаграмма последовательности же имеет только один недостаток: сложное описание логики.
Эдуард! А зачем рисовать отдельную диаграмму для каждого сценария? Это в UML 1.x надо было. В UML2 в диаграмму можно включать множество структур управления (если правильно помню, их 12 штук, любой условный переход!). И нарисовать легко. Только прочитать трудно!
Диаграмма состояний, все же, предназначена для описания состояний одного классификатора, большого или маленького, со множеством подсостояний, но одного.
Есть еще одна диаграмма, о которой все забыли, т.к. мало инструментов, которые ее реализуют.
Это диаграмма обзора взаимодействий: основа - диаграмма деятельности, действия представляются диаграммой последовательности. Чтобы изобразить такую диаграмму нужен дисплей размером ... ох!
Я такую диаграмму рисовал "искуственно" так: диаграмма деятельности, где действия - это CallBechavior. Каждое поведение - это взаимодействие, т.е. действие раскрывается отдельной диаграммой последовательности.
Примечание: Диаграмма обзора взаимодействий реализована в Rational Softvare Architect версии 8.0. Версия вышла очень недавно, я рисовать не пробовал: пока не понадобилось!
-
Надо сказать, что при описании формы и её поведении одной диаграммы мало.
Необходимо описать структуру, поток данных и связи между "соседними" формами приложения, и уже после приступить к описанию сценария функционирования.
Коллеги, не нужно усложнять жизнь .... для начала нужно понять, зачем вообще нужны "картинки"
Действительно, к чему усложнять. Картинка полезна для описания переходов между формами. Остальное, если нужно, можно без потери качества выразить текстом.
Чтобы описать структуру интерфейса, использую диаграмму состояний (пример в приложенином файле).
Диаграмма состояний, все же, предназначена для описания состояний одного классификатора, большого или маленького, со множеством подсостояний, но одного.
Думаю, формально ее можно рассматривать как диаграмму состояний фокуса ввода.
-
Чтобы описать структуру интерфейса, использую диаграмму состояний (пример в приложенином файле).
То что находится в приложении можно назвать описанием структуры интерфейса, но это никак не диаграмма состояний.
-
Чтобы описать структуру интерфейса, использую диаграмму состояний (пример в приложенином файле).
Думаю, формально ее можно рассматривать как диаграмму состояний фокуса ввода.
Действительно, аналитик и проектировщик могут использовать любые средства для "донесения" своей мысли. Текст, иллюстрации. Но простите, при чем здесь диаграмма состояний UML?
Есть очень простой способ: запустите валидацию в инструменте моделирования. Уверяю Вас, самого большого монитора не хватит, чтобы показать все ошибки!
Диаграмма состояний UML контекстна: она описывает состояния владельца. Попробуйте, например, в инструменте перетащить элемент диаграммы к другому владельцу. Фиг!
А теперь попробуйте то же самое сделать с классом. Да запросто!
-
Диаграмма состояний UML контекстна: она описывает состояния владельца. Попробуйте, например, в инструменте перетащить элемент диаграммы к другому владельцу. Фиг!
А теперь попробуйте то же самое сделать с классом. Да запросто!
Извините, я неточно выразился. Следует читать "элементы диаграммы состояний контекстны: они отражают состояния владельца!
Дальше все правильно.
-
Действительно, аналитик и проектировщик могут использовать любые средства для "донесения" своей мысли. Текст, иллюстрации. Но простите, при чем здесь диаграмма состояний UML?
Вы, несомненно, правы. Предложенный мной подход не претендует на соответствие стандарту. Он просто удобен для решения поставленной автором темы задачи: "...для описания сценария функционирования разрабатываемой формы".
Более "стандартных" (но в то же время доступных для восприятия человеком ) ) примеров пока никто здесь не предложил.
-
Юра Булуй вполне резонно указал, что такое описание на практике никому не нужно.
Для определения требований к интерфейсу с пользователем-человеком вполне достаточно диаграммы деятельности. Из описания к этой диаграмме (поля документирования каждого модельного элемента) должно быть ясно, какие средства управления (поля, кнопки и т.д.) нужны для реализации.
Иногда проектировщик делает диаграмму классов (граничных, по терминологии моделирования анализа). Окна, области, поля и т.д.
Для любого разработчика этого достаточно!
Средства управления, как правило, между собой не взаимодействуют.
Ну, а если форма в процессе заполнения взаимодействует с сущностями или контроллером (подсказки, запуск операций), так это не моделирование формы, а моделирование реализации прецедента (use case realization). См. RUP, там все очень подробно описано.