В чем состоит особенность структурного подхода к проектированию ИС? Опишите основные принципы структурного подхода и объясните на решение каких задач он ориентирован.



Мы поможем в написании ваших работ!


Мы поможем в написании ваших работ!



Мы поможем в написании ваших работ!


ЗНАЕТЕ ЛИ ВЫ?

В чем состоит особенность структурного подхода к проектированию ИС? Опишите основные принципы структурного подхода и объясните на решение каких задач он ориентирован.



Вопросы к рейтингу 2 для ИС-09

 

 

Приведите и опишите шаги, которые необходимо выполнить при использовании методологии «ускоренного» описании БП. Перечислите ее достоинства и недостатки. В каком случае целесообразно применять данную методологию?

Шаг 1. Определить внешних клиентов организации и входы/выходы для организации в целом.

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

Шаг 2.Составить перечень основных бизнес-процессов организации, формирующих внешние выходы.

Выделение основных бизнес-процессов организации осуществляется на основе информации о внешнем окружении и основных информационных и материальных потоках по принципу «клиент процесса ® потребляемый им продукт ® основной бизнес-процесс организации». Количество основных бизнес-процессов, которые могут быть выделены, желательно ограничивать (не более 7± 2). Кроме основных процессов, должны быть определены вспомогательные процессы. Общее количество процессов верхнего уровня не должно превышать 13-15.

Шаг 3.Определить внутренние входы/выходы каждого процесса и определить недостающие вспомогательные бизнес-процессы.

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

Шаг 4.Описать каждый бизнес-процесс в виде набора функций.

Каждый процесс, выделенный при выполнении шагов 2-3, описывается в виде набора функций (подпроцессов нижнего уровня). Формируется перечень функций, входящих в процесс. Эта работа может выполняться как с использованием специальной среды моделирования, так и простейшим средствами MS Word или Excel. Как определять функции, входящие в процесс? Для этого пользуются существующей документацией (положения о подразделениях, инструкции и т.д.). Как правило, такая документация является актуальной лишь на 30-40% - реально выполняемые функции отличаются от «бумажных». Рабочей группе приходится собирать информацию путем интервьюирования или анкетирования сотрудников и руководителей функциональных подразделений организации.

Шаг 5.Распределить полученные функции по подразделениям организации.

Полученные при выполнении шага 4 функции должны быть приписаны к конкретным функциональным подразделениям организации. Эта простая, на первый взгляд, задача на практике решается достаточно сложно, т.к. возникают противоречия по распределению ответственности и полномочий между руководителями функциональных подразделений. Такая ситуация обусловлена субъективностью определения границ бизнес-процессов и распределения функций между ними. Для снижения субъективности разработаны специальные методики, подробнее о которых можно узнать в [4]. Суть одно из методов состоит в том, что деятельность каждого подразделения может рассматриваться, как процесс. Поэтому задача распределения частей «большого» процесса между подразделениями существенно упрощается.

Шаг 6. Детально описать каждый процесс при помощи выбранной методики (IDEF0, IDEF3, DFD, ARIS VAD, ARIS eEPC).

 

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

Шаг 7.Составить регламенты по каждому бизнес-процессу. Сформировать матрицы ответственности по каждому бизнес-процессу.

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

1. «регламент выполнения процесса»;

2. положения о подразделениях;

3. должностные инструкции исполнителей;

4. рабочие инструкции исполнителей.

 

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

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

Рассмотренный «ускоренный» метод описания бизнес-процессов организации обладает рядом недостатков, к числу которых относятся:

1. субъективность определения перечня процессов верхнего уровня и привязки к ним внешних входов/выходов;

2. сложность и субъективность определения внутренних входов/выходов для основных и вспомогательных процессов;

3. субъективность определения вспомогательных процессов;

4. сложность и субъективность отнесения функций организации к тем или иным процессам;

5. при детальном описании границы процессов подвержены сильным изменениям;

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

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

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

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

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

 

