Текст книги "Современные концепции управления предприятием"

Отдел <состоит из> нескольких Сотрудников

Самолет <перевозит> нескольких Пассажиров.

Сотрудник <пишет> разные Отчеты.

Во всех перечисленных примерах взаимосвязи между сущностями соответствуют схеме один ко многим. Это означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Причем первая сущность называется родительской, а вторая – дочерней. В приведенных примерах глаголы заключены в угловые скобки. Связи отображаются в виде линии между двумя сущностями с точкой на одном конце и глагольной фразой, отображаемой над линией. На рис. 1.3.6 приводится диаграмма связи между Сотрудником и Отделом.

Рис. 1.3.6. Диаграмма связи между Сотрудником и Отделом

Отношения многие ко многим обычно используются на начальной стадии разработки диаграммы, например, в диаграмме зависимости сущностей и отображаются в IDEF1X в виде сплошной линии с точками на обоих концах. Так как отношения многие ко многим могут скрыть другие бизнес правила или ограничения, они должны быть полностью исследованы на одном из этапов моделирования. Например, иногда отношение многие ко многим на ранних стадиях моделирования идентифицируется неправильно, на самом деле представляя два или несколько случаев отношений один-ко– многим между связанными сущностями. Или, в случае необходимости хранения дополнительных сведений о связи многие-ко-многим, например, даты или комментария, такая связь должна быть заменена дополнительной сущностью, содержащей эти сведения. При моделировании необходимо быть увереным в том, что все отношения многие ко многим будут подробно обсуждены на более поздних стадиях моделирования для обеспечения правильного моделирования отношений.

Идентификация сущностей. Представление о ключах.

Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. На рис. 1.3.7 приведен пример IDEF1X диаграммы. Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены неключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных. Ключевая область объекта СОТРУДНИК содержит поле «Уникальный идентификатор сотрудника», в области данных находятся поля «Имя сотрудника», «Адрес сотрудника», «Телефон сотрудника» и т.д.

Ключевая область содержит первичный ключ для сущности. Первичный ключ – это набор атрибутов, выбранных для идентификации уникальных экземпляров сущности. Атрибуты первичного ключа располагаются над линией в ключевой области. Как следует из названия, неключевой атрибут – это атрибут, который не был выбран ключевым. Неключевые атрибуты располагаются под чертой, в области данных.

При создании сущности в IDEF1X модели, одним из главных вопросов, на который нужно ответить, является: "Как можно идентифицировать уникальную запись?". Для этого требуется уникальная идентификация каждой записи в сущности для того, чтобы правильно создать логическую модель данных. Напомним, что сущности в IDEF1X всегда имеют ключевую область и, поэтому в каждой сущности должны быть определены ключевые атрибуты.

Выбор первичного ключа для сущности является очень важным шагом, и требует большого внимания. В качестве первичных ключей могут быть использованы несколько атрибутов или групп атрибутов. Атрибуты, которые могут быть выбраны первичными ключами, называются кандидатами в ключевые атрибуты (потенциальные атрибуты). Кандидаты в ключи должны уникально идентифицировать каждую запись сущности. В соответствии с этим, ни одна из частей ключа не может быть NULL, не заполненной или отсутствующей.

Например, для того, чтобы корректно использовать сущность СОТРУДНИК в IDEF1X модели данных (а позже в базе данных), необходимо иметь возможность уникально идентифицировать записи. Правила, по которым вы выбираете первичный ключ из списка предполагаемых ключей, очень строги, однако могут быть применены ко всем типам баз данных и информации. Правила устанавливают, что атрибуты и группы атрибутов должны:

• Уникальным образом идентифицировать экземпляр сущности.

• Не использовать NULL значений.

• Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.

• Быть как можно более короткими для использования индексирования и получения данных. Если вам нужно использовать ключ, являющийся комбинацией ключей из других сущностей, убедитесь в том, что каждая из частей ключа соответствует правилам.

Рис. 1.3.7. Пример IDEF1X диаграммы

Для наглядного представления о том, как целесообразно выбирать первичные ключи, приведем следующий пример – выберем первичный ключ для знакомой нам сущности «СОТРУДНИК»:

