Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
Скачать 1.64 Mb.
|
Внешняя сущность представляет собой субъект окружающей среды (юридическое или физическое лицо, иногда материальный предмет), представ- ляющее собой источник или приемник информации, например, заказчики, по- ставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущ- ности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и их исполни- тели будут представлены как внешние сущности. Внешняя сущность обозначается прямоугольником (рис. 4.37), располо- женным как бы «над» диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений. Рис. 4.37. Внешняя сущность Внешние сущности обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или не- скольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок 225 Потоки данных описывают движение информации из одной части си- стемы в другую. Поток данных на диаграмме изображается линией, оканчива- ющейся стрелкой, которая показывает направление потока (рис. 4.38). Каждый поток данных имеет имя, отражающее его содержание. Рис. 4.38. Поток данных Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоуголь- ника работы. В DFD могут также применяться двунаправленные стрелки для описания диалогов типа «команда-ответ» между работами, между работой и внешней сущностью и между внешними сущностями. Понятие «потоки данных» является абстракцией, использующейся для моделирования передачи информации (или физических компонент) из одной части системы в другую. Информация передается через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного ком- пьютера на другой и т.д. Источники информации (внешние сущности) порождают информацион- ные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации. Хранилище (накопитель данных) позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Ин- 226 формация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя храни- лища должно определять его содержимое и быть существительным. Накопитель данных на диаграмме потоков данных изображается, как по- казано на рис. 4.39. Рис. 4.39. Накопитель данных Накопитель данных идентифицируется буквой «D» и произвольным чис- лом. Имя накопителя выбирается из соображения наибольшей информативно- сти для проектировщика. Накопитель данных в большинстве случаев является прообразом суще- ствующей или будущей базы данных (или таблицы БД) и описание хранящихся в нем данных должно быть увязано с информационной моделью. В широком смысле накопитель данныхпредставляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопи- тель и через некоторое время извлечь. Причем способы помещения и извлече- ния могут быть любыми, а физически накопитель данных может быть реализо- ван в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Словари данных являются каталогами всех элементов данных, присут- ствующих в DFD, включая групповые и индивидуальные потоки данных, хра- нилища и процессы, а также все их атрибуты. Миниспецификации обработки описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описа- ния задач, выполняемых процессами. Множество всех миниспецификаций яв- ляется полной спецификацией системы. Таким образом, диаграммы верхних уровней иерархии (контекстные диа- граммы) определяют основные процессы (подсистемы) с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Деком- 227 позиция продолжается до тех пор, пока не будет достигнут такой уровень де- композиции, на котором процессы становятся элементарными и детализировать их далее невозможно. Стрелки DFD показывают, как данные двигаются от одной работы к дру- гой. Диаграммы DFD содержат элементы для обозначения внешних сущностей ( источников и приемников данных), а также хранилищ данных. Процессы и по- токи информации совместно с хранилищами и внешними сущностями на DFD представляют функциональную часть ИС, информационное обеспечение, а так- же границы предметной области моделирования. Для описания последовательности и условий выполнения процессов ис- пользуют методологию IDEF3 моделирования потоков работ. IDEF 3 захватывает также поведенческие аспекты существующих или предполагаемых систем, структурируя процессы в контексте определенных сценариев. Моделирование потоков работ Описание стандарта Метод моделирования потоков работ IDEF3 (workflow diagramming, WFD ), являющийся частью семейства стандартов IDEF, был разработан в конце 1980- х годов для закрытого проекта ВВС США и был предназначен для моде- лирования таких процессов, в которых необходимо понять последовательность выполнения операций и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приоб- рел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 и методу DFD. Модели IDEF3 могут использоваться для описания сценариев или правил выполнения процессов, представленных функциональными блоками на диа- граммах IDEF0 и DFD. 228 IDEF3 позволяет описать следующее: • последовательность выполнения процессов; • условия перехода от одной операции к другой; • объекты, участвующие совместно в одном процессе. Схемы IDEF3 содержат следующие элементы: • логические операторы (блоки принятия решений); • события начала и окончания процесса; • элементы, показывающие временные задержки. С помощью логических операторов показывается, в каких случаях про- цесс протекает по одной технологии, а в каких – по другой. Например, с помо- щью данных элементов можно описать ситуацию, когда договор, стоимость ко- торого меньше определенной суммы, согласуется одной группой сотрудников, а договор с большей стоимостью согласуется по более сложной технологии или цепочке, в которой участвует большее количество сотрудников. С помощью событий начала и окончания процесса показывается, когда процесс начинается и когда заканчивается. Для жестко формализованных биз- нес-процессов, например, таких, как бюджетирование, в качестве событий мо- жет выступать время. В случаях, когда описание бизнес-процесса проводится с целью его даль- нейшей временной оптимизации, используют элементы задержки времени, ко- торые показывают места, в которых между последовательно выполняемыми работами имеется временной разрыв. Например, можно показать, что последу- ющая работа начинается только через некоторое время после завершения предшествующей. IDEF3 является стандартом документирования информационных, техно- логических и иных процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием (Scenario) – описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание по- 229 следовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующими пото- ками информации, например, в виде документов. На промышленном предприя- тии документооборот производственных процессов состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отоб- ражающих ход его выполнения (результатов тестов и экспертиз, отчетов о бра- ке, и т.д.). Для эффективного управления любым процессом, необходимо иметь де- тальное представление об его сценарии и структуре сопутствующего докумен- тооборота. Средства документирования и моделирования IDEF3 позволяют вы- полнять следующие задачи: • документировать имеющиеся данные о технологии процесса, выявлен- ные, в процессе предпроектного обследования путем опроса компетент- ных сотрудников, ответственных за организацию рассматриваемого про- цесса; • определять и анализировать точки слияния и разделения потоков инфор- мации; • определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса; • содействовать принятию оптимальных решений при реорганизации про- цессов; • разрабатывать модели процессов, по принципу "КАК БУДЕТ, ЕСЛИ..." IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функ- ция (функциональный блок IDEF0) может быть представлена в виде отдельного процесса средствами IDEF3. 230 Два типа диаграмм в IDEF3 Существуют два типа диаграмм в стандарте IDEF3, представляющие опи- сание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD). Иное встречающееся название для PFDD – диаграмма работ WFD (Work Flow Diagram). Ко второму типу относятся диаграммы Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN). Пример. Требуется задокументировать процесс окраски детали в произ- водственном цеху на предприятии. С помощью диаграмм PFDD документиру- ется последовательность и описание стадий обработки детали в рамках иссле- дуемого технологического процесса. Диаграммы OSTN используются для ил- люстрации трансформаций детали, которые происходят на каждой стадии об- работки. Процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выяв- ления брака) или отправить ее в дальнейшую обработку. На рис. 4.40 изобра- жена диаграмма PFDD, являющаяся графическим отображение сценария обра- ботки детали. Рис. 4.40. Пример PFDD диаграммы окраски детали 231 Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB- блоками в ходе процесса. Объект, обозначенный J1 – называется перекрестком(Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следую- щей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan- out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходи- мо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице 4.3. Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J". Сценарий, отображаемый на диаграмме, можно описать в следующем ви- де. Деталь поступает в окрасочный цех подготовленной к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново про- пускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки. 232 Таблица 4.3. Классификация перекрестков Обозна- чение Наименование Смысл в случае слияния стрелок (Fan-in Junction) Смысл в случае разветвления стрелок (Fan-out Junction) Asynchronous AND Все предшествующие процес- сы должны быть завершены Все следующие процессы долж- ны быть запущены Synchronous AND Все предшествующие процес- сы завершены одновременно Все следующие процессы запус- каются одновременно Asynchronous OR Один или несколько предше- ствующих процессов должны быть завершены Один или несколько следующих процессов должны быть запуще- ны Synchronous OR Один или несколько предше- ствующих процессов завер- шаются одновременно Один или несколько следующих процессов запускаются одновре- менно XOR (Exclusive OR) Только один предшествующий процесс завершен Только один следующий процесс запускается Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необхо- димой точностью. Под декомпозицией понимается представление каждого UOB с помощью отдельной IDEF3 диаграммы. Пример. Можно декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней по отношению к изображенной на рис., а та, соответственно, родительской. Номера UOB дочерних диаграмм имеют иерархическую нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1», «1.2» и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации. 233 Диаграммы состояния объекта и его трансформаций в процессе (Object State Transition Network, OSTN) Если диаграммы PFDD рассматривают технологический процесс «с точки зрения наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рас- сматривать тот же самый процесс с точки зрения объекта. На рис. 4.41 пред- ставлена OSTN диаграмма процесса окраски с точки зрения детали. Рис. 4.41. Пример OSTN диаграммы Состояния объекта (в нашем случае детали) и изменение состоянияяв- ляются ключевыми понятиями OSTN диаграммы. Состоянияобъекта отобра- жаются окружностями, а их изменения – направленными линиями. Каждая ли- ния имеет ссылку на соответствующий функциональный блок UOB, в результа- те которого произошло отображаемое ей изменение состояния объекта. На рис. 4.42 приведен более сложный пример IDEF3 диаграммы. 234 Рис. 4.42. Фрагмент PFDD диаграммы Отличительной особенностью IDEF3-диаграммы является то, что стрелки между операциями бизнес-процесса обозначают не потоки объектов (информа- ционные и материальные), а временную последовательность выполнения работ. IDEF3 используют в основном для описания бизнес-процессов нижнего уровня детализации (детальные работы, по названию которых понятно, что яв- ляется входом и что – выходом) и могут быть использованы для анализа завер- шенности процедур обработки информации. IDEF3 дополняет IDEF0 и DFD и содержит все необходимое для построе- ния моделей, которые в дальнейшем могут быть использованы для имитаци- онного анализа. Имитационное моделирование Имитационное моделирование может служить для получения оценоч- ных аспектов моделирования предметной области, которые связаны с разраба- тываемыми показателями эффективности автоматизируемых процессов. Имитационное моделированиезаключается в построении и исследовании имитационной модели. Имитационные модели – это динамические модели, 235 учитывающие время выполнения операций, и позволяющие анализировать ди- намику бизнес-процессов. Имитационные модели описывают не только сущности, потоки информа- ции и управление, но и различные метрики. Полученную модель можно «про- играть» во времени и получить статистику происходящих процессов так, как это было бы в реальности. В имитационной модели изменения процессов и данных ассоциируются с событиями. «Проигрывание» модели заключается в последовательном переходе от одного события к другому. Имитационная модель включает следующие основные элементы: 1) источники и стоки (Create и Dispose). Источники – это элементы, от ко- торых в модель поступает информация или материальные объекты. По смыслу они близки к понятиям «внешняя сущность» на DFD или «объект ссылки» на диаграммах IDEF3. Скорость поступления данных или объек- тов от источника обычно задается статистической функцией. Сток – это устройство для приема информации или объектов; 2) очереди (Queues). Понятие очереди близко к понятию «хранилища дан- ных» на DFD-диаграммах – это место, где объекты ожидают обработки. Время обработки объектов в разных работах может быть разным. В ре- зультате перед некоторыми работами могут накапливаться объекты, ожи- дающие своей очереди. Часто целью имитационного моделирования яв- ляется минимизация количества объектов в очередях; 3) процессы (Process) – это аналог работ в функциональной модели. В ими- тационной модели может быть задана производительность процессов. Функциональные и имитационные модели взаимосвязаны и дополняют друг друга. Имитационная модель дает больше информации для анализа систе- мы, в свою очередь результаты такого анализа могут быть причиной модифи- кации модели процессов. Существует также возможность преобразования функциональной модели 236 в имитационную модель. Целесообразно сначала строить функциональную мо- дель, а на ее основе – имитационную. Построение модели производится с помощью специальных CASE средств путем переноса из панели инструментов в рабочее пространство модулей Create, Dispose и Process. Связи между модулями устанавливаются автоматически, но могут быть переопределены вручную. Далее модулям назначаются свойства. Для контроля проигрывания модели необходимо в модель добавить модуль Simulate и задать для него параметры. Результаты проигрывания модели отображаются в автома- тически генерируемых отчетах. BPwin не имеет собственных инструментов, позволяющих создавать ими- тационные модели, однако дает возможность экспортировать модель IDEF3 в специализированное средство создания таких моделей. Для экспорта модели необходимо настроить свойства, определяемые пользователем UDP, специально включенные в BPwin для целей экспорта. |