Приведите и опишите шаги, которые необходимо выполнить при использовании методологии «полного» описании БП. Перечислите ее достоинства и недостатки. В каком случае целесообразно применять данную методологию?

Шаг 1.Определить внешних клиентов организации (окружения) и входы/выходы для организации в целом.

 

При выполнении первого шага рассматривается организация в целом и ее окружение. Определяются внешние входы и выходы. Результатом работ является спецификация входов/выходов и окружения организации. Важно отметить, что входы/выходы должны быть указаны в спецификации на верхнем уровне. Например, было бы неправильно включать в спецификацию такие позиции, как «накладная», «готовое изделие» и т.п. Нужно включать агрегированные позиции: «документы на отгрузку», «готовые изделия» и т.п.

Шаг 2. Привязать полученные входы/выходы к подразделениям организации.

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

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

Очевидно, что субъективность работ по привязке входов/выходов к подразделениям на этом этапе минимальная или вообще отсутствует.

Шаг 3.Определить внутренние входы/выходы для каждого подразделения организации.

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

Шаг 4. Определить перечень функций, выполняемых в каждом подразделении.

 

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

Для каждого подразделения формируется перечень выполняемых в нем функций. Именно на этом этапе начинает сказываться элемент субъективности. Как правило, реально выполняемые в подразделениях функции отражены в формальных документах лишь на 30-40%. Дело в том, что положения о подразделениях, инструкции и другие документы редко пересматриваются и не являются актуальными. Такое положение обусловлено в первую очередь отношением руководства компании к регламентирующей документации и отсутствием системы работы с документацией. Такое положение дел является характерным для российских организаций. В других странах (Европа, Япония, США) в крупных компаниях система управления документацией существует хотя бы в формальном виде. Дело в том, что подавляющее число предприятий развитых стран сертифицировано по стандартам ISO-9000, одним из требований которых является управление документацией. В настоящее время в России многие руководители осознают важность регламентации работы при помощи документации процессов и инициируют соответствующие проекты.

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

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

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

 

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

Шаг 6.Используя входы/выходы между подразделениями сгруппировать бизнес-процессы подразделений в бизнес-процессы организации.

 

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

Таким образом, все функции подразделений оказываются отнесенными к определенным бизнес-процессам.

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

 

Шаг 7.Сформировать матрицы ответственности по каждому подразделению. На основе этих матриц составить матрицы ответственности бизнес-процессов организации.

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

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

К недостаткам данного метода можно отнести:

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

2. значительная длительность описания (8-12 месяцев);

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

3. Дайте сравнительный анализ методологий «ускоренного» и «полного» описания бизнес-процессов организации.Какие существуют варианты перераспределения функций между процессами? Перечислите последовательность выполнения действий по перераспределению функций и их результаты.

Сравнение методологий описания процессов.

Критерий сравнения Методология 1 («ускоренное» описание БП) Методология 2 («полное» описание БП)
Степень субъективности Высокая Незначительная
Полнота описания деятельности организации Фрагментарное описание Полное описание
Длительность выполнения проекта 2-3 месяца 6-12 месяцев
Корректность полученных моделей процессов 40-80% соответствия реальным процессам 80-90% соответствия реальным процессам
Степень участия руководителей и сотрудников организации в проекте Незначительная Высокая
Трудоемкость выполнения проекта Средняя Высокая
Степень риска неудачи проекта (при наличии поддержки руководства) 30-70% 0%
Степень риска неудачи проекта (при отсутствии поддержки руководства) 80-100% 20-30%
Возможность использования результатов проекта (полученной информации в виде моделей) на 20-40% на 80-90%

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

Рассматривается некоторый бизнес-процесс «А». У этого бизнес-процесса есть владелец, отвечающий за его результативность и эффективность. Процесс выполняется по определенной технологии. Представим себе, что некоторый документ (или продукт), формируемый по ходу выполнения процесса «А», должен быть изменен (проверен, доработан и т.п.) в процессе «Б» (функция «Х»). В данном случае бизнес-процесс «Б» фактически является субподрядчиком (или поставщиком) бизнес-процесса «А».

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

 

