11) Методология sadt. Семейство стандартов idef. Функциональные модели (idef0). Диаграммы потоков данных (dfd). Нотации dfd. Диаграммы перехода состояний (std). Модели сценариев процесса (idef3).
Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition). Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
связность диаграмм (номера блоков);
уникальность меток и наименований (отсутствие повторяющихся имен);
синтаксические правила для графики (блоков и дуг);
разделение входов и управлений (правило определения роли данных).
отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Семейство стандартов IDEF.
Взаимная совокупность методик и моделей концептуального проектирования IDEF разработана в США. В настоящее время имеются методики функционального, информационного и поведенческого моделирования и проектирования, в которые входят IDEF-модели.
Основными объектами IDEF-диаграмм являются работы и стрелки, которые отражают взаимодействие и связи между ними
Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников (блоков). Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему. Такой порядок называется порядком доминирования. Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована.
Стрелки представляют собой некоторую информацию. Виды стрелок:
вход (информация, используемая или преобразуемая работой для получения результата (выхода)). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы;
управление — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Стрелка управления рисуется как входящая в верхнюю грань работы;
выход — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Стрелка выхода рисуется как исходящая из правой грани работы.
механизм — ресурсы, которые выполняют работу. Стрелка механизма рисуется как входящая в нижнюю грань работы.
вызов — специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы.
Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки называются граничными. Для связи работ между собой используются внутренние стрелки, т. е. стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.
IDEF0 реализует методику функционального моделирования сложных систем. Наиболее известной реализацией IDEF0 является методология SADT. Эта методика рекомендуется для начальных стадий проектирования сложных искусственных систем управления, производства, включающих людей, оборудование, программное обеспечение.
IDEF1X и IDEF1 реализуют методики инфологического проектирования баз данных. В IDEF1X имеется графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм «сущность-связь». Разработка информационной модели по IDEF1X выполняется в несколько этапов:
выясняются цели проекта, составляется план сбора информации, при этом исходные положения следуют из IDEF0-модели;
выявляются и определяются основные сущности — элементы базы данных, в которых будут храниться данные системы;
выявляются и определяются основные отношения, результаты представляются графически в виде так называемых ER-диаграмм;
детализируются нестандартные отношения, определяются ключевые атрибуты сущностей. Детализация отношений заключается в замене связей «многие ко многим» на связи «многие к одному» и «один ко многим»;
определяются атрибуты сущностей.
IDEF2 и IDEF3 реализуют поведенческое моделирование. В этих методиках детализируется ответ: «Как система это делает». В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания.
IDEF4 реализует объектно-ориентированный анализ больших систем. Он предоставляет пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов.
IDEF5 направлен на представление онтологической информации приложения в удобном для пользователя виде. Для этого используются символические обозначения объектов, их ассоциаций, ситуаций и схемный язык описания отношений классификации. В методике имеются правила связывания объектов в предложения.
IDEF6 направлен на сохранение рационального опыта проектирования информационных систем, что способствует предотвращению структурных ошибок.
IDEF8 предназначен для проектирования диалогов человека и технической системы.
IDEF9 предназначен для анализа имеющихся условий и ограничений (в том числе физических, юридических, политических) и их влияния на принимаемые решения в процессе реинжиниринга.
IDEF14 предназначен для представления и анализа данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т. п.
Функциональна модель IDEF0 — методология и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временна́я последовательность (WorkFlow).Так же отображаются все сигналы управления, которые на ПДП не отображались. Данная модель является одной из самых прогресивных моделей и используется при организации бизнес проектов и проектов основанных на моделировании всех процессов как административных, так и организационных. Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:-Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. -По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”). Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом: Верхняя сторона имеет значение “Управление” (Control); Левая сторона имеет значение “Вход” (Input); Правая сторона имеет значение “Выход” (Output); Нижняя сторона имеет значение “Механизм” (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер. Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название “входящей”, “исходящей” или “управляющей”. Кроме того, “источником” (началом) и “приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.)
Диаграммы потоков данных DFD (Data Flow Diagrams)
Диаграммы потоков данных используются для описания движения документов и обработки информации как дополнение к IDEF0. В отличие от IDEF0, где система рассматривается как взаимосвязанные работы и стрелки представляют собой жесткие взаимосвязи, стрелки в DFD показывают лишь то, как объекты (включая данные) движутся от одной работы к другой. DFD отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных. DFD - это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах.
DFD содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.
Процессы. Процесс преобразует значения данных. Процессы самого нижнего уровня представляют собой функции без побочных эффектов (примерами таких функций являются вычисление суммы двух чисел, вычисление комиссионного сбора за выполнение проводки с помощью банковской карточки и т.п.). Весь граф потока данных тоже представляет собой процесс (высокого уровня). Процесс может иметь побочные эффекты, если он содержит нефункциональные компоненты, такие как хранилища данных или внешние объекты. На DFD процесс изображается в виде эллипса, внутри которого помещается имя процесса; каждый процесс имеет фиксированное число входных и выходных данных, изображаемых стрелками.
Потоки данных. Поток данных соединяет выход объекта (или процесса) с входом другого объекта (или процесса). Он представляет промежуточные данные вычислений. Поток данных изображается в виде стрелки между производителем и потребителем данных, помеченной именами соответствующих данных. Дуги могут разветвляться или сливаться, что означает, соответственно, разделение потока данных на части, либо слияние объектов.
Активные объекты. Активным называется объект, который обеспечивает движение данных, поставляя или потребляя их. Активные объекты обычно бывают присоединены к входам и выходам DFD.
Хранилища данных. Хранилище данных - это пассивный объект в составе DFD, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они были туда помещены. Агрегатные хранилища данных, как, например, списки и таблицы, обеспечивают доступ к данным в порядке их поступления, либо по ключам.
Потоки управления. DFD показывает все пути вычисления значений, но не показывает в каком порядке значения вычисляются. Решения о порядке вычислений связаны с управлением программой, которое отражается в динамической модели. Эти решения, вырабатываемые специальными функциями, или предикатами, определяют, будет ли выполнен тот или иной процесс, но при этом не передают процессу никаких данных, так что их включение в функциональную модель необязательно. Тем не менее, иногда бывает полезно включать указанные предикаты в функциональную модель, чтобы в ней были отражены условия выполнения соответствующего процесса. Функция, принимающая решение о запуске процесса, будучи включенной в DFD, порождает в DFD поток управления и изображается пунктирной стрелкой.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых информационных систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.
Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и, кроме того, главный единственный процесс не раскрывает структуры распределенной системы.
Для сложных информационных систем строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не главный единственный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
Ниже приведена диаграмма потоков данных верхнего уровня с ее последующим уточнением:
ТЕРМИНОЛОГИЯ DFD-НОТАЦИИ
|
DFD-БЛОКИ – графическое изображение операции (процесса, функции, работы) по обработке или преобразованию информации (данных). Смысл DFD-блока, отображающего функцию совпадает со смыслом блоков IDEFO и IDEF3, заключающиеся в преобразовании входов в выходы. DFD-блоки также имеют входы и выходы, но не поддерживают управление и механизмы, как IDEFO. Назначение функции состоит в создании из входных потоков выходных в соответствии с действием, определяемым именем процесса. Поэтому имя функции должно содержать глагол в неопределенной форме с последующим дополнением. Функции обычно именуются по названию системы, например "Разработка системы автоматизированного проектирования''. Рекомендуется использовать глаголы, отображающие динамические отношения, например: «рассчитать», «получить», «заказать», «фрезеровать», «точить», «вычислить», «включить», «моделировать» и т.д. Если автор использует такие глаголы, как “обработать”, “модернизировать”, или “отредактировать”, то это означает, что он, вероятно, пока недостаточно глубоко понимает данную функцию процесса и требуется дальнейший анализ. По нотации Гейн-Сарсона DFD-блок изображается прямоугольником со скругленными углами. Каждый блок должен иметь уникальный номер для ссылки на него внутри диаграммы. Номер каждого блока может включать префикс, номер родительского блока (А) и номер объекта, представляющий собой уникальный номер блока на диаграмме. Например, функция может иметь номер А.12.4. Для того чтобы избежать пересечений линий потоков данных один и тот же элемент может на одной и той же диаграмме отображаться несколько раз; в таком случае два или более прямоугольника, обозначающих один и тот же элемент, могут идентифицироваться линией пе-речеркивающей нижний правый угол. DATA FLOW (поток данных) – механизм, использующийся для моделирования передачи информации между участниками процесса информационного обмена (функциями, хранилищами данных, внешними ссылками). По нотации Гейн-Сарсона поток данных (документы, объекты, сотрудники, отделы или иные участники обработки информации) изображается стрелкой между двумя объектами DFD-диаграммы, предпочтительно горизонтальной и/или вертикальной, причем направление стрелки указывает направление потока. Каждая стрелка должна иметь источник и цель. В отличие от стрелок IDEF0-диаграммы (ICOM), стрелки DFD могут входить или выходить из любой стороны блока. Стрелки описывают, как объекты (включая данные) двигаются из одной части системы в другую. Поскольку в DFD каждая сторона блока не имеет четкого назначения, в отличие от блоков IDEF0-диаграммы, стрелки могут подходить и выходить из любой грани. В DFD-диаграммах для описания диалогов типа команды-ответа между операциями, применяются двунаправленные стрелки между функцией и внешней сущностью и/или между внешними сущностями. Стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя. Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться обратно. Такая ситуация может моделироваться либо двумя различными потоками, ли-бо одним двунаправленным. На поток данных можно ссылаться, указывая процессы, сущности или накопители данных, которые поток соединяет. Каждый поток должен иметь имя, расположенное вдоль или над стрелкой, выбранное таким образом, чтобы в наибольшей степени передавать смысл содержания потока пользователям, которые будут рассматривать диаграмму потоков данных. Набрасывая диаграмму потоков данных, можно опустить наименования, если оно является очевидным для пользователя, но автор диаграммы должен в любой момент представить описание потока. DATA FLOW ДИАГРАММА (DFD-диаграмма) – диаграммы применяемые для графического представления (flowchart) движения и обработки информации в организации или в каком-либо процессе. Обычно диаграммы этого типа используются для проведения анализа организации информационных потоков и для разработки ИС. DFD-диаграммы являются ключевой частью документа спецификации требований - графическими иерархическими спецификациями, опи-сывающими систему с позиций потоков данных. Каждый узел-процесс в DFD может развертываться в диаграмму нижнего уровня, что позволяет на любом уровне абстрагироваться от деталей. Для диаграмм этого типа обычно применяется сокращенное обозначение DFD. DFD являются. В состав DFD могут входить четыре графических символа, представляющих потоки данных, процессы преобразования входных потоков данных в выходные, внешние источники и получатели данных, а также файлы и БД, требуемые процессами для своих операций. DFD-диаграммы моделируют функции, которые система должна выполнять, но почти ничего не сообщают об отношениях между данными, а также о поведении системы в зависимости от времени - для этих целей используются диаграммы сущность-связь и диаграммы переходов состояний, соответственно. DATA STORE (хранилище данных) – графическое представление потоков данных импорти-руемых/экспортируемых из соответствующих баз данных. Обычно это таблицы для хранения документов. В отличие от стрелок, описывающих объекты в движении, хранилища данных изо-бражают объекты в покое. Накопители данных являются неким прообразом базы данных ин-формационной системы организации. Хранилища данныхвключаются в модель системы в том случае, если имеются этапы технологического цикла, на которых появляются данные, которые необходимо сохранять в памяти. При отображении процесса сохранения данных стрелка пото-ка данных направляется в хранилище данных, и, наоборот – из хранилища, если идет импорт данных. Хранилища данных предназначены для изображения неких абстрактных устройств для хранения информации, которую можно туда в любой момент времени поместить или извлечь, безотносительно к их конкретной физической реализации. Хранилища данных используются:
По нотации Гейн-Сарсона хранилище данных обозначается двумя горизонтальными линиями, замкнутыми с одного края. Каждое хранилище данных должно идентифицироваться для ссылки буквой D и произвольным числом в квадрате с левой стороны, например D5. Имя должно подбираться с учетом наибольшей информативности для пользователя. В модели может быть создано множество вхождений хранилищ данных, каждое из которых может иметь одинаковое имя и ссылочный номер. Для того, чтобы не усложнять диаграмму потоков данных пересечениями линий, можно изображать дубликаты накопителя данных дополнительными вертикальными линиями с левой стороны квадрата. EXTERNAL REFERENCE (внешняя ссылка, внешняя сущность, external entities) – объект диаграммы потоков данных, являющийся источником или приемником информации извне модели. Внешние ссылки/сущности изображают входы и/или выходы, т.е. обеспечивают интерфейс с внешними объектами, находящимися вне моделируемой системы. Внешними ссылками системы обычно являются логические классы предметов или людей, представляю-щие собой источник или приемник сообщений, например, заказчики, конструкторы, технологи, производственные службы, кладовщики и т.д. Это могут быть специфические источники, такие, как бухгалтерия, информационно-поисковая система, служба нормоконтроля, склад. Если рассматриваемая система принимает данные от другой системы или передает данные в другую систему, то эта другая система является элементом внешней системы. Без объекта «внешняя сущность» аналитику бывает иногда сложно определить, откуда пришла в компанию данные документы. Или какие документы еще приходят от, такой внешней сущности как, например, "клиент". По нотации Гейн-Сарсона пиктограмма внешней ссылки представляет собой оттененный прямоугольник верхняя и левая сторона, которого имеет двойную толщину для того, чтобы можно было выделить этот символ среди других обозначений на диаграмме, и обычно располагается на границах диаграммы. Внешняя ссылка может идентифицироваться строчной буквой Е в левом верхнем углу и уникальным номером, например Е5. Кроме того, внешняя ссылка имеет имя. Одна и та же внешняя ссылка может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок. Каждая внешняя сущность имеет префикс. При рассмотрении системы как внешней функции, часто указывается, что она находится за пределами границ, моделируемой системы. После проведения анализа некоторые внешние ссылки могут быть перемещены внутрь диаграммы потоков данных рассматриваемой системы или, наоборот, какая-то часть функций системы может быть вынесена и рассмотрена как внешняя ссылка. OFF-PAGE REFERENCE (межстраничные ссылки) – инструмент нотации DFD, описывающий передачу данных или объектов с одной диаграммы модели на другую. Стрелка межстраничной стрелки имеет идентифицирующее имя, номер и изображение окружности. При интерпретации DFD-диаграммы используются следующие правила:
Помимо этого, для каждого информационного потока и хранилища определяются связанные с ними элементы данных. Каждому элементу данных присваивается имя, также для него может быть указан тип данных и формат. Именно эта информация является исходной на следующем этапе проектирования - построении модели "сущность-связь". При этом, как правило, информационные хранилища преобразуются в сущности, проектировщику остается только решить вопрос с использованием элементов данных, не связанных с хранилищами. Представление потоков в виде стрелок совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов, хранение объектов, поставка и распространение объектов. |
Диаграммы переходов состояний (STD) предназначены для моделирования и документирования аспектов систем, зависящих от времени или реакции на событие. Они позволяют осуществлять декомпозицию управляющих процессов и описывают отношения между входными и выходными управляющими потоками для управляющего процесса-предка.
С помощью STD-диаграмм можно моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования. Моделируемая система в любой заданный момент времени находится точно в одном из конечного множества состояний. С течением времени она может изменить свое состояние, при этом переходы между состояниями должны быть точно определены. STD-диаграмма состоит из следующих объектов:
Состояние – набор характеристик, описывающих условия устойчивости системы. Находясь в определенном состоянии и имея информацию о прошлой истории системы, можно определить очередное состояние в зависимости от текущих входных событий (потоков). Имя состояния должно отражать реальную ситуацию, в которой находится система, например, Нагревание,Охлаждение и т.п.
Начальное состояние – узел STD-диаграммы, являющийся стартовой точкой для начального системного перехода. STD-диаграмма имеет ровно одно начальное состояние, соответствующее состоянию системы после ее инсталляции (внедрения), но перед началом реальной работы, а также любое (конечное) число завершающих состояний.
Переход определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так и внутри моделируемой системы при выполнении некоторогоусловия (например, счетчик=999 или «кнопка нажата»). Следует отметить, что, вообще говоря, не все события необходимо вызывают переходы из отдельных состояний. С другой стороны, одно и то же событие не всегда вызывает переход в то же самое состояние.
Таким образом,условие представляет собой событие (или события), вызывающее переход и идентифицируемое именем перехода. Если в условии участвует входной управляющий поток управляющего процесса-предка, то имя потока должно быть заключено в кавычки, например, «пароль»=999, где Пароль - входной поток управляющего процесса-предка.
Кроме условия с переходом может связыватьсядействие или ряд действий, выполняющихся, когда переход имеет место. То есть действие – это операция, которая может иметь место при выполнении перехода. Если действие необходимо для выбора выходного управляющего потока управляющего процесса-предка, то имя этого потока должно заключаться в кавычки, например:
«Введенная карта» =true,где Введенная карта – выходной поток управляющего процесса-предка.
Кроме того, для спецификации А-, Т-, E/D-потоков (см. табл. 3.1) имя запускаемого или переключаемого процесса также должно заключаться в кавычки, например:
А: «Получить пароль» – активировать процесс Получить пароль.
Фактически условие есть некоторое внешнее или внутреннее событие, которое система способна обнаружить и на которое она должна отреагировать определенным образом, изменяя свое состояние. При изменении состояния система обычно выполняет одно или более действий (например, для информационной системы: производит вывод, выдает сообщение на терминал, выполняет вычисления). Таким образом, действие представляет собой отклик, посылаемый во внешнее окружение, или вычисление, результаты которого запоминаются в системе (обычно в хранилищах данных, представленных на DFD-диаграмме, структура и содержание которых представлены на ERD-диаграмме), для того, чтобы обеспечить реакцию на некоторые из планируемых в будущем событий.
На STD-диаграмме состояния представляются узлами, а переходы – дугами (рис. 3.21). Условия (по-другому называемые стимулирующими событиями) идентифицируются именем перехода и возбуждают его выполнение. Действия или отклики на события привязываются к переходам и записываются под соответствующим условием. Начальное состояние на диаграмме должно иметь входной переход, изображаемый потоком из подразумеваемого стартового узла (иногда этот стартовый узел изображается небольшим квадратом и привязывается к входному состоянию).
|
| |
|
|
|
При построении STD-диаграммы рекомендуется [20] следовать перечисленным ниже правилам:
- строить STD-диаграмму на как можно более высоком уровне детализации DFD-диаграммы;
- строить как можно более простые STD-диаграммы;
- по возможности детализировать STD-диаграммы;
- использовать те же принципы именований состояний, событий и действий, что и при именовании процессов и потоков.
Применяются два способа построения STD-диаграмм. Первый способ заключается в идентификации всех возможных состояний и дальнейшем исследовании всех не бессмысленных связей (переходов) между ними. По второму способу сначала строится начальное состояние, затем следующие за ним и т.д. Результат (в обоих случаях) – предварительная STD-диаграмма, для которой затем осуществляется контроль состоятельности, заключающийся в ответе на следующие вопросы:
- все ли состояния определены и имеют уникальное имя?
- все ли состояния достижимы?
- все ли состояния имеют выход?
- (для каждого состояния) реагирует ли система соответствующим образом на все возможные условия (особенно на ненормальные)?
- все ли входные (выходные) потоки управляющего процесса отражены в условиях (действиях) на STD-диаграмме?
В качестве примера рассмотрим диаграмму переходов состояний для системы управления лифтом. Для этого используем DFD-диаграммы этой системы.
В ситуации, когда число состояний и/или переходов велико, для проектирования STD-диаграммы могут использоваться таблицы или матрицы переходов состояний. Обе эти нотации позволяют зафиксировать ту же самую информацию, что и диаграммы переходов состояний, но в другом формате.
Матрица переходов состояний содержит по вертикали перечень состояний системы, из которых осуществляется переход, а по горизонтали – состояния, в которые осуществляется переход. При этом каждый элемент матрицы содержит соответствующие условия и действия, обеспечивающие переход из «вертикального» состояния в «горизонтальное». В качестве примера данного варианта матрицы переходов состояний приведена таблица 8, соответствующая диаграмме переходов состояний.
В завершении рассмотрения технологии 3VM следует отметить, что описанные три вида диаграмм и набор дополнительных средств позволяют комплексно визуализировать, формализовать и документировать процессы и потоки в исследуемой системе. Данная технология является весьма полезным средством, однако, только в том случае, если в дальнейшем планируется автоматизация и разработка программных средств методами и языками процедурного программирования.
Таблица 3.5. Матрица переходов состояний ECS.
|
|
Занят (движется) |
Остановлен |
Пуст (стоит) |
Перегружен (стоит) |
|
Занят (движется) |
прибытие на незапланированный этаж |
прибытие на запланированный этаж |
|
|
|
Остановлен |
лифт готов к движению, «кнопки назначения нажаты» |
|
лифт готов к движению, но кнопки не нажаты |
«лифт перегружен» |
|
Пуст (стоит) |
«лифт вызван с другого этажа» |
«лифт вызван с текущего этажа» |
|
|
|
Перегружен (стоит) |
|
«нет перегрузки» |
|
Лифт готов, но перегружен |
Отсутствие средств представления характеристик объектов, реализующих процессы и потоки, делает невозможным применение данной технологии при объектно-ориентированной разработке информационной системы.
IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием (Scenario) мы называем описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:
Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса.
Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов.
Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта.
Содействовать принятию оптимальных решений при реорганизации технологических процессов.
Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..."
Два типа диаграмм в IDEF3
Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.
На следующем примере, опишем, как графические средства IDEF3 позволяют документировать вышеуказанный производственный процесс окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку.
На рис.1 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называютсяфункциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса. Линии бывают следующих видов:
Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз.
Отношения (Relational Link)- пунктирная линия, использующаяся для изображения связей между UOB
Потоки объектов (Object Flow)- стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице.
|
Обозначение |
Наименование |
Смысл в случае слияния стрелок (Fan-in Junction) |
Смысл в случае разветвления стрелок (Fan-out Junction) |
|
|
Asynchronous AND |
Все предшествующие процессы должны быть завершены |
Все следующие процессы должны быть запущены |
|
|
Synchronous AND |
Все предшествующие процессы завершены одновременно |
Все следующие процессы запускаются одновременно |
|
|
Asynchronous OR |
Один или несколько предшествующих процессов должны быть завершены |
Один или несколько следующих процессов должны быть запущены |
|
|
Synchronous OR |
Один или несколько предшествующих процессов завершаются одновременно |
Один или несколько следующих процессов запускаются одновременно |
|
|
XOR (Exclusive OR) |
Только один предшествующий процесс завершен |
Только один следующий процесс запускается |
Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J".
Сценарий, отображаемый на диаграмме, можно описать в следующем виде:
Деталь поступает в окрасочный цех, подготовленной к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки.
Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB "Окрасить Деталь", представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 1, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.
Рисунок
2. Пример OSTN диаграммы
Если диаграммы PFDD технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис.2 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.
12) Цель и назначение порталов. Web-порталы. Классификация порталов.
Web-порталы: классификация и назначение
Этапы эволюции технологий и продуктов для создания порталов
Зачем нужны порталы?
Не секрет, что за последние несколько лет в способах ведения и организации бизнеса произошли качественные изменения. Сейчас одними из самых важных факторов успеха практически любой компании являются эффективность и своевременность использования информации, поступающей от ее сотрудников, партнеров и клиентов.
Следует отметить, что множество российских и зарубежных предприятий, успешно внедривших внутренние информационные системы, пока используют Интернет главным образом как средство коммуникации, то есть недостаточно эффективно. Нередко их внутренние информационные системы не интегрированы с приложениями, обеспечивающими взаимодействие с клиентами и партнерами. Тем не менее, понимая, что залогом успеха в конкурентной борьбе сегодня является наличие инфраструктуры, позволяющей использовать Интернет не только как средство коммуникации, но и как один из основных инструментов ведения бизнеса, многие предприятия уже начали применять Интернет-приложения в целях предоставления своим клиентам и сотрудникам актуальной информации и возможности прямого доступа к корпоративным приложениям, а также своевременной обработки поступивших от них сведений (например, заказов или предложений) на всех уровнях деятельности предприятия.
Чтобы предоставить пользователям единый интерфейс к актуальной информации и бизнес-приложениям, не затронув при этом уже эксплуатирующиеся внутренние информационные системы, сейчас нередко применяются портальные технологии, позволяющие осуществить интеграцию имеющихся приложений в рамках единого способа доступа к ним. Многие западные аналитики предсказывают значительный рост рынка этих технологий и реализующих их продуктов в течение ближайших двух лет. Поистине тема порталов стала в последнее время очень «модной».
Что же представляют собой порталы и какими они бывают?
По своей сути портал — это Web-сайт, предназначенный для определенной аудитории (например, клиентов и сотрудников компании), осуществляющий анализ, обработку и доставку информации и предоставляющий доступ к различным сервисам на основе персонализации пользователей с помощью любого устройства, подключенного к Интернету. Классифицировать порталы можно по различным признакам, но чаще всего прибегают к классификации по назначению.
|
|
|
Типы порталов
В настоящее время с точки зрения назначения различают три основных типа порталов:
Публичные, или горизонтальные, порталы (называемые иногда мегапорталами), такие как Yahoo, Lycos, Excite, Rambler. Такие порталы нередко являются результатом развития поисковых систем. Предназначены они для самой широкой аудитории, что отражается на содержании предоставляемой ими информации и услуг. Как правило, эта информация носит общий характер (например, новости о политических событиях, культурной жизни и т.д.), равно как и предоставляемые услуги (электронная почта, новостные рассылки и т.д.). Поскольку сфера деятельности таких компаний пересекается со сферой деятельности средств массовой информации, во многих западных странах в последнее время наблюдаются процессы слияния публичных порталов и средств массовой информации в рамках одной компании (рис. 1).
Вертикальные порталы. Этот вид порталов предназначен для специфических видов рынка и обслуживает аудиторию, пользующуюся услугами этого рынка или работающую на нем. Примерами таких порталов могут служить, например, туристические агентства, предоставляющие услуги по бронированию мест в гостиницах, заказу и доставке билетов, доступу к картам и сведениям об автомобильных маршрутах и т.д., либо порталы типа B2B (business-to-business), позволяющие своим клиентам реализовывать совместные бизнес-операции (например, выбирать поставщиков и осуществлять закупку товаров, проводить аукционы и т.д.). Число таких порталов в последнее время быстро растет, поскольку все новые и новые рынки товаров и услуг перемещаются в Интернет (рис. 2).
Корпоративные порталы предназначены для сотрудников, клиентов и партнеров одного предприятия. Пользователи такого портала получают доступ к предназначенным им сервисам и приложениям в зависимости от их роли и персонального профиля (рис. 3).
Помимо этих трех типов порталов термин «портал» иногда употребляется применительно к некоторым другим типам Web-приложений, предоставляющих своим пользователям те или иные услуги через Интернет, например, к голосовым порталам, предоставляющим доступ к некоторым услугам по телефонной линии с помощью голосовых команд или команд, посылаемых с клавиатуры телефона, или к так называемым персональным порталам, предоставляющим услуги персональных информационных менеджеров и электронной почты.
|
|
|
Основные характеристики корпоративных порталов
Основными характеристиками современных корпоративных порталов являются:
обеспечение возможности доступа сотрудников предприятия ко всем информационным ресурсам этого предприятия через единый интерфейс;
возможность осуществления поиска нужной информации;
возможность публикации пользовательской информации;
поддержка режимов коллективной работы;
строгая персонализация пользователей.
Отметим, что конфигурация рабочего места и предоставляемая пользователю информация в корпоративных порталах осуществляются на основе строгой персонализации и прав доступа пользователя к тем или иным ресурсам (данным, сервисам, приложениям, документам). Так, клиент Интернет-магазина может получать информацию о поступлении в магазин новых товаров в соответствии с его профилем, сформированным на основе истории его покупок или анкетных опросов, а также на основе сведений, предоставленных о нем менеджерами магазина. Обычно порталы обеспечивают не просто персонализацию, но и обратную связь со своими пользователями.
|
|
|
Наиболее популярные средства создания порталов
Переход к массовому применению порталов обусловил появление на рынке программного обеспечения специализированных средств их создания.
В таблице приведены средства создания порталов, которые, по данным аналитиков Gartner Group, наиболее широко применялись в последние годы (источники — http://www.gartnerweb.com/, http://www.techrepublic.com/), а также некоторые новые продукты, недавно появившиеся на рынке программного обеспечения. Заметим, что на сегодняшний день на этом рынке явных лидеров пока нет.
Как правило, стоимость решения на базе этих продуктов зависит от количества используемых серверов, количества и типа информации и сервисов, предоставляемых порталом, и планируемого числа пользователей и колеблется от нескольких тысяч до нескольких сотен тысяч долларов.
Многие из перечисленных продуктов позволяют создавать и вертикальные, и горизонтальные, и корпоративные порталы, хотя технологические реализации, а также платформы, для которых они предназначены, могут быть различными.
Подробная техническая информация и дополнительные материалы о перечисленных выше продуктах находятся на нашем компакт-диске. Отметим также, что некоторым из них посвящены отдельные статьи данного спецвыпуска.
|
|
|
Несколько слов о перспективах
Итак, порталы по своей сути становятся средством глобализации обработки данных, объединяя бизнес-процессы внутри предприятия с бизнес-процессами его партнеров и клиентов и таким образом выходя за рамки традиционной информационной системы. Реально современные и будущие порталы будут выполнять две различные функции — функцию агрегации содержимого и функцию интеграции приложений и данных, что необходимо для успешного взаимодействия с партнерами и клиентами. Не последнюю роль в функциях порталов будет играть и поддержка мобильных устройств, позволяющая пользователям заменить ими традиционные настольные компьютеры и получить возможность постоянного доступа к предоставляемым ими сервисам.
Отметим также, что порталы смогут предоставлять своим пользователям доступ к Web-сервисам, используя технологии UDDI (Universal Description, Discovery and Integration) и SOAP (Simple Object Access Protocol), а также реализовывать собственные Web-сервисы, предоставляя доступ к ним другим приложениям и порталам. Видимо, следует вскоре ожидать появления индустриальных стандартов на компоненты порталов.