Этот процесс называется функциональной декомпозицией, а диаграммы, описывающие каждый фрагмент и их взаимодействие, называются диаграммами декомпозиций.
Каждый фрагмент системы декомпозируется на более мелкие до достижения нужного уровня подробности описания.
Процесс обеспечения продукцией подразумевает выполнение последовательных процедур:
Отдел работы с клиентом;
Отдел исследований;
Отдел маркетинга.
Конкретизируем процесс обеспечения продукцией путем создания диаграммы декомпозиции, состоящей из 6 работ [Приложение 2].
Таблица 2. Работы диаграммы декомпозиции «Заказы клиентов»
| Имя работы (Activity Name) | Определение (Definition) |
| Отдел Работы с клиентами | Поиск клиентов, ведение договоров с клиентами, работа по соблюдению соответствия шаблонов рекламной продукции пожеланиям клиента. Обсуждение с клиентом качества выбраных материалов, качества печати и стоимости услуг. |
| Инженерно-дизайнерский отдел | Разработка электронных макетов рекламной продукции |
| Отдел изготовления и сборки рекламной продукции | Пробная печать баннера, Изготовление. Добавление крепежных элементов |
| Отдел размещения рекламы | Размещения изготовленных баннеров. |
Эти 3 работ будут связаны внутренними стрелками, которые не касаются границы диаграммы, начинаются у одной и заканчиваются у другой работы. Декомпозируем работу «Отдел исследований». Процесс проведения исследования подразумевает последовательное выполнение следующих этапов: составление клиентской базы, ведение проектов, в результате ведения проекта выдача готовых решений клиенту .
Добавим три работы и их определения [Приложение 3].
Таблица 3. Работы диаграммы декомпозиции «Отдел по работе с клиентами»
| Имя работы (Activity Name) | Определение (Definition) |
| Регистрация клиента в базе | Формирование базы данных о клиенте, необходимых для выполнения заказа. |
| Оформление заказа | Ведение проекта на основании заявленным требованиям заказчика. |
| Составление технического задания | Составление технического задания проекта заказчика. |
Рассмотрим процесс Проекты. Он состоит из 9 последовательных этапов:
Данные клиентов;
Анализ деятельности организации;
Ведение имитационного моделирования;
Управление бизнес-процессами;
Управление персоналом;
Управление внешними связями;
Организационные решения;
Дополнительная поддержка;
Система бизнес - задач и решений.
Для описания логики взаимодействия информационных потоков будем использовать методологию моделирования IDEF3, называемую workflow diagramming.
Графический язык IDEF3 дополняет IDEF0: позволяет описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
Декомпозируем работу «Проекты» на 8 работ IDEF3 [Приложение 4].
Таблица 4. Работы диаграммы декомпозиции «изготовление продукции»
| Имя работы (Activity Name) | Определение (Definition) |
| Разработка технического задания | Проводится в соответствии с требованиями клиента, указанными в заказе |
| Разработка дизайна макета рекламной продукции | На основе собранной информации разрабатывается макет рекламной продукции |
| Управление разработкой макета | Выполнение условий заказа разработке макета |
| Управление печатью рекламной продукции | Выполнение условий заказа по управлению печатью |
| Размещение рекламной продукции | Выполнение условий заказа по размещению рекламной продукции |
| Организационные решения | Необходимые организационные решения, принимаемые на основе проведенных работ по имитационному моделированию |
| Дополнительные сведения о заказе | Предоставление дополнительной поддержки по результатам проведенных работ |
| Система проектных решений и макетов | Формирование на основе сделанных выводов по проекту системы бизнес - задач и решений |
«Данные клиента» является внешним объектом ссылки.
Используются два перекрестка асинхронное «И»: разветвление и слияние.
Рассмотрим процесс «Отдел работы с клиентом». Он состоит из двух процессов:
проверка и внесение клиента в базу;
формирование заказа.
Для описания документооборота и обработки информации используем диаграмму потоков данных (Data flow diagramming, DFD) [Приложение 5]. DFD представляет систему в виде работ, хранилищ данных и внешних сущностей.
Таблица 5. Работы диаграммы декомпозиции «Изготовление рекламной продукции»
| Имя (Name) | Определение (Definition) | Роль (Roles) |
| Данные клиентов | Перечень сведений о клиенте, необходимых для составления заказа | Хранилище данных |
| Список предлагаемых услуг | Перечень услуг, предлагаемых клиенту для решения определенных бизнес - задач | Хранилище данных |
| Список оказываемых услуг | Перечень услуг, которые организация уже оказала клиенту | Хранилище данных |
| Заказы клиентов | Звонки клиентов, которые делают заказ на оказание услуг | Внешняя сущность |
| Проверка и внесение клиента в базу | Проверка наличия клиента в базе и его внесение в базу в случае отсутствия | Работа |
| Оформление заказа | В соответствии со списком предлагаемых услуг, формируется перечень оказываемых услуг клиенту | Работа |
Работы имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0. «Заказы клиентов» является внешней сущностью. Она изображает входы в систему.
Хранилища данных («Данные клиента», «список предлагаемых услуг», «список оказываемых услуг») изображают объекты в покое. Стрелки описывают движение объектов из одной части системы в другую. Так, информация о поставщиках направляется из хранилища «Данные клиентов» к работе «Оформление заказа». Граничные стрелки на диаграмме DFD отсутствуют.
Для представления всех процессов обеспечения продукцией в виде иерархически упорядоченных работ, создадим диаграмму дерева узлов [Приложение 6]. Диаграмма позволяет рассмотреть всю модель целиком - четыре уровня, но не показывает взаимосвязи между работами (стрелки).
2.3 Проектирование системы обеспечения продукцией в ERwin
Для построения инфологической ER-модели (логической и физической) я использовала CASE-средства ERwin. ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД.
ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.
Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.
Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рамках рабочей группы.
ERwin имеет два уровня представления модели - логический и физический.
Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Клиенты», «Города» или «Улицы» [Приложение 7]. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логический уровень модели данных может быть построен на основе другой модели, например на основе модели процессов. Логический уровень модели данных является универсальным и никак не связан с конкретной реализацией СУБД.
Физический уровень модели данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физическом уровне модели содержится информация о всех объектах базы данных. Поскольку стандартов на объекты базы данных не существует, физический уровень модели зависит от конкретной реализации СУБД. Следовательно, одному и тому же логическому уровню модели могут соответствовать несколько разных физических уровней различных моделей. Если на логическом уровне модели не имеет большого значения, какой конкретно тип данных у атрибута (хотя и поддерживаются абстрактные типы данных), то на физическом уровне модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логический и физический уровни позволяет решить несколько важных задач.
На физическом уровне объекты базы данных могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов.
ERwin позволяет создавать модели трех типов:
модель, имеющую только логический уровень;
модель, имеющую только физический уровень;
модель, имеющую как логический уровень, так и физический уровень.
Создание модели данных, начинается с создания логического уровня. После описания логического уровня выбирается СУБД. В модели, имеющей оба уровня (логический и физический), ERwin автоматически создаст соответствующую физическую модель [Приложение 8]. Это означает, что каждому объекту логического уровня соответствует объект физического, например каждой сущности соответствует таблица. Модель, имеющая только логический уровень, может быть синхронизирована с несколькими моделями, имеющими только физический уровень. Это позволяет эффективно разрабатывать гетерогенные ИС. На основе одной логической модели можно создавать несколько физических, соответствующих СУБД разных производителей (например, Oracle, Informix, MS SQLServer, Sybase и др.). Для генерации программного кода создания базы данных выбираем средства генерации приложений и формируем отчет.