- •Проектирование экономических информационных систем
- •Раздел 3. Индустриальное проектирование корпоративных экономических информационных систем 266
- •Глава 11. Реинжиниринг бизнес-процессов и проектирование корпоративной эис 266
- •Глава 12. Проектирование клиент-серверных корпоративных эис 298
- •Глава 13. Автоматизированное проектирование эис (case-технология) 334
- •Предисловие
- •Раздел 1. Теоретические основы проектирования экономических информационных систем (эис) Глава 1. Архитектура экономических информационных систем
- •1.1. Понятие и классификация эис
- •1.2. Функциональные подсистемы эис
- •Решение задач функциональных подсистем
- •Функциональный принцип:
- •Предметный принцип (подсистемы управления ресурсами):
- •1.3 Обеспечивающие подсистемы эис
- •Вопросы для самопроверки
- •Глава 2. Методологические основы проектирования эис
- •2.1. Технология проектирования эис
- •2.2 Жизненный цикл эис
- •2.3 Формализация технологии проектирования эис
- •Вопросы для самопроверки
- •Раздел 2. Каноническое проектирование эис Глава 3. Содержание и методы канонического проектирования эис
- •3.1. Состав стадий и этапов канонического проектирования эис
- •3.2. Состав и содержание работ на предпроектной стадии создания эис
- •Программа обследования
- •3.3. Состав и содержание работ на стадии технорабочего проектирования
- •3.4. Состав и содержание работ на стадиях внедрения, эксплуатации и сопровождения проекта.
- •Вопросы для самопроверки
- •Глава 4. Проектирование классификаторов технико-экономической информации
- •4.1. Общие сведения
- •4.2. Методы классификации.
- •4.2.1. Иерархическая система классификации
- •4.2.2. Фасетная система классификации
- •4.2.3. Дескрипторная система классификации
- •4.3. Понятия и основные системы кодирования экономической информации
- •4.4. Состав и содержание операций проектирования классификаторов
- •4.5. Понятие Единой системы классификации и кодирования (ескк)
- •4.6. Технология использования штрихового кодирования экономической информации
- •Вопросы для самопроверки
- •Глава 5. Проектирование системы экономической документации
- •5.1. Понятие унифицированной системы документации
- •5.2. Проектирование унифицированной системы документации эис
- •5.2.1. Особенности проектирования форм первичных документов
- •5.2.2 Особенности проектирования форм документов результатной информации
- •Вопросы для самопроверки
- •Глава 6. Проектирование внутримашинного информационного обеспечения эис
- •6.1. Проектирование экранных форм электронных документов
- •6.2. Понятие информационной базы и способы ее организации
- •6.3. Проектирование информационной базы при различных способах организации
- •Вопросы для самопроверки
- •Глава 7. Основы проектирования технологических процессов обработки данных
- •7.1. Основные понятия и классификация технологических процессов обработки данных
- •7.2. Показатели оценки эффективности и выбор варианта организации технологических процессов
- •Вопросы для самопроверки
- •Глава 8. Проектирование процессов получения первичной информации, создания и ведения информационной базы
- •8.1. Проектирование процессов получения первичной информации
- •8.2. Проектирование процесса загрузки и ведения информационной базы
- •8.3. Проектирование процесса автоматизированного ввода бумажных документов
- •Вопросы для самопроверки
- •Глава 9. Проектирование технологических процессов обработки экономической информации в локальных эис
- •9.1 Организация решения экономических задач
- •9.2 Проектирование технологических процессов обработки данных в пакетном режиме
- •9.3 Проектирование технологических процессов обработки данных в диалоговом режиме
- •Классификация диалоговых систем
- •Вопросы для самопроверки
- •Глава 10. Проектирование процессов защиты данных
- •10.1. Основные понятия и методы защиты данных
- •10.2. Стандарты на создание систем защиты данных
- •Оранжевая книга Национального центра защиты компьютеров сша (tcsec)
- •1. Концепция безопасности системы защиты
- •2. Гарантированность системы защиты
- •Гармонизированные критерии Европейских стран (itsec)
- •Концепция защиты от нсд Госкомиссии при Президенте рф
- •Рекомендации х.800
- •10.3. Проектирование системы защиты данных в иб
- •Вопросы для самопроверки
- •Раздел 3. Индустриальное проектирование корпоративных экономических информационных систем Глава 11. Реинжиниринг бизнес-процессов и проектирование корпоративной эис
- •11.1. Реинжиниринг бизнес-процессов на основе корпоративной эис
- •11.2. Этапы реинжиниринга бизнес-процессов
- •Идентификация бизнес-процессов
- •Обратный инжиниринг
- •Разработка моделей новой организации бизнес-процессов
- •Реализация проекта реинжиниринга бизнес-процессов
- •11.3. Методологии моделирования проблемной области
- •Объектная структура
- •Функциональная структура
- •Структура управления
- •Организационная структура
- •Техническая структура
- •Вопросы для самопроверки
- •Глава 12. Проектирование клиент-серверных корпоративных эис
- •12.1. Основные понятия и особенности проектирования клиент-серверных экономических информационных систем (кэис)
- •1. Разработка общей структуры корпоративной информационной системы (п1)
- •2. Создание вычислительной сети (вс) для кэис (п2)
- •3. Создание схемы базы данных (бд) (пз)
- •Использование систем управления рабочими потоками
- •Использование Интернет-приложений
- •12.3 Проектирование систем оперативного анализа данных
- •Подсистема хранения данных
- •Подсистема метаинформации (репозиторий)
- •Подсистема преобразования данных (загрузки хранилища)
- •Подсистема представления данных (организации витрин данных)
- •Подсистема оперативного анализа данных
- •Подсистема интеллектуального анализа данных (извлечения знаний)
- •Подсистема «Информационная система руководителя»
- •Подсистема web-публикации
- •Технология проектирования их
- •П1. Идентификация проблемной области
- •П2. Разработка концептуальной модели их
- •Пз. Формализация их
- •П4. Реализация проекта их
- •П5. Внедрение и опытная эксплуатация
- •Вопросы для самопроверки
- •Глава 13. Автоматизированное проектирование эис (case-технология)
- •13.1 Основные понятия и классификация case-технологий
- •13.2. Функционально-ориентированное проектирование эис
- •13.3. Объектно-ориентированное проектирование эис
- •Диаграмма прецедентов использования
- •Диаграммы классов объектов (Class diagram)
- •Диаграммы состояний (Statechart diagram)
- •Диаграмма взаимодействия объектов (interaction diagram)
- •Диаграмма деятельностей
- •Диаграммы пакетов
- •Диаграммы компонентов и размещения
- •Технологическая сеть проектирования эис на основе использования объектно-ориентированной case-технологии
- •Анализ системных требований к эис
- •Логическое проектирование эис
- •Физическое проектирование эис
- •Реализация эис
- •13.4. Прототипное проектирование эис (rad-технология)
- •Вопросы для самопроверки
- •Глава 14. Типовое проектирование эис
- •14.1 Основные понятия и классификация методов типового проектирования
- •14.2. Параметрически-ориентированное проектирование эис
- •14.3. Модельно-ориентированное проектирование эис
- •Вопросы для самопроверки
- •Раздел 4. Управление проектированием эис Глава 15. Организационные структуры проектирования эис
- •15.1. Общая структура организации работ по проектированию эис
- •15.2. Организационные формы управления проектированием эис
- •15.3. Организационные формы реинжиниринга бизнес-процессов
- •Вопросы для самопроверки
- •Глава 16. Планирование и контроль проектных работ
- •16.1. Основные компоненты процесса управления проектированием эис
- •16.2. Методы планирования и управления проектами и ресурсами
- •16.3. Технология применения метода спу для разработки проекта эис
- •16.4. Выбор системы для управления проектами
- •1. Средства описания комплекса работ проекта, связей между работами и их временных характеристик.
- •2. Средства поддержки информации о ресурсах и затратах по проекту и назначения ресурсов и затрат по отдельным работам над проектом.
- •3. Средства контроля за ходом выполнения проекта.
- •4. Графические средства представления структуры проекта, средства создания различных отчетов по проекту.
- •Вопросы для самопроверки
- •Литература
13.2. Функционально-ориентированное проектирование эис
Основными идеями функционально-ориентированной CASE-технологии являются идеи структурного анализа и проектирования информационных систем. Они заключаются в следующем:
1) декомпозиция всей системы на некоторое множество иерархически подчиненных функций;
2) представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически.
В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:
BFD (Bussiness Function Diagram) - диаграмма бизнес-функций (функциональные спецификации);
DFD (Data Flow Diagram) - диаграмма потоков данных;
STD (State Transition Diagram) - диаграмма переходов состояний (матрицы перекрестных ссылок);
ERD (Entity Relationship Diagram) - ER-модель данных предметной области (информационно-логические модели «сущность-связь»);
SSD (System Structure Diagram) - диаграмма структуры программного приложения.
Диаграммы функциональных спецификаций (BFD) позволяют представить общую структуру ИС, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов. Основными объектами BFD являются:
Функция - некоторое действие информационной системы, необходимое для решения экономической задачи;
Декомпозиция функции - разбиение функции на множество подфункций.
Изображение объектов диаграммы иерархии функций представлено в табл. 13.1 в нотациях:
Йодана (Yourdon);
Гейна - Сарсона (Gane - Sarson);
SADT (Structured Analysis and Design Technique);
SAG (Software AG).
Таблица 13.1 Изображение объектов диаграммы иерархии функций
Объект |
Йодана |
Гейна - Сарсона |
SADT |
SAG |
1 . Функция |
|
|
|
|
2. Декомпозиция функции |
|
|
Осуществляется с помощью иерархически взаимосвязанных уровней детализации |
|
В качестве примера рассмотрим фрагмент диаграммы иерархии функций в нотации SAG (рис. 13.2) для задачи аналитического учета товаров на складе.
Рис. 13.2. Фрагмент диаграммы иерархии функций для задачи аналитического учета товаров на складе
Как видно из рис. 13.2, одной из функций аналитического учета товаров на складе является организация товародвижения.
Далее эта функция декомпозируется на следующие подфункции: приемка товара; отпуск товара; ведение БД «Движение товаров»; инвентарный контроль.
Диаграммы потоков данных (ДПД), как правило, жестко ориентированы на какую-либо технологию обработки данных и отражают передачу информации от одной функции к другой в рамках заданной технологии обработки. В узлах диаграммы потоков данных (прямоугольниках) отражаются процедуры, а стрелками между узлами показываются потоки данных (над стрелками задаются имена передаваемых/используемых единиц информации - документов, экранных форм, файлов).
Рассмотрим основные понятия диаграммы потоков данных.
ДПД - показывает внешние по отношению к системе источники данных и адресатов, которые принимают информацию от системы, а также идентифицируют хранилища данных (накопители данных), к которым осуществляется доступ системы. Каждая логическая функция системы (бизнес-функция) описывается своей ДПД. Причем эта ДПД может иерархически детализировать функцию на ее подфункции.
Определим основные объекты ДПД и их графические изображения в различных нотациях (табл. 13.2).
Таблица 13.2
Графическое отражение объектов ДПД
Объект |
Йодана |
Гейна-Сарсона |
SADT |
SAG |
1 . Процесс |
|
|
|
|
2. Поток данных |
Имя
|
Имя
|
Имя
|
Имя
|
3. Хранилище данных |
|
|
Нет |
|
4. Источник/ приемник информации |
|
|
Текстовая метка |
|
5. Сущность |
Нет |
Нет |
Нет |
|
6. Чтение/запись |
Нет |
Нет |
Нет |
Чтение
Чтение/Запись
Запись
|
7. Группировка (сцепление) потоков |
|
|
|
Надо делать дополнительный процесс |
8. Разгруппировка |
|
|
|
Нет |
9. Неиспользуемый узел (на схеме есть, но в системе не описан) |
|
Нет |
|
|
10. Узлы-предки (наследование узлов) |
(серого цвета) |
(серого цвета) |
IСОМ-метки |
Автоматическое наследование не происходит |
Потоки данных - являются механизмами, которые показывают передачу информации от одного процесса к другому. На схемах они обычно отражаются направленной стрелкой, которая показывает направление движения информации или материалов (могут отражаться материальные потоки).
Процесс - его функция состоит в преобразовании входной информации в выходную. Имя процесса всегда должно содержать глагол в неопределенной форме с последующим дополнением (например, «нарисовать форму»).
Хранилище информации - позволяет на определенных участках ДПД сохранить в памяти данные между процессами. Хранилище не обязательно представлено магнитным носителем (например, папка бумаг). Имя хранилища должно идентифицировать его, а также его содержимое, выражается существительным.
Внешняя сущность (источник/приемник данных) - представляет некоторый объект вне системы, являющийся внешним объектом.
Контекстная диаграмма - самый верхний процесс (ТОР-уровень) декомпозиции системы, который отражает общие представления о системе. В контекстной диаграмме есть 1 процесс, с которым связаны внешние сущности.
Далее контекстная диаграмма декомпозируется на основные процессы, которые происходят в системе. Каждый основной процесс может быть декомпозирован на более мелкие процессы. При иерархическом построении ДПД каждый процесс более низкого уровня нужно соотнести с процессом более высокого уровня. Обычно для этого используют механизм наследования узлов.
Целью построения иерархически взаимосвязанных ДПД является необходимость сделать требования к системе ясными на каждом уровне детализации. Для этого надо пользоваться следующими рекомендациями:
на каждом уровне представлять 3-6 процессов и не более;
не загромождать диаграмму несущественными моментами на данном уровне детализации;
декомпозицию процессов и потоков вести параллельно;
выбирать ясные, отражающие суть объектов, имена для всех объектов ДПД;
однократно определять функционально идентичные процессы (в других местах просто ссылаться на этот процесс);
использовать ДПД для процессов, которые можно с помощью них описать.
Пример контекстной диаграммы и диаграмм 1-го уровня в нотации SADT для задачи аналитического учета товаров на складе приведен на рис.13.3.
Как видно из рисунка, на уровне контекстной диаграммы показаны основная цель построения ДПД и потоки информации, необходимые для ее достижения. В дальнейшем контекстная диаграмма детализируется на первом уровне, где отражаются основные функции, которые взаимосвязаны информационными потоками.
Диаграммы переходов состояний (ДПС) моделируют поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчетного периода и т.д.). Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками. С помощью ДПС можно моделировать последующее функционирование системы исходя из предыдущих и текущего состояний.
Рис. 13.3. Контекстная диаграмма и диаграмма 1-го уровня в нотации SADT для задачи аналитического учета товаров на складе
Моделируемая система в текущий момент времени находится только в одном состоянии из всего множества состояний. В течение времени она может изменить свое состояние и тем самым перейти в следующее состояние из заданного множества состояний. Для перехода в состояние нужно какое-либо особое условие - условие перехода. Оно может быть информационным (условие появления информации) или временным. В табл. 13.3 представлены символы ДПС в различных нотациях.
Таблица 13.3 Символы STD в различных нотациях
Объект |
Гейна - Сарсона |
Йодана |
SAG |
SADT |
Состояние (processing step) |
|
|
|
Нет |
Начальное состояние |
- |
|
|
Нет |
Переход |
Условие перехода
Действие перехода |
Условие перехода
Действие перехода |
а) - условие поданным б) - условие по времени |
Нет |
Определим основные объекты ДПС.
Состояние - рассматривается как устойчивое значение некоторого свойства в течение определенного времени. Находясь в текущем состоянии, необходимо знать о предыдущих состояниях, чтобы определить условие перехода в последующее состояние.
Начальное состояние - это узел ДПС, являющийся стартовой точкой для начального системного перехода. ДПС имеет только одно начальное состояние, но может иметь множество конечных состояний.
Переход - определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода - это событие, которое вызвало этот переход. Переход может быть вызван каким-либо действием ( например, нажатием клавиши).
Триггер - логическое выражение, написанное на макроязыке, которое показывает условие перехода в данное состояние.
Условие перехода - событие, вызывающее переход и идентифицируемое именем перехода.
Фрагмент диаграммы переходов состояний для задачи аналитического учета товаров на складе в нотации SAG приведен на рис. 13.4.
Рис. 13.4. Фрагмент диаграммы переходов состояний для задачи аналитического учета товаров на складе в нотации SAG
Как видно из рисунка, текущее состояние системы представлено ожиданием выбора того или иного пункта меню. Выбранный пункт меню - это информационное событие, а сам выбор - действие перехода в следующее состояние системы. Переход в состояние системы «Ведение БД «Движение товаров»» выполняется по логическому условию ИЛИ, что отражено в триггере. Одно из событий этого перехода является временным (дата закрытия периода).
Диаграммы инфологических моделей «сущность-связь» (ER-диаграммы) ориентированы на разработку базы данных, структура которой не зависит от конкретных информационных потребностей и позволяет выполнять любые запросы пользователей.
ERD-диаграмма «сущность-связь» представляет собой набор множества объектов и их характеристик, а также взаимосвязей между ними, нужных для выявленных данных, которые в дальнейшем используются функциями проектируемой системы.
Сущность - представляет собой множество экземпляров реальных или абстрактных объектов, которые обладают общими свойствами (атрибутами).
Отношение - связь между 2 и более сущностями (должны создать имя в виде глагола).
Независимая сущность - представляет независимые данные, которые всегда присутствуют в системе.
Зависимая сущность - представляет данные, которые зависят от других сущностей.
Объекты ERD в различных методологиях представлены в табл. 13.4.
Таблица 13.4. Объекты ERD в различных методологиях.
Фрагмент диаграммы «сущность-связь» для задачи учета труда и ЗП представлен на рис. 13.5.
Рис. 13.5. Фрагмент диаграммы «сущность-связь» для задачи учета труда и ЗП
Диаграмма структуры программного приложения (SSD) задает взаимосвязь функций и программных модулей, которые их реализуют (меню, формы, отчеты и т.д.).
Структура программного приложения (SSD) представляет собой иерархическую взаимосвязь программных модулей, которые реализует ИС. SSD служит мостом для перехода от системных требований, которые отображены в предыдущих диаграммах (BFD, DFD, STD, ERD), к реализации информационной системы.
Объекты SSD в различных методологиях представлены в табл. 13.5.
Таблица 13.5. Основные объекты SSD и их отображение в различных нотациях
В качестве примера рассмотрим фрагмент системной структурной диаграммы в нотации SAG (рис. 13.6) для задачи аналитического учета товаров на складе.
Рис. 13.6. Фрагмент SSD-диаграммы в нотации SAG для задачи аналитического учета на складах
Технологическая сеть проектирования ЭИС на основе использования функционально-ориентированной CASE-технологии представлена на рис. 13.7.
Технологические операции с преобразователями П1, П2, ПЗ, П4, П5, П6, П7 выполняются на стадии технического проектирования.
Преобразователь П1 «Инициализация проекта» используется для инициализации нового проекта ЭИС. На основании документа D1 «Материалы обследования» создается новый репозиторий G1 для проектируемой системы.
Рис. 13.7. Технологическая сеть проектирования ЭИС на основе использования функционально-ориентированной CASE-технологии: D1 - материалы обследования; D2 - перечень проектировщиков и их прав доступа; D3 - описание начальных параметров проекта; D4 - диаграмма функций проекта; DS - диаграмма потоков данных; D6 - диаграмма «сущность-связь»; D7 -диаграмма переходов состояний; D8 - системная структурная диаграмма; D9 - схема БД; D10 - модуль описания данных; D11 - модули программного приложения; U1 - универсум CASE-методологий проектирования; U2 - универсум нотаций; U3 - конструктивные элементы диаграмм иерархии функций; U4 - конструктивные элементы диаграмм потоков данных, US - конструктивные элементы диаграмм «сущность-связь», U6 - конструктивные элементы диаграмм переходов состояний; U7 - конструктивные элементы программного приложения; U8 - универсум целевых СУБД; U9 - универсум языков определения данных; UIO - универсум языков определения модулей; G1 - новый репозиторий; G2- программное приложение
Преобразователем П2 «Задание начальных параметров проекта» из универсума методологий проектирования U1 выбирается CASE-методология проектирования и в рамках выбранной методологии определяется нотация на основе универсума U2. Перечень проектировщиков и их прав доступа к проекту D2 служит для описания коллектива разработчиков проекта. Результатом выполнения операции является описание начальных параметров проекта в репозитории D3.
Технологические операции с преобразователями П3, П4, П5 и П6 выполняются последовательно-параллельно и взаимно уточняются в ходе выполнения.
На основе «Материалов обследования» D1 и универсума конструктивных элементов диаграмм иерархии функций U3 выполняется технологическая операция с преобразователем ПЗ «Построение диаграммы иерархии функций».
Выполнение преобразователя П3 сводится к выполнению следующих работ:
отображению основной функции;
декомпозиции основной функции на подфункции ;
дальнейшей декомпозиции подфункций до необходимой степени детализации;
контролю правильности построенной диаграммы.
Выходом преобразователя служит описание в репозитории дерева функций проекта D4.
Входом технологической операции с преобразователем П4 «Построение диаграммы потоков данных» являются:
материалы обследования (D1);
диаграмма иерархии функций (D4);
диаграмма «сущность-связь» (D6);
универсум конструктивных элементов диаграмм потоков данных U4.
Построение ДПД можно свести к следующим шагам.
Расчленение множества требований на функциональные группы.
Идентификация внешних объектов (по отношению к системе).
Идентификация информации, которая передается между процессами.
Разработка контекстной диаграммы.
Контроль контекстной диаграммы и уточнение, если это нужно.
Формирование ДПД первого уровня, где отражены основные функции системы.
Дальнейшая декомпозиция каждого процесса до тех пор, пока процесс самого нижнего уровня можно будет представить в виде некоторой спецификации (алгоритма).
Ревизия всех уровней с целью выяснения некорректности, а при ее обнаружении - устранение.
Выходом данной операции является описание в репозитории диаграммы потоков данных D5.
Преобразователь технологической операции П5 «Построение диаграммы переходов состояний» описывает возможные состояния проектируемой системы и переходы между ними.
При построении ДПС рекомендуется следовать перечисленным ниже правилам:
начинать построение ДПС на высоком уровне детализации ДПД;
строить наиболее простые диаграммы, содержащие 4-6 состояний;
по возможности включать детализацию в виде подчиненных шагов состояния (детализация на другом уровне);
использовать те же приемы наименования состояний, событий и действий, что и при наименовании процессов и потоков.
Применяются 2 способа построения ДПС:
первый способ заключается в том, что выявляются возможные состояния системы и далее выявляются переходы из одного состояния в другое;
при втором способе сначала строится начальное состояние, затем осуществляется переход в очередное состояние и т.д. (последовательный переход).
В результате получаем предварительную ДПС. Затем она проверяется на корректность ее построения. Когда число состояний и переходов достаточно велико, эта диаграмма может быть представлена в табличной форме «Матрица переходов состояний» (рис. 13.8).
Рис. 13.8. Графы матрицы переходов состояний
Входом преобразователя являются:
материалы обследования (D1);
диаграмма иерархии функций (D4);
диаграмма потоков данных (D5);
диаграмма «сущность-связь» (D6);
универсум конструктивных элементов диаграмм переходов состояний (U6).
Выход данной операции представлен интегрированным описанием в репозитории функций, потоков данных и состояний проектируемой системы (D7).
Технологическая операция с преобразователем П6 «Построение диаграммы «Сущность-связь» моделирует структуры данных, которые будут храниться в БД. Для ее выполнения необходима следующая входная информация:
материалы обследования (D1);
диаграмма потоков данных (D5);
универсум конструктивных элементов диаграмм сущность-связь (U5).
Построение ER-диаграмм сводится к следующим этапам.
Идентифицируются все сущности, их атрибуты, а также первичные ключи.
Идентифицируются отношения между сущностями и указывается мощность этих отношений.
Если на втором этапе были выявлены отношения N:N, такие отношения являются неспецифическими для реляционных, и их нужно преобразовать либо в 1:N, либо в 1:1. Как правило, это делается с помощью добавления новой сущности.
Выход данной операции представлен описанием в репозитории диаграммы сущность-связь (D6).
Технологическая операция с преобразователем П7 «Построение системной структурной диаграммы» используется для построения структуры программного приложения ЭИС (D8).
На вход преобразователя подаются:
диаграмма иерархии функций (D4);
диаграмма потоков данных (D5);
диаграмма сущность-связь (D6);
диаграмма переходов состояний (О7);
универсум конструктивных элементов программного приложения (U7).
Выходом преобразователя служит описание в репозитории структуры программного приложения (D8).
Этапы построения системной структурной диаграммы.
В диаграмме бизнес-функций необходимо выделить функции, которые будут реализованы в программном виде.
Взять диаграмму потока данных (соответствующие уровни DFD) для выделенных функций и подфункций и проанализировать ее с учетом входных и выходных потоков данных.
Определить структуру потоков данных, задав список атрибутов сущностей из ER-диаграммы.
На диаграмме переходов состояний определить состояния, переходы и события их вызывающие, которые реализуют бизнес-функции.
Задать программную реализацию каждого состояния в виде библиотечного модуля CASE-системы или модуля, написанного на другом языке.
Нарисовать эскиз системной структурной диаграммы для каждой выделенной функции.
Объединить построенные системные структурные диаграммы в одну исходя из диаграммы бизнес-функции.
Проконтролировать, если позволяют CASE-средства, построенную системную структурную диаграмму.
Если во время контроля ошибок не найдено, то перейти к прототипированию (макетированию) интерфейса программного приложения на основе системной структурной диаграммы.
Для каждого модуля необходимо выбрать шаблон интерфейса из встроенной библиотеки либо в режиме конструктора создать шаблон, либо написать программный модуль на встроенном языке программирования.
Таким образом, перед генерацией все элементы системной структурной диаграммы должны быть определены с учетом интерфейса и связи с таблицами ER-модели.
Технологические операции с преобразователями П8 - ПИ отражают процесс кодогенерации проекта.
Преобразователь П8 «Генерация описания схемы БД». На основе диаграммы «сущность-связь» (D6) и системной структурной диаграммы (D8), а также универсума целевых СУБД (U8) происходит выбор СУБД и генерация для нее описания схемы БД (D9).
Преобразователь П9 «Генерация модуля описания системы БД (DDL)». Входом для технологической операции с преобразователем П9 служат:
описание схемы БД (О9);
структура программного приложения (D8);
универсум языков определения данных (DDL) (U9).
В результате процесса генерации получаем исходные тексты программ на языке выбранной среды (D9). Генерация может быть двух видов:
Неполная генерация заключается в том, что на основе диаграммы «сущность-связь» и выбранной целевой СУБД генерируются модули описания данных DDL на языке описания данных. В результате выполнения неполной генерации на выбранном языке определения данных (SQL и т. п.) создается модуль описания данных (D10).
Полная генерация включает в себя:
генерацию DDL на языке описания данных;
выбор среды, в которой будет приведен исходный код, полученный во время генерации;
запуск процесса генерации.
Преобразователь П10 «Генерация приложения (DDM)». На основе системной структурной диаграммы (D8) и универсума языков определения модулей DDM (U10) происходит генерация модулей программного приложения П10. Результатом генерации являются модули программного приложения, реализующего ЭИС (D11).
Преобразователь П11 «Интеграция модулей приложения». В результате выполнения технологической операции с преобразователем Ш1 происходит интеграция полученных ранее модулей D10 и D11, что приводит к получению готового программного приложения, реализующего ЭИС(G2).