Особенности проектирования ис

Эволюция информационных систем от пакетной, массовой технологии обработки данных к системам, использующим базы данных, выявила три класса наиболее перспективных методологий проектирования. Первый из них ориентирован на концептуальное моделирование предметной области и технологию баз данных, второй — на выявление требований и спецификацию информационной системы через ее макетирование, третий — на системную архитектуру программных средств, поддерживаемую инструментальными средствами CASE (Computer Aided System Engineering) — технологии.

Проектирование систем на основе концептуального моделирования предметной области

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

При концептуальном моделировании ПО и применении технологии БД наиболее сложной задачей является выявление информационных и функциональных (динамических) связей между объектами реального мира.

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

Концептуальный подход к проектированию предполагает четыре этапа проектирования:

- сбор и анализ информационных потребностей пользователей, системный анализ предметной области;

- построение концептуальной (понятийной) модели предметной области;

- создание концептуальной модели базы данных;

- разработку системы  с  помощью инструментальных средств выбранной СУБД.

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

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

Концептуальная модель предметной области ориентирована на восприятие человека (пользователя и разработчика), а не на обработку данных в ЭВМ. Именно с помощью этой модели разработчики ИС (да и сами пользователи) достигают высокого уровня понимания существа информационных потребностей пользователей. В настоящее время для построения концептуальной модели предметной области обычно используют два подхода. При первом подходе модель ПО строится на основе интеграции спецификаций информационных потребностей, а при втором — на основе непосредственного анализа самой ПО.

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

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

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

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

Данный этап в свою очередь разбивают на следующие шаги:

- логическое проектирование БД;

- физическое проектирование БД;

- реализация приложений.

В соответствии с вышеизложенным методология проектирования ИС на основе концептуального моделирования ПО может быть представлена в виде последовательности этапов, изображенных на рис. 1.10.

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

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

Рис. 1.10. Этапы проектирования ИС на основе концептуального моделирования ПО.

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

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

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

Макетирование информационных систем

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

После получения замечаний и их устранения макет системы снова предъявляется пользователям. В результате проектируемая ИС эволюционирует и улучшается методом проб и ошибок.

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

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

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

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

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

Рис.1.11. Последовательность проектирования ИС на основе макета.

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

В связи с этим в другой смешанной методологии, напротив, предполагается, что этап структурированного анализа предшествует этапу макетирования. Но дальнейшая стратегия проектирования, по существу, совпадает с традиционной методологией, и если на более поздней стадии проекта потребуется внести изменения, то преимущества макетирования будут минимальными.

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

Методология пофазового проектирования на начальной стадии анализа и общего проектирования предполагает разбиение информационной системы на логические подсистемы, одна из которых детально проектируется, программируется, тестируется и затем внедряется. Обычно первой создается подсистема, которая для пользователя является логически наиболее важной. При этом целесообразно использовать языки четвертого поколения, существенно расширяющие возможности проектирования подсистем. Процесс продолжается циклически путем выбора новой подсистемы. Такой подход наиболее приемлем для информационных систем, которые могут быть разбиты на относительно независимые подсистемы, тогда последовательный порядок их реализации делает метод пофазового проектирования эффективным. Если же необходимо произвести такие изменения в подсистемах, которые влияют на другие подсистемы, то могут потребоваться значительные дополнительные усилия.

CASE-технологии проектирования систем

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

быстрее создавать и внедрять прикладные системы при меньших затратах;

обеспечить единый, простой интерфейс с конечными пользователями;

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

CASE-технология на основе системной архитектуры включает вопросы определения требований пользователя к системе и создания проекта на глобальном уровне так, чтобы он наиболее полно удовлетворял предъявляемым требованиям с учетом заданных экономических и технологических ограничений.

CASE-технология обычно содержит средства поддержки всех основных этапов проектирования и реализации информационных систем.

При этом на этапе анализа целей создания системы обычно используется концепция диаграмм потоков данных, когда основное внимание уделяется операциям (действиям) по обработке информации, которые связываются отношениями, соответствующими процессам обмена данными. Однако эта модель, по существу, больше ориентирована на описание требований к системе в терминах ЭВМ, чем в понятиях пользователей. Ее методы адекватны для операционного описания динамики реального мира. Она предоставляет пользователю средства, более пригодные для описания алгоритмов, чем для выражения закономерностей развития ПО.

Вместе с тем CASE-технологии являются значительным достижением в области автоматизации проектирования ИС, обеспечивая:

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

