ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.02.2024
Просмотров: 289
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Потоки данных являются абстракциями,использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Процессы (работы)служат для преобразования входных потоков данных в выходные. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, «получить документы по отгрузке продукции»). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель ) данных моделирует данные,которые будутсохраняться в памяти между процессами. Информация, которую содержит хранилище, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.
Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником данных. Ее имя должно содержать существительное, например, « склад товаров ». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.
Кроме основных элементов, в состав 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–циклический переход(в повторяющейся последовательности