2.2 Моделирование прецедентов
Разработка программного обеспечения подчиняется определенному жизненному циклу (ЖЦ). Жизненный цикл - это упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках каждого проекта по разработке ПО. Жизненный цикл определяет этапы, так что программный продукт переходит с одного этапа на другой, начиная с зарождения концепции продукта и заканчивая этапом его сопровождения.
На укрупненном уровне ЖЦ включает три этапа:
анализ;
проектирование;
реализация.
На детализированном уровне ЖЦ можно разбить на семь этапов:
установление требований;
спецификация требований;
проектирование архитектуры;
детализированное проектирование;
реализация;
интеграция;
сопровождение.
Наша задача рассмотреть подробно первый этап - установление требований. Задачей этапа определения требований является определение, анализ и обсуждение требований с заказчиками. На этом этапе применяются различные методы сбора информации от заказчиков, и занимается этим аналитик бизнес-процессов (системный аналитик). К методам можно отнести исследование концепции с помощью структурированных и неструктурированных интервью пользователей, анкеты, изучение документов и форм, видеозаписи и т.д.
Рассмотрим требования предъявляемые пользователями данной системы. У будущих пользователей возникают следующие требования к разрабатываемой системе:
система должна уменьшить количество затраченного времени на поиск и обработку информацию;
возможность пользователю при наличии минимальных знаний компьютера использовать программный продукт;
система должна обеспечить достоверность информации, все время пополняя базу данных, так как информация о клиентах часто обновляется;
система должна проводить анализ данных с учетом различных ограничений, выбранных пользователем и отображать результаты в табличном виде.
Следующим этапом разработки программного продукта является построение диаграммы прецедентов.
Поведение системы - так как оно выглядит для внешнего пользователя - изображается в виде прецедентов. Модели прецедентов можно разрабатывать на различных уровнях абстракции. На этапе анализа прецеденты вбирают в себя системные требования, концентрируясь на том, что делает или должна делать система.
Прецедент выполняет бизнес-функцию, которую может наблюдать внешний субъект и которая может быть впоследствии отдельно протестирована в процессе разработки. Субъект (актер) - это некто или нечто, взаимодействующее с прецедентом, ожидая в итоге получить некий полезный результат.
Диаграмма прецедентов - это документированная модель предполагаемого поведения системы.
Каждый прецедент должен быть описан с помощью документально зафиксированного потока событий. Соответствующий текстовый документ определяет, что должна делать система, когда актер инициирует прецедент. Структура документа, описывающего прецедент, различна, но типичное описание должно содержать следующие разделы:
краткое описание;
предусловия;
детализированное описание потока событий: основной поток и альтернативные потоки;
постусловия.
Диаграмма прецедентов показана на рисунке 2.1.
Рисунок 2.1 - Диаграмма прецедентов
Для дальнейшего более подробного рассмотрения и документирования выделяется прецедент "Формирование письма".
Приведем описательную спецификацию данного прецедента:
а) прецедент дает возможность оператору провести заполнение письма-уведомления и отобразить результаты в текстовый документ;
б) предусловиями для данного прецедента являются обязательное наличие базы данных;
в) основной поток: инженер отдела биллинга вызывает страницу графического отображения данных о клиентах и их реквизитов (сумма долга, оплата, ЛС, текущий долг), выбрав в пункте меню "Список должников”. Далее инженер может выбрать условия ограничения поиска данных (период, за который необходимы данные). Полученные результаты отображаются на экране. Далее инженер вводит номер лицевого счёта и на основе полученных данных формирует письмо уведомления, затем выводит отчет на печать;
г) альтернативный поток: инженер может импортировать данные MS Excel и перейти к главному окно, а так добавить в базу данных сведения о новом клиенте;
д) если прецедент закончился успешно, полученные результаты отображаются в табличном виде и графическом виде без сообщений об ошибках.
- Введение
- 1. Общая часть
- 1.1 Описание проблемной области
- 1.2 Описание средств проектирования
- 1.2.1 Язык программирования Delphi 7.0
- 1.2.2 Свойство SQL
- 1.2.3 Доступ к данным
- 2. Специальная часть
- 2.1 Моделирование проблемной области
- 2.2 Моделирование прецедентов
- 2.3 Построение диаграммы последовательности
- 2.4 Диаграмма состояния
- 2.5 Диаграмма классов
- 2.6 Проектирование баз данных
- 2.6.1 Этапы проектирования базы данных
- 2.6.2 Компоненты для работы с БД
- 2.6.3 Запросы и их применение
- 2.6.4 Взаимосвязи таблиц
- 2.6.5 Создание схемы данных
- 2.6.6 Создание контейнера TDataModule
- Статистика и анализ данных
- 3.3.14. Министерство статистики и анализа
- Глава XV, Общие вопросы анализа и обобщения данных правовой статистики
- 41. Подготовка к внедрению или разработке корпоративной информационной системы. Внедрение системы.
- Технология разработки и внедрения Хранилищ Данных
- Министерство статистики и анализа
- Организация сбора, обработки, хранения и передачи данных государственной статистики в российской федерации
- 4.6. Внедрение международной стандартной системы национальных счетов в государственную статистику Российской Федерации
- 33. Интеллектуальный анализ данных. Системы иад. Управление знаниями.