Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы и средства проектирования информационных систем и технологий. Учебное пособие.pdf
С помощью связи обобщения показывают, что у нескольких
действующих лиц имеются общие черты. Например, клиенты могут быть двух типов: корпоративные и индивидуальные. Эту связь
можно моделировать с помощью нотации, показанной на рис. 12.3.
Рис. 12.3. Обобщение действующего лица
Нет необходимости всегда создавать связи этого типа. В общем случае они нужны, если поведение действующего лица одного
типа отличается от поведения другого постольку, поскольку это
затрагивает систему. Если оба подтипа применяют одни и те же
варианты использования, показывать обобщение действующего
лица не требуется.
Варианты использования являются необходимым средством
на стадии формирования требований к ПО. Каждый вариант использования – это потенциальное требование к системе, и пока оно
не выявлено, невозможно запланировать его реализацию.
Задания к работе
1. Изучите операции по созданию модели UML MS Visio на
персональном компьютере.
2. Познакомьтесь со структурой UML-системы, создаваемой в
MS Visio.
3. Изучите возможности работы с проводником по модели
UML.
4. Рассмотрите возможности создания диаграммы вариантов
использования в MS Visio.
5. Опишите сценарии выполнения информационной системы.
111
6. Детализируйте пользовательские требования к информаци-
онной системе.
Методика выполнения работы
1. Запустите редактор MS Visio. Выберите категорию шабло-
нов «Программы и базы данных», шаблон «Схема модели UML»,
нажмите на кнопку «Создать».
2. В проводнике по моделям UML задайте осмысленное имя
информационной системе (например, «Система обработки заказов»), при необходимости возможно изменить имя статической
модели и основного пакета.
3. В проводнике по моделям UML щелкнув правой кнопкой
мыши по папке «Основной пакет», выберите команду меню «Создать» и далее «Схема сценариев выполнения». Все диаграммы
UML за исключением схемы состояний создаются аналогичным
образом.
4. У рабочего листа MS Visio появится название «Сценарий выполнения-1». Поскольку вся модель UML с множеством схем будет
сохранена в одном файле, необходимо давать соответствующим листам более короткие названия. В частности рассматриваемый лист
желательно переименовать в «ДВИ» (сокращенно от «Диаграмма
вариантов использования» – классическое название данной схемы).
Для переименования листа нужно щелкнуть правой кнопкой мыши
по его ярлычку и выбрать команду «Переименовать».
5. В результате создания новой схемы сценариев, автоматически откроется соответствующий шаблон графических элементов
для данной диаграммы.
6. Разместите на рабочем листе элемент «Граница системы»
и дать ему соответствующее название.
7. Разместите на рабочем листе необходимое количество элементов «Сценарий выполнения», соответствующих различным вариантам использования ИС. Каждому сценарию задайте соответствующее название. Для этого нужно дважды щелкните по элементу, и введите в поле «Имя» требуемое название. При этом размер
эллипса, соответствующего сценарию выполнения будет увеличиваться в размерах пропорционально длине его названия.
112
При необходимости расширить/сузить границы информаци-
онной системы так, чтобы все сценарии выполнения разместились
в них.
8. Разместите на рабочем листе необходимое количество элементов «Актер», соответствующих Действующим лицам (внешним
субъектам информационной системы). Каждому актеру дать соответствующее название. Для этого нужно щелкнуть дважды по элементу, и ввести в поле «Имя» требуемое название.
9. Разместите на рабочем листе элемент «Сообщение», который на данной диаграмме будет выполнять роль отношения ассоциации. Это единственный тип отношения на ДВИ, который используется для соединения актеров и сценариев. Все остальные отношения связывают только однотипные элементы. Щелкнуть правой кнопкой мыши по данному элементу и выбрать команду меню
«Параметры отображения фигуры …». В появившемся окне
настроить параметры отображения так, как показано на рис. 12.1.
Чаще всего для элемента «Сообщение» на диаграмме вариантов
использования имеет смысл отображать только направление стрелки (перемещаемость) и в более редких случаях множественность.
Множественность показывает, сколько актеров одного типа
может быть связано с конкретным сценарием, и наоборот – сколько однотипных сценариев может инициировать один актер. По
умолчанию считается, что это количество никак не ограничивается, поэтому по умолчанию ставится значок * (любое число), в связи с чем этот значок можно не отображать, чтобы не загромождать
схему. Также задавая параметры отображения фигуры, в данном
окне желательно отмечать галочками 2 последние команды – это
позволит не повторять одни и те же действия по настройке отображения много раз.
10. Разместите на рабочем листе необходимое количество
элементов «Сообщение», для соединения актеров и сценариев.
В случае необходимости задать направление потока информации.
Для этого нужно дважды щелкнуть по элементу «Сообщение»,
чтобы вызвать для него окно свойств. Далее в разделе «Окончание
ассоциаций» нужно для соответствующего конца поставить галочку в столбце «isNavigable» (перемещаемый).
113
Рис. 12.1 Настройки параметров отображения фигуры «Сообщение»
11. Провести описание сценариев выполнения (прецедентов,
вариантов использования). Описать предусловия и постусловия
выполнения сценариев.
12. Разместите на рабочем листе необходимое количество
элементов «Сообщение», для соединения актеров и сценариев. Соединить актеров с соответствующими сценариями с помощью элементов «Сообщение». В случае необходимости задать направление
потока информации. Для этого нужно дважды щелкнуть по элементу «Сообщение», чтобы вызвать для него окно свойств. Далее в
разделе «Окончание ассоциаций» нужно для соответствующего
конца поставить галочку в столбце «isNavigable» (перемещаемый).
В результате этого на отмеченном конце отношения будет отображаться стрелка.
13. Откройте команду меню UML и нажать на кнопку «Стереотипы». В появившемся окне нажать на кнопку «Создать». Для
114
нового стереотипа задать имя «include» (включение) и базовый
класс – «Обобщение».
Для отношений расширения и включения нужно изменить
внешний вид стрелок, чтобы привести их к виду, который был
предложен создателями языка UML. Для этого нужно выделить на
схеме любое одно отношение расширения или включения, щелкнуть по нему правой кнопкой мыши и выбрать в контекстном меню Формат – Линия. В категории Линия – Шаблон выбрать 09,
в категории Концы линии – Начало выбрать Перемещаемый.
14. Создайте свой набор элементов. Переместите в него стрел-
ку отношения сообщения. В окне шаблона появится Элемент Mas-
ter. Желательно дать этому элементу осмысленное имя, например
Расширение.
15. Разместите на рабочем листе отношения включения в необходимом количестве. Отношения включения также размещаются
аналогично отношению расширения: разместите элемент «Расширение», дважды щелкнуть по нему и в появившемся окне свойств в
списке «Стереотип» выбрать «include». Если в списке такого стереотипа не оказалось, значит была допущена ошибка на предыдущем шаге – скорее всего для стереотипа «include» был задан не тот
класс. Для того, чтобы это исправить, нужно снова вызвать окно
«Стереотипы», найдите в списке данный стереотип и задайте для
него необходимый класс. Произведя настройки для одного отношения в дальнейшем можно применить их и для других подобных
отношений. Для этого нужно сразу же после проведенных настроек выделить другой подобный элемент (или группу элементов)
и нажать на клавиатуре клавишу F4 (повторить последнее действие). Можно использовать и другой способ копирования формата: выделите фигуру, чей формат нужно скопировать, дважды
нажмите на кнопку «Формат по образцу» на панели инструментов
«Главная». После этого к курсору мыши добавится значок кисточки и если щелкнуть по любой фигуре, то она примет такой же
формат. Для того, чтобы отключить режим копирования формата,
нужно снова нажать на кнопку «Формат по образцу».
16. Соедините сценарии с помощью отношений включения
или расширения там, где это необходимо.
17. Разместите на рабочем листе отношения обобщения в необходимом количестве. Для этого в MS Visio также используется
115
элемент «Использование». Появится стрелка со стереотипом
«Uses». Для отношений обобщения стереотип не указывается, поэтому нужно вызвать окно настройки параметров отображения фигуры (о том, как это делается, говорилось в п. 0), и отключить
отображение стереотипа. Это связано с тем, что по канонам языка
UML, для отношения обобщения стереотипы не отображается, так
как внешний вид этой стрелки и без того отличается от других видов отношений. Исправленную стрелку отношения обобщения без
стереотипа также можно сохранить в своем наборе элементов. Новому элементу в наборе целесообразно дать осмысленное имя,
например, «Расширение».
18. Соедините между собой отдельные сценарии или отдельных актеров с помощью отношений обобщения там, где это необходимо.
Содержание отчета
В отчете по лабораторной работе 12 должен быть приведен про-
цесс поэтапного построения диаграммы вариантов использования.
Контрольные вопросы
1. Какова роль диаграмм вариантов использования в проектировании информационных систем?
2. Что показывают сценарии выполнения на диаграмме вариантов использования?
3. Каково назначение элементов «Актор» на диаграмме вариантов использования? Почему они так называются?
4. Какие виды отношений могут использоваться на диаграмме
вариантов использования?
5. В каких случаях используется тот или иной тип отношения?
6. Что такое стереотип в UML? Для чего используются стереотипы?
7. Каким образом можно настроить параметры отображения
фигур на схемах UML?
8. Для чего проводится анкетирование заказчика информационной системы?
9. Для чего создается словарь предметной области?.
10. Что показывают предусловия и постусловия выполнения
сценариев?
116
11. На какие главные вопросы предпроектного исследования
должны быть получены ответы в результате детального описания
диаграммы вариантов использования?
Литература
Основная: 1–4.
Дополнительная: 1–4.
13. ДИАГРАММА КЛАССОВ
Цель – изучение основных возможностей создания и редакти-
рования диаграмм классов в MS Visio.
Формируемые компетенции или их части: ПК-1; ПК-2; ПК-3;
ПК-4; ПК-30.
Теоретическая часть
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними.
На диаграммах классов изображаются также атрибуты классов,
операции классов и ограничения, которые накладываются на связи
между классами. Диаграмма классов для варианта использования
«Снять деньги со счета» представлена на рис. 13.1.
На этой диаграмме классов показаны связи между классами,
реализующими вариант использования «Снять деньги со счета».
В этом процессе задействованы четыре класса: Card Reader
(устройство для чтения карточек), Account (счет), ATM Screen
(экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс
на диаграмме выглядит в виде прямоугольника, разделенного на
три части. В первой содержится имя класса, во второй – его атрибуты. В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом).
Связывающие классы линии отражают взаимодействие между
классами. Так, класс Account связан с классом ATM Screen, потому
что они непосредственно сообщаются и взаимодействуют друг с
другом. Класс Card Reader не связан с классом Cash Dispenser, поскольку они не сообщаются друг с другом непосредственно.
117
Рис. 13.1. Диаграмма классов для варианта использования
«Снять деньги со счета»
Стереотипы – это механизм, позволяющий разделять классы
на категории. В языке UML основными стереотипами являются:
Boundary (граница), Entity (сущность) и Control (управление).
Граничные классы (boundary classes) – это классы, которые
расположены на границе системы и окружающей среды. Они
включают все формы, отчеты, интерфейсы с аппаратурой (такой,
как принтеры или сканеры) и интерфейсы с другими системами.
118
Для того чтобы найти граничные классы, надо исследовать
диаграммы вариантов использования. Каждому взаимодействию
между действующим лицом и вариантом использования должен
соответствовать, по крайней мере, один граничный класс. Именно
такой класс позволяет действующему лицу взаимодействовать с
системой.
Классы-сущности (entity classes) отражают основные понятия
(абстракции) предметной области и, как правило, содержат хранимую информацию. Обычно для каждого класса-сущности создают
таблицу в базе данных.
Управляющие классы (control classes) отвечают за координа-
цию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности – остальные классы не посылают ему
большого количества сообщений. Вместо этого он сам посылает
множество сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером.
В системе могут быть и другие управляющие классы, общие
для нескольких вариантов использования. Например, класс SecurityManager (менеджер безопасности) отвечает за контроль событий,
связанных с безопасностью. Класс Transaction-Manager (менеджер
транзакций) занимается координацией сообщений, относящихся к
транзакциям с базой данных. Могут быть и другие менеджеры для
работы с другими элементами функционирования системы, такими, как разделение ресурсов, распределенная обработка данных
или обработка ошибок.
Помимо упомянутых выше стереотипов, можно создавать и
свои собственные.
Пакеты применяют, чтобы сгруппировать классы, обладающие некоторой общностью. Существует несколько наиболее распространенных подходов к группировке. Во-первых, можно группировать их по стереотипу. В таком случае получается один пакет
с классами-сущностями, один с граничными классами, один с
управляющими классами и т. д. Этот подход может быть полезен с
точки зрения размещения готовой системы, поскольку все находя-
119
щиеся на клиентских машинах компоненты с граничными классами уже оказываются в одном пакете.
Другой подход заключается в объединении классов по их
функциональности. Например, в пакете Security (безопасность) со-
держатся все классы, отвечающие за безопасность приложения.
В таком случае другие пакеты могут называться Employee Mainte-
nance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода за-
ключается в возможности повторного использования.
Механизм пакетов применим к любым элементам модели, а не
только к классам. Если для группировки классов не применять некоторые эвристики, то она становится весьма произвольной. Одна
из них, которая в основном используется в UML, – это зависимость. Зависимость между двумя пакетами существует в том случае, если между любыми двумя классами в пакетах существует
любая зависимость. Таким образом, диаграмма пакетов (рис. 13.2)
представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, т. е. диаграмма пакетов –
это форма диаграммы классов.
Рис. 13.2. Диаграмма пакетов
Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь
за собой изменения в другом. Что касается классов, то причины
для зависимостей могут быть самыми разными: один класс посылает сообщение другому; один класс включает часть данных другого класса; один класс использует другой в качестве параметра
120