Материал: Лабораторные_Архитерктура ИС
38
имеется
свой
собственный
заголовочный
файл
и
файл
с
расширением
.
СРР
,
так
что
каждый
класс
преобразуется
в
свои
собственные
компоненты
на
диаграмме
.
Например
,
класс
ATM screen
преобразуется
в
компонент
ATM Screen
диаграммы
.
Он
преобразуется
также
и
во
второй
компонент
ATM Screen.
Вместе
эти
два
компонента
представляют
тело
и
заголовок
класса
ATM Screen.
Выделенный
темным
компонент
называется
спецификацией
пакета
(package specification)
и
соответствует
файлу
тела
класса
ATM Screen
на
языке
C++ (
файл
с
расширением
.
СРР
).
Невыделенный
компонент
также
называется
спецификацией
пакета
,
но
соответствует
заголовочному
файлу
класса
языка
С
++ (
файл
с
расширением
.
Н
).
Компонент
ATM.exe
является
спецификацией
задачи
и
представляет
поток
обработки
информации
(thread of processing).
В
данном
случае
поток
обработки
является
исполняемой
программой
.
Компоненты
соединены
штриховой
линией
,
что
соответствует
зависимостям
между
ними
.
Например
,
класс
Card Reader
зависит
от
класса
ATM Screen.
Это
означает
,
что
,
для
того
,
чтобы
класс
Card Reader
мог
быть
скомпилирован
,
класс
ATM Screen
должен
уже
существовать
.
После
компиляции
всех
классов
может
быть
создан
исполняемый
файл
ATMClient.exe.
Пример
АТМ
содержит
два
потока
обработки
и
,
таким
образом
,
получаются
два
исполняемых
файла
.
Один
из
них
–
это
клиент
АТМ
,
он
содержит
компоненты
Cash Dispenser, Card Reader
и
ATM Screen.
Второй
файл
–
это
сервер
ATM,
включающий
в
себя
компонент
Account.
Диаграмма
компонентов
для
сервера
АТМ
показана
на
рис
.
1
.
1
8.
Как
видно
из
примера
,
у
системы
может
быть
несколько
диаграмм
компонентов
,
в
зависимости
от
числа
подсистем
или
исполняемых
файлов
.
Каждая
подсистема
является
пакетом
компонентов
.
В
общем
случае
,
пакеты
–
это
совокупности
компонентов
.
Пример
АТМ
содержит
два
пакета
:
клиент
АТМ
и
сервер
АТМ
.
Диаграммы
компонентов
применяются
теми
участниками
проекта
,
кто
отвечает
за
компиляцию
системы
.
Из
нее
видно
,
в
каком
порядке
надо
компилировать
компоненты
,
а
также
какие
исполняемые
компоненты
будут
созданы
системой
.
На
такой
диаграмме
показано
соответствие
39
классов
реализованным
компонентам
.
Она
нужна
там
,
где
начинается
генерация
кода
.
Account
Account
ATMServer.exe
Рис
.
1
.
1
8.
Диаграмма
Компонентов
для
сервера
АТМ
1.9.
Диаграммы
размещения
Диаграмма
размещения
(deployment diagram)
отражает
физические
взаимосвязи
между
программными
и
аппаратными
компонентами
системы
.
Она
является
хорошим
средством
для
того
,
чтобы
показать
маршруты
перемещения
объектов
и
компонентов
в
распределенной
системе
.
Каждый
узел
на
диаграмме
размещения
представляет
собой
некоторый
тип
вычислительного
устройства
–
в
большинстве
случаев
,
часть
аппаратуры
.
Эта
аппаратура
может
быть
простым
устройством
или
датчиком
,
а
может
быть
и
мэйнфреймом
.
Диаграмма
размещения
показывает
физическое
расположение
сети
и
местонахождение
в
ней
различных
компонентов
.
В
нашем
примере
система
АТМ
состоит
из
большого
количества
подсистем
,
выполняемых
на
отдельных
физических
устройствах
,
или
узлах
(node).
Диаграмма
размещения
для
системы
АТМ
показана
на
рис
.
1
.
1
9.
40
Рис
.
1
.
1
9.
Диаграмма
размещения
для
системы
АТМ
Из
данной
диаграммы
можно
узнать
о
физическом
размещении
системы
.
Клиентские
программы
АТМ
будут
работать
в
нескольких
местах
на
различных
сайтах
.
Через
закрытые
сети
будет
осуществляться
их
сообщение
с
региональным
сервером
АТМ
.
На
нём
будет
работать
программное
обеспечение
сервера
АТМ
.
В
свою
очередь
,
посредством
локальной
сети
региональный
сервер
будет
сообщаться
с
сервером
банковской
базы
данных
,
работающим
под
управлением
Oracle.
Наконец
,
с
региональным
сервером
АТМ
соединен
принтер
.
Диаграмма
размещения
используется
менеджером
проекта
,
пользователями
,
архитектором
системы
и
эксплуатационным
персоналом
,
чтобы
понять
физическое
размещение
системы
и
расположение
её
отдельных
подсистем
.
459 Elm St.
ATM
ATMClient.exe
Regional
ATM Server
ATMServer.exe
<<Private Network>>
1
25 First St.
ATM
ATMClient.exe
<<Private Network>>
Printer
Banking Database
Server
Oracle Server
<<LAN>>
4
1
Глава
2.
Основные
сведения
о
CASE-
средстве
Rational Rose
Некоторые
проектные
команды
рассматривают
CASE-
средства
как
„
костыли
“
для
новичков
,
а
другие
считают
их
не
менее
важными
,
чем
текстовые
процессоры
.
Э
.
Йордон
„
Путь
камикадзе
“
2.1.
Введение
в
Rational Rose
Rational Rose –
семейство
объектно
-
ориентированных
CASE-
средств
фирмы
Rational Software Corporation –
предназначено
для
автоматизации
процессов
анализа
и
проектирования
ПО
,
а
также
для
генерации
кодов
на
различных
языках
и
выпуска
проектной
документации
. Rational Rose
использует
метод
объектно
-
ориентированного
анализа
и
проектирования
,
основанный
на
языке
UML.
Текущая
версия
Rational Rose
реализует
генерацию
кодов
программ
для
С
++, Visual C++, Visual Basic, Java,
PowerBuilder, CORBA Interface Definition Language (IDL),
генерацию
описаний
баз
данных
для
ANSI SQL, Oracle, MS SQL Server, IBM DB2,
Sybase,
а
также
позволяет
разрабатывать
проектную
документацию
в
виде
диаграмм
и
спецификаций
.
Кроме
того
, Rational Rose
содержит
средства
реверсного
инжиниринга
программ
и
баз
данных
,
обеспечивающие
повторное
использование
программных
компонентов
в
новых
проектах
.
Структура
и
функции
.
В
основе
работы
Rational Rose
лежит
построение
диаграмм
и
спецификаций
UML,
определяющих
архитектуру
системы
,
её
статические
и
динамические
аспекты
.
В
составе
Rational Rose
можно
выделить
шесть
основных
структурных
компонентов
:
репозиторий
,
графический
интерфейс
пользователя
,
средства
просмотра
проекта
(
браузер
),
средства
контроля
проекта
,
средства
сбора
статистики
и
генератор
документов
.
К
ним
добавляются
генератор
кодов
(
индивидуальный
для
каждого
языка
)
и
анализатор
для
С
++,
обеспечивающий
реверсный
инжиниринг
.
Репозиторий
представляет
собой
базу
данных
проекта
.
Браузер
обеспечивает
“
навигацию
”
по
проекту
,
в
том
числе
перемещение
по
иерархиям
классов
и
подсистем
,
переключение
от
одного
вида
диаграмм
к
другому
и
т
.
д
.
Средства
контроля
и
сбора
статистики
дают
возможность
находить
и
устранять
ошибки
по
мере
развития
проекта
,
42
а
не
после
завершения
его
описания
.
Генератор
отчетов
формирует
тексты
выходных
документов
на
основе
содержащейся
в
репозитории
информации
.
Средства
автоматической
генерации
кодов
программ
на
языке
С
++,
используя
информацию
,
содержащуюся
в
диаграммах
классов
и
компонентов
,
формируют
файлы
заголовков
и
файлы
описаний
классов
и
объектов
.
Создаваемый
таким
образом
скелет
программы
может
быть
уточнен
путем
прямого
программирования
на
языке
С
++.
Анализатор
кодов
С
++
реализован
в
виде
отдельного
программного
модуля
.
Его
назначение
–
создавать
модули
проектов
Rational Rose
на
основе
информации
,
содержащейся
в
определяемых
пользователем
исходных
текстах
на
С
++.
В
процессе
работы
анализатор
осуществляет
контроль
правильности
исходных
текстов
и
диагностику
ошибок
.
Модель
,
полученная
в
результате
его
работы
,
может
целиком
или
фрагментарно
использоваться
в
различных
проектах
.
Анализатор
обладает
широкими
возможностями
настройки
по
входу
и
выходу
.
Например
,
можно
определить
типы
исходных
файлов
,
базовый
компилятор
,
задать
,
какая
информация
должна
быть
включена
в
формируемую
модель
,
и
какие
элементы
выходной
модели
следует
выводить
на
экран
.
Таким
образом
,
Rational Rose/
С
++
обеспечивает
возможность
повторного
использования
программных
компонентов
.
В
результате
разработки
проекта
с
помощью
CASE-
средства
Rational
Rose
формируются
следующие
документы
:
–
диаграммы
UML,
в
совокупности
представляющие
собой
модель
разрабатываемой
программной
системы
;
–
спецификации
классов
,
объектов
,
атрибутов
и
операций
;
–
заготовки
текстов
программ
.
Тексты
программ
являются
заготовками
для
последующей
работы
программистов
.
Состав
информации
,
включаемой
в
программные
файлы
,
определяется
либо
по
умолчанию
,
либо
по
усмотрению
пользователя
.
В
дальнейшем
эти
исходные
тексты
развиваются
программистами
в
полноценные
программы
.
Взаимодействие
с
другими
средствами
и
организация
групповой
работы
.
Для
поддержки
командной
работы
над
проектом
на
каждой