• Атрибут "ID сотрудника" является потенциальным ключом, так как он уникален для всех экземпляров сущности СОТРУДНИК.

• Атрибут "Имя сотрудника" не очень хорош для потенциального ключа, так как среди служащих на предприятии может быть, к примеру, двое Иванов Петровых.

• Атрибут "Номер страхового полиса сотрудника" является уникальным, но проблема в том, что СОТРУДНИКА может не иметь такового.

• Комбинация атрибутов "имя сотрудника" и "дата рождения сотрудника" может оказаться удачной для наших целей и стать искомым потенциальным ключом.

После проведенного анализа можно назвать два потенциальных ключа – первый "Номер сотрудника" и комбинация, включающая поля "имя сотрудника" и "Дата рождения сотрудника". Так как атрибут "Номер сотрудника" имеет самые короткие и уникальные значения, то он лучше других подходит для первичного ключа.

При выборе первичного ключа для сущности, разработчики модели часто используют дополнительный (суррогатный) ключ, т.е. произвольный номер, который уникальным образом определяет запись в сущности. Атрибут "Номер сотрудника" является примером суррогатного ключа. Суррогатный ключ лучше всего подходит на роль первичного ключа потому, что является коротким и быстрее всего идентифицирует экземпляры в объекте. К тому же суррогатные ключи могут автоматически генерироваться системой так, чтобы нумерация была сплошной, т.е. без пропусков.

Потенциальные ключи, которые не выбраны первичными, могут быть использованы в качестве вторичных или альтернативных ключей. С помощью альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы.

Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими.

Классификация сущностей в IDEF1X. Зависимые и независимые сущности.

При разработке модели, зачастую, приходится сталкиваться с сущностями, уникальность которых зависит от значений атрибута внешнего ключа. Для этих сущностей (для уникального определения каждой сущности) внешний ключ должен быть частью первичного ключа дочернего объекта.

Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью. В примере на рис. 1.3.7 сущность СОТРУДНИК является зависимой сущностью потому, что его идентификация зависит от сущности ОТДЕЛ. В обозначениях IDEF1X зависимые сущности представлены в виде закругленных прямоугольников.

Зависимые сущности далее классифицируются на сущности, которые не могут существовать без родительской сущности и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Сущность СОТРУДНИК принадлежит ко второму типу зависимых сущностей, так как сотрудники могут существовать и без отдела. Напротив, существуют ситуации в которых сущность зависит от существования другой сущности. Рассмотрим две сущности: ЗАПРОС, используемый для отслеживания запросов покупателей, и ПОЗИЦИЯ ЗАПРОСА, который отслеживает отдельные элементы в ЗАПРОСе. Связь между этими двумя сущностями может быть выражена в виде ЗАПРОС <содержит> один или несколько ПОЗИЦИЙ ЗАПРОСА. В этом случае, ПОЗИЦИЯ ЗАПРОСА зависит от существования ЗАКАЗА.

Сущности, независящие при идентификации от других объектов в модели, называются независимыми сущностями. В вышеописанном примере сущность ОТДЕЛ можно считать независимой. В IDEF1X независимые сущности представлены в виде прямоугольников.

Типы связей между сущностями. Идентифицирующие и неидентифицирующие связи.

В IDEF1X концепция зависимых и независимых сущностей усиливается типом взаимосвязей между двумя сущностями. Если вы хотите, чтобы внешний ключ передавался в дочернюю сущность (и, в результате, создавал зависимую сущность), то можете создать идентифицирующую связь между родительской и дочерней сущность.

Идентифицирующие взаимосвязи обозначаются сплошной линией между сущностями.

Неидентифицирующие связи, являющиеся уникальными для IDEF1X, также связывают родительскую сущность с дочерней. Неидентифицирующие связи используются для отображения другого типа передачи атрибутов внешних ключей – передача в область данных дочерней сущности (под линией).

Неидентифицирующие связи отображаются пунктирной линией между объектами. Так как переданные ключи в неидентифицирующей связи не являются составной частью первичного ключа дочерней сущности, то этот вид связи не проявляется ни в одной идентифицирующей зависимости. В этом случае и ОТДЕЛ, и СОТРУДНИК рассматриваются как независимые сущности.

