Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Жизненный цикл программного обеспечения. Лабораторный практикум
.pdf
2. Выберите связь в главном окне, на которую будет помещено
сообщение:
3. Дважды щелкните на сообщении и введите имя сообщения в
появившемся диалоговом окне:
4. Результат будет следующим:
Сторожевое условие создается с помощью свойства Branch:
Object1
1 [сумма прев ы шает кредит] : проверитьСостояниеСчета()
Object2
111
Здесь показано следующее сообщение:
1 – номер сообщения, создается системой;
сумма превышает кредит – сторожевое условие;
проверитьСостояниеСчета – имя сообщения;
( ) ставятся системой, если не аргументов.
10.2. Порядок выполнения работы
В данной лабораторной работе изучается построение диаграмм
взаимодействия двух видов: диаграмм последовательности и диаграмм кооперации на примере системы управления банкоматом.
Для того чтобы создать диаграмму последовательности, необходимо выполнить следующие действия.
1. Запустите StarUML (иконка на рабочем столе). На экране
появится окно среды StarUML – New Project By Approach с требованием указать подход
Rational Approach и нажать на кнопку OK (см. рис. 6.8).
2. В пункте меню Model выберите подпункт Add и затем Model,
как показано на рис. 6.9.
3. В пункте меню Model выберите подпункт Add Diagram и затем
Sequence Diagram, как показано на рис. 10.11.
4. Создайте диаграмму последовательности для системы управле-
ния
банкоматом, как показано на рис. 10.12.
Диаграмма последовательности системы управления банкоматом
содержит 6 объектов и 10 сообщений. Объект класса Клиент является объектом worker и имеет стереотип отображения – Iconic.
к моделированию. Здесь надо выбрать иконку
Для того чтобы создать диаграмму кооперации, необходимо выполнить следующие действия.
1. Запустите StarUML (иконка на рабочем столе). На экране
появится окно среды StarUML – New Project By Approach с требованием указать подход к моделированию. Здесь надо выбрать иконку
Rational Approach и нажать на кнопку OK (см. рис. 6.8).
2. В пункте меню Model выберите подпункт Add и затем Model,
как показано на рис. 6.9.
3. В пункте меню Model выберите подпункт Add Diagram и затем
Collaboration Diagram, как показано на рис. 10.13.
4. Создайте диаграмму кооперации
для системы управления бан-
коматом, как показано на рис. 10.14.
112
Рис. 10.11. Выбор диаграммы последовательности
Диаграмма кооперации системы управления банкоматом содержит 6 объектов и 10 сообщений. Объект класса Клиент является объектом worker и имеет стереотип отображения – Iconic.
10.3. Задание для самостоятельной работы
Создать диаграммы последовательности и кооперации для систем,
указанных преподавателем.
113
: Устройство
: Клиент
1 : прочитатьПИНкод()
Чтения
4 : Прочитат ьНомерСче та()
: Контроллер
Банкомата
2 : проверить ПИНко д()
3 [номе р ПИНкода верный] : показат ь МенюОпций()
5 : проверит ьНомерСчета()
6 [Номер счет а верный] : показа ть Ме нюСу мм ы()
7 : открыть Счет()
8 [сумма превыш ает кре дит ] : уменьшитьСчет()
: Контроллер
Банка
: Экран
Банкомата
: Устройстро
Получения
Наличных
114
9 : извле чьКа рт у()
12 : получит ьНа личные()
10 : ВыдатьНаличные()
11 : Выдать сообщениеПолучитьНаличные()
Рис. 10.12. Диаграмма последовательности
системы управления банкоматом
Рис. 10.13. Выбор диаграммы кооперации
115
х
: УстройствоЧтения
<<loc al>>
1 : прочитатьПИНкод()
: Клиент
Рис. 10.14. Диаграмма кооперации системы управления банкоматом
3 : прочитатьНомерСчета()
10 : извле чь Ка рт у ()
9 : выдатьНаличные()
: Устройство
Получения Наличны
: КонтроллерБанкомата
<<local>>
: КонтроллерБанка
<<global>>
8 [Сумма не превышает кредит] : уменьшитьСчет()
5 [ПИНко верный] : показать Ме нюОпций()
2 : проверить ПИНкод()
4 : проверитьНомерСчета()
7 : открытьСчет()
6 [номер счета верный] : показать Меню Суммы ()
<<local>>
: Экран
Банкомата
116
Лабораторная работа 11
МОДЕЛИРОВАНИЕ ФИЗИЧЕСКОЙ СТРУКТУРЫ
СИСТЕМ С ИСПОЛЬЗОВАНИЕМ ДИАГРАММ
КОМПОНЕНТОВ И ДИАГРАММ РАЗМЕЩЕНИЯ
С ПОМОЩЬЮ СРЕДЫ STARUML
Цель работы – изучение средств построения физических моделей
систем с помощью диаграмм компонентов и диаграмм размещения
(или развертывания) в среде StarUML, построение диаграммы компо-
нентов и диаграммы размещения системы управления банкоматом, разработка этих диаграмм для варианта, предложенного преподавателем.
11.1. Основные понятия и определения
В языке UML для физического представления моделей систем используются так называемые диаграммы реализации (implementation
diagrams), которые включают в себя две отдельные диаграммы:
диаграмму компонентов;
диаграмму развертывания.
Диаграммы компонентов
Диаграммы компонентов применяются для статического моделирования систем с точки зрения их реализации. Сюда относится моделирование физических сущностей, развернутых в узле,
полняемых программ, библиотек, таблиц, файлов и документов. По
существу, диаграммы компонентов – это не что иное, как диаграммы
классов, сосредоточенные на системных компонентах. Целями разработки диаграмм компонентов являются:
визуализация общей структуры исходного кода программной
системы;
спецификация исполнимого варианта программной системы;
обеспечение многократного использования отдельных фраг-
ментов
аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного
программного кода;
представление концептуальной и физической схем баз данных.
В разработке диаграмм компонентов участвуют как системные
например ис-
117
кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, которые рассматриваются в качестве классификаторов.
Для представления физических сущностей в языке UML применяется специальный термин – компонент (component). Компонент реализует некоторый набор интерфейсов и служит для
общего обозначения элементов физического представления модели. Для графического представления компонента может использоваться специальный
символ – прямоугольник со вставленными слева двумя более мелкими прямоугольниками (рис. 11.1). Внутри объемлющего прямоугольника записывается имя компонента и, возможно, некоторая дополнительная информация. Изображение этого символа может незначительно варьироваться в зависимости от характера
ассоциируе-
мой с компонентом информации.
Catalog
а
Рис. 11.1. Варианты изображения компонента на диаграмме
компонентов: а – компонент на уровне класса;
б – компонент на уроне примеров
control.dll
б
Изображение компонента ведет свое происхождение от обозначения модуля программы, применявшегося некоторое время для отображения особенностей инкапсуляции данных и процедур. Так,
верхний маленький прямоугольник концептуально ассоциируется с
данными, которые реализует этот компонент. Нижний маленький
прямоугольник ассоциируется с операциями или методами, реализуемыми компонентом.
Поскольку компонент как элемент физической реализации модели
представляет отдельный модуль кода, иногда его комментируют с
указанием дополнительных графических символов, иллюстрирующих конкретные особенности его реализации. Их применение упрощает понимание диаграммы компонентов, существенно повышая
наглядность физического представления. Некоторые из таких общепринятых обозначений для компонентов изображены на рис. 11.2.
118
а б в
Рис. 11.2. Варианты графического изображения компонентов
на диаграмме компонентов
г
В языке UML выделяют три вида компонентов:
1) компоненты развертывания, которые обеспечивают непосред-
ственное выполнение системой своих функций; такими компонентами могут быть динамически подключаемые библиотеки с расширением .dll (рис. 11.2, а), web-страницы на языке разметки гипертекста
с расширением .htm (рис. 11.2, б) и файлы справки с расширением
.hpl (рис. 11.2, в);
2) компоненты – рабочие продукты; как
правило – это файлы с
исходными текстами программ, например, с расширением .h или .срр
для языка C++ (рис. 11.2, г);
3) компоненты исполнения, представляющие собой исполнимые мо-
дули – файлы с расширением .ехе; они обозначаются обычным образом.
Элементы, изображенные на рис. 11.2, иногда называют артефактами, подчеркивая при этом их законченное информационное содержание, зависящее от конкретной
технологии реализации соответст-
вующих компонентов.
Другой способ спецификации различных видов компонентов –
явное указание стереотипа компонента перед его именем. В языке
UML для компонентов определены следующие стереотипы:
библиотека (library) – определяет первую разновидность ком-
понента, который может быть представлен в форме динамической
или статической библиотеки;
таблица (table) – также определяет первую разновидность компо-
нента,
который может быть представлен в форме таблицы базы данных;
файл (file) – определяет вторую разновидность компонента, ко-
торый может быть представлен в виде файлов с исходными текстами
программ;
119
документ (document) – определяет вторую разновидность ком-
понента, который может быть представлен в форме документа;
исполнимый (executable) – определяет третий вид компонента,
который может исполняться в узле.
Диаграммы размещения
Физическое представление программной системы не может быть
полным, если отсутствует информация о том, на какой платформе и с
помощью каких вычислительных средствах она реализована
. При
разработке корпоративных приложений, в отличие от простых программ, возникает необходимость в создании диаграмм развертывания, или размещения, по трем следующим причинам.
1. Сложные программные системы могут реализовываться в сетевом варианте на различных вычислительных платформах и с использованием разных технологий доступа к распределенным базам данных. Наличие локальной
корпоративной сети требует решения целого комплекса дополнительных задач по рациональному размещению
компонентов в узлах этой сети, что определяет общую производительность программной системы.
2. Интеграция программной системы с Интернетом определяет необходимость решения дополнительных вопросов при проектировании
системы, таких как обеспечение безопасности, криптозащищенности и
устойчивости доступа к информации для корпоративных
клиентов.
3. Решение этих вопросов в немалой степени зависит от реализа-
ции проекта в форме физически существующих узлов системы, таких
как серверы, рабочие станции, брандмауэры, каналы связи и хранилища данных. Эти аспекты также требуют визуального представления с целью спецификации программных и технологических особенностей реализации распределенных архитектур.
Диаграммы размещения
– это один из двух видов диаграмм, используемых при моделировании физических аспектов объектноориентированной системы. Такая диаграмма показывает конфигурацию узлов, где производится обработка информации, и то, какие
компоненты размещены на каждом узле.
Диаграммы размещения предназначены для моделирования статического вида системы с точки зрения развертывания. В основном
под этим
понимается моделирование топологии аппаратных средств,
на которых выполняется система. По существу, диаграммы развертывания – это просто диаграммы классов, сосредоточенные на системных узлах.
120
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]