Функционально- ориентированное проектирование Составитель: Шаповалова С.В.

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

Инструментальные средства структурного анализа и проектирования: BFD (Business Function Diagram) - диаграмма бизнес-функций (функциональные спецификации); DFD (Data Flow Diagram) - диаграмма потоков данных; STD (State Transition Diagram) - диаграмма переходов состояний (матрицы перекрестных ссылок); ERD (Entity Relationship Diagram) - ER-модель данных предметной области (информационно- логические модели «сущность-связь»); SSD (System Structure Diagram) - диаграмма структуры программного приложения.

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

Нотации BFD Йодана (Yourdon); Гейна - Сарсона (Gane - Sarson); SADT (Structured Analysis and Design Technique); SAG (Software AG).

Нотации BFD

Пример диаграммы иерархии функций для задачи аналитического учета на складе

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

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

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

Графическое представление объектов ДПД

Серого цвета Stop

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

Пример контекстной ДПД

Пример декомпозиции ДПД

Целью построения иерархически взаимосвязанных ДПД является необходимость сделать требования к системе ясными на каждом уровне детализации. Для этого надо пользоваться следующими рекомендациями: на каждом уровне представлять 3-6 процессов и не более; не загромождать диаграмму несущественными моментами на данном уровне детализации; декомпозицию процессов и потоков вести параллельно; выбирать ясные, отражающие суть объектов, имена для всех объектов ДПД; однократно определять функционально идентичные процессы (в других местах просто ссылаться на этот процесс); использовать ДПД для процессов, которые можно с помощью них описать.

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

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

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

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

Символы ДПС в различных нотациях

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

Диаграммы инфологических моделей «сущность-связь» (ER-диаграммы) Ориентированы на разработку базы данных, структура которой не зависит от конкретных информационных потребностей и позволяет выполнять любые запросы пользователей. ERD-диаграмма представляет собой набор множества объектов и их характеристик, а также взаимосвязей между ними, нужных для выявленных данных, которые в дальнейшем используются функциями проектируемой системы.

Элементы ER-диаграммы Сущность - представляет собой множество экземпляров реальных или абстрактных объектов, которые обладают общими свойствами (атрибутами). Отношение - связь между 2 и более сущностями (должны создать имя в виде глагола). Независимая сущность - представляет независимые данные, которые всегда присутствуют в системе. Зависимая сущность - представляет данные, которые зависят от других сущностей.

Объекты ERD в различных методологиях

продолжение таблицы

Фрагмент диаграммы «сущность- связь» для задачи учета труда и ЗП

Диаграмма структуры программного приложения (SSD) SSD задает взаимосвязь функций и программных модулей, которые их реализуют (меню, формы. отчеты и т.д.). Структура программного приложения (SSD) представляет собой иерархическую взаимосвязь программных модулей, которые реализует ИС. SSD необходима для перехода от системных требований (которые отображены в BFD, DFD, STD и ERD диаграммах), к реализации информационной системы.

Объекты SSD в различных методологиях

Фрагмент структурной диаграммы в нотации SAG для задачи аналитического учета товаров на складе

Проектирование с использованием функционально- ориентированной CASE-технологии процесса 1 Вход Материалы обследования Процесс Инициализация проекта Выход Новый репозиторий для проектируемой системы Стадия проектирования Техническое проектирование

процесса 2 Вход Перечень проектировщиков и их прав доступа к проекту Процесс Задание начальных параметров проекта (выбирается CASE- методология проектирования и в рамках выбранной методологии определяется нотация) Выход Описание начальных параметров проекта в репозитории Стадия проектирования Техническое проектирование

процесса 3 Вход Материалы обследования Процесс Построение диаграммы иерархии функций: отображение основной функции; декомпозиция основной функции на подфункции ; дальнейшая декомпозиция подфункций до необходимой степени детализации; контроль правильности построенной диаграммы Выход Описание дерева функций проекта в репозитории Стадия проектирования Техническое проектирование

Номер процесса 4 Вход 1. Материалы обследования 2. Диаграмма иерархии функций 3. Диаграмма «сущность-связь» Процесс Построение диаграммы потоков данных Выход Описание в репозитории диаграммы потоков данных Стадия проектирования Техническое проектирование

