1.2.5. МетодVord(на основе различных точек зрения)

Точка зрения – это источник информации о системных данных. В этом случае точка зрения – основа для построения модели создания и использования данных в системе.

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

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

Идентификация точек зрения:

Информация обо всех ВУЗах

Фильтрация списка ВУЗов

Работа с проектами

Обновление системы

Информация об услугах репетиторов и подготовительных курсах

Просмотр календаря

Редактирование календаря

Информация

о проходных баллах

в прошедшие года

В овалах изображениы опорные точки мнения.

В прямоугольниках изображениы сервисы.

Структурирование точек зрения:

Анализируем данные предыдущего пункта, определяем, что нет сервисов не связанных ни с одной точкой зрения. Было обноружено, что на данном этапе точка зрения Служба безопасности не имеет сервисов, поэтому мы исключаем эту точку зрения из рассмотрения. Получаем иерархию наследования:

Работа с проектами

Обновление системы

Информация об услугах репетиторов и подготовительных курсах

Информация

о проходных баллах

в прошедшие года

Информация обо всех ВУЗах

Фильтрация списка ВУЗов

Редактирование календаря

Просмотр календаря

Документирование точек зрения:

Сервисы необходимо описать, как сценарии событий. Для этого вернёмся к пункту 1.2.4, где уже описаны сценарии.

1.2.6. Этнографический подход

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

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

Врезультате мы получили пользовательские требования, ключевые моменты которых см. в Приложении 5.

1.3. Разработка системных требований

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

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

1.3.1. Системные модели

Модели потоков данных:

Модели потоков данных – это простой и понятный способ описания последовательности обработки данных внутри системы. Для описания модели потоков данных воспользуемся диаграммами потоков данных (data flow diagram, DFD), во всем многообразии нотаций которых, можно выделить основные компоненты:

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

• поток данных – определяющий перемещение данных (материалов) между процессами;

• хранилище – места хранения данных (базы данных, например);

• внешние сущности – объекты внешнего (по отношению к системе) мира.

Детализация:

Модели конечных автоматов:

М

Запрос 4

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

Модели данных:

В разрабатываемом прототипе для получения данных о ВУЗах используется текстовый файл.

Информация в нём должна находиться в следующем формате:

V ВУЗ1:ВУЗ2;…:ВУЗn.

A АДР1: АДР1;…: АДР1.

S Сайт1: Сайт12;…: Сайт1n.

E Событие1: Событие 2;…: Событие n.

Важное замечание при работе с прототипом: в вводимых данных нельзя использовать символы «V», «A», «S», «E» кроме как в случае, их использования при описании формата данных. Символ «.» следует заменить на «|». Символ «;» - разделитель.

Над файлом определена следующая операция: loadFromFile.

Входные данные: тексьовый файл.

Выходные данные:

4 массива: vuz, address, site, events.

В общем случае в массивах содержится следующая информация:

Vuz – содержит данные из строки файла, которая начинается на символ «V».

Adress – содержит данные из строки файла, которая начинается на символ «A».

Site – содержит данные из строки файла, которая начинается на символ «S».

Events – содержит данные из строки файла, которая начинается на символ «E».

1й элемент массива – текст строки м/у первым пробелом и символом «;».

Следующие Эл-ты – текст строки м/у символами «;».

Последний элемент содержит текст строки от символа «;» до символа «.».

Присутствует соответствие: элементы массивов с одинаковыми номерами логически объединены, т.е описывают один и тот же ВУЗ.