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

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

1) декомпозиция всей системы на некоторое множество иерархически подчиненных функций;

2) представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически.

В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:

• BFD (Bussiness Function Diagram) - диаграмма бизнес-функций (функциональные спецификации);

• STD (State Transition Diagram) - диаграмма переходов состояний (матрицы перекрестных ссылок);

• ERD (Entity Relationship Diagram) - ER-модель данных предметной области (информационно-логические модели «сущность-связь»);

• SSD (System Structure Diagram) - диаграмма структуры программного приложения.

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

• Функция - некоторое действие информационной системы, необходимое для решения экономической задачи;

• Декомпозиция функции - разбиение функции на множество подфункций.

Изображение объектов диаграммы иерархии функций может быть представлена в нотациях:

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

Рассмотрим основные понятия диаграммы потоков данных.

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

Определим основные объекты ДПД и их графические изображения в различных нотациях.

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

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

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

Внешняя сущность (источник/приемник данных) - представляет некоторый объект вне системы, являющийся внешним объектом.

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

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

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

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

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

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

Триггер - логическое выражение, написанное на макроязыке, которое показывает условие перехода в данное состояние.

Условие перехода - событие, вызывающее переход и идентифицируемое именем перехода.

Диаграммы инфологических моделей «сущность-связь» (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), которая отображает распределение объектов по узлам вычислительной сети.

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: