Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Жизненный цикл программного обеспечения. Лабораторный практикум
.pdf
Кроме того, диаграмма размещения предназначена для визуализации элементов и компонентов программы, существующих лишь на
этапе ее исполнения (runtime). При этом на программе отображаются
только компоненты – экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты,
которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с
исходными текстами
программ могут присутствовать только на диаграмме компонентов.
На диаграмме развертывания они не указываются.
Диаграмма размещения содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от
диаграмм логического представления, диаграмма размещения является единой для системы в целом, поскольку должна всецело отражать особенности ее
реализации. Диаграмма размещения, по сути,
завершает процесс объектно-ориентированного анализа и проектирования для конкретной программной системы, и ее разработка, как
правило, является последним этапом спецификации модели.
Целями разработки диаграмм размещения являются:
определение распределения компонентов системы по ее физи-
ческим узлам;
определение физических связей между всеми узлами реализа-
ции
системы на этапе ее исполнения;
выявление узких мест системы и реконфигурирование ее топо-
логии для достижения требуемой производительности этой системы.
Для обеспечения этих требований диаграмма размещения разрабатывается совместно системными аналитиками, сетевыми инженерами и системотехниками.
Элементами диаграмм размещения являются:
пакет;
узел;
инстанция (экземпляр) узла;
артефакт;
порт;
часть;
ассоциация;
направленная ассоциация;
зависимость;
связь;
соединитель.
121

Большая часть элементов по своей семантике и процедурам создания аналогична соответствующим элементам диаграммы классов и
диаграммы компонентов. Узел (node) – это некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом. В качестве вычислительного ресурса узла может
рассматриваться наличие некоторого объема электронной или магнитооптической памяти и/или процессора.
В последней
версии языка UML понятие узла расширено и может
включать в себя не только вычислительные устройства (процессоры), но
и другие механические или электронные устройства, такие как датчики,
принтеры, модемы, цифровые камеры, сканеры и манипуляторы.
Графически на диаграмме размещения узел изображается в форме
трехмерного куба (строго говоря, псевдотрехмерного прямоугольного параллелепипеда). Узел имеет
собственное имя, которое указывается внутри этого графического символа. Сами узлы могут быть
представлены как в качестве типов, так и в качестве экземпляров
(рис. 11.3).
Узел на уровне типа
Сервер Принтеры
Узел на уровне экземпляра
Принтер HP LJ110:Принтеры
Рис. 11.3. Графическое обозначение узла
Кроме собственно изображений узлов на диаграмме размещения
указываются отношения между ними. В качестве отношений выступают физические соединения между узлами и зависимости между
узлами и компонентами, изображения которых тоже могут присутствовать на диаграммах размещения.
122

Соединения являются разновидностью ассоциации и изображаются отрезками линий без стрелок. Наличие такой линии указывает на
необходимость организации физического канала для обмена информацией между соответствующими узлами. Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением. Так, на представленном ниже
фрагменте диаграммы размещения (рис. 11.4) явно определены не
только требования к скорости передачи данных в локальной сети с
помощью помеченного значения, но и рекомендации по технологии
физической реализации соединений в форме примечания.
<<processor>>
Сервер
Рис. 11.4. Соединение между узлами
<<net>>
Локальная сеть
<<processor>>
Рабочая станция
11.2. Порядок выполнения работы
В данной лабораторной работе изучается построение диаграмм
физического моделирования двух видов: диаграмм компонентов и
диаграмм размещения на примере системы управления банкоматом.
Для того чтобы создать диаграмму компонентов, необходимо
выполнить следующие действия.
1. Запустите StarUML (иконка на рабочем столе). На экране
появится окно среды StarUML – New Project By Approach с требованием указать подход к
Rational Approach и нажать на кнопку OK (см. рис. 6.8).
2. В пункте меню Model выберите подпункт Add и затем Model,
как показано на рис. 6.9.
3. В пункте меню Model выберите подпункт Add Diagram и затем
Component Diagram, как показано на рис. 11.5.
4. Создайте диаграмму компонентов для системы управления бан-
коматом, как показано на рис. 11.6. Диаграмма компонентов системы
управления банкоматом содержит 2 узла, 4 артефакта и 1 интерфейс.
моделированию. Здесь надо выбрать иконку
123

Рис. 11.5. Выбор диаграммы компонентов
Для того чтобы создать диаграмму размещения, необходимо
выполнить следующие действия.
1. Запустите StarUML (иконка на рабочем столе). На экране
появится окно среды StarUML – New Project By Approach с требованием указать подход к моделированию. Здесь надо выбрать иконку
Rational Approach и нажать на кнопку OK (см. рис. 6.8).
2. В пункте меню Model выберите подпункт Add
и затем Model,
как показано на рис. 6.9.
3. В пункте меню Model выбрать подпункт Add Diagram и затем
Deployment Diagram, как показано на рис. 11.7.
4. Создайте диаграмму размещения для системы управления банкоматом, как показано на рис. 11.8.
124