- уменьшение времени и стоимости создания проекта по сравнению с неавтоматизированными технологиями;

- контроль за взаимосвязями и полнотой представления отдельных компонент проекта;

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

Среди подходов, ориентированных на системную архитектуру программных средств, отметим интегрированную программную архитектуру ISA (Integrated Software Architecture), развиваемую фирмой Software AG, и CASE-технологию разработки систем фирмы ORACLE, которые доведены до промышленного образца.

Этапы создания информационных систем на основе МПС технологии

МПС-технология включает три стадии: МАКЕТ, ПРОЕКТ и СИСТЕМА.

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

Характерные особенности МПС-технологии:

- полный охват этапов жизненного цикла разработки ИС;

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

- поэтапное уточнение, детализация и формализация требований пользователей в процессе создания проекта системы;

- хранение всей информации о проекте на машинном носителе в виде словаря проектирования (СП);

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

На стадии МАКЕТ обеспечиваются сбор, анализ и интеграция требований пользователей к создаваемой системе.

На стадии ПРОЕКТ разрабатываются спецификации структуры БД и обращений к ней со стороны информационных задач, планируется состав программного обеспечения и средств администрирования БД.

На стадии СИСТЕМА осуществляется реализация ИС в выбранной технической среде.

Результаты проектирования, полученные на первых двух стадиях, фиксируются в словаре проектирования и подвергаются сквозному структурному контролю. Очевидно, что результаты, полученные на стадии МАКЕТ, должны стать основой разработки ПРОЕКТА, а спецификации ПРОЕКТА использоваться для реализации СИСТЕМЫ. Это значит, что предлагаемый подход опирается на непрерывный цикл разработки, когда элементы информационной системы, созданные на ранних стадиях проектирования, непосредственно включаются в действующий вариант системы.

МПС-технология предоставляет для каждой из стадий жизненного цикла набор методов, критериев оценки качества проектных решений и средств формализации этих решений.

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

Так, этап сбора и анализа требований завершается созданием активного МАКЕТА системы, разработка спецификаций на структуры данных и программные модули — созданием активного ПРОЕКТА системы, а этап актуализации БД и программирования — созданием СИСТЕМЫ.

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

Выделение информационных задач

Проектирование ИС начинается со сбора и предварительного анализа информационных потребностей пользователя. Основная цель этого этапа построения макета системы — выделение информационных задач (рис. 1.12).

Рис. 1.12. Последовательнось разработки ИС в МПС технологии.

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

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

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

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

Рис. 1.13. Пример двух функциональных областей.

Рассмотрим пример, приведенный на рис. 1.13. Предположим, что целью разрабатываемой ИС является автоматизация служб повышения квалификации работников в некоторой области народного хозяйства. В результате предварительного обследования удалось выяснить, что среди пользователей будущей системы имеются работники институтов повышения квалификации (ИПК) и работники отделов подготовки кадров (ОПК) предприятий, отвечающих за повышение квалификации своих сотрудников. Из-за слабой связи между задачами, решаемыми в ИПК и ОПК, всю предметную область можно разбить на две функциональные области: ИПК и ОПК. В каждой из них выделяются информационные задачи, автоматизирующие деятельность пользователей ИПК и ОПК. К задачам функциональной области ИПК могут относиться: прием преподавателя на работу, справки о преподавателях, справки о курсах, составление расписания и др.

Возьмем одну из задач — ПРИЕМ ПРЕПОДАВАТЕЛЯ.

Пусть при предварительном обследовании удалось установить следующее:

1) задача предназначена для работников ИПК, отвечающих за прием преподавателей;

2) выполнение задачи может быть начато только после того, как произойдет событие ПРИЕМ РАЗРЕШЕН (устанавливаемое другой информационной задачей);

3) эта задача изменяет состояние функциональной области (событие ПРИНЯТ ЕЩЕ ОДИН ПРЕПОДАВАТЕЛЬ). Предположим, что требуется сообщать в ОПК предприятия (функциональная область ОПК) информацию о том, что новый преподаватель является совместителем и сотрудником данного предприятия (событие ПРИНЯТ ЕЩЕ ОДИН СОВМЕСТИТЕЛЬ).

Абстрагируясь от формы передачи этой информации (телефон, телефакс, телекс, сеть ЭВМ и т. д.), можно утверждать, что в функциональной области ОПК должна быть предусмотрена информационная задача ВВОД ИНФОРМАЦИИ О СОВМЕСТИТЕЛЯХ.

