Диаграммы потоков данных DFD используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота.
IDEF3 эффективно и наглядно описывает логику взаимодействия информационных потоков. Каждая работа в IDEF3 описывает какой-либо сценарий процесса и может являться составляющей другой работы. Основной единицей описания в IDEF3 также является диаграмма.
Erwin-пакет позволяет создать модели данных в системе. Он имеет два уровня представления моделей - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Отдел". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель может быть построена на основе модели процессов.
Физическаая модель данных зависит от конкретной СУБД, являясь отображением системного каталога, поскольку стандартов на объекты БД не существует. Если в логической модели не имеет значения, какой тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д. Для выбора СУБД служит редактор Target Server.
После разработки модели данных ее следует связать с моделью процессов. Первым шагом связывания является экскурс данных из Erwin в Bpwin. Далее создают сущности и атрибуты Bpwin и осуществляют их экспорт в Erwin.
9.7. Rational Rose
Семейство продуктов Rational Rose призвано обеспечить разработчика программ полным набором инструментов визуального моделирования на основе объектно-ориентированного языка UML. Пакет Rational Rose позволяет анализировать требования к системе с помощью диаграмм последовательности действий и диаграмм взаимодействий, моделировать состояния, генерировать код и поддерживать встроенный скрипт для доступа к внутренним компонентам программы.
Поведение разрабатываемой системы описывается с помощью функциональной модели, которая отображает системные прецеденты (use cases), системное окружение (актеров-actors) и связи между прецедентами и актерами (диаграммы прецедентов - use cases diagrams).
Актеры не являются частью системы - они представляют собой кого-то или что-то, что должно взаимодействовать с системой. Они могут снабжать информацией систему и получать информацию от системы.
Прецеденты определяют диалог между системой и актерами. Это последовательность транзакций, выполняемых системой, обеспечивающая нужный результат.
Требуемое поведение системы реализуется с помощью потока событий. Поток событий описывается в терминах того, что система должна сделать, а не как она это делает. События определяют когда и как прецеденты начинаются и заканчиваются, как они взаимодействуют с актерами, какие данные для них нужны, а также всю последовательность событий для прецедентов.
Графическое представление актеров, прецедентов и их взаимодействий дает диаграмма прецедентов (use case diagram). Динамику проекта представляют диаграммы действий (activity diagrams). Пути потоков управления от действия к действию представлены переходами.
В заключение отметим, что выбор системы моделирования определяется многими факторами. К ним относятся сложность исследуемой системы и ее функциональный состав, цель имитации, объем статистического анализа, стоимость программного обеспечения.
10. ТЕХНОЛОГИЯ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ
Формулирование цели моделирования. Целью моделирования может являться получение некоторых количественных показателей работы системы, наблюдение за процессами в ее среде, анализ загруженности элементов, выявление функциональных возможностей и т. д. Цель моделирования часто диктует средства, требуемые для имитации, продолжительность работы моделируемого комплекса и необходимый объем вычислений.
Изучение объекта и условий. Полнота знаний об объекте моделирования определяет степень адекватности разработанной модели функциональным особенностям и структуре объекта (системы).
К условиям работы объекта относятся рабочие входные данные, график функционирования и мешающие воздействия.
Декомпозиция объекта. Для очевидности и простоты отображения объекта в ЭВМ его необходимо расчленить на составляющие, описываемые стандартными средствами: аналитически, таблично, графически, последовательностью событий и процессов и т. д. Все составляющие должны быть соответствующим образом связаны друг с другом и зависеть от тех или иных входных или мешающих воздействий.
Разработка модели. Разработка модели предусматривает выбор концепции и логико-математического описания моделируемого объекта в соответствии с поставленной проблемой.
Разработчик должен уяснить структуру моделируемой системы, выявить общие правила её функционирования, исключив ненужные детали. Модель должна быть достаточно простой для понимания и в то же время достаточно сложной, чтобы отображать характерные черты реальной системы. На этапе разработки модели на основе изучения условий работы системы определяются модельные (формализованные) требования к входным данным. Некоторые из этих данных могут быть уже в распоряжении разработчика, в то время как для определения других потребуются время и усилия.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.