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

×


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

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


Сообщения - Rom

Страницы: 1
1
Спасибо за содержательный ответ, Inew.
Пункт 2 - соглашусь с Вами, а вот по 3-му...
Согласен, проблем нет отображать сценарий для отдельных пользователей в виде пулов и дорожек на диаграмме. Проблема в другом. Все предлагаемые в качестве решения диаграммы - не подходят в том плане, что не отображают наглядно изменение атрибутов элементов управления при переходе от состояния к состоянию формы. Единственное... диаграмма последовательностей... надо подумать.
По поводу книжки - я потому и обратился к сообществу, что примеров изображения сценариев функционирования для пользовательских форм ни в книгах, ни в интернет-статьях покамест не встречал.

2
Надо сказать, что при описании формы и её поведении одной диаграммы мало.
Необходимо описать структуру, поток данных и связи между "соседними" формами приложения, и уже после приступить к описанию сценария функционирования.
Как мне всё это видится в рамках нотации UML:
1. Каждый элемент управления может быть описан как класс со своим стандартным набором атрибутов и методов. Таким образом, структуру формы можно изобразить диаграммой классов, со связями типа ассоциации или агрегации.
2. Потоки данных между смежными формами можно, на мой взгляд, изобразить с помощью той же диаграммы классов или диаграммы потока данных.
С первыми двумя пунктами как будто бы проблем нет.
3. Описание схемы функционирования мыслилось следующим образом: Диаграмма классов пункта 1 описывает начальное состояние формы после загрузки (если не требуется параллельный запуск каких-либо процедур), т.е. это состояние можно детально не расписывать. Далее форма реагирует на действия пользователя, т.е. в системе возникают инициированные пользователем события, на которые форма (система) реагирует запуском процедур (в том числе и генерацией системного события) и/или изменением атрибутов других элементов управления внутри формы. Получается, что форма меняется от одного состояния к другому. Предполагаю, что для каждого события нужно будет показывать начальное и конечное состояние, между которыми будут помещены блоки процедур, триггеров и запросов. Сами состояния, как мне кажется, следует характеризовать набором классов (элементов управления), для которых будут изменяться их атрибуты.
Вроде бы всё понятно, а когда дело доходит до реализации... непонятны конкретные механизмы связывания объектов, непонятно как будет все это выглядеть, если необходимо учитывать разграничение ролей системных пользователей. И потом, если будет много элементов управления, то описание классами и событиями делает диаграмму ненаглядной. Дробить на несколько частей?
А самое главное: мне как новичку в этом деле хотелось бы видеть конкретные примеры из Вашего опыта, если таковые существуют.

3
Здравствуйте.
Необходимо дополнить ТЗ диаграммой. Что это за диаграмма будет - непонятно.
Подскажите, пожалуйста, нотацию и пример диаграммы для описания сценария функционирования разрабатываемой формы.

Страницы: 1