Курс лекций инструментальные средства. Конспект лекций
 Скачать 1.6 Mb.
|
|
ICOM-кодами. ICOM (аббревиатура от Input, Control, Output и Mechanism) – коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер. Граничные стрелки необходимо соединить с соответствующими входами, выходами и т. п. активностей диаграммы декомпозиции. Стрелки, соединяющие активности на диаграмме, называются внутренними.ВIDEF0различают пять типов связей работ. Связь по входу (output-input),когда стрелка выхода вышестоящейработы (далее – просто выход) направляется на вход нижестоящей работы (рисунок 3.2). На рисунках 3.5 – 3.6 в основном показаны только рассматриваемые связи.  Рисунок 3.2 - Связь по входу Связь по управлению (output-control),когда выход вышестоящейработы направляется на управление нижестоящей (рис. 3.3). Связь по управлению показывает доминирование вышестоящей работы.  Рисунок 3.3 - Связь по управлению Обратная связь по входу (output-input feedback),когда выходнижестоящей работы направляется на вход вышестоящей (рисунок 3.4). Такая связь, как правило, используется для описания циклов.  Рисунок 3.4 - Обратная связь по входу Обратная связь по управлению (output-control feedback),когдавыход нижестоящей работы направляется на управление вышестоящей (рисунок 3.5). Обратная связь по управлению часто свидетельствует об эффективном управлении бизнес – процессами. Связь выход-механизм (output-mechanism),когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (рисунок 3.6).  Рисунок 3.5 - Обратная связь по управлению  Рисунок 3.6 - Связь выход-механизм Простейшим и наиболее распространенным видом стрелок является явная стрелка,которая имеет источником одну-единственную активность иназначением тоже одну -единственную активность . Одни и те же данные или объекты, порожденные одной активностью, могут использоваться сразу в нескольких других активностях. С другой стороны, стрелки, порожденные в разных активностях, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления. Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей тоже именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления. Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. Правила именования сливающихся стрелок полностью аналогичны – ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после чего вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви. Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня , или наоборот – отдельные дуги нижнего уровня отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Вновь созданные на диаграмме декомпозиции граничные стрелки изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рисунок 3.7).  Рисунок 3.7 - Неразрешенная (unresolved) стрелка Можно разрешить миграцию новой стрелки на диаграмму верхнего уровня или не разрешить такую миграцию. В последнем случае говорят, что стрелка будет туннелирована. В BPwin для этого нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и в контекстном меню выбрать команду Arrow Tunnel. Появляется диалог Border Arrow Editor. Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel – стрелка будет туннелирована и не попадет на другую диаграмму. Туннельная стрелка изображается с круглыми скобками на конце. Туннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые нецелесообразно отображать на диаграммах вышестоящего уровня, то следует туннелировать стрелки на самом нижнем уровне. Такое туннелирование называется туннель "не-в-родительской-диаграмме".Другим примером туннелирования можетбыть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения. В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть туннелирована, острие стрелки на родительской диаграмме будет изображено в круглых скобках. В комментарии к стрелке или в словаре можно указать, что механизм будет использоваться во всех работах дочерней диаграммы декомпозиции. Такое туннелирование называется туннель "не-в-дочерней-диаграмме". Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей , принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов: Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия . Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы: Что поступает в подразделение "на входе"? Какие функции и в какой последовательности выполняются в рамках подразделения? Кто является ответственным за выполнение каждой из функций? Чем руководствуется исполнитель при выполнении каждой из функций? Что является результатом работы подразделения (на выходе)? На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели. Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 – читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению. Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление предприятии (системе) с заданной точки зрения и для заданной цели. Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели. 3.3 Методология DFD Целью методологии является построение модели рассматриваемой системы в виде диаграммы потоков данных (DataFlowDiagram – DFD). Диаграммы потоков данных предназначены прежде всего для описания документооборота и обработки информации,хотя допускают и представлениедругих объектов. При создании диаграммы потоков данных используются четыре основных понятия: потоки данных; процессы (работы) преобразования входных потоков данных в выходные; внешние сущности; накопители данных (хранилища). Потоки данных являются абстракциями,использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации. Процессы (работы)служат для преобразования входных потоков данных в выходные. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, «получить документы по отгрузке продукции»). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель ) данных моделирует данные,которые будутсохраняться в памяти между процессами. Информация, которую содержит хранилище, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным. Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником данных. Ее имя должно содержать существительное, например, « склад товаров ». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке. Кроме основных элементов, в состав DFD входят словари данных и миниспецификации. Словари данных являются каталогами всех элементов данных,присутствующих в DFD, включая потоки данных, хранилища и процессы, а также все их атрибуты. Миниспецификации обработки – описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы. Диаграммы потоков данных строятся в виде иерархии. Сначала строится контекстная диаграмма. При проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме должно быть по возможности небольшим , поскольку каждый из них может быть в дальнейшем разбит на несколько потоков на следующих уровнях диаграммы. Для сложных систем (признаками сложности могут быть наличие большого количества внешних сущностей (десять и более), распределенная природа системы или ее многофункциональность) строится иерархия контекстных диаграмм.При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. Для проверки контекстной диаграммы можно составить список событий.Список событий должен состоять из описаний действий внешних сущностей ( событий ) и соответствующих реакций системы на события. Каждое событие должно соответствовать одному или более потокам данных: входные потоки интерпретируются как воздействия, а выходные потоки – как реакции системы на входные потоки. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификация процесса должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев: наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока); возможности описания преобразования данных процессов в виде последовательного алгоритма; выполнения процессом единственной логической функции преобразования входной информации в выходную; возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк). В качестве языка спецификаций обычно используются структурированный естественный язык или псевдокод. В методологии DFD используются две нотации: Йодана-Де Марко (Yourdan) и Гейна-Сарсона (Gane-Sarson) – таблица 3.1. Следует отметить, что в BPwin формально используется нотация Гейна-Сарсона, но с рядом отступлений: отсутствуют миниспецификации, отличается изображение функций, контекстная диаграмма не может содержать подсистемы. Сравнивая методологии DFD и IDEF0, можно отметить, что в методологии DFD, кроме расширения изобразительных возможностей диаграмм (за счет хранилищ данных ), изменяются правила интерфейсов для стрелок: стрелки могут входить и выходить с любой стороны блока. Таблица 1.1 - Элементы методологии DFD в нотациях Гейна-Сарсона и Йодана-Де Марко  3.4 Методология IDEF3 IDEF3 является стандартом документирования технологических процессов,происходящих на предприятии,и предоставляет инструментарий длянаглядного исследования и моделирования их сценариев. Сценарием (Scenario) называется описание последовательности изменений свойств объекта в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цехе и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологические карты, стандарты и т.д.), и документов , отображающих ход его выполнения (результаты тестов и экспертиз, отчеты о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи: Документировать данные о технологии процесса. Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов. Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например, изменение конструктивных, технологических или эксплуатационных свойств конечного продукта. Содействовать принятию оптимальных решений при реорганизации технологических процессов. Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..." Такая возможность существует при использовании, например, системы имитационного моделирования ARENA. Существуют два типа диаграмм в стандарте IDEF3, представляющих описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы, относящиеся к первому типу, называются диаграммами потокового описания процесса (ProcessFlowDescriptionDiagrams, PFDD),а ко второму – диаграммами сети изменения состояний объектов (ObjectState TransitionNetwork, OSTN). Рассмотрим пример. Предположим, требуется описать процесс окраски детали в производственном цехе на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки. На следующем примере опишем, как графические средства IDEF3 позволяют документировать вышеуказанный производственный процесс окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку.  Рисунок 3.8 - Пример PFDD диаграммы На рисунке 3.8 изображена диаграмма PFDD, являющаяся графическим отображением сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (UnitofBehavior, UOB)1 и обозначают событие, стадию процесса или принятие решения . Каждый UOB имеет свое имя, отображаемое в глагольном наклонении, и уникальный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия, полученного в результате декомпозиции, обычно предваряется номером его родителя (рисунок 3.9).  Рисунок 3.9 - Изображение и нумерация действия в диаграмме IDEF3 Существенные взаимоотношения между действиями изображаются с помощью связей. Все связи в IDEF3 являются однонаправленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В таблице 3.2 приведены три возможных типа связей. Стандарт предусматривает и другие типы стрелок, но они малоприменимы и не поддерживаются CASE-системами. Таблица 3.2 - Типы связей IDEF3  Связь типа "временное предшествование" показывает,что исходноедействие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь типа "объектный поток" используется в том случае,когда некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Обозначение такой связи отличается от связи временного предшествования двойной стрелкой. Наименования потоковых связей должны четко идентифицировать объект , который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования , это означает , что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие может начать выполняться. Связь типа "нечеткое отношение" используется для выделения отношений между действиями, которые невозможно описать с использованием связей предшествования или объектных связей. Обычно эти связи указывают, что между объектам существуют некоторые отношения, но на момент описания процесса они не определены. Объект, обозначенный на рисунке 3.8 как J1, называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-inJunction) и перекрестки для разветвления (Fan-outJunction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице 3.3. Таблица 3.3 – Типы перекрестков  Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J". Сценарий, отображаемый на диаграмме, можно описать в следующем виде. Деталь поступает в окрасочный цех, подготовленной к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки. Описания процессов могут состоять из нескольких сценариев и содержать как диаграммы PFDD, так и OSTN. Для обозначения отношений и связей между UOB различных уровней PFDD и OSTN диаграмм и разных сценариев в IDEF3 используются специальные ссылки (Referents). Ссылки могут использоваться: для обращения к ранее определенному функциональному модулю UOBбез повторения его описания; для передачи управления или индикации наличия циклических действий при выполнении процесса; организации связи между диаграммами описания процесса PFDD и OSTNдиаграммами. Соответственно, выделяют следующие типы ссылок: GOTO–циклический переход(в повторяющейся последовательностиUOW),возможно,на текущей диаграмме,но не обязательно.Если всеUOWцикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую UOW. GOTO может ссылаться на перекресток. UOB–экземпляр другого,ранее определенногоUOB,выполняется вопределенной точке. Например, UOB "Контроль качества" может быть использован в процессе "Изготовление редуктора" несколько раз, после каждой единичной операции. SCENARIO–название сценария.Эта ссылка означает,что должна бытьпроизведена активизация всех декомпозиций указанного сценария. TS (Transition Schematic) –переход на схему.Это ссылка на соответствующую диаграмму, т. е. процесс, на который ссылаются, должен быть инициализирован. NOTE(примечание)используется для документирования информации,относящейся к каким-либо графическим объектам на диаграмме. Элемент «примечание» может использоваться как в диаграммах описания процесса, так и объектных диаграммах OSTN. Этот элемент может быть применен к функциональному элементу UOW, перекрестку, связи, объекту или ссылке. Отметим, что в BPwin используются немного другие ссылки. Методология IDEF3 определяет два вида ссылок по способу запуска. Ссылка "Вызвать и продолжить" (CallandContinueReferent)указывает,чтоэлемент, указанный в ссылке, должен быть активизирован до завершения выполнения действия модулем, к которому относится ссылка. Ссылка "Вызвать и ждать" (CallandWaitReferent),указывает,что элемент,указанный в ссылке, должен начать и закончить выполнение действия до завершения действия модулем, к которому относится ссылка. Графические обозначения ссылок приведены на рисунке 3.10. В основном поле символа ссылки указывается её тип (ReferentType) "UOB", "SCENARIO", "TS" или "GOTO" и через дробь "Label" – уникальное наименование блока, сценария, схемы или функции узла, на который указывает ссылка. В поле "Locator" указывается уникальный идентификатор элемента, указанного в ссылке. Пример использования ссылок показан на рисунке 3.11  Рисунок 3.10 - Графическое обозначение ссылок  Рисунок 3.11 - Примеры использования ссылок Каждый функциональный блок UOB может иметь последовательность декомпозиций,и,следовательно,может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOBс помощью отдельнойIDEF3диаграммы.Например,мы можем декомпозировать UOB "Окрасить Деталь", представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рисунке 3.8, а та, соответственно, родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации. На рисунке 3.12 приведен пример декомпозиции модулей (UOB) и принцип формирования их номеров. Для наглядности все модули представлены на одном рисунке, но в IDEF3 они отображаются в трех диаграммах. Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Возможность множественной декомпозиции отражается в нумерации работ: номер работы состоит из номера родительской работы, номера декомпозиции и номера работы на текущей диаграмме. На рисунке 3.13 представлен пример двух вариантов декомпозиции родительского модуля.  Рисунок 3.12 - Декомпозиция функциональных блоков  Рисунок 3.13 - Пример двух вариантов декомпозиции модуля Если диаграммы PFDD описывают технологический процесс "с точки зрения наблюдателя ", то другой класс диаграмм OSTN – диаграммы сети изменения состояний объектов (не поддерживаются вBPwin)позволяет рассматривать тот же самый процесс "с точки зрения объекта". С ее помощью можно графически представить, как одни виды объектов преобразуются в другие или изменяют свое состояние в ходе выполнения рассматриваемого процесса. На OSTN состояния объектов изображаются окружностями с именем объекта внутри, а изменения состояний − соединительными линиями. Состояние объекта описывается фактами и ограничениями, которые должны выполняться, чтобы объект находился в данном состоянии. Требования для перехода объекта в заданное состояние определяются условиями входа. Условия выхода говорят о ситуации, в которой объект выходит из заданного состояния. Эти ограничения описываются в списке свойств. Связи переходов состояний задают возможные способы изменения состояний объектов. Для изображения последовательностей переходов объектов из одного вида в другой и изображения перехода одного и того же объекта из одного состояния в другое в диаграммах OSTN используются связи переходов (Transition Links), которые бывают слабыми (Weak Transition Link) и сильными(Strong Transition Link).Слабые связи переходов изображаются сплошными одинарными стрелками (рисунок 3.14) и показывают, что объекту вида В предшествует объект вида А или что состоянию В некоторого объекта предшествует его состояние А.  Рисунок 3.14 - Пример слабой связи переходов Сильные связи переходов изображаются двойными однонаправленнымистрелками (рис. 1.15) и подчеркивают, что объекту вида В должен предшествовать объект вида А или что состояние В объекта достижимо только из состояния А.  Рисунок 3.15 - Пример сильной связи переходов В диаграммах OSTN используются те же виды ссылок, что и в диаграммах PFDD. Исключение составляет лишь ссылка типа GOTO, которая используется только в диаграммах потоковых процессов PFDD. Ссылки могут относиться как к символу объекта, так и к связи перехода. Соответственно, они интерпретируются как действия, которые необходимо осуществлять для поддержания объекта в данном виде или состоянии, или как действия, которые необходимы для преобразования вида или состояния объекта. Так как процессы поддержания объекта в определенном состоянии и его преобразования могут быть сложными, то допускается использование нескольких ссылок к любому элементу OSTN диаграммы. На диаграммах OSTN могут использоваться перекрестки. Перекресток изображается кружком, внутри которого содержится условное обозначение логической функции, реализуемой перекрестком В качестве логических функций могут использоваться И (&), ИЛИ (O) и ИСКЛЮЧАЮЩЕЕ ИЛИ (X). Как и на диаграммах PFDD, узлы перехода могут означать слияние и разветвление. Но на диаграммах OSTN перекрестки не делятся на асинхронные и синхронные. На рисунке 3.16 показан пример использования узла разветвления с логической функцией ИЛИ.  Рисунок 3.16 - Пример перекрестка с логической функцией ИЛИ Диаграмма рис. 1.16 означает, что под действиями UOB с именем P объект из состояния А может перейти в одно или сразу несколько состояний из множества возможных: B1, В2, …, Вn. Если бы в качестве логической функции использовалась функция ИСКЛЮЧАЮЩЕЕ ИЛИ, то это говорило бы, что возможен переход только в одно из возможных состояний B1, В2, …, Вn. Использование же функции И в перекрестке отображало бы переход объекта из состояния А сразу во все состояния B1, В2, …, Вn. На рисунке 3.17 представлено отображение процесса окраски с точки зрения OSTN диаграммы.  Рисунок 3.17 - Пример OSTN диаграммы BPwin имеет возможность преобразования диаграмм IDEF3 в имитационную модель популярной системы моделирования Arena.. Контрольные вопросы Дайте определение IDEF0-модели. Что называется декомпозицией в методологии IDEF0? Дайте определение IDEF3-модели. Что отражает DFD-диаграмма? Назовите различия между контекстными диаграммами при IDEF0- и DFD-моделировании? 4 Проектирование программного обеспечения при объектном подходе Задачи проектирования включают в себя две составляющие: логическое и физическое проектирование программных продуктов. Логическое проектирование заключается в разработке классов для реализации их экземпляров — объектов. Для этого требуется подробное описание полей и методов классов, а также связей между ними. Для этого используются статические диаграммы классов и объектов, динамические — последовательностей состояний и кооперации. Физическое проектирование предполагает построение программных компонентов из ранее определенных классов и объектов и размещение их на конкретных вычислительных устройствах. Разрабатываемые на этом этапе диаграммы — компонентов и развертывания. 4.1 Разработка структуры программного обеспечения при объектном подходе. Основы унифицированного языка моделирования UML На этапе проектирования уточняются поля и методы классов, а также отношения между классами. Все это находит отражение на диаграмме классов. Для уточнения содержания некоторых классов на диаграмме используют следующие обозначения: управляющий класс (control class) отвечает за координацию действий других классов и контролирует последовательность выполнения действий варианта использования для данного ПО. На каждой диаграмме классов должен быть хотя бы один управляющий класс (рисунок 4.1, а). класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно. Как правило, этот класс соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции — присоединенными или хранимыми процедура ми рисунок 4.1, 6); граничный класс (boundary class) располагается на границе системы с внешней средой. К этому типу относят как классы, реализующие пользовательские интерфейсы, так и классы, обеспечивающие интерфейс с аппаратными средствами или программными системами (рисунок 4.1, в).  Рисунок 4.1 – Графическое изображение классов моделирования программного обеспечения |