MainATM
MainBank
IAut orise
Message.txt
Transactions.dll
Transactions.cpp
Рис. 11.6. Диаграмма компонентов программной
MainA T M.cpp
{реализует классы:
УстройствоЧтения,
ЭкранБанкомата,
УстройствоПолученияНаличных,
ПринтерБанкомата}
системы управления банкоматом
{реализует класс:
КонтроллерБанкомата}
11.3. Задание для самостоятельной работы
Создать диаграммы компонентов и размещения для систем, ука-
занных преподавателем.
125

126
Рис. 11.7. Выбор диаграммы размещения

<<processor>>
Сервер банка
mainBank
IA u t o r is e
mainA T M
<<database>>
клиенты
<<net>>
сеть
<<processor>>
удаленный терминал
transactions
Защищенная
линия
связи
<<device>>
устройство
чтения
карточки
<<device>>
экран
банкомата
<<device>>
устройство
выдачи
наличных
Рис. 11.8. Диаграмма размещения программной
системы управления банкоматом
<<device>>
принтер
банкомата
127

Заключение
Современные крупные программные проекты имеют, как правило,
следующие особенности:
сложность описания (достаточно большое количество функций,
процессов, элементов данных и сложные взаимосвязи между ними),
требующая тщательного моделирования и анализа данных и процессов;
наличие совокупности взаимодействующих компонентов (под-
систем), имеющих свои локальные задачи и цели функционирования;
отсутствие прямых аналогов, ограничивающее
пользования каких-либо типовых проектных решений и прикладных
систем;
необходимость интеграции существующих и вновь разрабаты-
ваемых приложений;
функционирование в неоднородной среде на нескольких аппа-
ратных платформах;
разобщенность и разнородность отдельных групп разработчи-
ков по уровню квалификации и сложившимся традициям использования инструментальных средств;
существенная
временная протяженность проекта, обусловленная, с
одной стороны, ограниченными возможностями коллектива разработчиков, а с другой, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ПО.
Для успешной реализации программного проекта объект проектирования должен быть, прежде всего, адекватно описан, построены
полные функциональные и информационные модели. В
ном практикуме рассмотрены методы структурного моделирования
программных систем в соответствии со стандартами IDEF0, IDEF3,
DFD и IDEF1X с использованием CASE-средств BPWin и ERWin, а
также методология объектно-ориентированного моделирования с
использованием стандарта UML в среде системы StarUML. Данные
стандарты моделирования и проектирования ПО в настоящее время
реализованы и в других CASE-системах.
возможность ис-
лаборатор-
128

Библиографический список
Дубейковский В.И. Эффективное моделирование с CA ERWin®
Process Modeler. BPWin; AllFusion Process Modeler. – М.: ДИАЛОГ-
МИФИ, 2009. – 384 с.
Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование
информационных систем: Учеб. пособие. – М.: ИнтернетУниверситет Информационных технологий; БИНОМ. Лаборатория
знаний, 2008. – 300 с.
Пайлон Д., Питмен Н. UML 2 для программистов. – Пер. с англ. –
Спб.: Изд-во «Питер». 2012. – 240 с.
Вендров А.М
обеспечения экономических информационных систем: Учеб. пособие. – 2-е изд. – М.: Финансы и статистика, 2006. – 192 с.
Каюмова А.В. Визуальное моделирование систем в StarUML:
Учеб. пособие. – Казань: Казанский федеральный университет, 2013. –
104 с.
Карпович Е.Е., Федоров Н.В. Автоматизированное проектирование информационных систем на основе современных CASEтехнологий. Ч. 1. Структурный подход
ционных систем: Учеб. пособие. – М.: МГГУ, 2007. – 157 с.
Карпович Е.Е., Федоров Н.В. Автоматизированное проектирование информационных систем на основе современных CASEтехнологий: Учеб. пособие. Ч. 2. Современные CASE-технологии. –
М.: МГГУ, 2007. – 134 с.
. Практикум по проектированию программного
к проектированию информа-
129

Учебное издание
Карпович Елена Евгеньевна
ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Лабораторный практикум
Редактор Т.А. Кравченко
Компьютерная верстка М.А. Шамарина
Подписано в печать 15.11.16 Рег. № 716 Уч.-изд. л. 8,1
Формат 60 90 1/16
Национальный исследовательский
технологический университет «МИСиС»,
119049, Москва, Ленинский пр-т, 4
Издательский Дом МИСиС,
119049, Москва, Ленинский пр-т, 4
Тел. (495) 638-45-22
Отпечатано в типографии Издательского Дома МИСиС
119049, Москва, Ленинский пр-т, 4
тел. (499) 236-76-17, тел./факс (499) 236-76-35
130
Электронная версия Заказ 5234
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
