- •Р.А. Файзрахманов, А.В. Архипов
- •ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ ОБЪЕКТНО ОРИЕНТИРОВАННОГО ПОДХОДА
- •4.3. Подведение итогов
- •4.4. Контрольные вопросы
- •4.5. Контрольные задачи и упражнения
- •5. ДИАГРАММА КЛАССОВ
- •5.1. Теоретическая часть
- •5.2. Реализация в Rational Rose
- •5.5. Контрольные задачи и упражнения
- •6.1. Теоретическая часть
- •6.2. Реализация в Rational Rose
- •6.3. Подведение итогов
- •6.4. Контрольные вопросы
- •6.5. Контрольная задача
- •7. ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ
- •7.1. Теоретическая часть
- •7.2. Реализация в Rational Rose
- •7.3. Подведение итогов
- •7.4. Контрольные вопросы
- •7.5. Контрольные задачи
- •8. ДИАГРАММА СОТРУДНИЧЕСТВА
- •8.1. Теоретическая часть
- •8.2. Реализация в Rational Rose
- •8.5. Контрольные задачи
- •9. ДИАГРАММА СОСТОЯНИЙ
- •9.1. Теоретическая часть
- •9.3. Подведение итогов
- •9.4. Контрольные вопросы
- •9.5. Контрольные задачи
- •10. ДИАГРАММА ДЕЯТЕЛЬНОСТЕЙ
- •10.1. Теоретическая часть
- •10.3. Подведение итогов
- •10.4. Контрольные вопросы
- •11. ДИАГРАММА КОМПОНЕНТОВ
- •11.1. Теоретическая часть
- •11.4. Контрольные вопросы
- •11.5. Контрольные задачи
- •12.3. Подведение итогов
- •12.4. Контрольные вопросы
- •12.5. Контрольная задача
- •13. ГЕНЕРАЦИЯ КОДА
- •13.1. Алгоритм получения исходного кода C++
- •13.2. Задания для самостоятельного выполнения
- •ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
- •ИСПОЛЬЗОВАНИЕ МОДУЛЯ «RATIONAL ROSE C++ ANALYZER» ДЛЯ ОБРАТНОГО ВОССТАНОВЛЕНИЯ МОДЕЛИ ПО ИСХОДНОМУ КОДУ
- •РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С ИСПОЛЬЗОВАНИЕМ UML
- •1. Разработка диаграммы прецедентов
- •2. Разработка диаграммы классов
- •3. Разработка диаграмм взаимодействия
- •4. Разработка диаграммы состояний
- •5. Разработка диаграммы деятельности
- •9. Разработка приложения
- •Контрольные вопросы
- •МОДЕЛЬ РАБОТЫ ПРЕДПРИЯТИЯ ОПТОВОЙ ТОРГОВЛИ. РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
- •ОГЛАВЛЕНИЕ
- •1. Деятельность и структура предприятия
- •2.1. Реализация продукции со склада
- •2.2. Возврат товара клиентом
- •2.3. Закупка продукции
- •3.1. Общие требования и принципы построения системы
- •3.2. Обеспечение связи офис - склад
- •3.3. Требования к персоналу
- •4. Диаграмма прецедентов
- •4.1. Реализация продукции со склада
- •5. Диаграмма классов
- •5.2. Контрагенты предприятия оптовой торговли
- •5.3. Продукция предприятия оптовой торговли
- •5.4. Заказ продукции
- •5.5. Накладная на получение товара
- •6. Диаграмма взаимодействия
- •12. Разработка приложения
- •ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ ОБЪЕКТНО ОРИЕНТИРОВАННОГО ПОДХОДА
«Создание каталога дисциплин», «Отправка каталога на кафедры», «Рассылка каталога студентам по электронной почте», «Объявление о начале регистрации дисциплин студентами». Состояние «Выбор дисциплин преподавателем» создается на дорожке «Преподаватель», а остальные - на дорожке «Сотрудник деканата». Деятельность «Рас пределение дисциплин между преподавателями» повторяется до тех пор, пока все преподаватели не выберут дисциплины. В связи с этим возникает необходимость добавления в диаграмму точки принятия решения (ветвления). Точка принятия решения создается пиктограм мой «Decision» панели инструментов. Деятельности «Отправка ката лога на кафедры» и «Рассылка каталога студентам по электронной почте» выполняются параллельно после создания каталога. Для ото бражения этого используется полоса синхронизации, которая созда ется пиктограммой «Horizontal Synchronization» (горизонтальная синхронизация) или «Vertical Synchronization» (вертикальная синхро низация). Законченная диаграмма представлена на рис. 10.10.
10.3. Подведение итогов
Диаграммы деятельности можно использовать для моделирова ния динамических аспектов поведения системы. Как правило, они применяются, чтобы смоделировать последовательные (а иногда и параллельные) шаги вычислительного процесса. С помощью диа грамм деятельности можно также моделировать жизнь объекта, когда он переходит из одного состояния в другое в разных точках потока управления.
Диаграммы деятельности играют важную роль в понимании про цессов реализации алгоритмов выполнения операций классов и пото ков управления в моделируемой системе. Используемые для этой це ли традиционные блок-схемы алгоритмов обладают серьезными ог раничениями в представлении параллельных процессов и их синхро низации [2]. Применение дорожек открывает дополнительные воз можности для наглядного представления бизнес-процессов, позволяя специфицировать деятельность подразделений компаний и фирм.
10.4.Контрольные вопросы
1.Назовите основные элементы диаграммы деятельностей.
2.В чем отличие деятельности от действия?
3.Для чего используются полосы синхронизации и дорожки?
1. Укажите, какой из словесных алгоритмов корректно описывает следующую диаграмму деятельностей.
а) Если истина, |
б) |
выполняется С |
то выполняется С |
|
выполняются А и В |
в противном случае |
|
выполняется D |
выполняются А и В |
|
|
выполняется D |
|
|
в) Если истина, |
г) |
Если истина, |
то выполняется С |
|
то выполняется С |
в противном случае |
|
в противном случае |
выполняются А или В |
|
выполняется А |
выполняется D |
|
выполняется В |
|
|
выполняется D |
2. Постройте диаграмму деятельностей, описывающую процесс снятия денег со счета с использованием пластиковой карты. Диа грамма должна содержать состояния клиента: «Вставка пластиковой карты», «Ввод кода», «Ввод суммы» и «Выемка денег из слота»; со стояния банкомата: «Отображение баланса», «Выдача наличных», «Возврат карты»; состояния банка: «Идентификация», «Проверка ос татка», «Списание средств со счета».
11.ДИАГРАММА КОМПОНЕНТОВ
11.1.Теоретическая часть
Диаграмма компонентов (component diagram), в отличие от ранее рассмотренных диаграмм, описывает особенности физического пред ставления системы.
Логическое моделирование выполняется с целью визуализации, специфицирования и документирования решений по поводу словаря предметной области и взаимодействия различных сущностей. Физиче ское моделирование служит для построения исполняемой системы [1].
Диаграмма компонентов содержит компоненты, интерфейсы
и отношения.
Компонент (component) представляет собой физическую сущ ность, реализующую некоторый набор интерфейсов. Интерфейсы в этом случае выступают в качестве моста между логическими и фи зическими моделями.
С помощью компонентов все элементы логического представле ния реализуются в конкретные материальные сущности.
Для графического изображения компонента используется прямо угольник со вставленными слева двумя более мелкими прямоуголь никами (рис. 11.1). В основном прямоугольнике записывается имя компонента и опционально ряд свойств компонента.
Рис. 11.1. Изображение компонента
Имя компонента должно быть уникальным. Если имя компонента содержит название пакета, к которому принадлежит компонент, то имя называется составным, в противном случае простым.
Поскольку компонент как элемент физической реализации моде ли представляет некоторый отдельный модуль кода, то в качестве простых имен обычно используют названия соответствующих фай лов, включая расширения, например: «start.exe», «service.dll», «ешployee.db», «main.cpp».
Выделяют три вида компонентов:
1. Компоненты развертывания (deployment components). Обес печивают непосредственное выполнение системой своих функций. К их числу относятся динамически подключаемые библиотеки (dll),
веб-страницы (html) и др.
2. Компоненты - рабочие продукты (work-product components).
Представляют собой файлы с исходными текстами программ и дан ными, из которых создаются компоненты развертывания. Такие ком поненты не принимают непосредственного участия в работе испол няемой системы, но являются рабочими продуктами, из которых ис полняемая система создается. В качестве примера можно привести файлы с расширениями М или .срр для языка C++.
3. Компоненты исполнения (execution components). Представля ют собой исполнимые модули - файлы с расширением .ехе.
Кроме того, в UML определены пять стереотипов компонентов, которые могут быть указаны непосредственно перед именем компо нента [1]:
-executable (исполнимый) - определяет компонент, который может исполняться в узле;
-library (библиотека) - определяет статическую или динамиче скую объектную библиотеку;
-table (таблица) - определяет компонент, представляющий таб лицу базы данных;
-file (файл) - определяет компонент, представляющий доку мент, который содержит исходный текст или данные;
-document (документ) - определяет компонент, представляю щий документ.
На диаграмме компонентов отображаются интерфейсы, которые уже обсуждались ранее при рассмотрении диаграммы классов. Каж дый интерфейс на диаграмме компонентов так же, как и на диаграм ме классов, обозначается окружностью, которая соединяется с ком понентом так же, как и с классом, отрезком линии без стрелок (рис. 11.2). Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компо нент реализует соответствующий набор интерфейсов [2].
На диаграмме компонентов интерфейс может быть представлен в виде прямоугольника с указанием стереотипа «Interface» (рис. 11.2, б).
б
Рис. 11.2. Графическое изображение интерфейсов на диаграмме компонентов
Между элементами диаграммы компонентов помимо отношений реализации (см. рис. 11.2) могут существовать и отношения зависи мости (рис. 11.3).
Непосредственный показ зависимости между двумя компонента ми - это свернутая форма представления реальных отношений между ними. Компонент редко зависит от другого компонента напрямую; чаще он импортирует один или несколько интерфейсов, экспорти руемых вторым компонентом [1].
Отношение зависимости на диаграмме компонентов изображает ся пунктирной линией со стрелкой, направленной от зависимого эле мента к независимому элементу (рис. 11.3).
Рис. 11.3. Пример отношения зависимости между компонентами
Так же, как и классы, компоненты могут быть организованы в пакеты.