пособие курсового. Цели и задачи выполнения курсового проекта 4 Структура и содержание основных этапов курсового 5
 Скачать 103.67 Kb.
|
Рекомендации по моделированию предметных областейРекомендации по выполнению курсового проекта работы по тематике «Разработка функциональных моделей с помощью метода IDEF0» Задача по разработке модели процесса с помощью метода моделирования бизнес-процессов IDEF0 реализуется с помощью программного продукта CA ERwin Modeling Suite (CA ERwin Process Modeler (BPwin) в нотации IDEF0. Результатом выполнения задачи является модель соответствующего процесса в нотации IDEF0. Метод IDEF0 – метод создания функциональной модели, которая является структурированным изображением функций производственной системы или среды, а также информации и объектов, связывающих эти функции. Полученная модель позволяет сформировать архитектуру среды моделируемой системы. Под средой понимаются системы, организации или технологии, которые должны работать совместно для достижения общей цели производственной среды или системы. Назначение модели заключается в том, что она графически представляет основные взаимоотношения в среде моделируемой системы – функциональные связи, идентификацию информационных потоков. IDEF-модель становится архитектурой только тогда, когда она используется для более глубокого понимания и анализа не только производственной системы и ее окружения, но и того, как ее компоненты взаимодействуют друг с другом. В качестве нотации (языка моделирования) был выбран «метод блочного моделирования», в котором «блок» определен как производственная ячейка или функциональная единица. IDEF0-методология основана на следующих концепциях: Графическое представление блочного моделирования. Графика «блоков и дуг» IDEF0-диаграммы отражают производственную операцию в виде блока, а интерфейсы входа/выхода в/из операции представляются дугами, соответственно входящими в блок или выходящими из него. Для того чтобы иметь возможность описывать производственные операции, существующие в реальности, было предложено описывать взаимодействие блоков друг с другом посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом операции выполняются и управляются. Краткость. Документация архитектуры производственной системы для полного охвата материала должна быть точной. Двумерная форма графического языка имеет требуемую точность без потери возможности выразить такие взаимоотношения, как интерфейс, обратная связь, ошибочные пути. Передача информации. В IDEF0 существует ряд средств, разработанных для улучшения передачи информации: диаграммы, основанные на очень простой графике блоков и дуг; метки на естественном языке для описания блоков и дуг, а также глоссарий и сопроводительный текст для определения точного значения элементов диаграммы; постепенное представление деталей, при котором на верхнем уровне иерархии показаны основные функции, а на следующих уровнях происходит их более подробное уточнение; система узлов в иерархии диаграмм, обеспечивающая возможность легко составить перечень (индекс) размещенных на них деталей; ограничение каждой диаграммы шестью подфункциями для облегчения чтения. Строгость и точность. Выполнение правил IDEF0 требует достаточной строгости и точности, чтобы удовлетворить принципам архитектуры ICAM, не накладывая в то же время чрезмерных ограничений на аналитика. Правила IDEF0 включают: ограничение количества деталей на каждом уровне (правило 3-6 блоков); ограниченный контекст (без пропусков, но и без дополнительных деталей, выходящих за рамки рассмотрения); связность интерфейса диаграмм (номера узлов, номера блоков, C-номера); связность структуры данных (ICOM-коды и использование туннельных дуг); уникальность меток и наименований (отсутствие повторяющихся имен); синтаксические правила для графики (блоков и дуг); ограничение на ветвление дуг данных (метки для ограничений потоков данных на ветвях); разделение входов и управлений (правило определения роли данных); требования к меткам дуг данных (правила минимальных меток); минимальное управление для функций (для каждой функции нужна, по крайней мере, одна управляющая дуга; цель и точка зрения (у каждой модели есть цель и точка зрения). Методология. Пошаговые процедуры обеспечивают моделирование, рецензирование и решение задач интеграции. «Организация» из «функций». Отделение организации от функций включено в цель модели и осуществляется отбором имен функций и связей в процессе разработки модели. Постоянное рецензирование в ходе создания модели помогает избежать точки зрения, навязанной организацией. Функциональная модель представляет с нужной степенью точности систему функций, которые в свою очередь отражают свои взаимоотношения через предметы системы. Модели данных двойственны к функциональным моделям и представляют собой подробное описание предметов системы, связанных системными функциями. Основным рабочим элементом при моделировании является диаграмма. В состав диаграммы входят блоки, изображающие функции моделируемой системы, и дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками. Методология IDEF0 требует, чтобы в диаграмме было 3-6 блоков; в этих пределах диаграммы и модели удобны для чтения, понимания и использования. Вместо одной громоздкой модели используют несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуру сложного объекта. Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстами на естественном языке, описывающим функции. При этом каждая сторона блока имеет вполне определенное назначение: левая сторона предназначена для Входов (Input – I), верхняя – для Управления (Control – C), правая – для Выходов (Output – O), нижняя – для Механизмов (Исполнителей) (Mechanism – M). Модель IDEF0 представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы. Построение IDEF0-модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы (рис. 1). Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг – они также представляют полный набор внешних интерфейсов системы в целом.  Рисунок 1. Пример IDEF0-диаграммы (контекстный блок) Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами (рис. 2). Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.  Рисунок 2. Декомпозиция диаграммы (контекстного блока) Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются теми же, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Такое обозначение отражает определенные принципы функционирования системы: Входы преобразуются в Выходы, Управления ограничивают или предписывают условия выполнения, Механизмы описывают, за счет чего выполняются преобразования. Дуги в IDEF0 представляют наборы предметов (данных) и маркируются текстами на естественном языке. Данные могут состоять с функциями в четырех возможных отношениях: Вход, Выход, Управление, Механизм. Каждое из этих отношений изображается дугой, связанной с определенной стороной блока. Входные дуги изображают данные, используемые и преобразуемые функциями. Управляющие дуги изображают информацию, управляющую действиями функций. Выходные дуги изображают данные, в которые преобразуются входы. Дуги механизмов отражают методы и способы реализации функций. Блоки на диаграмме размещаются на «ступенчатой» схеме в соответствии с их доминированием, которое понимается как влияние, оказываемое одним блоком на другие. Кроме того, блоки должны быть пронумерованы в соответствии с их доминированием. Номера блоков служат однозначными идентификаторами для функций и автоматически организуют эти функции в иерархическую модель. Взаимовлияние блоков может выражаться либо в пересылке Выхода к другой функции для дальнейшего преобразования, либо в выработке управляющей информации, предписывающей, что именно должна делать другая функция. Таким образом, диаграммы IDEF0 являются предписывающими диаграммами, описывающими как преобразования между Входом и Выходом, так и предписывающие правила этих преобразований. Создание функциональных моделей и диаграмм происходит в следующей последовательности: Сбор информации. Декомпозиция объекта исследования. Моделирование: Выбор цели и точки зрения. Составление списка данных. Составление списка функций. Построение и обобщение диаграммы А0(А0 – А-0). Декомпозиция ограниченного объекта. Итерационный процесс рецензирования. Завершение моделирования. Документирование. Сбор информации может включать любую комбинацию следующих видов деятельности: чтение документов, наблюдение за существующими операциями, анкетирование группы экспертов, опрос одного или нескольких экспертов, использование собственных знаний и придуманного описания работы системы, которое впоследствии может быть откорректировано. Декомпозируя объект, необходимо, прежде всего, обратить внимание на входные и выходные данные всей системы. Декомпозиция всей системы начинается с составления списка основных типов данных и основных функций системы. Делая это, мы мысленно просматриваем основные функции системы, учитывая все нормальные и аномальные ситуации, обратные связи и случаи возможных ошибок. Эти списки снабжаются комментариями. Списки с комментариями используются для создания диаграммы А0, которая затем обобщается с помощью диаграммы А-0. Начало моделирования означает создание диаграмм А0 и А-0, которые затем могут быть отрецензированы. Эти две диаграммы полностью рассказывают все об изучаемой системе с минимальной степенью детализации. Прежде чем начать моделирование, необходимо подготовиться к нему, собрать информацию, декомпозировать объект исследования (декомпозиция – диаграмма А0 освещает наиболее важные функции и объекты системы), затем обобщить эту декомпозицию (диаграмма А-0 трактует систему как черный ящик, дает ей название и определяет наиболее важные входы, управления, выходы и механизмы). Цель и точка зрения модели определяются на самой ранней стадии создания модели. Выбор цели осуществляется с учетом вопросов, на которые должна ответить модель, а выбор точки зрения – в соответствии с выбором позиции, с которой описывается модель. Если выбор цели и точки зрения затруднен, то можно вначале построить диаграммуА0 и с ее помощью установить это. Иногда приходится строить несколько альтернативных диаграмм А-0 для достаточной уверенности в правильности выбранной цели и точки зрения. Помочь могут списки данных и списки функций. При этом лучше, если данных больше, чем меньше. Данные можно сразу группировать по типам. Функции системы тоже лучше объединить по типу используемых данных. Затем функции объединяются в группы (от 3 до 6) Желательно, чтобы эти группы имели один и тот же уровень сложности, содержали примерно одинаковый объем действий и функции в каждой из них имели сходные операции и цели. Исходное содержание диаграммы А0 обеспечивают списки данных и функций. Вначале изображаются блоки в соответствии с их доминированием. Затем основные дуги, представляющие ограничения. Эти дуги всегда являются внешними, так как представляют данные, поступающие из непосредственного окружения системы. Далее размещаются остальные внешние дуги и назначаются соответствующие им ICOM-коды. В завершение изображаются все оставшиеся дуги. Как правило, невозможно сразу без черновика нарисовать диаграмму. Поэтому ее перерисовывают (рисуют несколько версий). Обобщение является последним важным шагом начального этапа моделирования. Для любой IDEF0 – диаграммы есть родительская диаграмма, содержащая ее контекст. Контекстом для А0 служит А-0, представляющая обобщение всей модели. Эта диаграмма имеет несколько назначений: она объявляет общую функцию всей системы, дает множество основных типов или наборов данных, которые использует или производит система, указывает взаимоотношения между основными типами данных, производя их разграничение. Для построения А-0 в центре бланка рисуют один большой блок, название которого совпадает с названием диаграммы А0. Все внешние дуги диаграммы А0 изображаются на диаграмме А-0 входящими в соответствующую сторону блока. Далее на диаграмме выписываются цель и точка зрения модели. Продолжение моделирования (декомпозиция ограниченного объекта) основывается на тех же методах и выводит модель на следующий уровень детализации. Этот процесс является рекурсивным. Начало процесса декомпозиции заключается в выборе блока рассматриваемой диаграммы и рассмотрении объекта, определяемого этим блоком и его дугами. При этом надо учесть, что рассматривать следует в первую очередь такой блок, декомпозиция которого выявит многие аспекты диаграммы А0 и будет оказывать большее влияние на будущие декомпозиции других блоков этой системы. При выборе самого содержательного блока нужно учесть и доминирование, и функциональную сложность, и понятность. Лучшим блоком для первой декомпозиции будет тот, который позволит наиболее глубоко проникнуть в суть рассматриваемой системы. Детализация блока производится путем составления списка данных и списка функций и последующего построения диаграммы. Если вы сомневаетесь, стоит ли включать некоторые блоки и дуги в диаграмму, то лучше ее включить, снабдив соответствующими записями. Следующий этап – рецензирование созданной модели автором. После проверки пытаются построить альтернативные декомпозиции, которые могли бы лучше выразить нужную информацию. При этом даже если альтернативные декомпозиции хуже исходной, они позволяют лучше понять функционирование системы путем объединения и разъединения функций и данных. В результате этой работы могут быть внесены изменения как в новую (дочернюю), так и в родительскую диаграммы. Одна из самых важных проблем, возникающих при моделировании, – когда следует завершить построение конкретной модели. IDEF0-модели иерархичны, поэтому их размер может увеличиваться со скоростью геометрической прогрессии. Хотя многие IDEF0-модели имеют глубину 5-6 уровней, они чаще всего состоят не более чем из нескольких десятков диаграмм. Декомпозиция модели или ее части прекращается, если модель достигла уровня детализации, достаточного для достижения цели. Декомпозиция блока может быть прекращена, если окажется, что функции блока очень сходны с другой частью модели, которая уже декомпозирована. Таким образом, достаточность деталей, изменение уровня абстракции, изменение точки зрения и сходная функциональность являются основными критериями для прекращения декомпозиции. Рекомендации по выполнению курсовой работы по тематике «Разработка информационных моделей данных с помощью метода IDEF1X» Задача по разработке информационной модели с помощью метода моделирования IDEF1X реализуется с помощью программного продукта CA ERwin Modeling Suite (CA ERwin Data Modeler (EPwin) в нотации IDEF1X. Результатом выполнения задачи является модель сущность – связь в нотации IDEF1X. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы и решение о внедрении реляционной базы данных, как части информационной системы, было принято. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. Построение концептуальной модели базы данных в нотации IDEF1X поддерживает CASE средство ERwin. Первым шагом при создании логической модели является создание диаграммы зависимостей сущностей (Entity Relationship Diagram, ERD) – модели данных высокого уровня. Модель сущность - связь состоит из трех основных блоков: сущностей, атрибутов и связей. Основная задача ERD – оценить, какие требования к бизнес-информации будут достаточными для обеспечения нужд планирования разработки информационной системы. Эти модели не очень подробны (включены только основные сущности), атрибуты тоже слабо детализируются. Разрешены отношения многие – ко – многим, ключи, как правило, не включаются. Эта модель, в основном, предназначена для презентации и обсуждения. На рис. 3 показан пример диаграммы зависимостей сущности.  Рисунок 3. Пример диаграммы зависимостей сущностей Так же, как таблицы и колонки образуют физическую модель реляционной базы данных, диаграмма зависимостей сущностей (и другие логические модели) включает в себя компоненты, которые позволяют смоделировать структуры данных. Логическим эквивалентом таблицы является сущность, а логическим эквивалентом колонки является атрибут. На рис. 4 представлена диаграмма сущность - связь с атрибутами.  Рисунок 4. Пример диаграммы сущность - связь с атрибутами В такой модели названия сущностей могут быть только в единственном числе – сотрудник (а не сотрудники), отдел (а не отделы). Взаимосвязи между таблицами являются важными компонентами реляционных баз данных. Эти связи создаются за счет использования общих ключей, т.е. записи в одной таблице ссылаются на записи в другой таблице. Связь между двумя сущностями также включает то, что факты одной сущности ссылаются или ассоциированы с фактами другой сущности. Так, на рис. 4 информация о сотруднике и отделе взаимосвязана, и эта связь может быть выражена так: В Отделе работают один или более Сотрудников. Сущность служит для представления набора реальных или абстрактных предметов (людей, мест, событий и т.п.), которые обладают общими атрибутами или характеристиками. Сущность в ERwin обычно описывается тремя компонентами: тип сущности, атрибуты, являющиеся первичными ключами, неключевые атрибуты. ERwin имеет два типа сущностей: независимые и зависимые. Независимая сущность –это сущность, экземпляры которой могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью. Зависимая сущность –это сущность, экземпляры которой не могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью или сущностями.   (а) (б) Рисунок 5. Зависимая (а) и независимая (б) сущность Сущности могут быть определены в виде какого-либо лица, места, предмета, события, о которых содержится соответствующая информация. Сущность можно представлять как набор отдельных экземпляров (записей). Экземпляр – это конкретная реализация сущности. Каждый экземпляр должен быть отличен от остальных. На рис. 5 каждый экземпляр сущности Сотрудник содержит следующую информацию: Id_сотрудика, ФИО_сотрудника, Должность, ИНН, Квалификация. В логической модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности. Связь – является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases) Связи играют роль ссылок, соединений и ассоциаций между сущностями. Простые для понимания правила помогают определять ограничения, накладываемые на данные, а также точно определять атрибуты связей. Примером связи может быть: Отдел <состоит из > Сотрудник.  Рисунок 6. Пример связи между сущностями В этом примере взаимосвязи между сущностями соответствуют схеме один – ко – многим. Это означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Причем первая сущность называется родительской, а вторая – дочерней. Взаимосвязи отображаются в виде линии между двумя сущностями с точкой на одном конце и глагольной фразой, отображаемой над линией. В данном случае используются связь идентифицирующего типа один – ко – многим. Отношение многие – ко – многим, также называемое неопределенным отношением, отображает ситуацию, когда экземпляр в одной сущности относится к одному или нескольким экземплярам второй сущности, а экземпляр во второй сущности относится к одному или нескольким экземплярам первой сущности. Отношения многие – ко – многим обычно используются на начальной стадии разработки диаграммы, например, в диаграмме зависимости сущностей (ERD) и отображаются в IDEF1X в виде сплошной линии с точками на обоих концах. Основными объектами физической модели являются таблицы и колонки. ERwin автоматически создает имена таблиц и колонок на основе имен соответствующих сущностей и атрибутов, учитывая максимальную длину имени и другие синтаксические ограничения, накладываемые СУБД. При генерации имени таблицы и колонки по умолчанию все пробелы преобразуются в символы подчеркивания, а длина имени сокращается до максимально возможной длины. Физическая модель в ERwin имеет три основных уровня представлений: табличное представление (Table view): содержит таблицы с наименованиями и связями; табличное представление с комментариями (Comments view): дополнительно содержит комментарии к таблицам; представление колонок таблиц (Column view): содержит таблицы и названия колонок в таблицах. ERwin – не только лучший инструмент для проектирования баз данных, но и средство для их быстрого создания. ERwin оптимизирует модель в соответствии с физическими характеристиками целевой базы данных. В отличие от других инструментальных средств ERwin автоматически поддерживает согласованность логической и физической схем и осуществляет преобразование логических конструкций, таких как отношения многие – ко – многим, в их реализацию на физическом уровне. Процесс построения информационной модели состоит из следующих этапов: Создание логической модели данных: определение сущностей; определение зависимостей между сущностями; задание первичных и альтернативных ключей; определение не ключевых атрибутов сущностей. Переход к физическому описанию модели: назначение соответствий имя сущности – имя таблицы, атрибут сущности – атрибут таблицы; задание триггеров, хранимых процедур и ограничений. Генерация базы данных. |