Порядок построения ДПД 1. Расчленение множества требований на функциональные группы. 2. Идентификация внешних объектов. 3. Идентификация информации, которая передается между процессами. 4. Разработка контекстной диаграммы. 5. Контроль контекстной диаграммы и уточнение, если это нужно. 6. Формирование ДПД первого уровня, где отражены основные функции системы. 7. Дальнейшая декомпозиция каждого процесса до тех пор, пока процесс самого нижнего уровня можно будет представить в виде некоторого алгоритма (мини-спецификации). 8. Ревизия всех уровней с целью выяснения некорректности, а при ее обнаружении – устранение.

Номер процесса 5 Вход 1. материалы обследования; 2. диаграмма иерархии функций 3. диаграмма сущность-связь 4. диаграмма потоков данных Процесс Построение диаграммы переходов состояний (описывает возможные состояния проектируемой системы и переходы между ними). Выход Описание в репозитории функций, потоков данных и состояний проектируемой системы Стадия проектирования Техническое проектирование

Правила построения ДПС 1. начинать построение ДПС на высоком уровне детализации ДПД; 2. строить наиболее простые диаграммы, содержащие 4-6 состояний; 3. по возможности включать детализацию в виде подчиненных шагов состояния (детализация на другом уровне); 4. использовать те же приемы наименования состояний, событий и действий, что и при наименовании процессов и потоков. Применяются 2 способа построения ДПС: первый способ - выявляются возможные состояния системы и далее выявляются переходы из одного состояния в другое; второй способ - сначала строится начальное состояние, затем осуществляется переход в очередное состояние и т.д. (последовательный переход).

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

Номер процесса 6 Вход 1. материалы обследования; 2. диаграмма потоков-данных Процесс Построение диаграммы «Сущность-связь»: 1. Идентифицируются все сущности, их атрибуты, первичные ключи 2. Идентифицируются отношения между сущностями и указывается мощность этих отношений. 3. Преобразование отношений N:M, в отношения 1:N и 1:1 Выход Описание диаграммы «Сущность связь» в репозитории Стадия проектирования Техническое проектирование

Номер процесса 7 Вход 1. диаграмма иерархии функций; 2. диаграмма потоков данных; 3. диаграмма «сущность-связь»; 4. диаграмма переходов состояний Процесс Построение системной структурной диаграммы (используется для построения структуры программного приложения ЭИС ) Выход Описание в репозитории структуры программного приложения Стадия проектирования Техническое проектирование

Этапы построения системной структурной диаграммы. 1. В диаграмме бизнес-функций необходимо выделить функции, которые будут реализованы в программном виде. 2. Взять диаграмму потока данных (соответствующие уровни DFD) для выделенных функций и подфункций и проанализировать ее с учетом входных и выходных потоков данных. 3. Определить структуру потоков данных, задав список атрибутов сущностей из ER-диаграммы. 4. На диаграмме переходов состояний определить состояния, переходы и события их вызывающие, которые реализуют бизнес-функции. 5. Задать программную реализацию каждого состояния в виде библиотечного модуля CASE-системы или модуля, написанного на другом языке.

6. Нарисовать эскиз системной структурной диаграммы для каждой выделенной функции. 7. Объединить построенные системные структурные диаграммы в одну исходя из диаграммы бизнес-функции. 8.Проконтролировать, если позволяют CASE-средства, по­ строенную системную структурную диаграмму. 9. Если во время контроля ошибок не найдено, то перейти к прототипированию (макетированию) интерфейса программного приложения на основе системной структурной диаграммы. 10. Для каждого модуля необходимо выбрать шаблон интерфейса из встроенной библиотеки либо в режиме конструктора создать шаблон, либо написать программный модуль на встроенном языке программирования.

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

Номер процесса 8 Вход 1. диаграмма «сущность-связь» 2. системная структурная диаграмма Процесс Генерация описания схемы БД Выход Сгенерированное в рамках целевой СУБД описание схемы базы данных Стадия проектирования Кодогенерация (физическое проектирование)

Номер процесса 9 Вход 1. Описание схемы БД. 2. Структура программного приложения. Процесс Генерация модуля описания системы БД (DDL) Выход Исходные тексты программ на языке выбранной среды Стадия проектирования Кодогенерация (физическое проектирование)

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

Номер процесса 10 Вход Системная структурная диаграмма Процесс Генерация приложения (DDM) Выход Модули программного приложения, реализующего ЭИС Стадия проектирования Кодогенерация (физическое проектирование)

Номер процесса 11 Вход 1. Модуль описания данных 2. Модули программного приложения Процесс Интеграция модулей приложения Выход Готовое программное приложение, реализующее ЭИС Стадия проектирования Кодогенерация (физическое проектирование)

Литература: 1. Смирнова Г.Н.,Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник М.: «Финансы и статистика», 2002