Добавлен: 25.10.2018
Просмотров: 5085
Скачиваний: 13
Это означает: результат обработки есть незаконченное задание, получаемое на каждом шаге выполнения задания, что в полной мере соответствует действительности.
Выявление интерфейсных ошибок. В IDEF-моделях сбои часто происходят в точках интерфейса. Для IDEF0 интерфейсными являются места соединения диаграмм со своими родителями. Поэтому каждую декомпозицию необходимо аккуратно соединять со своим родителем, используя ICOM-метки.
На примере декомпозиции в этой главе показан один из способов реализации этого подхода: прежде чем составлять список данных, необходимо записать имена и ICOM-коды для всех дуг, образующих границу. Это поможет при декомпозиции уменьшить вероятность пропуска части граничных дуг.
Выполнив декомпозицию, возвращаются назад к исходному блоку родительской диаграммы и соединяют каждую внешнюю дугу новой диаграммы с соответствующей дугой, касающейся этого блока. Это позволит избежать пропуска необходимого соединения.
Принципы и приемы расположения дуг. Дуги выражают связи между блоками. Их вычерчивают не для показа последовательности действий. Они отражают отношения между блоками, независящие от потенциального следования.
Например, диаграмма на рис. 1.10 не указывает возможной последовательности действий. В частности, функции выбрать инструменты может как встретиться, так и не встретиться перед функцией подготовить рабочее место. Это зависит от того, каким является следующий шаг задания. Если же оборудованное рабочее место уже создано, блок обработать на станке и собрать может выполняться неоднократно, пока не возникнет потребность в выполнении следующего шага задания. Такой механизм приводит к реализации различных сценариев, активизируя блоки в различные моменты времени в зависимости от ситуации.
Может случиться, что, начав рисовать дугу, возникнут сомнения в том, что она нужна на диаграмме. Но, не изобразив дугу при первом наброске диаграммы, возникает риск совершить ошибочный пропуск. Поскольку IDEF-диаграммы всегда проверяются другими специалистами и поскольку отсутствующую дугу никто не сможет обнаружить, изъятие сомнительной дуги с диаграммы - прямая дорога к возникновению ошибок и отсечению дополнительных возможностей.
Рекомендуется включать сомнительные дуги в диаграмму с вопросом об их необходимости адресованным читателям. Полученные в ответ комментарии, скорее всего, помогут разрешить возникшие сомнения. IDEF - дуги представляют собой наборы объектов и поэтому они потенциально могут нести много данных.
Например, сырье может быть просто стальным бруском, а может быть листами, рулонами, кусками дерева, пластика или различных металлов.
Опытные IDEF - аналитики не изображают каждый объект отдельной дугой. В крайнем случае, целесообразно давать определение новой дуги в глоссарии и, возможно, уточнять ее содержимое при декомпозиции тех блоков, которых она касается. Таким образом, предоставляется читателям достаточно информации для понимания сформированной диаграммы и не тратится много времени на избыточно подробное описание модели на слишком ранней стадии, что неизбежно привело бы в дальнейшем к большим переделкам.
2. Разработка моделей с использованием стандарта IDEF1X
IDEF1X (Integration Definition for Information Modeling) - это методология семантического моделирования данных.
Данная методология разработана с учетом следующих требований:
1. Поддерживает разработку концептуальных схем
Синтаксис IDEF1X поддерживает семантические конструкции, необходимые для разработки концептуальной схемы. Окончательная версия IDEFlX-модели обладает желаемыми характеристиками - непротиворечивостью, расширяемостью и адаптируемостью.
2. Обеспечивает ясный язык
IDEF1X имеет простую, ясную, непротиворечивую структуру и четкие семантические понятия. Синтаксис и семантика IDEF1X сравнительно легки для понимания, хотя и являются достаточно мощным средством.
3. Проста для изучения
Семантическое моделирование данных - новое понятие для многих пользователей IDEF1X. Проблема обучаемости этому языку является важным фактором. Язык рассчитан на понимание и использование как профессиональными бизнесменами и системными аналитиками, так и администраторами данных и разработчиками баз данных. Он может служить эффективным средством коммуникации в коллективах, состоящих из различных специалистов.
4. Возможность автоматизации
IDEFlX-диаграммы могут создаваться большим числом графических программных пакетов. Существует также коммерческое программное обеспечение, поддерживающее детализацию, анализ и управление конфигурацией IDEFlX-моделей.
IDEF1X использует подход сущностей-отношений к семантическому моделированию данных.
Исходная разработка IDEF1 заключалась в расширении понятий сущности-отношения по методу П. Ченна, объединенных с понятиями реляционной теории Т. Кодда. Кроме того, для улучшения графического представления и процедур моделирования IDEFlX-методология семантически обогащена введением отношений категоризации (называемых также отношениями обобщения).
Язык IDEF1X включает коммерческие разработки D.Appleton Company и The Database Design Group.
Основными конструкциями IDEFlX-модели являются:
1. Предметы, к которым относятся данные, т.е. люди, места, идеи, события и т.д. Они изображаются блоками.
2. Отношения между этими предметами, изображаемые соединяющими блоки линиями.
3. Характеристики этих предметов, изображаемые именами атрибутов внутри блоков.
Разработка модели в стандарте IDEF1X включает следующие этапы:
1. Планирование проекта.
2. Сбор данных.
3. Определение сущностей.
3. Определение отношений между сущностями.
5. Определение ключевых атрибутов (ключей).
6. Определение неключевых атрибутов (остальных атрибутов сущностей).
7. Проверка правильности модели.
8. Приемка модели
2.1. Планирование и подготовка работы над проектом/моделью
Стадия подготовки работы над проектом/моделью. IDEF1X-модель данных должна быть описана и определена в терминах как ее ограничений, так и целей.
Разработчик модели является одним из главных лиц при определении назначения модели. Вместе с руководителем проекта разработчик модели составляет план для достижения цели на стадии подготовки работы над проектом/моделью, которую иногда называют «стадией 0».
Эта цель включает:
-
Определение проекта - общая формулировка того, что должно быть сделано, почему и как это будет достигнуто.
-
Исходный материал - план сбора исходной информации, ее регистрация и структуризация.
-
Авторские соглашения - выбор основополагающих соглашений (методов), используемых автором при построении модели.
Реализация этого плана наряду с другой описательной и пояснительной информацией является результатом работы на стадии 0.
Определение цели моделирования
Установление цели моделирования охватывает два аспекта:
-
Определение направленности - утверждение охватываемых моделью вопросов, т.е. контекстуальных рамок.
-
Определение области действия - утверждение функциональных границ модели.
Одним из основных вопросов, на который при установлении цели моделирования должен быть дан ответ, является вопрос о временном интервале для модели: будет ли это модель существующей ситуации (т.е. "как есть" - модель) или модель того, что произойдет в результате задуманных изменений (т.е. "что должно быть" - модель).
Формальное описание проблемной области IDEFlX-проекта может включать обзор, построение, модификацию и выработку одной или нескольких (функциональных) IDEF0-моделей. По этой причине и автор, и руководитель проекта должны обладать некоторым опытом разработки и использования IDEF0-моделей. Обычно IDEF0-модель уже существует и может служить основой для описания проблемной области.
Хотя целью моделирования данных является установление объективной картины основной инфраструктуры данных всего предприятия, для каждой модели важно определить конкретную область действия. Это поможет выявить данные, представляющие особый интерес.
Область действия может быть связана с типом пользователя (например, покупатель или проектировщик), деловой функцией (например, выпуск технического чертежа или планирование организации цеха), типом данных (например, параметры конфигурации продукции или финансовая информация). Утверждение области действия и направленности модели определяет цель моделирования.
Приведем пример цели моделирования:
"Целью данной модели является определение текущих данных, используемых начальником производственного подразделения, для производства и проверки, сложных авиационных деталей".
Хотя область действия может быть ограничена одним типом пользователя, в процесс моделирования должны быть включены и другие пользователи для обеспечения объективной точки зрения.
2.2. Сбор данных
Одной из первых проблем, возникающих перед разработчиком модели, является определение, какого рода материалы необходимо получить и из каких источников.
Нередко область действия и контекст модели устанавливаются на основе анализа функциональной IDEF0-модели. Анализ функций и связей между ними выявляет целевые функции в пределах представляемого функциональной моделью предприятия.
Узел целевой функции - это узел, представляющий совокупность информации, репрезентативной для данной проблемной области.
После выявления областей целевых функций и выбора интересующих категорий первичной информации могут быть выбраны участники процесса сбора данных в пределах этих функций.
Такой сбор данных может осуществляться несколькими способами, включая опрос людей, обладающих информацией, наблюдение за деятельностью, анализ документов, линий поведения и процедур, применение специфических, информационных моделей и т.п.
Это требует отображения узлов целевых функций в их эквивалент, соответствующий участникам моделирования. После идентификации групп, участвующих в целевой функции, менеджер проекта может продолжить выявление лиц или заслуживающих внимания областей, которые могут использоваться в качестве источников информации для модели.
Исходный материал может иметь разнообразные формы и довольно широко распространяться по организации.
Он включает:
-
результаты опроса;
-
результаты наблюдения;
-
линии поведения и процедуры;
-
выходные данные существующих систем (отчеты и выборки);
-
входные данные для существующих систем (бланки входных данных и выборки);
-
спецификации баз данных и файлов для существующих систем.
Независимо от применяемых методов целью разработчика в этот момент является разработка план сбора репрезентативной документации, отражающей информацию, соответствующую цели и точке зрения модели. Полученная информация должна быть отмечена таким образом, чтобы можно было проследить ее источник. На различных стадиях разработки модели будут постоянные ссылки на эту документацию и на документацию, получаемую в процессе моделирования. Разработчик будет искать и изучать исходный материал, который может служить обоснованием структурных характеристик модели и смысла представленных данных.
Как отмечалось ранее, целью моделирования данных является определение единого, согласованного в рамках всего предприятия взгляда на ресурсы данных, что в принято называть концептуальной схемой.
Исходные документы, по большей части, представляют либо внешнюю, либо внутреннюю схемы, соответствующие концептуальной схеме, но более ориентированные на практическое использование.
Пользовательские отчеты, например, являются представлением данных из внешней схемы и могут служить исходной документацией.
Описания файлов и проекты баз данных соответствуют представлениям данных из внутренней схемы и также могут использоваться в качестве исходной документации.
Хотя в процессе моделирования структура данных существенно меняется, окончательная модель должна по-прежнему соответствовать внутренней и внешней схеме, на основе которых она построена.
Правильный план сбора данных имеет первостепенное значение для успешного достижения цели. Он должен отражать, какой тип данных является важным, где такие данные можно получить и кто их предоставит.