5.Анализ требований и определение спецификаций программного обеспечения при объектном подходе

5.1.UML – стандартный язык описания разработки программных продуктов с использование объектного подхода

Модели разрабатываемого ПО при объектном подходе основаны на предметах и явлениях реального мира. В основе всех моделей лежит описание требуемого поведения разрабатываемого ПО, т.е. его функциональности, но это поведение связывается с состояниями элементов (объектов) конкретной предметной области.

Таким образом, на этапе анализа ставятся две задачи:

• уточнить требуемое поведение разрабатываемого ПО;

• разработать концептуальную модель его предметной области с точки зрения поставленных задач.

В основе объектного подхода к разработке ПО лежит объектная декомпозиция, т.е. представлении разрабатываемого ПО в виде совокупности объектов, в процессе взаимодействия которых посредством передачи сообщений и происходит выполнение требуемых функций (рис. 5.1).

Разрабатываемое с помощью объектного подхода программное обеспечение, как правило, очень сложно, поэтому для описания разработки в настоящее время используют специальный язык – универсальный язык моделирования UML. Этот язык, авторами которого являются Г. Буч, Д. Рамбо и А. Джакобсон [1], недавно был признан стандартным средством описания объектных разработок.

Полное описание разработки с использованием UML включает несколько моделей, характеризующих определенный аспект проектируемой системы (рис. 5.2):

• модель использования – представляет собой описание функциональности ПО с точки зрения пользователя;

• логическая модель – описывает ключевые абстракции ПО (классы, интерфейсы, и т.п.), т.е. средства, обеспечивающие требуемую функциональность;

• модель реализации – определяет реальную организацию программных модулей;

• модель процессов – отображает организацию вычислений и оперирует понятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность ПО;

• модель развертывания – показывает особенности размещения программных компонентов на конкретном оборудовании.

Всего UML предлагает девять дополняющих друг друга диаграмм, входящих в различные модели:

• диаграммы вариантов использования;

• диаграммы классов;

• диаграммы пакетов:

• диаграммы последовательностей действий;

• диаграммы кооперации:

• диаграммы деятельностей:

• диаграммы состояний объектов:

• диаграммы компонентов:

• диаграммы размещения.

Полная спецификация разрабатываемого ПО, помимо указанных диаграмм, как и при структурном подходе, обязательно включает словарь терминов и различного рода описания и текстовые спецификации. Конкретный набор документации определяется разработчиком.

UML и предлагаемая теми же авторами методика разработки ПО названная Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм можно получить также средствами программы Microsoft Visual Modeler и других CASE-средств.

5.2.Определение вариантов использования

Разработку спецификаций начинают с анализа требований к функциональности, указанных в техническом задании. В процессе этого анализа выявляют внешних пользователей разрабатываемого ПО и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспекты поведения ПО были названы «вариантами использования» или «прецедентами» (use cases).

Вариант использования представляет собой характерную процедуру применения разрабатываемой системы конкретным действующим лицом, в качестве которого могут выступать не только люди, но и другие системы и устройства.

Не следует путать вариант использования с конкретными операциями будущей системы. Каждый вариант использования связан с некоторой целью, имеющей самостоятельное значение, например, для текстового редактора Формирование оглавления – это вариант использования, а Связывание заголовков со специальными стилями – операция, которую необходимо выполнить, чтобы стало возможно автоматическое построение оглавления.

В зависимости от цели выполнения процедуры различают следующие варианты использования:

• основные – обеспечивают требуемую функциональность разрабатываемого ПО;

• вспомогательные – обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т.п.);

• дополнительные – обеспечивают дополнительные удобства для пользователя (как правило, реализуются в том случае, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации).

В зависимости от уровня абстракции вариант использования может описываться кратко или более подробно. Краткая форма описания содержит: название варианта использования, его цель, действующих лиц, тип варианта использования (основная, второстепенная или дополнительная) и его краткое описание. Ниже приведено краткое описание варианта использование Выполнение задания системы решения комбинаторно-оптимизационных задач. Предполагается, что эта система должна обеспечивать возможность решения нескольких комбинаторно-оптимизационных задач на графах (задачи коммивояжера, задачи определения кратчайшего пути и т.п.) разными алгоритмами и хранить в базе данных исходные данные и результаты.

Название варианта	Выполнение задания
Цель	Получение результатов решения задачи
Действующие лица	Пользователь
Краткое описание	Решение задачи предполагает выбор задачи, выбор алгоритма, задание данных и получение результатов решения.
Тип	Основной

Основные варианты использования обычно описывают подробно, стараясь отразить особенности предметной области разрабатываемого ПО. Подробная форма, кроме указанной выше информации, включает описание типичного хода событий и возможных альтернатив. Типичный ход событий представляют в виде диалога между пользователями и системой, последовательно нумеруя события. Если пользователь может выбирать варианты, то их описывают в отдельных таблицах. Также отдельно приводят альтернативы, связанные с нарушением типичного хода событий. Например:

Вариант использования Выполнение задания

Типичный ход событий

Действия исполнителя	Отклик системы
1. Пользователь инициирует новое задание	2. Система регистрирует новое задание и предлагает список типов задач
3. Пользователь выбирает тип задачи.	4. Система регистрирует тип задачи и предлагает список способов задания данных
5. Пользователь выбирает способ задания данных. а) Если выбран ввод с клавиатуры, см. раздел Ввод данных. б) Если выбран ввод из базы данных, см. раздел Выбор данных из базы	6. Система регистрирует данные и предлагает список алгоритмов решения
7. Пользователь выбирает алгоритм	8. Система регистрирует алгоритм и предлагает начать решение
9. Пользователь инициирует процесс решения	10. Система запускает подпрограмму решения задачи
11. Пользователь ожидает	12. Система демонстрирует результаты и предлагает сохранить их в базе
13. Пользователь анализирует результаты и выбирает, сохранять их в базе или нет	14. Если выбрано сохранение данных, то система выполняет запись данных задания в базу
	15. Система переходит в состояние ожидания

Альтернатива:

10. Если время выполнения программы с точки зрения пользователя велико, то он прерывает процесс выполнения.

11. Система прерывает расчеты, предлагает список алгоритмов решения и возвращается на шаг 7.

Дополнительная информация.

1. Необходимо обеспечить произвольную последовательность выбора типа задачи, данных и алгоритма.

2. Необходимо обеспечить возможность выхода из варианта на любом этапе.

Раздел Ввод данных

Типичный ход событий

Действия исполнителя	Отклик системы
1. Пользователь выбрал Ввод данных.	2. Система последовательно запрашивает ввод данных.
3. Пользователь вводит данные.	4. Система проверяет данные и запрашивает, сохранять ли данные в базе.
5. Пользователь отвечает на запрос.	6. Если выбран вариант сохранения данных, то система выполняет запись данных в базу и регистрирует их в текущем задании.

Альтернатива:

4. Если обнаружены некорректные данные, то система выдает сообщение об ошибке с диагностикой и предлагает их исправить, возвращаясь на предыдущий шаг.

Раздел Выбор данных из базы