- •Проектирование информационных систем
- •Введение
- •1. Объектно-ориентированные методы анализа и проектирования информационных систем
- •1.1. Основы объектно-ориентированного подхода
- •1.2. Основные элементы объектной модели
- •1.3. Общие сведения о языке uml
- •1.4. Диаграммы вариантов использования
- •1.5. Диаграммы взаимодействий
- •1.6. Диаграммы классов
- •1.7. Диаграммы состояний
- •1.8. Диаграммы деятельностей
- •1.9. Диаграммы компонентов
- •1.10. Диаграммы размещения
- •1.11. Объектный подход к моделированию бизнес-процессов
- •2. Работа в среде Rational Rose
- •2.1. Инструментальное средство Rational Rose
- •2.2. Элементы экрана Rational Rose
- •2.3. Четыре представления модели Rational Rose
- •2.4. Параметры настройки отображения
- •3. Лабораторный практикум Лабораторная работа № 1 Построение бизнес-модели
- •Лабораторная работа № 2 Действующие лица и варианты использования
- •Лабораторная работа № 3 Классы и пакеты
- •Лабораторная работа № 4 Взаимодействие объектов
- •Лабораторная работа № 5 Атрибуты, операции и связи
- •Лабораторная работа № 6 Поведение объектов
- •Лабораторная работа № 7 Представление компонентов
- •Лабораторная работа № 8 Представление размещения
- •Библиографический список
1.9. Диаграммы компонентов
Диаграмма компонентов показывает, как выглядит система на физическом уровне. На ней изображены компоненты программного обеспечения и связи между ними. Используется для моделирования иерархии подсистем системы.
Компонент является физической частью системы. Компонентом может быть таблица, массив данных, исполняемый файл, динамически подключаемая библиотека, документ и т.д. Компонент можно рассматривать как программную реализацию класса, причем один компонент может содержать реализацию нескольких классов. Компоненты моделируют для реализации следующих целей:
заказчик сможет увидеть структуру законченной системы;
разработчики смогут представить структуру будущей работы;
редакторы документации и файлов справки смогут лучше понять, что именно разрабатывается;
компоненты можно будет использовать повторно.
Главный элемент диаграммы компонентов имеет вид прямоугольника, на левую сторону которого наложены еще два прямоугольника. Эта пиктограмма обозначает компонент (рис. 17). Внутрь пиктограммы помещается имя компонента.
Рис. 17. Обозначение компонента
Если компонент является элементом пакета, то имя пакета можно указать перед именем компонента. Можно также добавить информацию, разъясняющую содержимое компонента (классы, реализуемые компонентом). Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы (рис. 18).
Рис. 18. Диаграмма компонентов
Диаграмма компонентов может быть конкретизирована в зависимости от того, каким образом реализуется система. На рис. 19–20 изображены диаграммы компонентов банковской системы.
Банковская система содержит два потока управления и, таким образом, получаются два исполняемых файла. Один из них – клиентская часть системы, она содержит компоненты CashDispenser, CardReader и ATMScreen. Второй файл – это сервер, включающий в себя компонент Account.
Система разрабатывается на языке C++. У каждого класса имеется свой заголовочный файл (файл с расширением .h) и файл тела класса (файл с расширением .срр). Например, класс ATMScreen преобразуется в компоненты ATMScreen: тело и заголовок класса. Выделенный темным компонент называется спецификацией пакета (package specification) и соответствует файлу тела класса ATMScreen. Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса. Компонент АТМ.ехе называется спецификацией задачи и моделирует поток управления – исполняемую программу.
Рис. 19. Диаграмма компонентов для клиентской части системы
Компоненты соединены зависимостями. Например, класс CardReader зависит от класса ATMScreen. Это означает, что, для того чтобы класс CardReader мог быть скомпилирован, класс ATMScreen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл ATMClient.exe.
Рис. 20. Диаграмма компонентов для сервера
В модели может быть несколько диаграмм компонентов, в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонентов. Диаграммы компонентов применяются участниками проекта, отвечающими за компиляцию и сборку системы (там, где начинается генерация кода).