Прежде всего, необходимо выполнить анализ деятельности . Следует выполнить анализ возможности и целесообразности выполнения функции «Х» в процессе «А»:

1. наличие в процессе «А» ресурсов, необходимых для выполнения функции «Х»;

2. квалификация персонала, требуемая для выполнения функции «Х»;

3. экономическое обоснование целесообразности выполнения функции «Х» в процессе «А» (сокращение времени выполнения процесса, снижение затрат, сокращение числа несоответствий и т.п.).

 

Следует так же проанализировать, как выполняется функция «Х» в процессе «Б»:

1. анализ выполнения функции «Х» (сложность технологии, степень специализации персонала, потребность в ресурсах, юридические аспекты);

2. степень загрузки функции «Х» (% времени) по созданию продуктов для процесса «А» (необходимо выяснить, создает ли функция «Х» продукты/услуги для других клиентов, кроме продуктов для процесса «А»);

3. экономический анализ целесообразности выполнения функции «Х» в процессе «Б».

Целесообразно, чтобы анализ проводился совместно владельцем процесса «А» и владельцем процесса «Б».

Анализ выполнения функции «Х» и взаимодействия процессов «А» и «Б» позволяет сделать вывод о целесообразности передачи функции «Х» в процесс «А». Возможно несколько вариантов реорганизации. Некоторые их них представлены ниже.

Рассмотрим первый вариант возможной реорганизации. Если анализ показывает, что функцию «Х» целесообразно оставить в процессе «Б» (например, для выполнения функции «Х» требуется специальное оборудование, сложная технология и узкоспециализированный персонал), то необходимо более четко регламентировать взаимодействие между процессами «А» и «Б». Для этого определяется формы, сроки передачи документов (продуктов), ответственные лица. Далее согласованная информация заносится в регламент выполнения процесса «А» и в регламент выполнения процесса «Б». Кроме того, в процессах должны быть установлены контрольные точки (места для сбора информации), необходимые для анализа информации об отклонениях.

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

 

Вторым вариантом реорганизации является передача функции «Х» из процесса «Б» в процесс «А». Такая передача может быть осуществлена только после проведения тщательного анализа целесообразности (в т.ч. при помощи экономических оценок). Например, если функция «Х» не требует для своего выполнения существенных ресурсов, узкоспециализированных специалистов и в процентном отношении на 100% выполняется для процесса «А», то, вероятно, ее целесообразно передать в процесс «А»,

 

Третьим вариантом реорганизации является создание в рамках процесса «А» новой функции «Х» . В качестве примера можно привести ситуацию, когда функция «Х» не требует для своего выполнения существенных ресурсов, узкоспециализированных специалистов, но в процентном отношении «работает на» процесс «А» лишь частично (не 100% времени). Целесообразность создания в процессе «А» функции «Х», дублирующей аналогичную функцию в процессе «Б», должна быть обоснована экономическим расчетом. (В качестве примера можно привести случай, когда выполнение функции «Х» в процессе «Б» и транспортировка результатов ее выполнения из процесса «Б» в процесс «А» дороже, чем выполнение функции «А» в процессе «А»).

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

Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6-7); ограниченный контекст, включающий лишь существенные на каждом уровне детали; дуальность данных и операций над ними; использование строгих формальных правил записи; последовательное приближение к конечному результату.

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

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

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

2. Принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы.

3. Принцип упрятывания – заключается в упрятывании несущественной на конкретном этапе информации: каждая часть «знает» только необходимую ей информацию.

4. Принцип концептуальной общности – заключается в следовании единой философии на всех этапах ЖЦ (структурный анализ – структурное проектирование – структурное программирование – структурное тестирование).

5. Принцип полноты – заключается в контроле на присутствие лишних элементов.

6. Принцип непротиворечивости – заключается в обоснованности и согласованности элементов.

7. Принцип логической независимости – заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.

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

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

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

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

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

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

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

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

