2.2 Моделирование прецедентов

Разработка программного обеспечения подчиняется определенному жизненному циклу (ЖЦ). Жизненный цикл - это упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках каждого проекта по разработке ПО. Жизненный цикл определяет этапы, так что программный продукт переходит с одного этапа на другой, начиная с зарождения концепции продукта и заканчивая этапом его сопровождения.

На укрупненном уровне ЖЦ включает три этапа:

анализ;

проектирование;

реализация.

На детализированном уровне ЖЦ можно разбить на семь этапов:

установление требований;

спецификация требований;

проектирование архитектуры;

детализированное проектирование;

реализация;

интеграция;

сопровождение.

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

Рассмотрим требования предъявляемые пользователями данной системы. У будущих пользователей возникают следующие требования к разрабатываемой системе:

система должна уменьшить количество затраченного времени на поиск и обработку информацию;

возможность пользователю при наличии минимальных знаний компьютера использовать программный продукт;

система должна обеспечить достоверность информации, все время пополняя базу данных, так как информация о клиентах часто обновляется;

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

Следующим этапом разработки программного продукта является построение диаграммы прецедентов.

Поведение системы - так как оно выглядит для внешнего пользователя - изображается в виде прецедентов. Модели прецедентов можно разрабатывать на различных уровнях абстракции. На этапе анализа прецеденты вбирают в себя системные требования, концентрируясь на том, что делает или должна делать система.

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

Диаграмма прецедентов - это документированная модель предполагаемого поведения системы.

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

краткое описание;

предусловия;

детализированное описание потока событий: основной поток и альтернативные потоки;

постусловия.

Диаграмма прецедентов показана на рисунке 2.1.

Рисунок 2.1 - Диаграмма прецедентов

Для дальнейшего более подробного рассмотрения и документирования выделяется прецедент "Формирование письма".

Приведем описательную спецификацию данного прецедента:

а) прецедент дает возможность оператору провести заполнение письма-уведомления и отобразить результаты в текстовый документ;

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

в) основной поток: инженер отдела биллинга вызывает страницу графического отображения данных о клиентах и их реквизитов (сумма долга, оплата, ЛС, текущий долг), выбрав в пункте меню "Список должников”. Далее инженер может выбрать условия ограничения поиска данных (период, за который необходимы данные). Полученные результаты отображаются на экране. Далее инженер вводит номер лицевого счёта и на основе полученных данных формирует письмо уведомления, затем выводит отчет на печать;

г) альтернативный поток: инженер может импортировать данные MS Excel и перейти к главному окно, а так добавить в базу данных сведения о новом клиенте;

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