В отношении самой задачи ПРИЕМ ПРЕПОДАВАТЕЛЯ можно лишь пока утверждать, что в ходе ее выполнения должны произойти следующие события: ЗАПОЛНЕНА АНКЕТА; ПРОВЕРЕНЫ ДОКУМЕНТЫ; ЗАПОЛНЕНО ЗАЯВЛЕНИЕ; ПОДТВЕРЖДЕНИЕ С КАФЕДРЫ ПОЛУЧЕНО; ПОЛУЧЕН ПРИКАЗ О ЗАЧИСЛЕНИИ.

Процесс наступления событий, происходящих в ходе решения информационной задачи, может быть представлен сетью Петри, показанной на рис. 1.14. Здесь используется проверенная на практике интерпретация сети УСЛОВИЕ — СОБЫТИЕ. Позиции в сети (показанные на рисунке кружками) обозначают условия, которые в зависимости от состояния сети (разметки) либо истинны (есть метка), либо ложны (метка отсутствует). События рассматриваются как переходы в сети (на рисунке они представлены вертикальными линиями с входящими и выходящими стрелками). Переходы в сети происходят, если все условия, связанные с входящими стрелками (предусловия события), истинны. Результатом перехода является свершение события, в результате которого истинными становятся условия, связанные выходящими стрелками (постусловия события).

Рис 1. 14. Событийный граф представления задачи ПРИЕМ ПРЕПОДАВАТЕЛЯ.

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

Кроме отношения следования взаимосвязь событий может отражать отношения «целое — часть» и «обобщение — специализация».

Конструирование сценария диалога

После предварительного обследования предметной области для каждой информационной задачи конструируется интерфейс взаимодействия с пользователем. Вначале создаются макеты экранных представлений информации, связываемые с выполнением каждой задачи без учета их последовательности и взаимосвязи, что составляет конструктивную основу взаимопонимания разработчиков и пользователей информационной системы. При описании структуры экранных форматов в рассмотрение вовлекаются их составные части: меню, окна, статические подсказки. Окна в свою очередь могут содержать динамические подсказки, промежуточные таблицы, отдельные поля. Кроме экранных форматов могут рассматриваться диаграммы и выходные отчеты.

Следующий шаг в построении макета — конструирование сценария диалога: описываются события, определяющие порядок формирования экранных представлений при решении каждой информационной задачи. Примерами таких событий являются: НАЖАТА КЛАВИША F2, ВВЕДЕНО ЗНАЧЕНИЕ >10, ДОСТИГНУТ КОНЕЦ ПРОСМОТРА ОТЧЕТА.

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

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

Построение модели предметной области

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

Рассмотрим пример, показанный на рис. 1.10. Предположим, что данные, вводимые с помощью экранного формата ЗАПОЛНЕНИЕ АНКЕТЫ ПРИ ПРИЕМЕ, формируемого в ходе выполнения информационной задачи ПРИЕМ ПРЕПОДАВАТЕЛЯ, должны быть переданы объекту ПРЕПОДАВАТЕЛЬ с помощью сообщения АНКЕТА ПОСТУПАЮЩЕГО ПРЕПОДАВАТЕЛЯ. Это сообщение активизирует метод ВВЕСТИ НОВОГО ПРЕПОДАВАТЕЛЯ.

В описании класса объектов ПРЕПОДАВАТЕЛЬ должен быть предусмотрен метод ВВЕСТИ НОВОГО ПРЕПОДАВАТЕЛЯ, с помощью которого воспринимаются анкетные данные (передаваемые как аргументы сообщения) и отображаются на состоянии объекта (в данном случае этот метод должен создавать новый объект). Новое состояние объекта может быть охарактеризовано одним или несколькими свершившимися событиями. Важно, чтобы эти события относились к конкретному объекту определенного класса.

Рис. 1. 15. Взаимосвязь экранных форматов и объектов ПО.

Классы объектов могут, быть связаны отношением специализации, в котором каждый подчиненный класс наследует все структурные и динамические свойства от старших классов, дополняя их новыми специфическими. Например, на рис. 1.15 показано, что класс объектов ЛИЧНОСТЬ является более широким классом, чем класс объектов ПРЕПОДАВАТЕЛЬ. Это означает, что класс объектов ПРЕПОДАВАТЕЛЬ наследует все характеристики объектов класса ЛИЧНОСТЬ (например, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА РОЖДЕНИЯ) и имеет специфические характеристики: ДАТА ПРИЕМА, ОБЩИЙ СТАЖ РАБОТЫ, ВИД ОПЛАТЫ.

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

