Стандарты и языки представления информационных моделей продукции

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

1. Стандарты CALS

Объекты стандартизации.

Фундаментом CALS-технологии является система единых международных стандартов.

CALS-стандарты можно подразделить на три группы:

- функциональные стандарты, определяющие процессы и методы формализации;

- информационные стандарты по описанию данных о продуктах, процессах и средах;

- стандарты технического обмена, контролирующие носители информации и процессы обмена данными между передающими и принимающими системами.

Поскольку целью CALS является обеспечение информационной интеграции, важную роль в данной проблематике играет применение международных стандартов (серии ISO). Перечень основных стандартов приведен в табл. 1.

Таблица 1

Информационные модели	Стандарт представления информации	Содержание стандарта
Модель ЖЦ продукта и выполняемых в его ходе бизнес-процессов	IDEF - Integrated Definition	Функциональное моделирование жизненного цикла и выполняемых бизнес-процессов
	ISO 10303 AP208
Модель продукта	Конструкторская	ISO 10303 (STEP)	Структура, конфигурация и геометрия изделия
	Производственная	ISO-13584 (PLIB)	Формат данных о библиотеках деталей у поставщиков
		MIL-STD- 1388-1/2 Logistic Support Analysis (LSA) Record	Формат данных в процессах материально-технического снабжения
	Эксплуатационная	MIL-M-87268 - Manuals, Interactive Electronic Technical General Content, Style, Format, and User-Interaction Requirements (IETM)	Требования к электронным руководствам: содержание, стиль, формат, Интерфейс с пользователем
		MIL-D-87269 - Data Base, Revisable Interactive Electronic Technical Manuals, for the support of	Требования к оформлению баз данных и электронных справочников по изделиям
		ISO 8879 (SGML) - Standard Generilized MarkUp Language	Способ представления информации в тексто-графических документах
		MIL-PRF-28001C - Markup Requirements and Generic Style Specification for Electronic Printed Output and Exchange of Text	Требования к оформлению электронных документов (рекомендации по применению SGML для оформления электронных документов)
		MIL-PRF-28002C -Requirements for Raster Graphics Representations in Binary Format	Требования к представлению растровых изображений в двоичном формате в электронной документации
		MIL-PRF-28003 - Color Graphics Metafile (CGM)	Требования к представлению иллюстраций для технической документации в электронном виде
		ISO 10744 HyTime - (Hypermedia/Time Based Structuring Language	Требования к мультимедийной информации в электронных документах
Модель среды	ISO 15531 (MANDATE)	Форма представления и методы использования информации о производстве и используемых производственных ресурсах, их характеристиках и ограничениях с точки зрения управления производством.

2. Стандарты и методы семейства IDEF

2.1 Общая характеристика методов IDEF

Методы IDEF (Integrated DEFinition), как отмечено в историческом введении, изначально были разработаны в рамках реализации программы интегрированной компьютерной поддержки производства ICAM в США в середине 70-х годов с целью улучшения взаимодействия специалистов, занимающихся интеграцией существующих производственных и организационных систем. В основу была положена технология структурированного анализа и проектирования SADT (Structured Analysis and Design Technique), разработанная в начале 70-х годов фирмой SoftTech. Они направлены на различные методы описания и анализа процессов, потоков, структур промышленных и организационных систем с целью улучшения их характеристик. Методы взаимодополняют друг друга, обеспечивая возможность многоаспектного анализа систем. На их основе разработаны федеральные стандарты США (FIPS), их методологические основы используются при разработке новых стандартов CALS.

Кратко охарактеризуем основные методы IDEF.

IDEF0 - метод функционального моделирования; был разработан для описания функций различных систем путем создания наглядной графической модели. Функциональные модели строятся методом декомпозиции от главной (контекстной) функции к более мелким простым с учетом их взаимной связи. Цель моделирования и степень детализации модели определяется разработчиком. Элементы модели каждого уровня представляют собой действия по переработке информационных или материальных ресурсов при определенных условиях (ограничениях, управляющих воздействиях) с использованием определенных механизмов. Как правило, моделирование средствами IDEF0 является начальным этапом изучения любой системы. Модели используются для детального функционального анализа с целью улучшения структуры функций объекта (реинжиниринга). На методе IDEF0 базируется функционально-стоимостной анализ - ФСА (АВС - Activity Based Costing). Стандарт IDEF0 выпущен в 1981г., последняя его версия - в 1993 г. (FIPS 183).

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

IDEF1X - метод моделирования данных и проектирования реляционных баз данных. Он, так же как и IDEF1, относится к типу методологий «сущность-взаимосвязь» (ER - Entity-Relationship), однако сущности здесь понимаются не как реальные объекты, а как их типы, обладающие общими свойствами. Связи между сущностями более сложны. Это позволяет хранить информацию в форме абстрактной схемы (семантической модели), которая связывает хранящиеся в компьютере символы с реальным миром и является верным его отражением. Подобный способ хранения информации является относительно независимым, «нейтральным» и позволяет получить ответ на различные запросы пользователя о свойствах описанной в модели среды. Стандарт IDEF1Х выпущен в 1993 году (FIPS 184).

IDEF2 - метод динамического моделирования систем. В связи с весьма серьезными сложностями анализа динамических систем развитие этого стандарта происходит медленно. Однако в настоящее время существуют алгоритмы и их компьютерные реализации, позволяющие превратить набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN - Color Petri Nets), т.е. отслеживать изменение состояние систем с помощью фиксации ряда дискретных квазистационарных состояний. Подобный подход широко используется при динамическом моделировании технических систем, описываемых дифференциальными уравнениями различного типа.

