Файл: Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы.pdf

Глава III. Метод структурного системного анализа и проектирования SSADM

3.1 Основные понятия метода SSADM

SSADM (Structured Systems Analysis and Design Method) – системный подход к анализу и проектированию ИС.

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

1. Логическое моделирование данных– процесс идентификации, моделирования и документирования требований к разрабатываемой системе. Элементы логической модели данных:

- связи – ассоциации между сущностями.

- сущности – то, о чем фирме нужно записать информацию;

2. Моделирование потоков данных– процесс идентификации, моделирования и документирования движения данных в ИС. Моделирование потоков данных исследует:

- потоки данных – маршруты, по которым данные могут двигаться.

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

- внешние сущности – сущности, которые посылают данные в систему или получают данные из системы;

- накопители данных – области (промежуточного) хранения

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

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

Все три методологии во взаимосвязи друг с другом дают гарантию полноты и точности всего приложения.

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

1. Анализ осуществимости проектного решения– анализ предметной области для определения сможет ли проектируемая система удовлетворить бизнес-требованиям.

2. Анализ требований. На этом этапе определяются подлежащие разработке системные требования и моделируется текущая среда предприятия в терминах процессов с включением структур данных.

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

4. Логическая системная спецификация. На этом этапе вырабатываются опции технической системы, логический проект обновлений, обработка запросов и системные диалоги.

5. Физический проект. На этапе физического проектирования создается физический проект базы данных и комплект программных спецификаций с использованием логической и технической системных спецификаций.

По причине жесткой структуры методологии, SSADM хороша с точки зрения контроля проектов и способности разрабатывать системы лучшего качества. [2]

3.2 Моделирование данных

Существует два уровня представления модели данных – логический и физический.

Логическая модель – это абстрактное представление данных. В логической модели данные представляются и могут называться так, как выглядят и называются в реальном мире, например «Постоянный клиент», «Отдел» или «Фамилия сотрудника». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами.

В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД, фактически являясь отображением ее системного каталога. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Особенности документирования физической модели заключаются в следующем:

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

2) многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов – пробела и т. п.);

3) в нелокализованных версиях СУБД объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т.е. нельзя назвать таблицу, используя предложение – ее можно назвать только одним словом);

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

Существует два типа проектирования модели данных: прямое и обратное.

Прямое проектирование – процесс генерации физической схемы БД из логической модели, состоящий из следующих этапов:

1) разработка логической модели;

2) выбор СУБД и автоматическое создание физической модели на основе логической;

3) генерация системного каталога СУБД или соответствующего SQL-скрипта на основе физической модели.

Прямое проектирование обеспечивает масштабируемость – создав одну логическую модель данных, можно сгенерировать физические модели под любые СУБД.

Обратное проектирование – процесс генерации логической модели из физической БД. Обратное проектирование решает задачу позволяет конвертировать БД из одной СУБД в другую. После создания логической модели БД путем обратного проектирования можно переключиться на другой сервер и произвести прямое проектирование.

1) по содержимому системного каталога или SQL-скрипту воссоздается логическая модель данных;

2) на основе полученной логической модели данных генерируется физическая модель для другой СУБД;

3) создается системный каталог этой СУБД.

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

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

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

В инженерии ПО, моделирование «сущность-связь»– это пример абстрактного и концептуального представление данных; это метод моделирования БД, используемый для создания концептуальной схемы или семантической модели данных системы (часто реляционной БД), а также требований к системе в форме «сверху-вниз». Диаграммы, созданные таким способом, называются диаграммами «сущность-связь» или ER-диаграммами, или кратко ERD.

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

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

1. Модель данных, основанная на ключах– более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.

2. Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи «многие-ко-многим» и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.

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

Существует несколько соглашений для ERD. Классическая нотация связана, главным образом, с концептуальным моделированием. При этом существует ряд нотаций, применяемых для логического и физического проектирования БД, например IDEF1X. Диаграмма структуры данных DSD – это модель данных для описания концептуальных моделей данных с помощью графических нотаций, которые документируют сущности и связи между ними, а также условия по ограничению связей. Диаграммы структуры данных DSD являются расширением E-R-модели.

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

Рисунок 11 - Графическое изображение сущности

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

Рисунок 12 - Графическое изображение связей

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

Атрибут может быть либо обязательным, либо необязательным (рис. 13). Обязательность означает, что атрибут не может принимать неопределенных значений.

Рисунок 13 - Обязательные и необязательные атрибуты

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

Рисунок 14 - Идентификация атрибутов

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

Каждая сущность должна обладать хотя бы одним возможным ключом.

3.3 Методология IDEF1X

IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации.

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

Рисунок 19 - Независимые и зависимые сущности

Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (рис. 20).

Рисунок 20 - Связь

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

- каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.