Такая спецификация макета составляет базу знаний о ПО, о пользователях ИС и самой ИС (включая сценарии диалога информационных задач).

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

Разработка проекта

На стадии ПРОЕКТ спецификации макета должны быть детализированы и формализованы настолько, чтобы по ним можно было перейти к развертыванию ИС в выбранной технической среде. Результатом стадии проектирования являются структура БД, спецификации реализации информационных и технологических задач, методов и правил контроля целостности.

Рис. 1.16. Спецификации сиадии ПРОЕКТ.

Стадия ПРОЕКТ объединяет этапы концептуального, логического и физического проектирования БД (рис. 1.16) и задач информационной системы. На данных этапах концептуальное объектно-ориентированное описание предметной области последовательно формализуется в виде концептуальной, логической и физической схемы БД. По мере уточнения состава схемных элементов конкретизируются спецификации информационных задач и методов, изменяющих состояние объектов. При этом их потребность в данных специфицируется через выявленные схемные элементы в структуре БД, входные данные или данные, вычисляемые алгоритмическим путем.

Концептуальное проектирование БД

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

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

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

Для этапа концептуального проектирования БД концепция МПС-технологии по уточнению и преобразованию накопленных спецификаций реализована в виде автоматизированного получения начальных концептуальных спецификаций проекта БД: начальной схемы и начальных спецификаций процессов. В основу интерфейса между стадиями МАКЕТ и ПРОЕКТ положена генерация списков понятий-кандидатов на включение в начальные концептуальные спецификации структуры БД и процессов. Структурные понятия-кандидаты выявляются в результате анализа объектов предметной области, их свойств, событий, параметров сообщений и полей экранных форматов. Понятия-кандидаты для начальных спецификаций процессов определяются из описаний информационных задач и используемых ими объектов и методов.

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

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

Нагрузка на пути доступа, точки входа процессов в концептуальную структуру и другие результаты согласования фиксируются в матрицах разных типов, объединенных общим названием «данные — процессы». Строки матриц соответствуют структурным элементам, а столбцы — процессам. Матрицы являются важным источником информации для проектных решений двух следующих этапов стадии ПРОЕКТ.

Логическое проектирование

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

В результате логического проектирования создается спецификация отображения «концептуальная схема — логическая схема», или, более коротко, КЛ-отображения, с помощью которого генерируется логическая схема БД. Данная спецификация ставит в соответствие каждому концептуальному элементу и свойству фрагмент логической структуры БД.

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

Физическое проектирование

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

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

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

Описание систем сетями Петри

Для того, чтобы представить ИС и моделировать перемещение потоков данных в ней с помощью сетей Петри, необходимо ознакомиться с понятиями теории комплектов.

Элементы теории комплектов

Теория комплектов (ТК) это расширение теории множеств. В комплекте допускается несколько экземпляров одного и того же элемента.

Пример: Задана область объектов { a, b, c, d }

B1 = {a, b, c}. B2 = {a}. B3 = {a, b, c, c}. B4 = {a, a, a}. B5 = {b, c, b, c}.

B6 = {c, c, b, b}. B7 = {a, a, a, a, a, b, b, c, d, d, d, d, d, d}.

Здесь,

B1, B2 – множества.

B5, B6 – один и тот же комплект.

Основное понятие ТК – число экземпляров #(x, B), читается «число x в B»

Например: 0 #(x, B) 1, получим множество B, т.к. ограничили число экземпляров одним элементом.

Мощность |B| = общее число экземпляров в комплекте.

Пусть A B. A подкомплект B.

Тогда #(x,A) #(x,B) для всех x.

Над комплектами справедливы следующие операции.

Объединение комплектов

A B: #(x, A B) = max(#(x,A), #(x,B)).

Пересечение комплектов

A B: #(x, A B) = min(#(x,A), #(x,B)).

Сумма комплектов

A+B: #(x, A+B) = #(x,A) + #(x,B).

Разность комплектов

A-B: #(x, A-B) = #(x,A) - #(x, A B).

Сети Петри

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

Впервые сеть Петри предложил Карл Адам Петри (ФРГ) 1962г.

Применение при проектировании и анализе систем (2 подхода).