IDEF3 -метод получения описания функционирования системы и моделирования как причинно-следственных связей внутри одного бизнес-процесса, так и между различными процессами. Он предоставляет пользователю два типа диаграмм: описания процесса PFD (Process Flow Description) - «внутреннее описание» и описания переходов из одного состояния в другое OSTD (Object State Transition Description) - «внешнее описание», когда дополнительно рассматривается вход и выход объекта. Эти два способа моделирования дополняют друг друга и позволяют описать любой процесс функционирования системы.

IDEF4 - метод объектно-ориентированного проектирования. Средства метода позволяют наглядно отображать структуру объектов и принципы их взаимодействия, позволяя анализировать и оптимизировать и создавать сложные системы. В отличие от других методов, кроме констатации взаимодействия, здесь учитывается его принцип (в частности, физический). Поэтому он, как и IDEF1Х, является методом проектирования.

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

В CALS-технологиях наибольшее применение нашли методы IDEF0 и IDEF1Х.

Метод IDEF0 является стандартом CALS, однако он не обеспечивает прямой интеграции функциональных моделей с моделями продукции. Для этого разрабатывается один из прикладных протоколов стандарта STEP - ISO 10303 AP208, который базируется на методологии IDEF0.

Метод IDEF1Х по своей идеологии близок к языку EXPRESS стандарта ISO 10303 STEP, предназначенного для описания продукции в нейтральном формате (в форме EXPRESS-схем, характерных для реляционных баз данных).

Поэтому методы IDEF0 и IDEF1Х рассмотрим более детально.

2.2 Метод IDEF0

Графический язык IDEF0 прост и гармоничен. В основе метода лежат 4 основных понятия.

Первым из них является понятие функционального блока (Activity Box).

Функциональный блок изображается в виде прямоугольника (см. рис.1) и олицетворяет некоторую конкретную функцию в рамках рассматриваемой системы, которая выражается глагольной формой. Например: «Обработать заготовку», а не «Обработка заготовки».

Рис. 1. Функциональный блок<!--mstheme--><!--msthemelist-->

Каждая из сторон блока имеет определенное значение (роль):

верхняя сторона имеет значение «Управление» (Control);

левая сторона имеет значение «Вход» (Input);

правая сторона имеет значение «Выход» (Output);

нижняя сторона имеет значение «Механизм» (Mechanism).

Каждый блок должен иметь уникальный идентификационный номер.

