Фонд оценочных средств профессионального модуля
 Скачать 6.85 Mb.
|
FEO диаграммыFEO (For Exposition Only) диаграммы (другое название - диаграммы только для экспозиции, описания) используются для иллюстрации альтернативной точки зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. FEO диаграммы позволяют нарушить любое синтаксическое правило, посколько эти диаграммы - фактически обычные картинки - копии стандартных диаграмм. Например, работа на FEO диаграмме может не иметь стрелок выхода или управления. AllFusion Process Modeler позволяет также строить FEO диаграммы для диаграмм в нотации DFD. Для построения FEO диаграммы необходимо выбрать пункт меню Diagram -> Add FEO Diagram и в появившемся окне выбрать диаграмму, на базе которой будет строиться FEO диаграмма (рис. 1).  Рисунок 1. Добавление FEO диаграммы Созданная диаграмма будет точной копией родительской диаграммы и будет иметь номер, равный номеру родительской диаграммы + буква F. После создания диаграммы ее можно изменять. При этом изменения не будут влиять на родительскую диаграмму. Для просмотра списка имеющихся FEO диаграмм нужно выбрать в Обозревателе Модели (Model Explorer) вкладку Diagrams (рис.2).  Рисунок 2. Просмотр списка имеющихся FEO диаграмм Построим FEO диаграмму для диаграммы декомпозиции второго уровня А0 "Деятельность предприятия по сборке и продаже компьютеров и ноутбуков" и покажем на ней как дочерние работы связаны между собой. Для этого создаем диаграмму, как показано выше, и удаляем на ней все граничные стрелки. Итоговая FEO диаграмма показана на рис.3:  Рисунок 3. FEO диаграмм Диаграммы дерева узловДиаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. В одной модели диаграмм дерева узлов может быть множество, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня. Для построения диаграммы дерева узлов необходимо выбрать пункт меню Diagram -> Add Node Tree. Появляется мастер, с помощью которого диаграмма будет создана. На первом шаге (рис.4) задается имя диаграммы дерева узлов, узел верхнего уровня и глубина дерева. Имя дерева узлов по умолчанию совпадает с именем работы верхнего уровня, а номер диаграммы генерируется автоматически как номер узла верхнего уровня + буква N.  Рисунок 4. Создание диаграммы дерева узлов. Шаг 1 На втором шаге мастера (рис.5) задаются свойства диаграммы дерева узлов.  Рисунок 5. Создание диаграммы дерева узлов. Шаг 2 По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные работы - в виде прямоугольников. Если необходимо отобразить все дерево в виде прямоугольников, то следует снять галочку возле опции "Bullet last level". Список всех созданных диаграмм дерева узлов можно посмотреть в Обозреватели Модели. Диаграмма дерева узлов для всех узлов модели показана на рис. 6:  Рисунок 6. Диаграммы дерева узлов Содержание отчета: FEO диаграмма диаграмма дерева узлов Практическая работа №9 Расщепление и слияние моделей Цель работы: Изучить методы слияния и расщепления моделей, которые необходимы для обеспечения коллективной работы над проектом. Основные сведения Возможность слияния и расщепления моделей необходима для обеспечения коллективной работы над проектом. Так, руководитель проекта может создать декомпозицию верхнего уровня и дать задание аналитикам продолжить декомпозицию каждой ветви дерева в виде отдельных моделей. После окончания работы над отдельными ветвями все подмодели могут быть слиты в единую модель. С другой стороны, отдельная ветвь модели может быть отщеплена для использования в качестве независимой модели, для доработки или архивирования. Для слияния и разветвления моделейв BPwinиспользуются стрелки вызова. Расщепление модели Для отщепления ветви от модели следует щелкнуть правой кнопкой мыши по декомпозированной работе, например «Изготовление деталей» (работа не должна иметь диагональной черты в левом верхнем углу) и выбрать во всплывающем меню пункт SplitModel(рис. 4.1). В появившемся диалоге SplitOptionsследует указать имя создаваемой модели, например «Изготовление деталей». После подтверждения расщепления в старой модели работа станет недекомпозированной (признак - диагональная черта в левом верхнем углу), будет создана стрелка вызова (рис. 4.2), причем ее имя будет совпадать с именем новой модели, и, наконец, будет создана новая модель, причем имя контекстной работы будет совпадать с именем работы, от которой была «оторвана» декомпозиция, т.е. «Изготовление деталей» (рис. 4.3).  Рис. 4.1. Выбор режима расщепления модели  Рис. 4.2. Модель с отщепленной работой «Изготовление деталей»  Рис. 4.3. Представление новой модели «Изготовление деталей» в браузере Слияние моделей Что бы произвести слияние моделей необходимо выполнить следующие условия: э) обе сливаемые модели должны быть открыты в BPwin; ю) имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели (рис. 4.4);  Рис. 4.4. Условия слияния моделей я) стрелка вызова должна исходить из недекомпозируемой работы (работа должна иметь диагональную черту в левом верхнем углу) (рис. 4.5); аа) имена контекстной работы подсоединяемой модели-источника и работы на модели-цели, к которой мы подсоединяем модель-источник, должны совпадать (рис. 4.4); бб) модель-источник должна иметь, по крайней мере, одну диаграмму декомпозиции.  Рис. 4.5. Стрелка вызова работы «Сборка изделия» модели − цели Для слияния моделей необходимо выделить работу, с которой будет сливаться модель и правой кнопкой мыши вызвать контекстное меню. В контекстном меню выбрать пункт Merge Model.  Рис. 4.6. Выбор режима слияния моделей Появляется диалог, в котором следует указать опции слияния модели (рис. 4.7). При слиянии моделей объединяются и словари стрелок и работ. В случае одинаковых определений возможна перезапись определений или принятие определений из модели-источника. То же относится к именам стрелок, хранилищам данных и внешним ссылкам.  Рис.4.7.ДиалогContinue with merge? После подтверждения слияния (кнопка ОК) модель-источник подсоединяется к модели-цели, стрелка вызова исчезает, а работа, от которой отходила стрелка вызова, становится декомпозируемой – к ней подсоединяется диаграмма декомпозиции первого уровня модели-источника (рис. 4.8).  Рис. 4.8. Модель после слияния с моделью «Изготовление деталей» Стрелки, касающиеся работы на диаграмме модели-цели, автоматически не мигрируют в декомпозицию, а отображаются как неразрешенные. Их следует туннелировать вручную. На рис. 4.9 показано, как выглядят модели в окне ModelExplorerпосле слияния. Стрелкой показано, что модель склеилась с работой.  Рис.4.9. Вид моделей в ModelExplorerпосле слияния В процессе слияния модель-источник остается неизменной и к модели-цели подключается фактически ее копия. Не нужно путать слияние моделей с синхронизацией. Если в дальнейшем модель-источник будет редактироваться, эти изменения автоматически не попадут в соответствующую ветвь модели-цели. Практическая работа №10 Построение концептуальной схемы Цель практической работы: Научиться создавать концептуальную схему базы данных для решения конкретной экономической задачи в соответствии с индивидуальным вариантом. После выполнения практической работы студент должен: Знать: назначение концептуальной схемы в проектировании БД, методы создания схемы, рассмотреть пример создания концептуальной схемы с помощью модели “сущность-связь. Уметь: создать концептуальную схему для простейшей задачи. Пояснения к работе Порядок выполнения практической работы: 1. Проработать все описанные упражнения самостоятельно, руководствуясь методическими указаниями, 2. Выполнить задание, спроектировав концептуальную схему БД по своему индивидуальному варианту. 3. Проверить свои знания по контрольным вопросам и сдать практическую работу. Предварительная подготовка Трехуровневая архитектура БД. Различие между логическим и физическим представлением данных было официально признано в 1978 году. Тогда была предложена обобщенная структура систем баз данных. Эта структура получила название трехуровневой архитектуры БД, которая состоит из следующих уровней: концептуальный, внешний, внутренний Внешний уровень (модель)- составляют пользовательские представления данных. К БД обращаются много пользователей, но не Физическая структура БД Логическая схема БД одному пользователю не нужна вся БД в целом, а только её часть. Представления могут пересекаться. Каждое представление дает ориентированное на пользователя описание элементов данных. Объекты, атрибуты объектов, потоки и их направление, регламентные операции. Отсюда можно вывести концептуальную логическую схему (модель) БД. Концептуальный уровень –определяет логическую схему БД. Внутренний уровень(модель) – обеспечивает физический взгляд на БД. Ни один пользователь не касается этого уровня. СУБД и ОС преобразовывают адреса и указатели в соответствующие имена и отношения. Такой перевод стоит большой системной поддержке (как и по сложности, так и по цене). Концептуальная модель данных. С начала 70-х годов было предложено несколько концептуальных моделей данных. Например, двоичная семантическая модель данных, категорно-относительная модель Чена, функциональная модель данных, семантическая модель данных Хаммера и Мак Леода. Концептуальная модель БД легко преобразуется в реальные модели. Рис. 2 Преобразование концептуальной модели в реализуемую. Проектировщик БД, выбирая для своей системы конкретную СУБД, прежде всего, сталкивается с задачей выбора наиболее подходящей модели для своей прикладной области. При этом оцениваются следующие свойства модели данных СУБД: 1. сложность и трудоемкость программ для манипулирования данных; 2. сложность модели для изучения пользователем; 3. наглядность структуры данных; 4. модель должна иметь минимальное число базисных структур. Создание концептуальную модель БД рассмотрим на примере модели ”сущность-связь”. Ее отличает относительная простота, применение естественного языка, легкость понимания. Модель “сущность – связь”. Это неформальная модель предметной области, которая используется на этапе концептуального проектирования базы данных. Основное назначение модели – описание предметной области и представление информации для обоснования выбора видов моделей и структур данных. Существует несколько подходов к построению модели типа “сущность-связь”. Общим для всех подходов является использования нескольких элементов: сущность, атрибут, связь, время. Информация о проекте объединяется с помощью графических диаграмм. Сущность – это объект, процесс или явление, о котором необходимо хранить информацию в системе. В качестве объектов или сущностей рассматриваются материальные (предприятия, изделия) и нематериальные (счет, реферат) лексические или абстрактные (человек) объекты. Атрибут – это поименованная характеристика объекта или сущности, которая принимает значение из некоторого множества значений. Например: книга – объект. Атрибуты- название, автор и т. д. Основное назначение атрибута – описание свойства сущности, а также идентификация экземпляров сущностей. Связь – выступает в модели в качестве средства с помощью которого представляются отношения между сущностями. Анализ связей между сущностями показал, что могут встречаться бинарные (между двумя сущностями), тернарные (между тремя) и в общем случае n-арные связи. Информацию о проекте оформляют в виде диаграмм, для этого обозначают: типы сущностей- прямоугольниками, атрибуты- овалами, связи- ромбами соединяя их между собой. При моделировании предметной области проектировщик разбивает ее на ряд локальных областей, моделирует каждое локальное представление, а затем их объединяет. Объединение локальных представлений. Перед объединением необходимо решить вопрос о порядке объединения локальных представлений. Обычно используется бинарное объединение (попарное). Перед объединением необходимо выполнить группировку локальных представлений (по смыслу или подобию). При объединении используются следующие принципы: идентичность, агрегация, обобщение. Два или более элементов модели идентичны, если имеют одинаковое смысловое значение. Агрегация позволяет рассматривать связь между элементами модели как новый элемент (например, экзамен {фам_студента, наз_дисциплины, ФИО_препод, оценка} Обобщением называется объединение данных, позволяющее трактовать класс различных типов объектов как один поименованный обобщенный тип объекта. Например, гарнитур{стол, стул, шкаф} Проектирование схемы БД “Ресторан” Проектирование базы данных «Ресторан». Будет производиться на основе описания реального объекта – ресторана. Первый шаг проектирования базы данных для ресторана состоит в создании концептуальной модели данных, отвечающей практике ресторана. Задача проектирования состоит в определении требований к данным. Для этого необходимо поставить вопросы к данным. Например, необходимо решить каким образом будет производиться расчет прибыли? Из каких элементов она будет складываться? Каким образом будет осуществляться движение ингредиентов блюд? Как производится учет труда персонала его влияние на прибыль? Каким образом будет осуществляться компоновка меню? Каким образом будет подсчитываться дневная выручка и чистая прибыль? На основе этих данных можно будет проанализировать работу ресторана и тем самым увеличить прибыль. Исходя, из этих вопросов выделяются объекты предметной области, о которых нужно собрать информацию в БД. Это следующие объекты: Персонал, Заказ, Блюдо, Склад. Объекты также можно выделить исходя из тех форм, которые циркулируют в той или иной предметной области. Мы не можем опереться на этот подход, так как у нас форм нет. Составляем концептуальную модель данных, объекты на ней представляем в виде прямоугольников, свойства объектов в виде овалов. В представленной схеме модели данных показано, как объекты связаны друг с другом. Объекты представлены квадратами ,а отношения между ними отрезками. Символы «1» и «*» обозначают как именно они взаимодействуют. Отношения между объектами Персонал и Заказ(один ко многим): Каждый Служащий(официант) может выполнять один или нескольких Заказов (*). Каждый Заказ может состоять из одного или нескольких блюд (*).Отношение между объектом Заказ и Блюдо(один ко многим). Каждое блюдо может иметь несколько ингредиентов(*). Мы видим тип отношений: один-ко-многим, существует еще один тип отношения не представленный на схеме. Это отношение один-кодному. Задания В соответствии с индивидуальным вариантом создайте концептуальную схему базы данных. Варианты индивидуальных заданий: 1. Отделение коммерческого банка 2. Поликлиника 3. Колледж 4. Отделение полиции 5. Дизайнерская фирма 6. Офис интернет-провайдера 7. Агентство недвижимости 8. Туристическое агентство 9. Офис благотворительного фонда 10. Издательство 11. Рекламное агентство 12. Отделение налоговой службы 13. Редакция газеты 14. Гостиница 15. Праздничное агентство 16. Городской архив 17. Диспетчерская служба такси 18. Железнодорожная касса |