Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Задачи и этапы предпроектного обследования).pdf

7) для выделения связи внешних стрелок с соответствующими граничными стрелками, границу субъекта изобразить жирной линией;

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

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

Диаграмма – это основная единица описания системы, расположенная на отдельном листе, представляющая функции и интерфейсы в виде блоков и дуг. Место соединения дуги с блоком определяет тип интерфейса. Диаграммы являются графическим представлением знаний экспертов о моделируемой системе и предметом обсуждения со специалистами конкретной предметной области. Аналитик представляет знания экспертов, изложенные с помощью естественного языка, используя графическую нотацию IDEF0, давая более наглядное, лаконичное и однозначное описание системы, не жертвуя при этом качеством представления. Таким образом, в ходе разработки диаграмм знания экспертов структурируются, и устраняется неоднозначность описаний за счет:

• стандартизации интерпретации графических обозначений. Так, например, содержание контекстной диаграммы интерпретируется следующим образом: «Процесс преобразует Вход в Выход при выполнении условий, заданных в Управление с помощью Механизма»;

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

Моделирование IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.

Контекстная диаграмма – это IDEF0-диаграмма, расположенная на вершине иерархии диаграмм, представляющая собой самое общее описание системы, состоит из одного блока, описывающего функцию верхнего уровня, стрелок и пояснительного текста, определяющего точку зрения и цель моделирования. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Контекстная диаграмма имеет узловой номер A-n (n = 0), которая представляет контекст модели. Диаграмма верхнего уровня обозначается идентификатором «А-0» (произносится «А минус ноль»), на которой объект моделирования представлен единственным блоком с граничными стрелками, отображающими связь системы с окружающей средой, устанавливает область моделирования, определяет границы модели и является обязательной диаграммой IDEF0-модели. Поскольку единственный блок представляет весь объект, то его имя – общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта.

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

Точка зрения. С определением модели тесно связана позиция, с которой наблюдается система и создается ее модель. Поскольку качество описания системы резко снижается, если оно ни на чем не сфокусировано, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции. Эта позиция называется «точкой зрения» данной модели. Точка зрения определяет основное направление развития модели, уровень необходимой детализации, что и в каком разрезе можно увидеть в пределах модели. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Изменение точки зрения приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект. У модели может быть только одна точка зрения. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели. Точка зрения определяет субъект моделирования и что, соответственно, будет в дальнейшем рассматриваться как элементы/компоненты системы, а что – как внешняя среда/воздействие.

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

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

Таким образом, в процессе декомпозиции функциональные блоки диаграммы подвергаются детализации на другой диаграмме, которая называется дочерней (Child Diagram) по отношению к детализируемому блоку. Каждый из функциональных блоков, принадлежащих дочерней диаграмме, называется дочерним блоком (Child Box). В свою очередь, функциональный блок-предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждый блок дочерней диаграммы может быть далее детализирован аналогичным образом, став родительским по отношению с соответствующей диаграмме его детализации.

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

SSADM (Structured Systems Analysis and Design Method) – системный подход к анализу и проектированию ИС. SSADM как комплект стандартов для системного анализа и разработки приложений был разработан в начале 1980-х для Центрального агентства по компьютерам и телекоммуникациям (Central Computer and Telecommunications Agency, сейчас это Office of Government Commerce) – государственного учреждения UK, заинтересованного в использовании технологии в управлении. Позже SSADM широко использовался для государственных ИТ-проектов в UK, затем нашел широкое применение во всем мире для проектирования ИС. SSADM использует комбинацию текста и диаграмм для проектирования системы на всем ее жизненном цикле, от идеи до реального физического проекта приложения SSADM использует комбинацию из трех методологий моделирования.

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

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

• связи (relationships) – ассоциации между сущностями.

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

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

• накопители данных (data stores) – области (промежуточного) хранения данных (the holding areas for data);

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

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

3. Моделирование поведения сущностей (Entity Behavior Modeling) – процесс идентификации, моделирования и документирования событий, которые влияют на каждую сущность и последовательности, в которой эти события происходят. Каждая их этих трех моделей системы обеспечивает различные точки зрения на одну и ту же систему, и каждая из точек зрения необходима для формирования полной модели проектируемой системы. Все три методологии во взаимосвязи друг с другом (are cross-referenced against each other) дают гарантию полноты и точности всего приложения.

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

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

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

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

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

5. Физический проект (Physical Design). На этапе физического проектирования создается физический проект базы данных и комплект программных спецификаций с использованием логической и технической системных спецификаций. В отличие от RAD (см. гл. 1.5), который подразумевает параллельное выполнение этапов, SSADM строит каждый этап на основе работы, которая была предписана на предыдущем этапе без отклонений от модели.

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

Проектирование модели данных

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

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

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

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

3) генерация системного каталога СУБД или соответствующего SQLскрипта на основе физической модели. ERwin при генерации физической схемы включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД. Прямое проектирование обеспечивает масштабируемость – создав одну логическую модель данных, можно сгенерировать физические модели под любые СУБД. Обратное проектирование (Reverse Engineering) – процесс генерации логической модели из физической БД. Обратное проектирование решает задачу позволяет конвертировать БД из одной СУБД в другую. После создания логической модели БД путем обратного проектирования можно переключиться на другой сервер и произвести прямое проектирование. 1) по содержимому системного каталога или SQL-скрипту воссоздается логическая модель данных; 2) на основе полученной логической модели данных генерируется физическая модель для другой СУБД; 3) создается системный каталог этой СУБД. Обратное проектирование решает задачу по переносу структуры данных с одного сервера на другой.

Создание логической модели данных

Информационное (концептуальное) моделирование

Цель информационного моделирования – обеспечение разработчиков ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей данных, которые относительно легко могут быть отображены в любую систему баз данных. Концептуальная схема представляет собой карту понятий и отношений между ними, т.е. семантику организации (а не дизайн базы данных) и может существовать на различных уровнях абстракции. Если функциональная схема представляет собой определенную точку зрения на мир и не является гибкой (меняется мир – должна поменяться схема), то концептуальная схема объединяет в себе все точки зрения и дает более абстрактное представление об объекте, описывая фундаментальные понятия, лишь с экземплярами которых человек имеет дело. В инженерии ПО, моделирование «сущность-связь» (Entity-Relationship Model, ERM) – это пример абстрактного и концептуального представление данных; это метод моделирования БД, используемый для создания концептуальной схемы или семантической модели данных системы (часто реляционной БД), а также требований к системе в форме «сверху-вниз». Диаграммы, созданные таким способом, называются диаграммами «сущность-связь» (entity-relationship diagrams) или ER-диаграммами, или кратко ERD. ERD является наиболее распространенным средством документирования данных. С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных. На уровне физической модели сущности соответствует таблица; экземпляру сущности – строка в таблице; атрибуту – колонка таблицы.

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

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