Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
cherepashkov_a_a_nosov_n_v_kompyuternye_tehnolo...docx
Скачиваний:
1
Добавлен:
01.03.2025
Размер:
49.82 Mб
Скачать

Раздел 6. Создание, внедрение и интеграция систем и технологий

другой сущности, а может быть и не связан ни с одним экзем­

пляром.

Модальность «должен» означает, что экземпляр одной сущно­

сти обязан быть связан не менее чем с одним экземпляром дру­

гой сущности.

Связь может иметь разную модальность с разных концов, на­

пример, каждая деталь должна быть связана с определенным из­

делием, но не в каждую модификацию изделия может входить

данная деталь.

Описанный графический синтаксис позволяет однозначно

читать диаграммы IDEF1, пользуясь следующей схемой постро­

ения фраз:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯ-

ЗИ>

НАИМЕНОВАНИЕ СВЯЗИУ

<ТИП СВЯЗИУ

<экземпляр

СУЩНОСТИ 2>.

Каждая связь может быть прочитана как слева направо, так

и справа налево. Связь, изображенная на рис. 6.7. Юж, читается

так:

слева направо: «любой конструктор может быть разработ­

чиком нескольких штампов»;

справа налево: «каждый штамп детали должен иметь един­

ственного

конструктора».

Основным отличием IDEF1X по сравнению с ER является об­

ширная и более строгая стандартизация языка моделирования.

Сущность описывается в диаграмме IDEF1X графическим

объектом в виде прямоугольника, разделенного горизонтальной

линией на две части. В верхней части расположены ключевые

поля, а в нижней — остальные атрибуты, составляющие основ­

ные данные.

Сущность называется независимой, если каждый экземпляр

сущности может быть однозначно идентифицирован без опре­

деления его отношений с другими сущностями. Например, на

рис.6.7.11а сущность ДЕТАЛЬ является зависимой от сущности

ИЗДЕЛИЕ. Зависимые сущности изображаются в виде прямоу­

гольников с закругленными углами. Сущности, не зависящие

при идентификации от других объектов в модели, называются

независимыми сущностями. Так, сущность ИЗДЕЛИЕ можно

считать независимой.

484

Рис. 6.7.10. Синтаксис информационного моделирования в нотации ER:

а — обозначение сущности; б — атрибуты сущности;

в — пример экземпляра сущности; г — типы связей;

д,е — модальности связей; ж пример бинарной связи

Каждой сущности присваиваются уникальное имя и номер,

разделяемые косой чертой «/» и помещаемые над блоком. Связи

отображаются в виде линии между двумя сущностями с точками

на концах и глагольной фразой, отображаемой над линией.

Если экземпляр сущности-потомка однозначно определяется

своей связью с сущностью-родителем, то отношение называется

идентифицирующим отношением. В противном случае отноше­

485

ние называют неидентифицирующим и обозначают пунктирной

линией.

6.7. Методология структурного анализа и моделирования систем

Таким образом, для эффективного управления проектным

хи производственным процессом необходимо иметь детальное

представление о его сценарии и структуре сопутствующего до-

1ентооборота.

Средства документирования и моделирования, заложенные

IDEF3, позволяют выполнять следующие задачи:

в

— описывать последовательность бизнес-процессов на фор­

мализованном графическом языке;

— выявлять степень влияния потоков сопутствующего доку­

ментооборота на сценарий работ и технологических процессов;

— выявлять критические ситуации, определяющие жизнен­

ный цикл процесса;

— проводить оптимизацию потоков работ при реорганизации

эеинжиниринге) бизнес-процессов.

Единицы работы (Unit of Work — VOW), или просто «работы»

(Activity), являются главными компонентами модели сценария

троцесса. Работы принято изображать в виде прямоугольника

(рис. 6.7.12) и называть по имени выраженным глаголом или от­

Язык моделирования IDEF3 имеет синтаксис, удобный для

описания последовательности работ, например, для отображе­

ния алгоритма (сценария) определенной проектной деятель­

ности (workflow — потока работ), выполняемой пользователем

в составе автоматизированной системы. Это свойство позволяет

применять нотацию IDEF3 при описании и исследовании техно­

логических процессов на предприятиях.

Сценарием бизнес-процесса (Scenario) в терминологии IDEF

называется описание последовательности изменений свойств

объекта в рамках рассматриваемого процесса, например, описа­

ние последовательности этапов обработки детали и изменения

её свойств после прохождения каждого этапа [66].

Сценарий для большинства промышленных процессов дол­

жен быть обязательно документирован. Например, технологи­

ческий документооборот может состоять из двух основных по­

токов — совокупности документов, определяющих структуру

и последовательность процесса (маршрутных и операционных

карт и т.д.), и документов, отображающих результаты и ход его

выполнения (ведомости измерений и контроля, отчеты о браке

и т.д.).

486

глагольным существительным, например «Принять решение»,

«Разработать документ» или «Изготовление изделия», «Разра­

ботка чертежа». Каждая работа (UOW) в потоке должна иметь

уникальный идентификационный номер, который размещают

в левом нижнем углу диаграммы. Номер присваивается при соз­

дании диаграммы и никогда больше не меняется. Даже если ра­

бота впоследствии будет исключена, ее номер больше не исполь­

зуется в данной модели.

Связи, обозначаемые стрелками, устанавливают последо­

вательные взаимоотношения работ, так как могут быть только

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

блока, но принято, если это возможно, изображать вход в работу

слева и выход из неё справа. Различают три типа связей, обозна­

чаемых следующим образом (табл. 6.7.1).

Каждый функциональный блок, входящий в диаграмму

IDEF3, может быть рассмотрен более подробно посредством его

декомпозиции на составные элементы. При этом диаграмма сле­

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

