Функционально-ориентированное проектирование ЭИС

Основными идеями функционально-ориентированной 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 «Построение диаграммы потоков данных» являются:

1. материалы обследования (D1);

2. диаграмма иерархии функций (D4);

3. диаграмма «сущность-связь» (D6);

4. универсум конструктивных элементов диаграмм потоков данных U4.

Построение ДПД можно свести к следующим шагам.

1. Расчленение множества требований на функциональные группы.

2. Идентификация внешних объектов (по отношению к системе).

3. Идентификация информации, которая передается между процессами.

4. Разработка контекстной диаграммы.

5. Контроль контекстной диаграммы и уточнение, если это нужно.

6. Формирование ДПД первого уровня, где отражены основные функции системы.

7. Дальнейшая декомпозиция каждого процесса до тех пор, пока процесс самого нижнего уровня можно будет представить в виде некоторой спецификации (алгоритма).

8. Ревизия всех уровней с целью выяснения некорректности, а при ее обнаружении - устранение.

Выходом данной операции является описание в репозитории диаграммы потоков данных D5.

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

При построении ДПС рекомендуется следовать перечислен­ным ниже правилам:

1. начинать построение ДПС на высоком уровне детализации ДПД;

2. строить наиболее простые диаграммы, содержащие 4-6 состояний;

3. по возможности включать детализацию в виде подчиненных шагов состояния (детализация на другом уровне);

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

Применяются 2 способа построения ДПС:

· первый способ заключается в том, что выявляются возможные состояния системы и далее выявляются переходы из одного состояния в другое;

· при втором способе сначала строится начальное состояние, затем осуществляется переход в очередное состояние и т.д. (последовательный переход).

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

Рис. 13.8. Графы матрицы переходов состояний

Входом преобразователя являются:

· материалы обследования (D1);

· диаграмма иерархии функций (D4);

· диаграмма потоков данных (D5);

· диаграмма «сущность-связь» (D6);

· универсум конструктивных элементов диаграмм переходов состояний (U6).

Выход данной операции представлен интегрированным описанием в репозитории функций, потоков данных и состояний проектируемой системы (D7).

Технологическая операция с преобразователем П6 «Постро­ение диаграммы «Сущность-связь» моделирует структуры данных, которые будут храниться в БД. Для ее выполнения необходима следующая входная информация:

· материалы обследования (D1);

· диаграмма потоков данных (D5);

· универсум конструктивных элементов диаграмм сущность-связь (U5).

Построение ER-диаграмм сводится к следующим этапам.

1. Идентифицируются все сущности, их атрибуты, а также первичные ключи.

2. Идентифицируются отношения между сущностями и указывается мощность этих отношений.

3. Если на втором этапе были выявлены отношения N:N, такие отношения являются неспецифическими для реляционных, и их нужно преобразовать либо в 1:N, либо в 1:1. Как правило, это делается с помощью добавления новой сущности.

Выход данной операции представлен описанием в репозитории диаграммы сущность-связь (D6).

Технологическая операция с преобразователем П7 «Построение системной структурной диаграммы» используется для построения структуры программного приложения ЭИС (D8).

На вход преобразователя подаются:

· диаграмма иерархии функций (D4);

· диаграмма потоков данных (D5);

· диаграмма сущность-связь (D6);

· диаграмма переходов состояний (О7);

· универсум конструктивных элементов программного приложения (U7).

Выходом преобразователя служит описание в репозитории структуры программного приложения (D8).

Этапы построения системной структурной диаграммы.

1. В диаграмме бизнес-функций необходимо выделить функ­ции, которые будут реализованы в программном виде.

2. Взять диаграмму потока данных (соответствующие уровни DFD) для выделенных функций и подфункций и проанализировать ее с учетом входных и выходных потоков данных.

3. Определить структуру потоков данных, задав список атрибутов сущностей из ER-диаграммы.

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

5. Задать программную реализацию каждого состояния в виде библиотечного модуля CASE-системы или модуля, написанного на другом языке.

6. Нарисовать эскиз системной структурной диаграммы для каждой выделенной функции.

7. Объединить построенные системные структурные диаграммы в одну исходя из диаграммы бизнес-функции.

8. Проконтролировать, если позволяют CASE-средства, построенную системную структурную диаграмму.

9. Если во время контроля ошибок не найдено, то перейти к прототипированию (макетированию) интерфейса программного приложения на основе системной структурной диаграммы.

10. Для каждого модуля необходимо выбрать шаблон интерфейса из встроенной библиотеки либо в режиме конструктора создать шаблон, либо написать программный модуль на встро­енном языке программирования.

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

Технологические операции с преобразователями П8 - ПИ отражают процесс кодогенерации проекта.

Преобразователь П8 «Генерация описания схемы БД». На основе диаграммы «сущность-связь» (D6) и системной структурной диаграммы (D8), а также универсума целевых СУБД (U8) проис­ходит выбор СУБД и генерация для нее описания схемы БД (D9).

Преобразователь П 9 «Генерация модуля описания системы БД (DDL)». Входом для технологической операции с преобразователем П9 служат:

· описание схемы БД (О9);

· структура программного приложения (D8);

· универсум языков определения данных (DDL) (U9).

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

1. Неполная генерация заключается в том, что на основе диаграммы «сущность-связь» и выбранной целевой СУБД генерируются модули описания данных DDL на языке описания данных. В результате выполнения неполной генерации на выбранном языке определения данных (SQL и т. п.) создается модуль описания данных (D10).

2. Полная генерация включает в себя:

· генерацию DDL на языке описания данных;

· выбор среды, в которой будет приведен исходный код, полученный во время генерации;

· запуск процесса генерации.

Преобразователь П10 «Генерация приложения (DDM)». На основе системной структурной диаграммы (D8) и универсума языков определения модулей DDM (U10) происходит генерация модулей программного приложения П10. Результатом генерации являются модули программного приложения, реализующего ЭИС (D11).

Преобразователь П11 «Интеграция модулей приложения». В результате выполнения технологической операции с преобразователем Ш1 происходит интеграция полученных ранее модулей D10 и D11, что приводит к получению готового программного приложения, реализующего ЭИС(G2).

---

Дата добавления: 2015-08-18