Вторым понятием метода является понятие интерфейсной дуги (Arrow). Графическим отображением интерфейсной дуги является однонаправленная стрелка (поэтому дуги часто называют стрелками, потоками). Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label), которое должно быть оборотом существительного. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Это могут быть элементы реального мира (люди, изделия, детали и др.), потоки данных и информации (документы, инструкции и др.). «Источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только блоки, причем «источником» может быть только выходная сторона блока, а «приемником» - любые из трех оставшихся. Функциональный блок должен обязательно иметь управляющую и исходящую интерфейсную дугу, поскольку каждый процесс должен происходить по каким-то правилам и давать некоторый результат (иначе его рассмотрение не имеет смысла).

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

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

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

Процесс моделирования начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами. Эта диаграмма называется контекстной и обозначается идентификатором «А0». В пояснительном тексте к контекстной диаграмме в краткой форме должна быть указана цель (Purpose) и зафиксирована точка зрения (Viewpoint). Цель определяет области в анализируемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Она позволяет отказаться от несущественных свойств в данном аспекте рассмотрения. Например, функциональные модели предприятия с точки зрения главного технолога и финансового директора будут различаться, поскольку финансового директора интересуют финансовые потоки, а главного технолога - аспекты переработки сырья.

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

Следует отметить, что рис.6 выполнен с использованием специализированного программного средства - CASE-средства Design/IDEF для построения диаграмм в соответствии с методами IDEF0 и IDEF1X. Design/IDEF автоматически контролирует основные правила построения диаграмм, автоматически выполняет оцифровку блоков, переносит интерфейсные дуги с родительской диаграммы, вписывает в соответствующие поля необходимую информацию (например, в нижней части диаграммы указано имя родительской функции и номер родительской диаграммы).

Часто бывают случаи, когда отдельные дуги не имеет смысла продолжать рассматривать на дочерних диаграммах, или наоборот, отдельные дуги не имеют практического смысла выше какого-то уровня. Это будет усложнять диаграммы. Для этого вводится понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала дуги обозначает, что она была не унаследована, а появилась из «туннеля» на данной диаграмме. Если скобки стоят у конца дуги, то это означает, что дуга не будет наследоваться. Бывает, что некоторые дуги сначала «погружаются» в туннель, а потом «возвращаются» из туннеля.

Рис. 2. Декомпозиция диаграмм при функциональном моделировании

Рис. 3. Функциональная диаграмма создания и модификации проекта изделия (второй уровень)

Четвертым из основных понятий метода является глоссарий (Glossary). Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных дуг) создаются и поддерживаются определения, ключевые слова, повествовательные изложения, которые характеризуют объект. Глоссарий снабжает диаграммы дополнительной информацией.

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

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

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

Если использовать термин «бизнес-процесс», то можно сказать, что метод IDEF0 позволяет идентифицировать бизнес-процессы, рассмотреть функционирование предприятия «как есть» и на основе их анализа дать предложения «как должно быть», то есть по-новому взглянуть на работу предприятия, уточнить обязанности работников, оценить эффективность использования ресурсов, увидеть недостатки, искусно скрытые в обычной организационной структуре. Следовательно, выявление, анализ и внесение изменений в бизнес-процессы может быть использовано для повышения эффективности работы предприятия.

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

- сбор информации о предприятии;

идентификация бизнес-процессов предприятия и создание функциональной модели бизнес-процессов предприятия;

анализ и возможный реинжиниринг бизнес-процессов предприятия.

Для анализа распределения затрат применяется метод ABC, базирующийся на IDEF0. Метод ABC основывается на том, что выполнение каждой функции в процессе функционирования предприятия обладает определенной стоимостью, то есть вносит свой вклад в появление издержек. АВС аналогично понятию ФСА - функционально-стоимостного анализа. При помощи метода АВС рассчитываются затраты на выполнение всего процесса или отдельной функции, стоимость продукции на выходе процесса, выявляются источники основных затрат. Затраты на выполнение декомпозируемой функции определяются как сумма затрат на выполнение всех составных элементов в этой функции.

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