отношению к первоисточнику, а блок верхнего уровня называ­

ется родительской диаграммой. Номера дочерних диаграмм, как

487

но, в случае описания сценария работ необходимо определить,

что после окончания данной работы станет возможным испол­

нение сразу нескольких последующих работ (логическое «И»),

может быть, только одной работы из всех возможных (логи­

а

ческое «ИЛИ»). Возможно, не надо дожидаться окончания всех

работ, а основанием для начала следующей работы может быть

завершение только одной из возможных работ. Описать все эти

ситуации позволяет представительный перечень перекрестков,

которые являются логическими операциями.

Все перекрестки должны быть пронумерованы с префиксом

«J»

(Junction-перекресток).

Различают перекрестки для слияния (Fan-in Junction) и раз­

ветвления (Fan-out Junction) стрелок. Перекресток не может ис­

пользоваться одновременно для слияния и для разветвления.

На рис. 6.7.13 приведен пример диаграммы в нотации IDEF3,

описывающей поток работ КТПП машиностроительного произ­

водства.

На диаграммах IDEF3 могут также быть дополнительные ука­

затели:

— которые уточняют (ELAB — Elaboration), например, подроб­

но поясняют условия и логику перекрестков;

— которые поясняют (NOTE), являясь текстовым коммента­

рием, вынесенным в графическую диаграмму;

— которые дополняют описание, указывая на участие в опера­

ции важного объекта (OBJECT);

— которые указывают на переход в циклических работах

(GOTO);

— отмечающие работы, которые используются в сценарии

многократно (UOB — Unit of behavior).

Указатели представляются на диаграмме IDEF3 в виде пря­

моугольника, похожего на изображение работы, но без номера.

Отличительной особенностью указателей является обязательное

наличие в текстовой части вспомогательного блока ключевых

слов: ELAB, NOTE, OBJECT, GOTO, UOB.

При создании сценария следует придерживаться следующих

ограничительных правил [34]:

— в сценарии или декомпозиции работы может быть только одна

точка входа, за которой следуют или работа, или перекресток;

488

489

6.7. Методология структурного анализа и моделирования систем

Таблица 6.7.2

Логические операции на перекрестках связей работ

490

491

Компьютер не в состоянии заменить человека, но может зна­

- для декомпозиции может существовать только одна точка

выхода;

- сценарий, который не является декомпозицией, может 1

иметь несколько точек выхода;

- нотация IDEF3 более гибка, чем IDEF1, например, слож­

ная логика взаимодействия работ может быть отображена графи­

чески в виде комбинации перекрестков или описана с помощью

текста в ссылке ELAB;

- сведения о документах, материальных объектах и о преоб­

разовании их состояния могут быть добавлены с помощью ссы­

лок NOTE и OBJECT;

- каждая диаграмма сопровождается текстовым документом,

в котором приводится подробное описание объектов, фактиче­

ской информации, связанной с выполнением работ и ограниче­

ниями, накладываемыми на работу.

Составление диаграмм IDEFO, IFEF1, IDEF3 может быть

автоматизировано при помощи специальных программно-

методических комплексов. Одним из самых популярных средств

автоматизации структурного анализа систем и моделирования

бизнес-процессов является система ALLFusion Modelling Suite

[34], более известная под своим старым названием BPwin.

6 . 8 . П р о б л е м а полготовки к а д р о в лля P L M

При изучении многочисленных публикаций, посвященных

разработке и внедрению автоматизированных систем управле­

ния жизненным циклом изделий, может показаться, что CALS/

И П И / P L M — это панацея, позволяющая автоматически до­

стичь высоких показателей эффективности производства, стоит

только приобрести компьютерную технику и программное обе­

спечение.

В какое-то мере это действительно так: хорошие компьютеры

и правильно подобранные программы способны на многое. Но

только при одном очень важном условии. Это условие — ком­

петентность специалистов, которые по определению являются

основным элементом организационно-технической системы.

492

чительно увеличить эффективность его труда. В случае PLM-

системы, интегрирующей все стадии и этапы работ, результат во

ногом зависит от слаженной коллективной работы всего персо­

м

нала автоматизированной системы.

Практика показывает, что даже самые лучшие проекты авто­

матизации не находят реальной поддержки на местах без наличия

достаточно глубокой, современной информационной культуры

у персонала всех уровней, даже непосредственно не связанных

с работой за компьютером. Главной причиной, сдерживающей

внедрение PLM, является, прежде всего, отсутствие знаний и на­

выков работы в интегрированной информационной среде у ра­

ботников предприятий.

Наличие выдающихся инженеров, виртуозно справляющихся

с работой на локальных автоматизированных рабочих местах, не

гарантирует эффективной работы интегрированной системы в це­

лом. Для обеспечения целенаправленной коллективной деятель­

ности персонала в среде сложной организационно-технической

системы требуются не только навыки управления техническими

и программными средствами на конкретном рабочем месте, но

и достаточно глубокое понимание каждым участником методов

и принципов функционирования всего комплекса средств авто­

матизации. Для этого нужны специалисты с развитым системным

подходом к информационным процессам, а также достаточно

серьезными знаниями методологии, стандартов и современных

технологий комплексного использования промышленных ав­

томатизированных систем для решения не только своей, но и

смежных задач.

Следовательно, внедрение PLM не сводится только к про­

блеме выбора программно-методических комплексов и проведе­

нию соответствующих организационных мероприятий. Это еще

и обязательная тщательная подготовка кадров, которые будут

работать в составе автоматизированной системы. Так как PLM

охватывает всю производственную деятельность предприятия, то

эта подготовка обязательна для всей иерархии участников созда­

ния продукта — от рядового техника до генерального директора.

Конечно, в определенном объеме и в соответствии с его уровнем

Компетенции.

493