Объектно-ориентированный подход
Вспомним понятие класса.
Класс – множество однотипных объектов, у которых есть:
- свойства
- методы
Для описания свойств системы используется специальный язык UML (Unified Modeling Language) под управлением Rational Rose.
Язык UML
Этот язык хорошо описывает проект и архитектуру создаваемой системы.
Архитектура создаваемой системы описывается следующими документами (или артефактами, как они называются в Rational Rose):
1. Представление условий использования (взаимодействие системы с пользователем);
2. Логическое представление (структура системы, например диаграмма классов);
3. Компонентное представление системы (размещение логических элементов системы по программным исполняемым модулям и физическим БД);
4. Представление о размещении (привязка компонент к конкретным аппаратным средствам);
Для изображения каждого типа схем в UML есть специальные графические средства, которые позволяют строить диаграммы.
Рассмотрим подробно все типы графических средств UML.
Представление об условиях использования системы
Иначе это называется прецедентами использования системы пользователем.
Основной прецедент – типовой алгоритм взаимодействия пользователя с системой.
Вспомогательный прецедент – нетиповые алгоритмы взаимодействия пользователя с системой.
ГОСТов на описание прецедентов нет.
Этот артефакт составляется системным аналитиком.
Рассмотрим пример артефакта описания прецедента использования системы.
Прецедент – «Покупка товара»
| № Шага | Действующий субъект | Система | Ограничения |
| 1. | Прецедент начинается, когда продавец нажимает кнопку «Новая продажа» | Для продавца открывается окно «Новая продажа» и включается сканер | Общее время отклика < 1 сек |
| 2. | Продавец сканирует товары и вводит количество | Отображает наименование и цену товара | Общее время отклика на сканирование 1 товара < 1 сек |
| 3. | Продавец щелкает кнопку «Итого» | Вычисляет и отображает стоимость | |
| 4. | Продавец считывает дисконтную карту | Если карта действительна*, то распечатывается чек со скидками, обновляется состав товара в магазине и сумма дохода. Это конец условия использования |
* Если дисконтная карта не действительна, то действует другой, вспомогательный прецедент.
Диаграмма прецедента использования на языке UML.
Условные обозначения:
| № | Условное обозначение | Расшифровка |
| 1. |
| Актер (либо пользователь, либо внешняя система) |
| 2. |
| Прецедент использования |
Пример:
Диаграммы прецедентов определяют основные требования к системе, определяет функциональные требования к системе.
Прочие функциональные требования – дополнительные требования по быстродействию, объему памяти и другие специфические количественные требования.
Для описания дополнительных требований специальных формализмов нет, в ряде случаев при описании требований используют ограничения.
Диаграммы логического представления.
Диаграммы класса
Условные обозначения:
| 1. |  | класс | |
| 2. |  | Отношение ассоциаций | |
| 3. |  | Отношение обобщения | Пример:
Свойства летательного аппарата наследуются самолетом. |
| 4. | | Отношение агрегации | Пример:
|
| 5. |  | Отношение зависимости | Независимый класс (элемент) может разрабатываться независимо от зависимого класса (элемента). |
| 6. | | Отношение включения (физического) | Один класс входит в состав другого более сложного класса. |
| 7. | | Отношение реализации |  Пример: Для выполнения методов используется класс – справочник.
|
Пример диаграммы класса:
Предметная область: покупатель хочет приобрести товар.
Введем классы в ПО:
1. Продукт и его запасы в магазине
2. Заказ его составляющие
3. Клиент:
- Юридическое лицо
- Физическое лицо
|
|
|
Эта диаграмма является базовой. В основе получения программного кода лежит именно диаграмма класса.
В начале создается базовая диаграмма класса, а затем она уточняется.
Классы, относящиеся к одной подобласти предметной области, могут быть объединены в пакеты.
|
Между пакетами могут существовать отношения, в основном это отношения зависимостей.
Эти отношения между пакетами описываются в рамках диаграммы пакетов.
Пример диаграммы пакетов:
Диаграмма состояния класса
Диаграмма состояния класса описывает диаграммы объектов одного класса.
Условные обозначения:
| 1. |  | Вершина |
| 2. |  | Конечная вершина |
| 3. |  | Состояние |
| 4. |  | Переход |
Построим граф перехода для объекта «строка заказа»
Для случая, когда заказ может быть удовлетворен или неудовлетворен.
На стрелке указывается
- Условие перехода
- Действие, сопровождающее переход.
Практически на стрелке записывается продукция.
Граф состояний определяет диаграмму поведения одного объекта.
Диаграмма взаимодействия
(объектов разных классов при исполнении одного прецедента)
Существует 2 типа диаграммы взаимодействия:
1. Диаграмма последовательности взаимодействия
Условные обозначения:
| Актёр
|  |
| Класс типа «сущность» (классы баз данных) |  |
| Класс типа «экранная форма» |  |
| Управляющие классы |  |
При построении диаграммы следует помнить, что время на диаграмме течёт сверху вниз.
Пример:
Оформляется и исполняется заказ на закупку:
1. Кооперативная диаграмма
Пример:
| ||||
 | ||||
|
|
|
|
|
Нумеровка на диаграмме соответствует последовательности действий.
Диаграмма деятельности
С её помощью описываются процессы, происходящие в системе с учётом их параллелизма.
Пример использования операторов fork (распараллеливание) и join (объединение):
Пример:
Человек испытывает жажду и хочет выпить кофе.
Диаграмма компонентов
Показывает, как выглядит система на физическом уровне.
В одном компоненте могут быть файлы c расширением *.exe или более сложные структуры. Внутри компонента могут находиться один или более классов.
Условное обозначение компонентов:
Диаграмма размещения
Указывает размещение компонентов по аппаратным средствам системы (где будут физически размещаться отдельные компоненты: на серверах, на рабочих станциях и т.д.)