Bpwin и ERwin моделирование
Составляющие диаграмм потоков (DFD) и их обозначение в различных нотациях. Построение модели, описанной в задании предметной области, в программе BPWin в нотации IDF0. Контекстная диаграмма, диаграммы первого уровня и детализации любого из ее процессов.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | контрольная работа |
Язык | русский |
Дата добавления | 17.10.2014 |
Размер файла | 1,5 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Содержание
- Основные составляющие диаграмм потоков (dfd) и их обозначение в различных нотациях
- Практическое задание № 1 Построение IDF0-модели (40)
- Практическое задание № 2 построение DFD-модели (50)
- Практическое задание № 3 построение диаграммы "сущность связь" (60)
- Литература
Основные составляющие диаграмм потоков (dfd) и их обозначение в различных нотациях
DFD - общепринятое сокращение от англ. Data Flow Diagrams - диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.
Исторически сложилось так, что для описания диаграмм DFD используются две нотации - Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. Нотация DFD - удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда.
Основными компонентами диаграмм потоков данных являются:
внешние сущности;
системы/подсистемы;
процессы;
накопители данных;
потоки данных.
1) Внешние сущности (External Entity)
Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом (рисунок 1), расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений:
Рис. 1 Внешняя сущность
2) Системы и подсистемы (Systems and subsystems)
При построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем.
Подсистема (или система) на контекстной диаграмме изображается следующим образом (рисунок 2).
Рис. 2 Подсистема
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
3) Процессы (Process)
диаграмма моделирование нотация поток
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
Процесс на диаграмме потоков данных изображается, как показано на рисунке 3.
Рис. 3. Процесс
Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например:
"Ввести сведения о клиентах";
"Выдать информацию о текущих расходах";
"Проверить кредитоспособность клиента".
Использование таких глаголов, как "обработать", "модернизировать" или "отредактировать" означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
4) Накопители данных (Datastore)
Накопитель данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных на диаграмме потоков данных изображается, как показано на рисунке 4.
Рис. 4. Накопитель данных
Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.
Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью.
5) Потоки данных (Dataflow)
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рисунок 5). Каждый поток данных имеет имя, отражающее его содержание.
Рис. 5. Поток данных
В DFD используются следующие типы объектов: · работа (activity) - синоним работе в IDEF0 и IDEF3; · внешняя сущность (external entity) - объекты - источники/получатели информации/данных, изменяемых или используемых в данной функции. · стрелка (data flow) - обозначение потока информации (данных); · data store (хранилище данных) - любой механизм или абстракция (например, запись в базе данных), в которой хранятся данные. Потоки данных между работами в DFD возможны не только опосредованно, через хранилища данных, но и непосредственно между работами, если данные не поступают сначала в хранилище. Нотации IDEF0, IDEF3 и DFD могут быть последовательно использованы при все более и более глубокой проработке модели организации, завершающим этапом которой может быть детальное описание бизнес-процессов и информационной системы организации
Практическое задание № 1 Построение IDF0-модели (40)
1. В программе BPWin в нотации IDF0 построить модель описанной в задании предметной области. Модель должна содержать контекстную диаграмму, диаграмму первого уровня и одну диаграмму детализации любого из процессов диаграммы первого уровня. В отчете привести распечатки или изображения всех диаграмм, кратко описать построение и привести обоснование построения.
2. Построить дерево узлов для полученной модели. В отчете привести распечатку или изображение диаграммы дерева узлов, кратко описать построение.
Торговая фирма.
Создать функциональную модель деятельности торговой фирмы по реализации продовольственной продукции, учитывая работу фирмы с клиентами, поставщиками, доставку продукции от поставщиков и по торговым точкам клиентов.
Выполнение задания
Создание контекстной диаграммы
Контекстная диаграмма отражает отношение системы с внешней средой. Она должна содержать только один процесс (работу), называемый общей фразой, обозначающий в целом деятельность всей моделируемой системы. Имя любого процесса должно начинаться с глагола или отглагольного существительного. Например: Найти товар, Выдать чек или Поиск товара. Выдача чека.
В данном случае процесс будет называться "Реализации продовольственной продукции".
Процесс (работа) - функция системы, набор действий или элементарное действие. На 1DEF0 диаграммам изображается прямоугольником. Детализируется при помощи диаграмм нижних уровней.
Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными, например, "Заготовка", "Изделие", "Заказ".
Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее.
В IDEF0 различают пять типов стрелок:
Вход (input) - материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы. Например, "Продукция поставщика" на рисунке I - это нечто, что перерабатывается в процессе "Реализации продовольственной продукции" для получения результата. Очень часто сложно определять, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются (изменяются) ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет - управление.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рисунке 1 стрелки "Предложение продукции поставщиками" и "Спрос клиентов на продукцию" - управление для работы "Реализации продовольственной продукции". Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.
Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рисунке I стрелка "Реализованная продукция" является выходом для работы "Реализации продовольственной продукции".
Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т.д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рисунке 1 стрелка "Сотрудники фирмы" является механизмом для работы "Реализации продовольственной продукции".
Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. На рисунке I стрелка "Другая модель работы" является вызовом для работы "Реализации продовольственной продукции". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.
Контекстная диаграмма будет иметь вид представленный на рисунке 1.
Рисунок I - Вид контекстной диаграммы
Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других аспектов контекста служит диалог Model Properties.
Диаграммы декомпозиции содержат родственные работы, т.е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке
Возникает диалог Activity Box Count, в котором следует указать нотацию новой диаграммы и количество работ в ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции. Допустимый интервал числа работ - 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.
Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по свободному месту на диаграмме. Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему. В левом верхнем углу располагается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее нужные или выполняемые позже работы. Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ. Диаграмма декомпозиции представлена на рисунке 2.
Рисунок 2 - Диаграмма декомпозиции
Аналогичным образом строиться диаграмма декомпозиции любой из работ.
Для примера детализируем первую работу "Приём продукции от поставщика". Диаграмма декомпозиции представлена на рисунке 2.1.
Рисунок 2.1 - Диаграмма декомпозиции 1-го процесса
Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами (стрелки) (рисунок 3). Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. Впрочем, BPWin имеет мощный инструмент навигации по модели - Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде, однако этот инструмент является составляющей стандарта 1DEF0.
Для создания диаграммы дерева узлов следует выбрать в меню пункт Insert/Node Tree (или Diagram/Add Node Tree). Возникает диалог формирования диаграммы дерева узлов Node Tree Definition.
Диаграмма дерева узлов представлена на рисунке 3.
Рисунок 3 - Диаграмма дерева узлов
Под работой "Прием продукции от поставщика" перечислены работы с диаграмм декомпозиции.
Практическое задание № 2 построение DFD-модели (50)
В программе BPWin в нотации DFD построить модель описанной в задании предметной области. Модель должна содержать контекстную диаграмму, диаграмму первого уровня (не менее 5 процессов). Если на диаграмме первого уровня менее пяти процессов, создать диаграмму детализации любого из них. Также модель должна содержать минимум одну внешнюю сущность и хранилище. В отчете привести распечатки или изображения всех диаграмм, кратко описать построение и привести обоснование построения.
Личная библиотека.
Пользователь вносит данные о новых книгах, то есть название, автора, жанр, расположение.
Пользователь может ввести
жанр и получить названия книг и авторов этого жанра;
название книги и получить ее расположение;
автора и получить название его книг.
Результаты пользователь может получить как на экране, так и в виде отчета.
Выполнение задания
Создание контекстной диаграммы.
Контекстная диаграмма отражает отношение системы с внешней средой. Она должна содержать только один процесс, называемый общей фразой, обозначающий в целом деятельность всей моделируемой системы. В данном случае это процесс будет называться "Обработать данные".
Процесс - функция системы, набор действий или элементарное действие. В названии процесса обязательно должен присутствовать глагол. Обозначается прямоугольником с закругленными углами. Детализируется при помощи диаграмм нижних уровней.
На контекстной диаграмме желательно отобразить все внешние сущности, то есть объекты, поставляющие информацию в систему или получающие ее. В данном примере она одна - пользователь. Обозначается внешняя сущность как прямоугольник с выделенными более ярко двумя границами.
Потоки данных между процессом и внешними сущностями отображают получаемую и передаваемую информацию. Называют их с использованием имен существительных, обозначают стрелкой, направление стрелки указывает направление потока данных. В данном примере:
от пользователя к процессу идут четыре потока данных, необходимых для получения нужных пользователю сведений - Название книги, Автор книги, Жанр книги, Расположение книги; и один поток для ввода новых данных - Данные о новых книгах (название, жанр, автор);
от процесса к пользователю идут шесть потоков данных - Названия книг и авторов жанра, Место расположения книги, Названия книг автора, отчёт о названии книг и авторов жанра, отчёт о месте расположения книг, отчёт о названии книг автора. Эти потоки соответствуют данным, выдаваемым на монитор компьютера и отчетам, напечатанным на принтере.
Этих данных достаточно, чтобы построить контекстную диаграмму. Она приведена на рисунке 4.
Рисунок 4 - Контекстная DFD диаграмма
Сразу после создания диаграммы первого уровня (аналогично IDEF0) на ней находятся только процессы (пока не подписанные) и стрелки потоков данных, не соединенные ни с одним процессом. Все потоки на диаграмме соответствуют потокам, созданным на контекстной диаграмме, и сохраняют свое направление.
На диаграмме первого уровня в данной задаче необходимо разместить пять процесса, соответствующие основным функциям справочной системы.
В названии процесса обязательно должен быть глагол. Эти процессы можно назвать так:
Процесс 1 - "Внести новые данные" - вносит в базу данных сведения, вводимые пользователем.
Процесс 2 - "Найти жанр" - выполняет поиск книг и авторов по введенному жанру.
Процесс 3 - "Найти расположение книги" - по введенному названию книги находит и выдаёт её местоположение.
Процесс 4 - "Найти книги автора" - по введенному имени автора находит названия его книг.
Процесс 5 - "Распечатать отчеты" - распечатывает для пользователя отчеты из найденных данных.
Теперь надо распределить информационные потоки между процессами. Потоки на контекстной диаграмме, идущие от процесса к пользователю на диаграмме первого уровня, направлены стрелкой во вне, т.е. от процессов. В дальнейшем они будут обозначаться как исходящие потоки. Потоки, направленные на контекстной диаграмме от пользователя к процессу, на диаграмме первого уровня направлены стрелкой к процессам. В дальнейшем они будут обозначаться как входящие потоки.
На данной диаграмме необходимо разместить Хранилище: оно соответствует базе данных, хранящей сведение о книгах, авторах и жанрах.
Процесс "Найти жанр" должен получить данные для поиска. Это наименование жанра. Поэтому надо связать его и входящий поток данных "Жанр книги". Это процесс выдает пользователю результат поиска - название книг данного жанра и их авторы. Следовательно, исходящий поток данных "Название книги автор книги" надо связать с данным процессом.
Кроме того, данный процесс из найденных данных формирует отчет о данном книгах этого жанра различных авторов. Следовательно, надо создать новый поток данных и направить его от процесса "Найти жанр" к процессу "Распечатать отчеты", назвать его следует "Отчет о названии книг и авторов жанра".
Чтобы получить данные, процесс должен направить к базе данных запрос. Из базы данных он получает результат поиска. Надо создать два новых потока. Один от базы данных к процессу, второй от процесса к базе данных. Названия будут для первого - "Результат поиска 1". а для второго - "Запрос 1".
Аналогичным образом потоки данных распределяются между остальными процессами.
Диаграмма первого уровня представлена на рисунке 5.
Рисунок 5 - Диаграмма первого уровня.
Практическое задание № 3 построение диаграммы "сущность связь" (60)
При помощи программы Erwin создайте модели базы данных для предметных областей, указанных в задании. Описать ход работы. Обосновать выбор связей, ключевых атрибутов, типов данных. В отчете привести распечатки или изображения диаграмм физического и логического уровней.
Приложить к выполненному заданию распечатку или изображение.
База данных "Турагентство"
Содержит информацию о путевках (код путевки, страна, место, продолжительность, стоимость), о клиентах (ФИО, адрес, телефон), о выбранных путевках (код путевки. ФИО, дата отъезда). Клиент может выбрать одну или несколько путевок, путевка может быть не выбрана никем.
Выполнение задания
При создании новой диаграммы первым появляется диалоговое окно для ввода шаблона модели. В нем надо выбрать модель с логическим и физическим уровнями (Logical/Physical).
Понятие логический уровень подразумевает, что при его создании мы мыслим в понятиях реального мира и непосредственно из него берем объекты для моделирования. Например, люди, столы, подразделения - это реальные вещи. Объекты, на которые мы ссылаемся на логическом уровне, должны получать имена из естественного языка, с использованием таких разделителей (пробелов, черточек и т.п.), которые имеют смысл. На логическом уровне не имеет значения, как потом будет реализовываться база данных. Особенности реализации отражаются на физическом уровне.
После создания новой модели надо настроить среду разработки ERWin, для того чтобы диаграммы имели стандартный вид. В меню Model надо выбрать пункт ModelProperties, в появившемся окне найти закладку Notation и установить для логической и физической моделей IE.
Для того чтобы были видны подписи на связях, надо выбрать меню Format, в нем Relationship, а в нем установить галочку возле Verb Phrase.
Путёвки, Клиенты, Выбранные путёвки. Эти объекты на диаграмме будут обозначены как сущности.
Сущность служит для представления набора реальных или абстрактных предметов (людей, мест, событий и т.п.), которые обладают общими атрибутами или характеристиками. Сущность - "логический" объект, который в физической среде СУБД представлен таблицей. Сущность в ERwin обычно описывают три характеристики:
атрибуты, являющиеся первичными ключами:
неключевые атрибуты;
тип сущности.
ERwin поддерживает два типа сущностей: независимые и зависимые. Независимая сущность - это сущность, экземпляры которой могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью. Обозначается прямоугольником. Зависимая сущность - это сущность, экземпляры которой не могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью или сущностями - обозначается прямоугольником с закругленными краями.
Создадим и подпишем все три сущности:
Выберем пиктограмму независимой сущности (квадрат с острыми углами). Она находится рядом со стрелкой выбора. После щелкнете по пиктограмме, она выделится. Форма курсора изменится: вместо стрелки появится крест;
Передвигаем крест в то место, где у Вас будет находиться новая сущность, и щелкаем кнопкой мыши. Появится новая сущность с меткой Е/#, где "Е" означает сущность, а "#" - уникальный номер.
Двойной щелчок по сущности приведет к открытию ее редактора - EDtity-Properties. Это верно для всех объектов, для которых существует редактор.
В этом редакторе можно присваивать сущности имя, внести описание, присваивать иконки для сущностей.
В этом редакторе есть выпадающий список под названием Entity. Он позволяет выбрать другую сущность и изменить ее свойства.
Закладка Definition используется для ввода определения сущности. Эти определения полезны на логическом уровне, поскольку они помогают людям, читающим модель, понять, что это за объект. Они полезны и на физическом уровне, поскольку их можно экспортировать как часть Вашей схемы и использовать в реальной базе данных.
Закладки Note/ Nole2/Note3 - это комбинированный редактор, в котором допускается ввод информации трех типов: общие замечания о сущности; примеры запросов, в которых, участвует сущность; примеры экземпляров данных для сущности. Эта информация может быть полезной при документировании идей и вопросов, возникающих в процессе разработки моделей данных.
Далее необходимо создать атрибуты каждой сущности.
Атрибут представляет собой тип характеристики, связанной с множеством реальных или абстрактных предметов (людей, мест, событий и т.д.). В ER-диаграммах каждая сущность описывается своим набором атрибутов. Если сущность является прообразом таблицы в базе данных, то атрибут - прообраз поля. Атрибуты могут быть ключевыми и неключевыми.
Неключевой атрибут служит для описания сущности, но его недостаточно, чтобы уникально задать каждый экземпляр сущности. экземпляр сущности - прообраз записи, конкретный объект.
Ключевые атрибуты делятся на атрибуты первичного ключа, внешний ключ.
Атрибуты первичного ключа - атрибут (атрибуты), который (е) уникальным образом идентифицируют экземпляр сущности.
Внешний ключ - атрибут, мигрировавший от родительской сущности к дочерней через связь. Внешние ключи создаются при установлении связей. Таким образом, при проектировании сущностей нет необходимости создавать атрибуты, аналогичные атрибутам другой сущности, чтобы потом установить связь. Например, при проектировании сущности Выбранные путёвки атрибут "Код путёвки" не создается. Он мигрирует в эту сущность после установки связи с сущностью "Путёвки".
Для создания нового атрибута надо определить его тип данных и домен.
Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких, как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал).
Понятие домена свойственно базам данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена.
Домен можно представить как допустимое множество значений данного типа. Например, домен "ФИО" определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые изображают имя (в частности, такие строки не могут начинаться с мягкого знака).
Если в базе данных есть атрибуты со сходным смыслом, то они могут быть определены на одном домене. Например, если есть атрибуты "адрес организации" и "адрес заказчика", то для них можно создать один домен "Адрес". Это возможно, потому что правила написания и для адреса заказчика, и для адреса организации одинаковы.
Для создания домена надо вызвать диалог Domain Dictionary' из меню Model. Диалог показывает уже существующие домены и основные типы данных. Для создания нового нажмите кнопку New. В появившемся окне укажите имя нового домена для логической и физической модели (обычно они совпадают), затем выберите домен или тип данных, на котором будет основываться создаваемый домен. Основные типы данных - это текстовый (string), числовой (Number), дата-время (Datetime), логический (Blob). Нажмите ОК и вернитесь к главному окну диалога. В списке существующих типов появиться новый домен. Иконка возле него - обычное изображение папки. Ее можно изменить, выбрав значок из списка Domain Icons, обычно выбирается значок, как у типа данных. Можно загрузить нестандартный значок, нажав на кнопке с троеточием возле списка Domain Icons.
Когда все необходимые для сущностей домены заданы, их надо внести в сущность. Для этого необходим редактор атрибутов. Щелкнув по сущности правой кнопкой мыши, выберите пункт Attributes.
В самом верху окна находится список, из которого можно выбрать сущность. Кнопка с троеточием, размещенная возле списка, вызывает окно свойств сущности.
В правой части окна указаны все определенные в модели атрибуты. Кнопка с троеточием, размещенная возле списка, вызывает окно диалог Domain Dictionary, если необходимо создать еще один атрибут.
В левой части окна помещено поле для выбранных атрибутов сущности. Ключевые атрибуты отмечены символом Ключ. Над полем есть две кнопки со стрелками. Они позволяют менять порядок следования полей в сущности.
Ниже поля размещены кнопки управления. После щелчка по кнопке New. появляется окно, в котором нужно выбрать атрибут. В качестве примера можно привести домены: "Количество" (определен на числовом типе данных), "Адрес" и "ФИО" (определены на строковом типе). Атрибуты "Адрес_клиента", "Место и Страна" будет определен на домене "Адрес".
Для данной моделируемой предметной области надо создать следующие домены: Код, Адрес, Продолжительность, Стоимость, ФИО, Телефон, Дата.
У сущности "Путёвки" будут следующие атрибуты:
КОД_ПУТЁВКИ - ключевой атрибут, так как по коду можно определить конкретную путёвку. Определен на домене "Код".
МЕСТО_И_СТРАНА_ПУТЕВКИ - неключевой атрибут. Определен на домене "Адрес".
ПРОДОЛЖИТЕЛЬНОСТЬ_ПУТЕВКИ - неключевой атрибут. Определен на домене "Продолжительность".
СТОИМОСТЬ_ПУТЕВКИ - неключевой атрибут. Определен на домене "Стоимость".
У сущности "Клиенты" будут следующие атрибуты:
ФИО_КЛИЕНТА - ключевой атрибут, так как по названию можно определить конкретного клиента. Определен на домене "ФИО".
АДРЕС_КЛИЕНТА - неключевой атрибут. Определен на домене "Адрес".
ТЕЛЕФОН _КЛИЕНТА - неключевой атрибут. Определен на домене "Телефон".
У сущности "Выбранные путёвки" будут следующие атрибуты;
КОД_ПУТЁВКИ - ключевой атрибут, внешний ключ. Появляется после установки связи с сущностью Путевки;
ФИО_КЛИЕНТА - ключевой атрибут, внешний ключ. Появляется после установки связи с сущностью Клиенты. До установки связей сущность не содержит атрибутов.
ДАТА_ОТЪЕЗДА _КЛИЕНТА - неключевой атрибут. Определен на домене "Дата".
Связь - это соотношение либо между двумя сущностями, либо между сущностью и этой же сущностью. Связь - "логический" объект, представленный одним или несколькими атрибутами - внешними ключами. Связь в ERwin обычно содержит пять типов информации тип связи, родительский конец связи, дочерний конец связи, знак "обязательности" связи и кардинальность связи.
Идентифицирующая связь - такая связь, при которой экземпляр дочерней сущности идентифицируется через свою ассоциацию с родительской сущностью. Атрибуты первичного ключа родительской сущности становятся атрибутами первичного ключа дочерней.
Неидентифицирующая связь - это такая связь, при которой экземпляр дочерней сущности не идентифицируется через свою ассоциацию с родительской сущностью. Атрибуты первичного ключа родительской сущности становятся неключевыми атрибутами дочерней.
Неопределенная связь "многие-ко-многим" устанавливается на логическом уровне. Это отношение между двумя сущностями, при котором каждый экземпляр первой сущности связан с 0,1 или более экземплярами второй сущности и каждый экземпляр второй сущности связан с 0,1 или более экземплярами первой сущности. В дальнейшем ее лучше заменять двумя связями один-ко-многим и введением дополнительной сущности.
Виды связей, которые можно устанавливать, зависят от того, выбран логический или физический уровень.
Чтобы установить связь необходимо выбрать на панели тип связи, выделить сначала главную (родительскую), а затем зависимую (дочернюю) сущности. Чтобы вызвать редактор, можно дважды щелкнуть по связи или щелкнуть правой кнопкой мыши и выбрать пункт Relationship Properties.
Связь имеет двойное имя в направлении от главной сущности к дочерней и от дочерней к главной. Например, связь между сущностями Клиент и Товар имеет имя "Покупает/Заказывается". Клиент покупает Товар; и Товар заказывается Клиентом.
Кардинальное число определяет возможное число объектов (экземпляров сущности) на дочернем конце связи. Это число не существует для связи многие-ко-многим. В Erwin приняты следующие типы:
ноль, один более;
один и более;
ноль или один;
конкретное число.
Например, если кардинальное число - один и более, то для каждой записи главной таблицы в дочерней должно существовать не менее одной записи в дочерней.
На закладке свойств Rollename можно задать свойства мигрирующих атрибутов. Например, псевдоним для внешнего ключа.
В данном примере надо установить две связи:
между сущностями Путевки и Выданные путёвки - связь идентифицирующая, один-ко-многим, кардинальное число - 0 или 1. Именно такая связь необходима, потому что одна путёвка может быть выбрана только одним клиентом или не выбрана ни кем;
между сущностями Клиенты и Выбранные путёвки - связь идентифицирующая, один-ко-многим, кардинальное число - 1 и более. Клиент может выбрать одну или несколько путевок.
На рисунках 6 и 7 представлены логическая и физическая модели.
Рисунок 6 - Диаграмма логического уровня.
Рисунок 7 - Диаграмма физического уровня.
Литература
1 Замятина О.М. Моделирование систем. Учебное пособие. - Томск: Изд-во ТПУ 2009. - 204 с.
2 Аксенов К.А. Работа с CASE - средствами BPwin, ERwin. - Екатеренбург.: УГТУ-УПИ 2004 г.
3 Боброва Н.Л. Программа, методические указания и контрольные задания по дисциплине "Корпоративные информационные системы". Мн.: - ВГСК 2009.
Размещено на Allbest.ru
...Подобные документы
Анализ предметной области "строительная фирма". Обоснование прикладного программного обеспечения (CA ERwin Data Modeler) для моделирования процессов. Структурно-функциональная модель "Как есть" и "Как надо". Реализация модели помощью средств BPWin.
курсовая работа [539,5 K], добавлен 10.06.2014Характеристика и организационная структура компании. Описание ее бизнес-процессов. Разработка модели организации различных видов работ, осуществляемых в магазине при помощи BPWin. Ее стоимостной анализ. Построение логической диаграммы процессов в ERWin.
курсовая работа [1,2 M], добавлен 11.04.2015Построение функциональной модели IDEF0 средствами программного обеспечения BPWin. Произведение двухуровневой декомпозиции построенной диаграммы. Создание функциональной схемы программного продукта для учёта услуг, оказываемых "Интернет-центром".
лабораторная работа [339,7 K], добавлен 13.06.2014- Построение информационной модели предприятия пищевой промышленности АНО "Центр интернет-образования"
Функциональное моделирование IDEF0. Описание всех процессов работы отдела техподдержки. Декомпозиция контекстной диаграммы и основных процессов. Построение модели процессов предметной области в стандарте IDEF1Х. Интерфейс программы контроля трафика.
отчет по практике [1,8 M], добавлен 22.11.2014 Создание моделей процесса в BPwin, Aris Express, MS Visio, IBM Rational Rose и в соответствии с требованиями ГОСТ 19.701-90. Создание данных в Erwin и базы данных в MS Access. Расчет экономической эффективности реинжиниринга данного процесса в BPwin.
курсовая работа [2,3 M], добавлен 12.07.2015Проектирование и объектно-ориентированный анализ программного продукта для создания и поддержки составления генеалогического дерева. Морфологическая и функциональная модель системы, построение соответствующих диаграмм. Теория о BPWin и Microsoft Word.
курсовая работа [887,4 K], добавлен 27.08.2012Проектирование модели информационной системы "Гостиница" в стандарте IDEF0. Разработка диаграммы потоков данных (Data Flow Diagramming), предназначенной для описания документооборота и обработки информации. Создание диаграммы декомпозиции в нотации IDEF3.
курсовая работа [3,8 M], добавлен 14.12.2012Проектирование процесса материально-технического снабжения с помощью BPWin 4.0: разработка диаграммы декомпозиции, дерева узлов и потоков данных, контекстной диаграммы. Детализация бизнес-процесса. Выявление в модели AS-IS недостатков, их исправление.
курсовая работа [6,3 M], добавлен 14.12.2011Оформление диаграммы. Размещение и редактирование диаграммы. Построение диаграмм. Круговая диаграмма. Столбчатая диаграмма. Линейная диаграмма. Ярусная диаграмма. Областная диаграмма (диаграмма площадей). Индивидуальные работы.
реферат [12,3 K], добавлен 17.11.2002Проектирование модели информационной системы "Склад" с помощью AllFusion Process Modeler 4.1 (Bpwin4.1). Диаграмма дерева узлов AS-TO-BE и AS-IS. ER-диаграмма потоков данных "Сущность-связь". Физическо-логическая модель базы данных в нотации IDEF1X.
курсовая работа [2,4 M], добавлен 25.06.2014Создание информационной системы для автоматизации деятельности компании по регистрации доставки грузов транспортной компании. Анализ предметной области. Методология функционального моделирования IDEF0. Контекстная диаграмма. Стоимостный анализ в BPwin.
контрольная работа [222,5 K], добавлен 05.02.2014Выделение бизнес-процессов, контекстная диаграмма потоков данных. Разработка информационной системы, содержащей сведения о номерах гостиницы: категория, количество мест, стоимость проживания за сутки. Диаграммы декомпозиции в нотации DFD, IDEF3.
курсовая работа [3,0 M], добавлен 28.06.2011Построение функциональной и информационной моделей с использованием программ BPWin и ERWin. Описания интерфейса и элементов панели инструментов. Создание реляционной базы данных с помощью Microsoft Access. Разработка проекта федеральной целевой программы.
курсовая работа [703,3 K], добавлен 26.02.2014Разработка функциональной модели бизнес-процессов предприятия "Партнер", занимающегося продажей автомобилей, средствами BPwin. Построение контекстной диаграммы, охватывающей всю деятельность фирмы. Создание диаграмм декомпозиции, дерева узлов и FEO.
курсовая работа [1,1 M], добавлен 19.06.2012Создание модели бизнес-процессов "Распродажа" в ВPwin. Цели и правила распродажи. Прогнозирование бизнес-процессов ППП "Statistica". Методы анализа, моделирования, прогноза деятельности в предметной области "Распродажа", изучение ППП VIP Enterprise.
курсовая работа [2,4 M], добавлен 18.02.2012Моделирование процесса в нотациях IDEF, EPC, BPMN и в соответствии с требованиями ГОСТ 19.701-90. Описание предметной области. Формальное описание алгоритмов. Модель EPC, BPMN. Моделирование данных в нотации IDEF1X. Эффективность реинжиниринга процесса.
курсовая работа [1,2 M], добавлен 20.06.2015Разработка объектно-ориентированной модели ООО "Мир Компьютеров". Описание предметной области. Разработка функциональной модели системы средствами BPwin. Проектирование информационной системы средствами Rational Rose. Сопровождение информационных сетей.
курсовая работа [843,4 K], добавлен 07.01.2015Проектирование программного обеспечения. Построение контекстной диаграммы, концептуальной модели данных. Диаграмма потоков данных нулевого уровня, системных процессов нулевого уровня, последовательности экранных форм. Инструкция для пользователя.
курсовая работа [4,2 M], добавлен 17.03.2011Разработка функциональной и инфологической модели системы "Кадровый учет" с использованием индустриального проектирования CASE средств (BPWin и ERWin). Программная система позволяет упростить процесс проведения регистрации и учета сотрудников лицея.
дипломная работа [1,3 M], добавлен 28.06.2011Методика и основные этапы построения модели бизнес-процессов верхнего уровня исследуемого предприятия, его организационной структуры, классификатора. Разработка модели бизнес-процесса в IDEF0 и в нотации процедуры, применением Erwin Data Modeler.
курсовая работа [1,6 M], добавлен 01.12.2013