Для построения функциональной модели предлагается выбрать CASE-пакет Design/IDEF, так как помимо возможностей создания функциональной модели этот пакет содержит встроенный механизм АВС подсчета затрат на выполнение функций, позволяющий анализировать бизнес-процессы и их составляющие. Каждый вид ресурса, потребляемый (обрабатываемый) функцией, а также механизмы, выполняющие функцию, добавляют стоимость к этой функции, при этом учитываются элементы затрат, игнорируемые при обычном представлении предприятия как совокупности организационных структур. Следовательно, каждой функции h модели IDEF0 можно поставить в соответствие значение затрат на выполнение этой функции Ex(h).

Рис. 4. Общая схема методики анализа и реинжиниринга бизнес-процессов предприятия

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

2.3 Метод моделирования данных IDEF1X

Стандарт FIPS 184 на основе этого метода, выпущенный в 1993 году, не входит в перечень CALS-стандартов. Однако разработанные на его основе структуры реляционных баз данных напрямую могут быть использованы для создания информационных систем с использованием языка EXPRESS стандарта ISO 10303 (STEP)<!--msthemeseparator-->, который составляет основу CALS-технологий. Аналогия положений IDEF1X и требований языка EXPRESS станет очевидной при рассмотрении EXPRESS.

IDEF1X - это метод для разработки реляционных баз данных. Он использует условный синтаксис для описания семантических конструкций, необходимых для построения концептуальной схемы. Концептуальная схема - это единое интегрированное определение данных предметной области, не ориентированное на какое-либо конкретное приложение и независимое от способов доступа и способов физического хранения данных.

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

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

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

<!--mstheme-->Концепция IDEF1X несколько отличается от<!--mstheme--> IDEF1, хотя их терминология схожа. Сущность в IDEF1X ссылается на коллекцию или набор аналогичных экземпляров данных, которые могут отличаться друг от друга. Отдельные члены набора называются экземплярами сущности. Таким образом, блок в IDEF1X представляет набор экземпляров реального мира. Атрибут - это значение, ассоциированное с каждым конкретным экземпляром набора. Отношению, существующему между отдельными экземплярами этих наборов, даётся имя, которое выражено глагольной формой.

Сильной особенностью IDEF1X является его поддержка моделирования логических типов данных через использование структуры классификации. Эта конструкция является попыткой отразить модель реального мира, данные о которых представляются либо блоками, либо сущностями, попыткой промоделировать типы данных вещей. Эти отношения категоризации представляют взаимно исключающие подмножества родовой сущности или множества. Подмножества общего надмножества не могут иметь общих экземпляров. Например, родовая сущность ОСОБА имеет два подмножества, представляющих полный набор категорий, а именно, МУЖЧИНА и ЖЕНЩИНА. Ни один экземпляр подмножества МУЖЧИНА не может быть экземпляром подмножества ЖЕНЩИНА, и наоборот. Уникальный идентификатор атрибута для каждого подмножества - это тот же атрибут, что и для экземпляра родовой сущности.

<!--mstheme-->Сущности<!--mstheme--> в IDEF1X сущности являются либо идентификационно независимыми, либо идентификационно зависимыми. Экземпляры идентификационно независимых сущностей могут существовать независимо от другого экземпляра сущности, в то время как экземпляры идентификационно зависимых сущностей являются бессмысленными (по определению) без другого ассоциированного экземпляра сущности. Зависимость и независимость являются спецификой модели.

<!--mstheme-->Отношения связности<!--mstheme--> (сплошные или пунктирные линии с кружками с одной или двух сторон) показывают, как сущности (множества экземпляров данных) относятся друг с другом. Отношения связности существуют всегда только между двумя сущностями. Отношение связности, начинающееся с независимой родовой сущности и заканчивающееся на зависимой порождённой сущности, помечается глагольной фразой, описывающей отношение. Каждое отношение связности имеет соответствующую мощность. Мощность определяет число экземпляров зависимой сущности, связанных с экземпляром независимой сущности.

