Системный анализ предметной области

Тема «Системный анализ предметной области»

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

Предметная область определяет назначение и функции базы данных.

Для определения функционала будущей базы данных необходимо выполнить системный анализ предметной области.

Моделирование и анализ деятельности пользователей в рамках предметной области.

Концептуальное моделирование - создание модели "сущность-связь" на основе перечня объектов, полученного на предыдущем этапе.

Реляционное моделирование - преобразование модели "сущность-связь" в соответствии с требованиями реляционной модели

Генерация схемы базы данных.

Генерация прототипов программных модулей по иерахии функций и потокам данных.

Моделирование и анализ деятельности пользователей в рамках предметной области

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

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

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

Основные причины:

  1. не обеспечивается достаточно глубокий анализ требований к данным
  2. большая длительность процесса структурирования
  3. трудность учета и согласования изменений, сделанных в системе несколькими разработчиками
  4. ограничения сроков на разработку системы

Предметная область - часть реального мира, подлежащая изучению с целью организации управления.

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

В теории проектирования информационных систем предметную область принято рассматривать в виде трех представлений:

Реальность. Представление предметной области в том виде, как она реально существует.

Описание реальности. Как ее воспринимает человек (имеется в виду проектировщик базы данных).

Данные. Как она может быть описана с помощью символов.

Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):

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

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

Внутренняя схема - это сама база данных.

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

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

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

Логическое проектирование - преобразование требований к данным в структуры данных.

На выходе получаем структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.

Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.

КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ

сущности

связи

Представление аналитика

атрибуты

ЛОГИЧЕСКИЙ УРОВЕНЬ

записи

элементы данных

Представление программиста

связи между записям

ФИЗИЧЕСКИЙ УРОВЕНЬ

группирование данных

методы доступа

Представление администратора

индексы

CASE (Computer Aided Software Engeneering - создание программного обеспечения с помощью компьютера)

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

Основные черты CASE –технологии

  1. использование методологии структурного проектирования "сверху-вниз"
  2. разработка прикладной системы представляется в виде последовательных четко определенных этапов:

Основные черты CASE –технологии

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

CASE-системы поддерживают следующие этапы процесса разработки:

  1. Моделирование и анализ деятельности пользователей в рамках предметной области.
  2. Концептуальное моделирование - создание модели "сущность-связь" на основе перечня объектов, полученного на предыдущем этапе.
  3. Реляционное моделирование - преобразование модели "сущность-связь" в соответствии с требованиями реляционной модели.
  4. Генерация схемы базы данных.
  5. Генерация прототипов программных модулей по иерахии функций и потокам данных.

Методология SADT (Structured Analisys and Design Technique) разработана Дугласом Т. Россом в 1969-73 годах. Она изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения.

IDEF0 (подмножество SADT) используется для моделирования бизнес-процессов в организационных системах и имеет развитые процедуры поддержки коллективной работы.

Правила интерпретации модели:

  1. Функциональный блок (функция) преобразует входные объекты в выходные
  2. Управление определяет, когда и как это преобразование может или должно произойти
  3. Исполнитель осуществляет это преобразование

Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничивается, зато рекомендуется на одной диаграмме использовать не менее 3 и не более 6 блоков.

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

Диаграммы потоков данных (DFD - Data Flow Diagramm)

нотация Йордона - Де Марко

Элемент

Описание

Обозначение

Функция

Действие, выполняемое моделируемой системой

Поток данных

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

Хранилище данных

Структура для хранения информационных объектов

Внешняя сущность

Внешний по отношению к системе объект, обменивающийся с нею потоками данных

Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами, представляющими потоки данных. Дуги могут разветвляться или сливаться, что означает, соответственно, разделение потока данных на части, либо слияние объектов.

При интерпретации DFD-диаграммы используются следующие правила:

  1. Функции преобразуют входящие потоки данных в выходящие
  2. Хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов
  3. Преобразования потоков данных во внешних сущностях игнорируется

Для каждого информационного потока и хранилища определяются связанные с ними элементы данных.

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

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

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

Уточнение модели производится путем детализации необходимых функций на DFD-диаграмме следующего уровня. Так мы можем разбить функцию "Определение потребностей и обеспечение материалами" на подфункции "Определение потребностей", "Поиск поставщиков", "Заключение и анализ договоров на поставку", "Контроль платежей", "Контроль поставок", связанные собственными потоками данных, которые будут представлены на отдельной диаграмме. Детализация модели должна производится до тех пор, пока она не будет содержать всю информацию, необходимую для построения информационной системы.

Системный анализ предметной области