Тем не менее, взаимосвязь может отражать зависимость существования, если бизнес правило для взаимосвязи определяет то, что внешний ключ не может принимать значение NULL. Если внешний ключ должен существовать, то это означает, что запись в дочерней сущности может существовать только при наличии ассоциированной с ним родительской записи.

Преимущества IDEF1X

Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая несомненно является значительным недостатком ER.

Предназначение IDEF3

IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием (Scenario) мы называем описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

• Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса.

• Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов.

• Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта.

• Содействовать принятию оптимальных решений при реорганизации технологических процессов.

• Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ…"

Два типа диаграмм в IDEF3

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму – диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.

На следующем примере, опишем, как графические средства IDEF3 позволяют документировать вышеуказанный производственный процесс окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку.

Рис. 1.3.8. Пример PFDD диаграммы

На рис. 1.3.8 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса. Линии бывают следующих видов:

– Старшая (Precedence) – сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз.

– Отношения (Relational Link) – пунктирная линия, использующаяся для изображения связей между UOB

– Потоки объектов (Object Flow) – стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.

Объект, обозначенный J1 – называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.

Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице 1.3.1

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J".

Таблица 1.3.1. Классификация возможных типов перекрестков

Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

Деталь поступает в окрасочный цех, подготовленной к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки.

Если диаграммы PFDD технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис. 1.3.9 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

Рис. 1.3.9. Пример OSTN диаграммы

Исторически, понятие онтологии появилось в одной из ветвей философии, называемой метафизикой, которая изучает устройство реального мира. Основной характерной чертой онтологического анализа является, в частности, разделение реального мира на составляющие и классы объектов (at its joints) и определение их онтологий, или же совокупности фундаментальных свойств, которые определяют их изменения и поведение. Таким образом, естественная наука представляет собой типичный пример онтологического исследования. Например, атомная физика классифицирует и изучает свойства наиболее фундаментальных объектов реального мира, таких как элементарные частицы, а биология, в свою очередь, описывает характерные свойства живых организмов, населяющих планету.

Однако фундаментальные и естественные науки не обладают достаточным инструментарием для того, чтобы полностью охватить область, представляющую интерес для онтологического исследования. Например, существует большое количество сложных формаций или систем, созданных и поддерживаемых человеком, таких как производственные фабрики, военные базы, коммерческие предприятия и т.д. Эти формации представляют собой совокупность взаимосвязанных между собой объектов и процессов, в которых эти объекты тем или иным образом участвуют. Онтологическое исследование подобных сложных систем позволяет накопить ценную информацию об их работе, результаты анализа которой будут иметь решающее мнение при проведении процесса реорганизации существующих и построении новых систем.

Методология IDEF5 обеспечивает наглядное представление данных, полученных в результате обработки онтологических запросов в простой естественной графической форме.

Основные принципы онтологического анализа

Онтологический анализ обычно начинается с составления словаря терминов, который используется при обсуждении и исследовании характеристик объектов и процессов, составляющих рассматриваемую систему, а также создания системы точных определений этих терминов. Кроме того, документируются основные логические взаимосвязи между соответствующими введенным терминам понятиями. В дальнейшем мы не будем делать различия между понятиями и терминами. Результатом этого анализа является онтология системы, или же совокупность словаря терминов, точных их определений взаимосвязей между ними.

Таким образом, онтология включает в себя совокупность терминов и правила, согласно которым эти термины могут быть скомбинированы для построения достоверных утверждений о состоянии рассматриваемой системы в некоторый момент времени. Кроме того, на основе этих утверждений, могут быть сделаны соответствующие выводы, позволяющие вносить изменения в систему, для повышения эффективности её функционирования.

В любой системе существует две основные категории предметов восприятия, такие как сами объекты, составляющие систему (физические и интеллектуальные) и взаимосвязи между этими объектами, характеризующие состояние системы. В терминах онтологии, понятие взаимосвязи, однозначно описывает или, другими словами, является точным дескриптором зависимости между объектами системы в реальном мире, а термины – являются, соответственно, точными дескрипторами самих реальных объектов.

При построении онтологии, в первую очередь происходит создание списка или базы данных дескрипторов и с помощью них, если их набор достаточен, создается модель системы. Таким образом, на начальном этапе должны быть выполнены следующие задачи:

