Основными идеями функционально-ориентированной CASE-технологии являются идеи структурного анализа и проектирования информационных систем. Они заключаются в следующем:
1) декомпозиция всей системы на некоторое множество иерархически подчиненных функций;
2) представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически.
В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:
• BFD (Bussiness Function Diagram) - диаграмма бизнес-функций (функциональные спецификации);
• ERD (Entity Relationship Diagram) - ER-модель данных предметной области (информационно-логические модели «сущность-связь»);
• SSD (System Structure Diagram) - диаграмма структуры программного приложения.
Диаграммы функциональных спецификаций позволяют представить общую структуру ИС, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов. Основными объектами BFD являются:
• Функция - некоторое действие информационной системы, необходимое для решения экономической задачи;
• Декомпозиция функции - разбиение функции на множество подфункций.
Изображение объектов диаграммы иерархии функций может быть представлена в нотациях:
• Йодана (Yourdon);
• Гейна - Сарсона (Gane - Sarson);
• SADT (Structured Analysis and Design Technique);
• SAG (Software AG).
Диаграммы потоков данных (ДПД), как правило, жестко ориентированы на какую-либо технологию обработки данных и отражают передачу информации от одной функции к другой в рамках заданной технологии обработки. В узлах диаграммы потоков данных (прямоугольниках) отражаются процедуры, а стрелками между узлами показываются потоки данных (над стрелками задаются имена передаваемых/используемых единиц информации - документов, экранных форм, файлов).
Рассмотрим основные понятия диаграммы потоков данных.
ДПД - показывает внешние по отношению к системе источники данных и адресатов, которые принимают информацию от системы, а также идентифицируют хранилища данных (накопители данных), к которым осуществляется доступ системы. Каждая логическая функция системы (бизнес-функция) описывается своей ДПД. Причем эта ДПД может иерархически детализировать функцию на ее подфункции.
Определим основные объекты ДПД и их графические изображения в различных нотациях .
Потоки данных ~ являются механизмами, которые показывают передачу информации от одного процесса к другому. На схемах они обычно отражаются направленной стрелкой, которая показывает направление движения информации или материалов (могут отражаться материальные потоки).
Процесс - его функция состоит в преобразовании входной информации в выходную. Имя процесса всегда должно содержать глагол в неопределенной форме с последующим дополнением (например, «нарисовать форму»).
Хранилище информации - позволяет на определенных участках ДПД сохранить в памяти данные между процессами. Хранилище не обязательно представлено магнитным носителем (например, папка бумаг). Имя хранилища должно идентифицировать его, а также его содержимое, выражается существительным.
Внешняя сущность (источник/приемник данных) - представляет некоторый объект вне системы, являющийся внешним объектом.
Контекстная диаграмма - самый верхний процесс (ТОР-уровень) декомпозиции системы, который отражает общие представления о системе. В контекстной диаграмме есть процесс, с которым связаны внешние сущности.
Диаграммы переходов состояний (ДПС)моделируют поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчетного периода и т.д.)- Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками. С помощью ДПС можно моделировать последующее функционирование системы исходя из предыдущих и текущего состояний.
Моделируемая система в текущий момент времени находится только в одном состоянии из всего множества состояний. В течение времени она может изменить свое состояние и тем самым перейти в следующее состояние из заданного множества состояний. Для перехода в состояние нужно какое-либо особое условие перехода. Оно может быть информационным (условие появления информации) или временным. Определим основные объекты ДПС.
Состояние - рассматривается как устойчивое значение некоторого свойства в течение определенного времени. Находясь в текущем состоянии, необходимо знать о предыдущих состояниях, чтобы определить условие перехода в последующее состояние.
Начальное состояние - это узел ДПС, являющийся стартовой точкой для начального системного перехода. ДПС имеет только одно начальное состояние, но может иметь множество конечных состояний.
Переход - определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода - это событие, которое вызвало этот переход. Переход может быть вызван каким-либо действием ( например, нажатием клавиши).
Триггер - логическое выражение, написанное на макроязыке, которое показывает условие перехода в данное состояние.
Условие перехода - событие, вызывающее переход и идентифицируемое именем перехода.
Диаграммы инфологических моделей «сущность-связь» (ER-диаграммы) ориентированы на разработку базы данных, структура которой не зависит от конкретных информационных потребностей и позволяет выполнять любые запросы пользователей.
ERD-диаграмма «сущность-связь» представляет собой набор множества объектов и их характеристик, а также взаимосвязей между ними, нужных для выявленных данных, которые в дальнейшем используются функциями проектируемой системы.
Диаграмма структуры программного приложения (SSD) задает взаимосвязь функций и программных модулей, которые их реализуют (меню, формы, отчеты и т.д.).
Структура программного приложения (SSD) представляет собой иерархическую взаимосвязь программных модулей, которые реализует ИС. SSD служит мостом для перехода от системных требований, которые отображены в предыдущих диаграммах (BFD, DFD, STD, ERD), к реализации информационной системы.
Объектно-ориентированное проектирование ЭИС.
Структурная декомпозиция ЭИС на основе объектно-ориентированного подхода отличается от функционально-ориентированного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникающих событий. В этом плане модель проблемной области рассматривается как совокупность взаимодействующих во времени объектов. Тогда конкретный процесс обработки информации формируется в виде последовательности взаимодействий объектов. Одна операция обработки данных может рассматриваться как результат одного взаимодействия объектов.
Конечным результатом процесса объектно-ориентированного проектирования должно стать множество классов объектов с присоединенными методами обработки атрибутов. Если в функциональном подходе модели данных и операций разрабатываются относительно независимо друг от друга и только координируются между собой, то объектно-ориентированный подход предполагает совместное моделирование данных и процессов. При этом модели проблемной области в репозитории постепенно уточняются.
В связи с этим система объектно-ориентированных моделей последовательно разворачивается по направлению от модели общего представления функциональности ЭИС к модели динамического взаимодействия объектов, на основе которой могут быть сгенерированы классы объектов в конкретной программно-технической среде.
В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML (Unified Modeling Language), который разработан группой ведущих компьютерных фирм мира OMG (Object Management Group) и фактически является стандартом по объектно-ориентированным технологиям. Язык UML реализован многими фирмами - производителями программного обеспечения в рамках CASE-технологий, например Rational Rose (Rational), Natural Engineering Workbench (Software AG), ARIS Toolset (IDS prof. Scheer) и др.
Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:
1) диаграмму прецедентов использования (Use-case diagram), которая отображает функциональность ЭИС в виде совокупности выполняющихся последовательностей транзакций;
2) диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода;
3) диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;
4) диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;
5) диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы);
6) диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы);
7) диаграмму компонентов (Component diagram), которая отображает физические модули программного кода;
8) диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.