<!--mstheme-->Отношения категоризации<!--mstheme--> позволяют проектировщику определить категорию общей сущности. Сущность может принадлежать только одной категории. Например, может существовать общая сущность МАШИНА, являющаяся родовой сущностью для категории, представляющей различные марки машин (ВОЛГА, ОКА, НИВА). Каждая сущность-категория должна иметь одинаковый первичный ключ с общей сущностью. Кроме того, обязаны существовать различия между сущностями-категориями. Сущности-категории различаются атрибутом - дискриминатором (описателем), который обязан иметь различные значения для каждой сущности-категории. В рассмотренном примере дискриминатор - МАРКА МАШИНЫ.

<!--mstheme-->Атрибуты<!--mstheme--> - это свойства, используемые для описания сущностей. Имена атрибутов являются уникальными для всей модели IDEF1X, значения имён должны быть согласованными. Например, атрибут «цвет» можно использовать для цвета волос, цвета кожи, цвета радуги. Каждое такое использование имеет допустимый диапазон значений, и, следовательно, сущность необходимо раздельно именовать. Каждый атрибут принадлежит только одной сущности. Например, атрибут «страховой номер» может использоваться в модели во многих местах, но должен принадлежать только одной сущности (например, ПЕРСОНА). Все другие появления атрибутов страхового номера будут наследоваться через отношения.

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

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

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

Помимо того факта, что ключ обязан однозначно идентифицировать сущность, все атрибуты ключа должны удовлетворять условию однозначной идентификации (правило наименьшего ключа). Таким образом, при определении должен ли наследуемый атрибут быть частью ключа, следует ответить на вопрос: «Необходим ли этот атрибут для однозначной идентификации?» Однозначной идентификации родителя при этом недостаточно <!--mstheme--> <!--mstheme-->.

Внешние ключи - являются не совсем настоящими ключами, а атрибутами, наследуемыми от первичных ключей других сущностей. Внешние ключи помечаются меткой (FK - foreign key), чтобы выделить, что они не принадлежат сущности. Внешние ключи весьма важны для изображения отношений между сущностями. Так как сущности определяются своими атрибутами, если сущность состоит из атрибутов, наследованных из других сущностей, то эта сущность является подобной тем сущностям. Это свойство используется для реализации сложных выборок из базы данных.

IEF1X является мощным средством моделирования данных наряду с множеством других методов, таких как ER и ENALIM. Достоинство IDEF1X лежит в его истоках. Благодаря жесткой стандартизации всех проектов МО США методу IEF1X удалось избежать неоднозначности в толковании основных положений, что повредило использованию метода ER. Наличие стандарта и твёрдое следование ему является существенным для обмена информацией между организациями.

Недостатком всех таких методов, включая IDEF1X, является тот факт, что разработчик обязан быть опытным специалистом. Моделирование носит итеративный и коллективный характер (разработчик, эксперт и др.).

3. Стандарт ISO 10303 (STEP)

3.1 Структура стандарта

ISO 10303 (STEP - Standard for the Exchange of Product Model Data) -- это международный стандарт для компьютерного представления и обмена данными о продукте (изделии). Цель стандарта -- дать нейтральный механизм описания данных о продукте на всех стадиях его ЖЦ, не зависящий от конкретной системы. Природа такого описания делает его подходящим не только для нейтрального файла обмена, но и в качестве базиса для реализации и распространения баз данных о продукте, а также для архивирования.

В соответствии с названием, STEP определяет «нейтральный» формат представления данных об изделии в виде информационной модели. Для обеспечения возможности единообразного описания изделий в различных прикладных областях, предполагается, что информационные модели (в терминах стандарта «прикладные протоколы») создаются на базе типовых блоков («интегрированных ресурсов»), причем для описания схем данных используется специально введенный язык EXPRESS. Язык EXPRESS является одним из разделов стандарта ISO 10303 STEP и описан в 11 томе стандарта ISO 10303. Он регламентирует черчение (прямое и ассоциативное), проектирование конструкций, инженерный анализ, технологическую подготовку, производство, тестирование данных и обмен ими (в том числе с IDEF-моделями) в специальном текстовом формате, который обеспечивает безопасность и надежность передачи информации по Интернет партнерам.

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