1) Создание и документирования словаря терминов.

2) Описание правил и ограничений, согласно которым на базе введенной терминологии формируются достоверные утверждения, описывающие состояние системы.

3) Построение модели, которая на основе существующих утверждений, позволяет формировать необходимые дополнительные утверждения.

Что мы имеем в виду под необходимыми дополнительными утверждениями? Дело в том, что при рассмотрении каждой системы существует огромное количество утверждений, достоверно отображающих ее состояние в различных разрезах, а построенная онтологическим способом модель должна выбирать из них наиболее полезные для эффективного рассмотрения в том или ином контексте. Дополнительно, эта модель помогает описывать поведение объектов и соответствующее изменение взаимосвязей между ними, или, другими словами, поведение системы. Таким образом, онтология представляет собой некий словарь данных, включающий в себя и терминологию и модель поведения системы.

Концепции IDEF5

Процесс построения онтологии, согласно методологии IDEF5 состоит из пяти основных действий:

1) Изучение и систематизирование начальных условий. Это действие устанавливает основные цели и контексты проекта разработки онтологии, а также распределяет роли между членами проекта.

2) Сбор и накапливание данных. На этом этапе происходит сбор и накапливание необходимых начальных данных для построения онтологии.

3) Анализ данных. Эта стадия заключается в анализе и группировке собранных данных и предназначена для облегчения построения терминологии.

4) Начальное развитие онтологии. На этом этапе формируется предварительная онтология, на основе отобранных данных.

5) Уточнение и утверждение онтологии – Заключительная стадия процесса.

Язык описания онтологий в IDEF5

Для поддержания процесса построения онтологий в IDEF5 существуют специальные онтологические языки: схематический язык (Schematic Language-SL) и язык доработок и уточнений (Elaboration Language-EL). SL является наглядным графическим языком, специально предназначенным для изложения компетентными специалистами в рассматриваемой области системы основных данных в форме онтологической информации (См. рисунок 1.3.10). Этот несложный язык позволяет естественным образом представлять основную информацию в начальном развитии онтологии и дополнять существующие онтологии новыми данными. EL представляет собой структурированный текстовой язык, который позволяет детально характеризовать элементы онтологии.

Язык SL позволяет строить разнообразные типы диаграмм и схем в IDEF5. Основная цель всех этих диаграмм – наглядно и визуально представлять основную онтологическую информацию.

Несмотря на кажущееся сходство, семантика и обозначения схематичного языка SL существенно отличается от семантики и обозначений других графических языков. Дело в том, что часть элементов графической схемы SL может быть изменен или вовсе не приниматься во внимание языком EL. Причина этого состоит в том, что основной целью применения SL является создание лишь вспомогательной структурированной конструкции онтологии, и графические элементы SL не несут достаточной информации для полного представления и анализа системы, тем самым они не предназначены для сохранения при конечном этапе проекта. Тщательный анализ, обеспечение полноты представления структуры данных, полученных в результате онтологического исследования, являются задачей применения языка EL.

Рис. 1.3.10. Схематические графические изображения IDEF5

Виды схем и диаграмм IDEF5

Как правило, наиболее важные и заметные зависимости между объектами всегда являются преобладающими, когда конкретные люди высказывают свои знания и мнения, касающиеся той или иной системы. Подобные взаимосвязи явным образом описываются языками IDEF5. Всего существует четыре основных вида схем, которые наглядно используются для накопления информации об онтологии в достаточно прозрачной графической форме.

1. Диаграмма классификации. Диаграмма классификации обеспечивает механизм для логической систематизации знаний, накопленных при изучении системы. Существует два типа таких диаграмм: Диаграмма строгой классификации (Description Subsumption – DS) и диаграмма естественной или видовой классификации (Natural Kind Classification – NKC). Основное отличие диаграммы DS заключается в том, что определяющие свойства классов высшего и всех последующих уровней являются необходимым и достаточным признаком принадлежности объекта к тому или иному классу. На рисунке 1.3.11 приведен пример такой диаграммы, построенной на основе тривиальной возможности классификации многоугольников по количеству углов. Из геометрии известно точное математическое определение многоугольника, суть определяющих свойств родительского класса. Определяющим свойством каждого дочернего класса дополнительно является количество углов в многоугольнике. Очевидно, зная это определяющее свойство для любого многоугольника, можно однозначно отнести его к тому или иному дочернему классу. С помощью диаграмм DS, как правило, классифицируются логические объекты.

