Файл: Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы.pdf
Добавлен: 13.03.2024
Просмотров: 22
Скачиваний: 0
Каждый из функциональных блоков, принадлежащих дочерней диаграмме, называется дочерним блоком.
Каждый блок дочерней диаграммы может быть далее детализирован аналогичным образом, став родительским по отношению с соответствующей диаграмме его детализации.
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, кото-рая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм.
Для того чтобы указать положение любой диаграммы в иерархии, используются номера диаграмм. На рис. 9 показано дерево диаграмм.
Рисунок 9 – Дерево диаграмм
Глоссарий. Последним из понятий IDEF0 является глоссарий. Для каждого из элементов IDEF0 – диаграмм, функциональных блоков, интерфейсных дуг – существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. [7]
Глава 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 разработана с учетом таких требований, как простота изучения и возможность автоматизации.