методы описания (язык EXPRESS);

стандартные решения (способы применения);

структура и методология проверки на совместимость;

общие интегрированные ресурсы;

прикладные интегрированные ресурсы;

прикладные протоколы (в различных отраслях);

набор абстрактных тестов (абстрактные примеры);

элементы для конкретных приложений.

Каждый том документации по ISO 10303 начинается с одной и той же преамбулы, определяющей назначение и структуру ISO 10303, а именно: «ISO 10303 -- международный стандарт для компьютерного представления и обмена данными о продукте». Цель стандарта--дать нейтральный механизм описания данных о продукте на всех стадиях его ЖЦ, не зависящий от конкретной системы.

Приведенное определение ISO 10303 нуждается в комментариях.

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

2. Утверждать, что ISO 10303 является стандартом обмена данными о продукте, можно лишь при расширенной трактовке STEP (ISO 10303) как стандарта, включающего в себя стандарты PLIB и MANDATE. С технологической точки зрения это так и есть, поскольку PLIB и MANDATE строятся на базе стандарта STEP, заимствуя из него методы описания (язык EXPRESS), формы реализации (обменный файл и интерфейс доступа к данным) и, при необходимости, интегрированные ресурсы (информационные структуры). С потребительской же точки зрения каждый из трех стандартов имеет свою предметную область:

ISO 13584 (PLIB) дает средства описания продукта внутри производства во внутренней сфере обращения (здесь под продуктом уже понимается материальный продукт производства, участвующий в товарообмене). Он представляет информацию о библиотеке изделий вместе с необходимыми механизмами и определениями, обеспечивающими обмен, использование и корректировку данных библиотеки изделий. Имеется в виду обмен между различными компьютерными системами и средами, связанными с ЖЦ продукта, где могут использоваться изделия библиотеки, включая проектирование, изготовление, эксплуатацию, обслуживание и утилизацию продукта.

ISO 15331(MANDATE) описывает динамику производства как снаружи (связи производства с внешней средой), так и изнутри (материальные и информационные потоки в организационно-производственной структуре, короче -- интегрированная модель производства).

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

<span style="mso-bidi-font-size: 10.0pt; mso-fareast-font-family: Times New Roman; mso-ansi-language: UK; mso-fareast-language: EN-US; mso-bidi-language: AR-SA" lang="UK">CALS-технологии, в частности стандарт ISO 10303 STEP, предлагают способ решения этой проблемы при помощи использования стандартизованного интегрированного описания изделия.</span>.

Интегрированное электронное описание изделия - это набор данных различного типа, полученных в ходе проектирования различными способами, а затем преобразованных в стандартизованный вид и достаточных для решения задач последующих этапов ЖЦ. Например, конструкторское электронное описание в соответствии со стандартом STEP содержит структуру и варианты конфигурации изделия, геометрические модели и чертежи, свойства и характеристики составных частей и др.

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

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

Стандарт STEP регламентирует: логическую структуру базы данных (БД), номенклатуру информационных объектов, хранимых в БД, их связи и атрибуты. Типовые информационные объекты, такие как данные, о составе изделия, материалах, геометрических изделиях, независимые от характера описания изделия, называются в стандарте «интегрированными ресурсами», на основе которых строятся схемы баз данных об изделии для разных предметных областей автомобилестроения, судостроения, аэрокосмической промышленности и т.д.

Готовые схемы баз данных называются в стандарте «протоколами применения» (прикладными протоколами, как это показано на рис.6) и представляют собой типовые решения.

Практически, стандарт STEP может быть применен несколькими способами.

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

2. Структуры данных могут быть созданы в готовой PDM системе путем ее соответствующей настройки и разработки соответствующих визуальных приложений.

3. Могут быть использованы готовые решения.

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

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

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

2. Продажа лицензии на производство продукта. Фактически, речь идет о необходимости поставки конструкторской и технологической документации в электронной форме. Аналогичная ситуация возникает при кооперации с зарубежными партнерами. Решением этой проблемы также является использование стандартизованного обменного файла.

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