Рис. 1.3.11. Виды диаграмм IDEF5:диаграмма строгой классификации (слева) и диаграмма естественной классификации (справа)

2. Диаграммы естественной классификации или же диаграммы NKC, наоборот, не предполагают того, что свойства класса являются необходимым и достаточным признаком для принадлежности к ним тех или иных объектов. В этом виде диаграмм определение свойств класса является более общим. Пример такой диаграммы также приведен на рис. 1.3.12.

Композиционная схема. Композиционные схемы (Composition Schematics) являются механизмом графического представления состава классов онтологии и фактически представляют собой инструменты онтологического исследования по принципу «Что из чего состоит». В частности, композиционные схемы позволяют наглядно отображать состав объектов, относящихся к тому или иному классу. На рисунке 1.3.12 изображена композиционная схема шариковой ручки, относящейся к классу шариковых автоматических ручек. В данном случае шариковая ручка является системой, к которой мы применяем методы онтологического исследования.

Рис. 1.3.12. Пример композиционной схемы

С помощью композиционной схемы мы наглядно документируем, что авторучка состоит из нижней и верхней трубки, нижняя трубка в свою очередь включает в себя кнопку и фиксирующий механизм, а верхняя трубка включает в себя стержень и пружину.

3. Схема взаимосвязей. Схемы взаимосвязей (Relation Schematics) позволяют разработчикам визуализировать и изучать взаимосвязи между различными классами объектов в системе. В некоторых случаях схемы взаимосвязей используются для отображения зависимостей между самими же классовыми взаимосвязями. Мотивацией для развития подобной возможности послужило то тривиальное правило, что все вновь разработанные концепции всегда базируются на уже существующих и изученных. Это тесно согласуется с теорией Новака и Гоуэна (Novak & Gowin, 1984), суть которой в том, что изучение любой системы часто происходит от частного к общему, то есть, происходит изыскание и исследование новой частной информации, влияющее на конечные характеристики более общей концепции, к которой эта информация имела прямое отношение. Исходя из этой гипотезы, естественным образом изучения новой или плохо понимаемой взаимосвязи является соотнесение ее с достаточно изученной взаимосвязью, для исследования характеристик их сосуществования.

4. Диаграмма состояния объекта. Диаграмма состояния объекта (Object State Schemantic) позволяет документировать тот или иной процесс с точки зрения изменения состояния объекта. В происходящих процессах могут произойти два типа изменения объекта: объект может поменять свое состояние или класс. Между этими двумя видами изменений по сути не существует принципиальной разницы: объекты, относящиеся к определенному классу K в начальном состоянии в течение процесса могут просто перейти к его дочернему или просто родственному классу. Например, полученная в процессе нагревания теплая вода, уже относится не к классу ВОДА, а к его дочернему классу ТЕПЛАЯ ВОДА. Однако при формальном описании процесса, во избежание путаницы, целесообразно разделять оба вида изменений, и для такого разделения используется обозначения следующего вида: "класс:состояние". Например теплая вода будет описываться следующим образом: «вода:теплая», холодная – «вода:холодная» и так далее. Таким образом, диаграммы состояния в IDEF5 наглядно представляют изменения состояния или класса объекта в течение всего хода процесса. Пример такой диаграммы приведен на рис.1.3.13.

Рис. 1.3.13. Пример диаграммы состояния

Заключение

Суммируя вышеизложенное, еще раз отметим, что строение и свойства любой системы могут быть эффективно исследованы и задокументированы при помощи следующих средств: словаря терминов, используемых при описании характеристик объектов и процессов, имеющих отношение к рассматриваемой системе, точных и однозначных определений всех терминов этого словаря и классификации логических взаимосвязей между этими терминами.

Набор этих средств, по сути, и является онтологией системы, а стандарт IDEF5 предоставляет структурированную методологию, с помощью которой можно наглядно и эффективно разрабатывать, поддерживать и изучать эту онтологию.