· спецификация системы из-за объема и технических терминов часто непонятна для заказчика;

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

 

Связи

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

 

Стиль стрелок устанавливается с помощью выбора соответствующей стрелки в окне свойств стрелки. (Щелчок правой кнопкой мыши по стрелке ® Style ® Type.)

 

Старшая (Precedence) – сплошная линия, связывающая единицы работ (UOW), Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Отношения (Relational Link) – пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.
Потоки объектов (Object Flow) – стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.

Перекрестки (Junctions)

Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления.

 

Для внесения перекрестка служит кнопка в палитре инструментов –Junction Tool. При добавлении в диаграмму перекрестка, необходимо выбрать его тип в открывающемся диалоговом окне.

 

Описание каждого типа перекрестков приведен в таблице 4.

 

Таблица 4. Типы перекрестков
Обозначение Наименование Смысл в случае слияния стрелок (Fan-in Junction) Смысл в случае разветвления стрелок (Fan-out Junction)
Asynchronous AND Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены
Synchronous AND Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно
Asynchronous OR Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены
Synchronous OR Один или несколько предшествующих процессов завершены одновременно Один или несколько следующих процессов запускаются одновременно
XOR (Exclusive OR) Только один предшествующий процесс завершен Только один следующий процесс запускается

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. После добавления перекрестка, возможно изменение его типа и свойств с помощью диалогового окна Junction Properties.

В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Объекты ссылки

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

Рис. 2. Пример использования объекта ссылки

 

Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Arrow Properties, в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Для внесения объекта ссылки служит кнопка Referent Tool в палитре инструментов.

 

Объекты ссылки должны быть связаны с единицами работ или перекрестками. Официальная спецификация IDEF3 различает три стиля объектов ссылок – безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

Объект ссылка помимо имени может характеризоваться типом. Типы объектов ссылок приведены в таблице 5. Имя объекта ссылки чаще всего включает его тип (рис.60).

Таблица 5. Типы объектов ссылок
Тип объекта ссылки Цель описания
OBJECT Описывает участие важного объекта в работе.
GOTO Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекресток.
UOB (Unit of behavior) Применятся, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа «Контроль качества» может быть использована в процессе «Изготовления изделия» несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ.
NOTE Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму.
ELAB (Elaboration) Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках.

 

11. Какую роль в IDEF3 играют перекрестки? Опишите существующие типы перекрестков, приведите примеры их использования.

Перекрестки (Junctions)

Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления.

 

Для внесения перекрестка служит кнопка в палитре инструментов –Junction Tool. При добавлении в диаграмму перекрестка, необходимо выбрать его тип в открывающемся диалоговом окне.

 

Описание каждого типа перекрестков приведен в таблице 4.

 

Таблица 4. Типы перекрестков
Обозначение Наименование Смысл в случае слияния стрелок (Fan-in Junction) Смысл в случае разветвления стрелок (Fan-out Junction)
Asynchronous AND Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены
Synchronous AND Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно
Asynchronous OR Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены
Synchronous OR Один или несколько предшествующих процессов завершены одновременно Один или несколько следующих процессов запускаются одновременно
XOR (Exclusive OR) Только один предшествующий процесс завершен Только один следующий процесс запускается

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. После добавления перекрестка, возможно изменение его типа и свойств с помощью диалогового окна Junction Properties.

В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Рассмотрим примеры, иллюстрирующие использование перекрестков.

Фрагмент диаграммы, представленной на рис.57 иллюстрирует процесс выдачи наличных кассиром банка. Перекресток J1 обозначает ситуацию, когда любой из последующих процессов (А1.1 или А1.2) должны быть запущены. Перекресток J2 означает, что для продолжения выполнения работ, следующих за перекрестком необходимо завершение хотя бы одного из предшествующих процессов.

Рис. 3. Фрагмент диаграммы выдачи кассиром банка наличных денег

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



Последнее изменение этой страницы: 2016-09-05; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.229.142.91 (0.015 с.)