4. Ведение библиотек изделий (каталогов запасных частей, стандартных элементов). Логическая структура базы данных, описанная в стандарте STEP, позволяет создавать категории изделий и наделять их характеристиками.

3.2 Продукты поддержки стандарта STEP

ST-Developer включает набор средств для разработки STEP-приложений: средства информационного моделирования, средства верификации данных в формате STEP и библиотеки для организации доступа к STEP-моделям для языков С, С++, Java ST-Database Adaptors содержит набор программных продуктов, расширяющих возможности ST-Developer. Они обеспечивают загрузку и выгрузку данных в формате STEP в популярные СУБД: Oracle, Object Store и Versant.

ST-EXPRESS - средства информационного моделирования для аналитиков и разработчиков прикладных протоколов STEP. Включают в себя собственно компилятор языка информационного моделирования EXPRESS и набор средств для работы с графическим представлением языка - EXPRESS-G.

ST-ACIS обеспечивает конвертирование твердотельных моделей в формате ACIS в геометрию STEP и обратно. Поддерживает геометрические модели STEP согласно прикладному протоколу АР203. Представляет из себя либо отдельно исполненный транслятор, либо библиотеку для С++ с целью использования в собственных разрабатываемых приложениях.

ST-Visualizer - средство просмотра геометрических 3D моделей, описанных в формате STEP. Отображает тонированные твердотельные модели и может импортировать векторную и поверхностную геометрию по стандарту IGES. Обеспечивает функции вырезки и вставки геометрических примитивов между STEP-файлами и редактирование топологии твердотельных моделей.

ST-WebPublisher позволяет обеспечить доступ к моделям в формате STEP с использованием Web-технологии. Обеспечивает как просмотр геометрии в STEP-модели, так и данных конфигурации изделия. В состав ST-WebPublisher входят средства и шаблоны для создания HTML-страниц, растровых образов в формате GIF и Java по исходному обменному файлу STEP Part 21.

3.3 Основные элементы языка EXPRESS

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

Реализация объектно-ориентированного подхода возможна в двух вариантах.

Первый вариант -- некоторый набор знаний сразу доводится до уровня машинной программы. В этом случае необходим язык программирования, поддерживающий функционально полное описание класса. Практически это означает, что описание класса должно включать как данные (перечень атрибутов класса), так и «методы» (программы, реализующие полный набор операций над объектами данного класса). C++, Симула-67 -- примеры языков объектно-ориентированного программирования, то есть реализации подхода по первому варианту.

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

Во втором варианте проектирование программного продукта включает три вида деятельности: информационное моделирование, функциональное моделирование и программную реализацию. Стандарт STEP (в расширенной трактовке) должен обеспечить интеграцию понятий в предметной области «промышленное производство продукции», то есть представить единую информационную модель этих понятий в виде, формализованном на уровне спецификаций EXPRESS.

Информационное моделирование (на базе методологии IDEF1Х) представляет информацию о сущностях, их связях и атрибутах, которое может быть использовано далее при создании спецификаций EXPRESS.

Функциональное моделирование отвечает за второй элемент представления знаний -- функциональные связи между понятиями. Интеграция знаний в этой области пока осуществляется без привлечения ЭВМ, хотя предпринимаются попытки как-то регламентировать представление знаний, в частности, средствами IDEFO. В стандарте STEP средства IDEFO используются для иллюстративного представления сферы использования приложения -- программной реализации стандартного протокола приложения АР, содержащего специализированную информационную модель.

Наконец, стандарт STEP касается и третьей компоненты проектирования -- программной реализации стандартного АР. Для каждого стандартного протокола его разработчиками составляется набор абстрактных тестов, по которому проверяется реализация протокола на соответствие требованиям АР. Следует отметить, что структура функциональной модели приложения (и, следовательно, представление в ЭВМ функциональных связей между понятиями) не определяется стандартом STEP, а лишь ограничивается снизу требованием, чтобы ЭВМ «владела» понятиями информационной модели, по крайней мере, на уровне минимальных требований, заданных набором абстрактных тестов.

Второй вариант является предпочтительным для использования в CALS, поскольку информация для создания информационных систем предварительно систематизируется и верифицируется.

В разработке первой версии языка EXPRESS участвовало порядка 20 человек в период с 1985 по 1991 год. Проблема не ограничивалась изъятием методов из структуры описания класса. Требовалось разработать специализированный язык информационного моделирования, достаточно полный для описания любой системы понятий, связанных с производственной деятельностью, достаточно простой для освоения пользователем-непрограммистом и, наконец, достаточно технологичный для работы приложений с языковыми конструкциями. Конкретизация предметной области использования языка EXPRESS была необходима по существу, так как имеются области знания с более сложными структурами понятий (например, семиотика), ориентация на которые могла бы привести к чрезмерному усложнению проблемы.

Итак, язык EXPRESS предназначен для описания информационных моделей (как и метод IDEF1Х). Информационная модель описывается одной или несколькими взаимосвязанными схемами.

Прикладной протокол AP - это схема, описывающая некоторую предметную область. Прикладной протокол включается в стандарт как один из томов стандарта. Имена объектов, констант, функций, процедур, правил и типов уникальны в пределах данной схемы.

База данных (БД), формируемая в соответствии с описанием EXPRESS-схем, предназначена для хранения произвольного количества экземпляров каждой из сущностей, представленных в схемах. Сущность -- информационный объект, характеризующийся идентификатором и списком атрибутов, определяющих свойства каждого из экземпляров сущности. Остальные элементы описания схемы играют вспомогательную роль, а именно: type-объявления определяют структуру представления атрибутов сущности. Алгоритмы и правила служат для проверки соответствия содержимого БД информационной модели, а интерфейс предназначен для унификации описания объектов (типов, алгоритмов, правил), используемых более чем в одной схеме.

Возможности описания информационных структур в языке EXPRESS сводятся, в основном, к следующим. Прежде всего, имеется набор стандартных (встроенных в EXPRESS) данных, состоящий из группы простых типов, включающей типы number, integer, real, logical, boolean, binary, string, и из группы агрегативных типов, включающей типы array, bag, list, set -- разновидности множества однотипных компонент. При использовании в схеме простых типов real, binary, string можно специфицировать их формат, а при использовании агрегативных типов -- их размеры (границы).

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

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

Домен стандартных типов может иметь переменные размеры. Поэтому структура атрибута может варьироваться по размерам в разных экземплярах сущности. Более того, при наличии в entity-обьявлении необязательных (optional) атрибутов их структуры в некоторых экземплярах сущности могут отсутствовать вообще. По аналогии с использованием термина «популяция» в документации по EXPRESS для обозначения содержимого БД популяцией сущности называют совокупность всех имеющихся в БД ее экземпляров. Если трактовать популяцию сущности как файл записей -- экземпляров сущности, -- то, как видим, придется уточнить, что запись может варьироваться в файле по размерам и составу атрибутом (в пределах максимального состава).

Ограниченность значений атрибута рамками домена соответствующего базового типа является необходимым, но не всегда достаточным условием соответствия БД информационной модели. Для описания подобных ограничений в языке предусмотрены логические функции типа глобальных правил (rules).

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

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

Рассмотренный выше тип связи между экземплярами сущностей по атрибутам (с помощью ссылок на необходимые экземпляры) является одним из двух имеющихся в языке EXPRESS типов связей. Второй тип связи -- «генетический», или механизм множественного наследования, -- состоит в следующем. С помощью subtype-предложения в entity-объявлении можно указать список сущностей -- непосредственных «предков» данной сущности, от которых она наследует все свойства -- атрибуты, правила и алгоритмы. Отношение наследования транзитивно, то есть вместе с наследованием свойств непосредственных предков наследуются свойства предков вышестоящего уровня, а в итоге -- свойства всей «родословной». Наследование атрибутов означает их непосредственное включение в структуру собственных атрибутов сущности, в результате чего образуется «сложный» экземпляр.

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

...