МЕТОДОЛОГИЧЕСКИЕ ПОДХОДЫ К ПРОЕКТИРОВАНИЮ 1 ВСЕ РАЗВИТЫЕ

МЕТОДОЛОГИЧЕСКИЕ ПОДХОДЫ К ПРОЕКТИРОВАНИЮ 1

ВСЕ РАЗВИТЫЕ СФЕРЫ ПРОИЗВОДСТВА ПРОХОДЯТ В СВОЕМ РАЗВИТИИ СЛЕДУЮЩИЕ СТАДИИ: Искусство

ВСЕ РАЗВИТЫЕ СФЕРЫ ПРОИЗВОДСТВА ПРОХОДЯТ В СВОЕМ РАЗВИТИИ СЛЕДУЮЩИЕ СТАДИИ: Наука

ВСЕ РАЗВИТЫЕ СФЕРЫ ПРОИЗВОДСТВА ПРОХОДЯТ В СВОЕМ РАЗВИТИИ СЛЕДУЮЩИЕ СТАДИИ: Технологии

МЕТОДОЛОГИЧЕСКИЕ ПОДХОДЫ Для информационных технологий и информационных систем научный фундамент представлен в том числе и методологиями. В настоящее время выделяют следующие методологические подходы : структурный; объектно-ориентированный многомодельный , отраженный в таком понятии, как архитектурный подход

СВЯЗЬ МЕТОДОЛОГИЧЕСКИХ ПОДХОДОВ С ОСНОВНЫМИ ЭТАПАМИ ЖЦ ИС № Основные этапы структурный Объектноориентированн ый 1 Предпроектное обследование SADT All Fusion Process Modeler All Fusion Data Modeler RUP Rational So. DA+Rational Rose 2 Формирование требований к системе Интеграция со средством управления требованиями RTM Workshop RUP Rational Requisite. Pro, Rational So. DA+Rational Rose 3 Проектирование основных компонентов системы: 3. 1 Проектирование БД All Fusion Data Modeler Rational Rose, Rational XDE 3. 2 Проектирование приложений All Fusion Process Modeler Rational Rose, Rational XDE 3. 3 Проектирование ИИ All Fusion Component Modeler Rational Rose, Rational XDE АП Схема Захмана IBM Rational / Telelogic System Architect

СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ

СУЩНОСТЬ СТРУКТУРНОГО ПОДХОДА Заключается в декомпозиции системы, которая производится следующим образом: система разбивается на функциональные подсистемы, которые делятся на подфункции, те – на задачи и так далее до конкретных процедур. Система Подсистема Подфункция Подсистем Подфункция

ПРИНЦИПЫ СТРУКТУРНОГО ПОДХОДА В основе структурного подхода лежат следующие принципы: принцип декомпозиции (научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач); принцип иерархического упорядочения (организация составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне); принцип абстрагирования (выделение существенных аспектов системы и отвлечение от несущественных); принцип непротиворечивости (обоснованность и согласованность элементов системы); принцип структурирования данных (данные должны быть структурированы и иерархически организованы).

МЕТОДОЛОГИИ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ Методология структурного анализа и проектирования определяет руководящие указания для оценки и выбора разрабатываемого проекта, шаги работы, которые должны быть выполнены, их последовательность, правила распределения и назначения операций и методов. В настоящее время успешно используются практически все известные методологии структурного анализа и проектирования, однако наибольшее распространение получили методологии: SADT (Structured Analysis and Design Technique), структурного Sarson), структурного анализа и проектирования Йодана/Де Марко (Yourdon/De Marko), развития систем Джексона (Jackson), системного анализа Гейна-Сарсона информационного моделирования Мартина (Martin). (Gane-

КЛАССИФИКАЦИЯ СТРУКТУРНЫХ МЕТОДОЛОГИЙ Современные структурные методологии анализа и проектирования классифицируются по следующим признакам: по отношению к школам - Software Engineering (SE) и Information Engineering (IE); по порядку построения модели - процедурноориентированные, ориентированные на данные и информационноориентированные; по типу целевых систем - для систем реального времени (СРВ) и для информационных систем (ИС).

ШКОЛА SOFTWARE ENGINEERING SE является нисходящим поэтапным подходом к разработке ПО, начинающейся с общего взгляда на его функционирование. Затем производится декомпозиция на подфункции, и процесс повторяется для подфункций до тех пор, пока они не станут достаточно малы для их реализации кодированием. В результате получается иерархическая, структурированная, модульная программа. SE является универсальной дисциплиной разработки ПО, успешно применяющейся как при разработке систем реального времени, так и при разработке информационных систем.

ШКОЛА INFORMATION ENGINEERING IE - более новая дисциплина. С одной стороны, она имеет более широкую область применения, чем SE: IE является дисциплиной построения систем вообще, а не только систем ПО, и включает этапы более высокого уровня (например, стратегическое планирование), однако на этапе проектирования систем ПО эти дисциплины аналогичны. С другой стороны, IE - более узкая дисциплина, чем SE, т. к. IE используется только для построения информационных систем, а SE - для всех типов систем.

МОДЕЛЬ РАЗРАБОТКИ ПО И ИС Разработка ПО и ИС основана на модели ВХОД-ОБРАБОТКАВЫХОД: данные входят в систему, 2. обрабатываются, 3. выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. 1. вход Обработка выход

ПОРЯДОК ПОСТРОЕНИЯ МОДЕЛИ Процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными - структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход, как часть IE-дисциплины, отличается от подхода, ориентированного на данные, тем, что позволяет работать с неиерархическими структурами данных.

ТИПЫ ЦЕЛЕВЫХ СИСТЕМ Информационные системы Системы реального времени Управляемы данными Сложные структуры данных Большой объем входных данные Интенсивный вводвывод Машинная независимость Управляемы событиями Простые структуры данных Малое количество входных данных Интенсивные вычисления Машинная зависимость

СРЕДСТВА ПОДДЕРЖКИ СИСТЕМ РАЗНОГО ТИПА Название методологии Школа Порядок построения Тип систем Йодан-Де Марко SE Процедурноориентированная ИС, СРВ Гейн-Сарсон SE Процедурноориентированная ИС, СРВ Джексон SE Ориентированная на данные ИС, СРВ Мартин IE Информационноориентированная ИС SADT IE варианты использования: 1)проц. -ориент. 2)ор. на данные ИС

МЕТОДОЛОГИЯ SADT Предпосылки создания. Сущность.

СУЩНОСТЬ МЕТОДОЛОГИИ SADT Методология SADT (Structured Analysis and Design Technique) основана Россом в семидесятые годы прошлого столетия и является методологией, ориентированной на описание процессов. (Задание: прочитать предисловие Росса к книге «Методология анализа и проектирования» Дэвида А. Марка и Климента Мак. Гоуэна» ) С точки зрения SADT модель может основываться либо на функциях системы, либо на ее предметах. Соответствующие модели принято называть функциональными (активностными) моделями и моделями данных. Функциональная модель представляет с нужной степенью точности систему функций, которые в свою очередь отражают свои взаимоотношения через предметы системы. Модели данных двойственны к функциональным моделям и представляют собой подробное описание предметов системы, связанных системными функциями. Полная методология SADT заключается в построении моделей обеих типов для более точного описания сложной системы.

ВОЗНИКНОВЕНИЕ SADT Работа над методологией SADT началась, в основном, в конце 60 -х годов в ходе революции, вызванной структурным программированием (крупномасштабные коммерческие проекты в промышленности и управлении и контроле за вооружением). Результатом работ явилась формализация процесса создания системы, выделение фаз проекта: анализ – определение того, что система будет делать проектирование – определение подсистем и их взаимодействие реализация – разработка подсистем по отдельности объединение – соединение подсистем в единое целое тестирование – проверка работы системы установка – введение системы в действие функционирование – использование системы

ПРИЧИНЫ ПОЯВЛЕНИЯ SADT(1) Большой процент ошибок в системе на фазах анализа и проектирования. Цена (временная и денежная) обнаружения и исправления ошибок выше на более поздних стадиях проекта. Увеличение стоимости проектов

ПРИЧИНЫ ПОЯВЛЕНИЯ SADT(2) Гипотеза: совершенствование методов анализа есть ключ к созданию систем, эффективных по стоимости, производительности и надежности Решение проблемы: SADT как способ уменьшения количества дорогостоящих ошибок за счет структуризации на ранних этапах создания системы, улучшенияконтактов между пользователями и разработчиками

РАЗВИТИЕ SADT 1969 год: началась работа над SADT 1973 год: реализация первого крупного приложения при разработке большого аэрокосмического проекта, Sof. Tech, Inc. 1974 год: SADT была еще улучшена и передана одной из крупнейших европейских телефонных компаний 1975 год: Появление SADT на рынке после годичного оформления в виде продукта 1981 год: SADT уже используют более чем в 50 компаниях при работе более чем над 200 проектами, включавшими более 2000 людей охватывавшими дюжину проблемных областей, в том числе: телефонные сети, аэрокосмическое производство, управление и контроль, учет материально-технических ресурсов и обработку данных. настоящее время – SADT в части IDEF 0 является стандартом

ПРИЧИНЫ ШИРОКОГО ПРИМЕНЕНИЯ отражает системные характеристики - управление, - обратная связь - исполнители содержит развитые процедуры поддержки коллективной работы сочетается с другими структурными методами за счет использования графической нотации, связывающей различные методы, примененные для описания определенных частей системы с различным уровнем детализации

ДУГЛАС РОСС О МЕТОДОЛОГИИ: Мир и все в нем, включая наши мысли о нем, можно рассматривать как систему взаимодействующих систем. У системы есть граница, поведение и сущность. Каждое из этих понятий определяется взаимодействием этой системы с другими системами, с которыми она соединяется еще и в новые системы. Так, например, грузовик имеет электрическую, механическую и гидравлическую системы. Конкретно - у него есть системы управления движением, расписания доставки и расценок. Другая, более абстрактная область - наука имеет предмет, теории, лаборатории, учебный курс, эксперименты, бюджет, студентов. У романа есть изложение, персонажи, сюжет и стиль. История (прошлое, настоящее, будущее - возможное или испытанное в жизни) может включать все это.

ДУГЛАС РОСС О МЕТОДОЛОГИИ. ВОПРОСЫ И ОТВЕТЫ (1): Вопрос: Как такое разнообразие систем можно строго исследовать? Ответ: Приспосабливая и используя именно тот язык, который является наиболее естественным для данного объекта. Это может быть "естественный" язык, такой, как английский, технический жаргон искусственного формального языка, математические формулы или далее изображения форм и очертаний. Вопрос: Как можно избежать неточностей двусмысленности такого разнообразия выражений? и Ответ: Так же, как это происходит в любом естественном языке: к этим выражениям следует применять правила пунктуации, которые не несут самостоятельного смысла, но служат для ограничения, структурирования и интерпретации этих выражений так, чтобы сохранить только то значение, которое имелось в виду.

ДУГЛАС РОСС О МЕТОДОЛОГИИ. ВОПРОСЫ И ОТВЕТЫ (2): Вопрос: Как такое разнообразие различных объектов может быть включено в одну и ту же схему пунктуации? Ответ: Путем введения строгой, точной, пригодной для чтения как человеком, так и машиной письменной формы, которая сама по себе моделирует границу, поведение и сущность любого выбранного объекта, выраженные на естественном для данного объекта языке. Вопрос: Что значит "моделирует"? Может ли одна модель моделировать все? Ответ: "М моделирует А, если М отвечает на вопросы относительно А".

СХЕМА МОДЕЛИРОВАНИЯ РОССА: SAБЛОК Одна и та же схема моделирования может быть использована для моделирования любого выбранного объекта. Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль. Итак, что же является универсальной единицей универсальной пунктуации для неограниченного структурного анализа? SA-блок Вход при наличии управления преобразуется в выход с помощью "механизма" (исполнителя).

Основы функционального моделирования

ГРАФИЧЕСКИЙ ЯЗЫК SADT Под словом "система" мы понимаем совокупность взаимодействующих компонент и взаимосвязей между ними. Под термином "моделирование" мы понимаем процесс создания точного описания системы. Описание системы с помощью SADT называется моделью. В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка - сама методология SADT. Графический язык SADT обеспечивает структуру и точную семантику естественному языку модели. Графический язык SADT организует естественный язык вполне определенным и однозначным образом, за счет чего SADT и позволяет описывать системы, которые до недавнего времени не поддавались адекватному представлению.

МОДЕЛИ SADT С точки зрения SADT модель может быть сосредоточена либо на функциях системы, либо на ее объектах. SADT-модели, ориентированные на функции, принято называть функциональными моделями, а ориентированные на объекты системы - моделями данных, функциональная модель представляет с требуемой степенью детализации систему функций, которые в свою очередь отражают свои взаимоотношения через объекты системы. Модели данных дуальны к функциональным моделям и представляют собой подробное описание объектов системы, связанных системными функциями. Полная методология SADT поддерживает создание множества моделей для более точного описания сложной системы

ЦЕЛЬ МОДЕЛИ SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает из формального определения модели в SADT: М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А. Таким образом, целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Это означает, что сама модель должна будет дать ответы на эти вопросы с заданной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели. Вопросы для SADT-модели формулируются на самом раннем этапе проектирования, при этом основная суть этих вопросов должна быть выражена в одной-двух фразах.

СУБЪЕКТ МОДЕЛИРОВАНИЯ. ГРАНИЦЫ СИСТЕМЫ Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система. Однако моделируемая система никогда не существует изолированно: она всегда связана с окружающей средой. В методологии SADT необходимо точно определять границы системы. SADT-модель всегда ограничивает свой субъект, т. е. модель устанавливает точно, что является и что не является субъектом моделирования, описывая то, что входит в систему, и подразумевая то, что лежит за ее пределами. Ограничивая субъект, SADT-модель помогает сконцентрировать внимание именно на описываемой системе и позволяет избежать включения посторонних субъектов.

ТОЧКА ЗРЕНИЯ С определением модели тесно связана позиция, с которой наблюдается система и создается ее модель. Поскольку качество описания системы резко снижается, если оно не сфокусировано ни на чем, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции. Эта позиция называется "точкой зрения" данной модели. "Точку зрения" лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии.

ОПРЕДЕЛЕНИЕ ЦЕЛИ И ТОЧКИ ЗРЕНИЯ

МОДЕЛЬ КАК НАБОР ДИАГРАММ После того как определены субъект, цель и точка зрения модели, начинается первая интеграция процесса моделирования по методологии SADT. Субъект определяет, что включить в модель, а что исключить из нее. Точка зрения диктует автору модели выбор нужной информации о субъекте и форму ее подачи. Цель становится критерием окончания моделирования. Конечным результатом этого процесса является набор тщательно взаимоувязанных описаний, начиная с описания самого верхнего уровня всей системы и кончая подробным описанием деталей или операций системы. Каждое из таких тщательно описаний называется диаграммой. взаимосогласованных SADT-модель объединяет и организует диаграммы в иерархические структуры, в которых диаграммы наверху модели менее детализированы, чем диаграммы нижних уровней. Модель SADT можно представить в виде древовидной структуры диаграмм, где верхняя диаграмма является наиболее общей, а самые нижние наиболее детализированы.

ДИАГРАММА - ОСНОВНОЙ РАБОЧИЙ ЭЛЕМЕНТ МОДЕЛИРОВАНИЯ Диаграмма является основным рабочим элементом моделирования. Разработчик диаграмм и моделей обычно называется аналитиком, или, в терминологии SADT, автором. Диаграммы имеют собственные синтаксические правила, отличающиеся от синтаксических правил моделей. Графика SADT позволяет определить различные системные функции и показать, как функции влияют друг на друга. В состав диаграммы входят: блоки, изображающие функции моделируемой системы, дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками

БЛОКИ Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстами на естественном языке, описывающим функции. Блок представляет функцию или активную часть системы, поэтому названиями блоков служат глаголы или глагольные обороты. Например, названиями блоков диаграммы выполнить задание являются: определить степень выполнения задания, выбрать инструменты, подготовить рабочее место, обработать на станке и собрать, При этом каждая сторона блока имеет вполне определенное назначение: левая сторона предназначена для Входов (Input – I), верхняя сторона – для Управления (Control – C), правая сторона – для Выходов (Output – O), нижняя сторона– для Механизмов (Исполнителей) (Mechanism - M).

ПРАВИЛА ПРЕДСТАВЛЕНИЯ БЛОКОВ SADT требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования. Другими словами, SADT-диаграммы и SADT-модели наглядны Блоки на диаграмме размещаются на «ступенчатой» схеме в соответствии с их доминированием, которое понимается как влияние, оказываемое одним блоком на другие. Блоки должны быть пронумерованы в соответствии с их доминированием. Номера блоков служат однозначными идентификаторами для функций и автоматически организуют эти функции в иерархическую модель

ТИПИЧНАЯ SADT - ДИАГРАММА

ДУГИ Дуги на SADT-диаграмме изображаются одинарными линиями со стрелками на концах. Дуги в SADT представляют наборы предметов (данных) или объектов. При этом понятие объекта трактуется в широком смысле слова. Так как в SADT дуги изображают объекты, они описываются (помечаются) существительными или существительными с определениями. Дуги обеспечивают взаимосвязь между блоками и могут состоять с функциями в четырех возможных отношениях: Вход, Выход, Управление, Механизм.

ДУГИ КАК ИНСТРУМЕНТ ВЗАИМОСВЯЗИ МЕЖДУ БЛОКАМИ. Входы преобразуются в Выходы, Управления ограничивают или предписывают условия выполнения, Механизмы описывают, за счет чего выполняются преобразования.

ВЗАИМОСВЯЗЬ БЛОКОВ Взаимовлияние блоков может выражаться либо в пересылке Выхода к другой функции для дальнейшего преобразования, либо в выработке Управляющей информации, предписывающей, что именно должна делать другая функция. Существуют пять типов взаимосвязей между блоками для описания их отношений: Управление, Вход, Обратная Связь по Управлению, Обратная Связь по Входу, Выход-Механизм.

ОТНОШЕНИЕ УПРАВЛЕНИЯ Отношение Управления возникает тогда, когда Выход одного блока непосредственно влияет на блок с меньшим доминированием.

ОТНОШЕНИЕ ВХОДА Отношение Входа возникает тогда, когда Выход одного блока становится Входом для блока с меньшим доминированием.

ОБРАТНАЯ СВЯЗЬ ПО УПРАВЛЕНИЮ Обратная Связь по Управлению возникает тогда, когда Выход некоторого блока влияет на блок с большим доминированием.

ОБРАТНАЯ СВЯЗЬ ПО ВХОДУ Обратная Связь по Входу имеет место, когда Выход одного блока становится Входом другого с большим доминированием.

ВЫХОД-МЕХАНИЗМ Отношение Выход – Механизм отражают ситуацию, при которой Выход одной функции становится средством достижения цели другой функции

ДУГА КАК СЛОЖНЫЙ ОБЪЕКТ Дуга в SADT редко изображает один объект. Обычно она символизирует набор объектов. Например, дуга, именуемая рабочий комплект, отражает техническое задание, чертеж, планграфик, некоторое сырье и заготовки. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными сложными способами.

РАЗВЕТВЛЕНИЕ ДУГ Разветвления дуг, изображаемые в виде расходящихся линий, означают, что все содержимое дуг или его часть может появиться в каждом ответвлении дуги. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь дуги может быть помечена или не помечена в соответствии со следующими правилами: непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением (т. е. все объекты принадлежат этим ветвям); ветви, помеченные после точки разветвления, содержат все объекты или их часть, указанные в метке дуги перед разветвлением (т. е. каждая метка ветви уточняет, что именно содержит ветвь).

СЛИЯНИЕ ДУГ Слияние дуг в SADT, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения. Кроме того, каждая ветвь перед слиянием может помечаться или не помечаться в соответствии со следующими правилами: непомеченные ветви содержат все объекты, указанные в общей метке дуги после слияния (т. е. все объекты исходят из всех ветвей); помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния (т. е. метка ветви ясно указывает, что содержит ветвь).

ПРИМЕР РАЗВЕТВЛЕНИЯ И СЛИЯНИЯ ДУГ

ПОДДЕРЖКА ВЕРСИОННОСТИ И РАБОТЫ В ПРОЕКТНОЙ ГРУППЕ. СНОМЕРА При создании SADT-модели одну и ту же диаграмму вместе с ее блоками и дугами перечерчивают несколько раз, что приводит к появлению различных ее вариантов. Чтобы различать разные версии одной и той же диаграммы и авторов диаграмм, в SADT используется схема контроля конфигурации диаграмм, основанная на хронологических номерах, или С-номерах. С-номерные коды образуются из инициалов автора и последовательных номеров. Эти коды ставятся в нижнем правом углу SADT-бланка.

ПРАВИЛА СИНТАКСИСА МОДЕЛЕЙ. ДЕКОМПОЗИЦИЯ SADT-модель является иерархически организованной совокупностью диаграмм. Диаграммы обычно состоят из трех-шести блоков, каждый из которых потенциально может быть детализирован на другой диаграмме. Каждый блок может пониматься как отдельный тщательно определенный объект. Разделение такого объекта на его структурные части (блоки и дуги, составляющие диаграмму) называется декомпозицией. Декомпозиция формирует границы, и каждый блок в SADT рассматривается как формальная граница некоторой части целой системы, которая описывается. Блок и касающиеся его дуги определяют точную границу диаграммы, представляющей декомпозицию этого блока. Эта диаграмма, называемая диаграммой с потомком, описывает все, связанное с этим блоком и его дугами, и не описывает ничего вне этой границы. Декомпозируемый блок называется родительским блоком, а содержащая его диаграмма - соответственно родительской диаграммой. Таким образом SADT-диаграмма является декомпозицией некоторого ограниченного объекта. Принцип ограничения объекта встречается на каждом уровне.

КОНТЕКСТНАЯ ДИАГРАММА И ЕЕ РОЛЬ Один блок и несколько дуг на самом верхнем уровне используются для определения границы всей системы. Этот блок описывает общую функцию, выполняемую системой. Дуги, касающиеся этого блока, описывают главные управления, входы, выходы и механизмы этой системы. Диаграмма, состоящая из одного блока и его дуг, определяет границу системы и называется контекстной диаграммой модели. Таким образом, этот блок изображает границу системы: все, лежащее внутри него, является частью описываемой системы, а все, лежащее вне него, образует среду системы.

ПРИМЕР КОНТЕКСТНОЙ ДИАГРАММЫ

СОЗДАНИЕ ФУНКЦИОНАЛЬНЫХ МОДЕЛЕЙ И ДИАГРАММ Сбор информации. Декомпозиция объекта исследования. Моделирование: Выбор цели и точки зрения. Составление списка данных. Составление списка функций. Построение и обобщение диаграммы А 0(А 0 – А-0). Декомпозиция ограниченного объекта. Итерационный процесс рецензирования. Завершение моделирования. Документирование.

СБОР ИНФОРМАЦИИ Сбор информации может включать любую комбинацию следующих видов деятельности: чтение документов, наблюдение за существующими операциями, анкетирование группы экспертов, опрос одного или нескольких экспертов, использование собственных знаний

ДЕКОМПОЗИЦИЯ всей системы начинается с составления списка основных типов данных и основных функций системы. Делая это, мысленно просматриваем основные функции системы, учитывая все нормальные и аномальные ситуации, обратные связи и случаи возможных ошибок. Эти списки снабжаются комментариями. Списки с комментариями используются для создания диаграммы А 0, которая затем обобщается с помощью диаграммы А-0. Декомпозиция

ЦЕЛЬ И ТОЧКА ЗРЕНИЯ Цель и точка зрения модели определяется на самой ранней стадии создания модели. Выбор цели осуществляется с учетом вопросов, на которые должна ответить модель, а выбор точки зрения – в соответствии с выбором позиции, с которой описывается модель.

СПИСКИ ДАННЫХ И СПИСКИ ФУНКЦИЙ Списки данных. Лучше, если данных больше, чем меньше. Данные можно группировать по типам. Списки функций. Функции системы тоже лучше объединить по типу используемых данных. Затем функции объединяются в группы (от 3 до 6) Желательно, чтобы эти группы имели один и тот же уровень сложности, содержали примерно одинаковый объем действий и функции в каждой из них имели сходные операции и цели.

ДИАГРАММА А 0 Исходное содержание диаграммы А 0 обеспечивают списки данных и функций. Вначале изображаются блоки в соответствии с их доминированием. Затем основные дуги, представляющие ограничения. Эти дуги всегда являются внешними, так как представляют данные, поступающие из непосредственного окружения системы. Далее размещаются остальные внешние дуги и назначаются соответствующие им ICOM-коды. В завершении изображаются все оставшиеся дуги.

ОБОБЩЕНИЕ Обобщение является последним важным шагом начального этапа моделирования. Для любой SADT – диаграммы есть родительская диаграмма, содержащая ее контекст. Контекстом для А 0 служит А-0, представляющая обобщение всей модели. Эта диаграмма имеет несколько назначений: она объявляет общую функцию всей системы, дает множество основных типов или наборов данных, которые использует или производит система, указывает взаимоотношения между основными типами данных, производя их разграничение. .

ДИАГРАММА А-0 Для построения А-0 в центре бланка рисуют один большой блок, название которого совпадает с названием диаграммы А 0. Все внешние дуги диаграммы А 0 изображаются на диаграмма А-0 входящими в соответствующую сторону блока. Далее на диаграмме выписывается цель и точка зрения модели

ПРОЦЕСС ДЕКОМПОЗИЦИИ Начало процесса декомпозиции заключается в выборе блока рассматриваемой диаграммы и рассмотрении объекта, определяемого этим блоком и его дугами. В первую очередь рассматривается блок, декомпозиция которого выявит многие аспекты диаграммы А 0 и будет оказывать большее влияние на будущие декомпозиции других блоков этой системы. При выборе самого содержательного блока нужно учесть и доминирование, и функциональную сложность и понятность.

БЛОК ДЛЯ ПЕРВОЙ ДЕКОМПОЗИЦИИ Лучшим блоком для первой декомпозиции будет тот, который позволит наиболее глубоко проникнуть в суть рассматриваемой системы. Детализация блока производится путем составления списка данных и списка функций и последующего построения диаграммы.

РЕЦЕНЗИРОВАНИЕ Рецензирование модели автором. Опытные аналитики разделяют этап создания и этап критического рассмотрения диаграммы. За несколько минут проверки можно самому обнаружить те ошибки, которые часто выявляются с помощью обратной связи с читателями. В результате этой работы могут быть внесены изменения как в новую (дочернюю), так и в родительскую диаграммы.

РЕЦЕНЗИРОВАНИЕ МОДЕЛИ АВТОРОМ. Опытные аналитики разделяют этап создания и этап критического рассмотрения диаграммы. За несколько минут проверки можно самому обнаружить те ошибки, которые часто выявляются с помощью обратной связи с читателями. В результате этой работы могут быть внесены изменения как в новую (дочернюю), так и в родительскую диаграммы.

ВНЕШНЯЯ ОЦЕНКА Точное описание модели может быть достигнуто только с помощью внешней оценки читателей и экспертов системы. Этот процесс требует создания комплектов рабочих материалов для рассылки экспертам. Этот комплект носит название папки. Папки рассылаются читателям для получения замечаний. Автор отвечает на замечания и вновь отправляет папки читателям и так до тех пор, пока модель не достигнет необходимого уровня точности. Эти папки кроме стандартных бланков содержат текстовые страницы с различными пояснениями, страницы FEO для графических и текстовых дополнений и глоссария, титульную страницу с указанием названия папки, ее автора, краткого содержания и имен экспертов.

ЗАВЕРШЕНИЕ МОДЕЛИРОВАНИЯ Одна из самых важных проблем, возникающих при моделировании – когда следует завершить построение конкретной модели. SADT-модели иерархичны и поэтому их размер может увеличиваться со скоростью геометрической прогрессии. Хотя многие SADT-модели имеют глубину 5 -6 уровней, они чаще всего состоят не более чем из нескольких десятков диаграмм. Декомпозиция модели или ее части прекращается, если модель достигла уровня детализации, достаточного для достижения цели. Декомпозиция блока может быть прекращена, если окажется, что функции блока очень сходны с другой частью модели, которая уже декомпозирована. Таким образом, достаточность деталей, изменение уровня абстракции, изменение точки зрения и сходная функциональность являются основными критериями для прекращения декомпозиции.

Стандарт IDEF 0

IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными Методология IDEF состоит из нескольких методологий моделирования, основанных на графическом представлении систем.

СЕМЕЙСТВО IDEF (1) IDEF 0 — Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF 0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF 0). Как правило, моделирование средствами IDEF 0 является первым этапом изучения любой системы. Методологию IDEF 0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique); IDEF 1 — Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF 1 X (IDEF 1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

СЕМЕЙСТВО IDEF(2) IDEF 2 — Simulation Model Design — методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF 0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets); IDEF 3 — Process Description Capture — Документирование технологических процессов. IDEF 3 — методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF 3 имеет прямую взаимосвязь с методологией IDEF 0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF 3; IDEF 4 — Object-Oriented Design — методология построения объектноориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

СЕМЕЙСТВО IDEF(3) IDEF 5 — Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF 5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация; IDEF 6 — Design Rationale Capture — Обоснование проектных действий. Назначение IDEF 6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась? » Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF 6 акцентирует внимание именно на процессе создания модели; IDEF 7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;

СЕМЕЙСТВО IDEF (4) IDEF 8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE 8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции); IDEF 9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

СЕМЕЙСТВО IDEF (5) IDEF 10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 14 — Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии.

МЕТОДОЛОГИЯ IDEF 0 – методология создания функциональной модели, которая является структурированным изображением функций производственной системы или среды, а также информации и объектов, связывающих эти функции. Полученная модель позволяет сформировать архитектуру среды моделируемой системы.

ОСНОВНЫЕ ПОНЯТИЯ IDEF 0 производства» - типовые базовые решения, обеспечивающие выполнение основных производственных функций Среда - другие системы, организации или технологии, работающие совместно для достижения общей цели производственной среды или системы Модель графическое представление основных взаимоотношений в среде моделируемой системы – функциональных связей и идентификации информационных потоков IDEF-модель становится архитектурой только тогда, когда она используется для более глубокого понимания и анализа не только производственной системы и ее окружения, но и того, как ее компоненты взаимодействуют друг с другом «Архитектура

НОТАЦИЯ IDEF 0 В качестве нотации (языка моделирования) был выбран «метод блочного моделирования» , в котором «блок» определен как производственная ячейка или функциональная единица

ОСНОВНЫЕ СВОЙСТВА НОТАЦИИ выражает производственные операции естественным и несложным способом, поскольку целью архитектуры является описание производства; краток и обеспечивает поиск интересующих деталей, поскольку моделируемый объект является весьма обширным и сложным; обеспечивает взаимодействие как работающего персонала в производстве, так и персонала управления;

ОСНОВНЫЕ СВОЙСТВА НОТАЦИИ обеспечивает достаточную строгость и точность, поскольку служит базой для планирования общих подсистем, их разработки и внедрения; должен включать методологию (правила и процедуры) использования, что позволит большому числу рабочих групп разрабатывать отдельные компоненты архитектуры системы и сделает возможным широкое обсуждение, рецензирование, критику и утверждение результатов; методология должна включать средства отделения «организационной» структуры от «функций» . Это означает, что общие соглашения могут быть достигнуты только в том случае, когда различия в организационных структурах отдельных компаний не принимаются в расчет, а рассматриваются только общие функциональные связи.

КОНЦЕПЦИИ IDEF 0 (1) Модель – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. М моделирует А, если М отвечает на вопросы относительно А. Здесь М – модель, А – моделируемый объект (оригинал). Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит.

КОНЦЕПЦИИ IDEF 0 (2) Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия происходящие в изучаемой системе. В IDEF 0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF 0 –диаграмме, основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась.

КОНЦЕПЦИИ IDEF 0 (3) Лаконичность и точность. Документация, описывающая систему, должна быть точной и лаконичной. Многословные характеристики, изложенные в форме традиционных текстов, неудовлетворительны. Графический язык позволяет лаконично, однозначно и точно показать все элементы (блоки) системы и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи и т. д. .

КОНЦЕПЦИИ IDEF 0 (4) Передача информации. Средства IDEF 0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому. К числу таких средств относятся: диаграммы, основанные на простой графике блоков и стрелок, легко читаемые и понимаемые; метки на естественном языке для описания блоков и стрелок, а также глоссарий и сопроводительный текст для уточнения смысла элементов диаграммы; последовательная декомпозиция диаграмм, строящаяся по иерархическому принципу, при котором на верхнем уровне отображаются основные функции, а затем происходит их детализация и уточнение; древовидные схемы иерархии диаграмм и блоков , обеспечивающие обозримость модели в целом и входящих в нее деталей.

КОНЦЕПЦИИ IDEF 0 (5) Строгость и формализм. Разработка моделей IDEF 0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила описываются ниже. Здесь отмечается только основное из них: все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов , связанных с неполнотой или некорректностью документации.

ПРАВИЛА СТРОГОСТИ И ФОРМАЛИЗМА(1) ограничение количества деталей на каждом уровне (правило 3 -6 блоков); ограниченный контекст (без пропусков, но и без дополнительных деталей, выходящих за рамки рассмотрения); связность интерфейса диаграмм (номера узлов, номера блоков, C-номера); связность структуры данных (ICOM-коды и использование туннельных дуг); уникальность меток и наименований (отсутствие повторяющихся имен);

ПРАВИЛА СТРОГОСТИ И ФОРМАЛИЗМА(1 Строгость и точность (2). синтаксические правила для графики (блоков и дуг); ограничение на ветвление дуг данных (метки для ограничений потоков данных на ветвях); разделение входов и управлений (правило определения роли данных); требования к меткам дуг данных (правила минимальных меток); минимальное управление для функций (для каждой функции нужна, по крайней мере, одна управляющая дуга; цель и точка зрения (у каждой модели есть цель и точка зрения).

КОНЦЕПЦИИ IDEF 0 (6) Отделение «организации» от «функций» . При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы). Это помогает избежать субъективной точки зрения, навязанной организацией и ее руководством. Организационная структура должна явиться результатом использования (применения) модели. Сравнение результата с существующей структурой позволяет, во-первых, оценить адекватность модели, а во -вторых – предложить решения, направленные на совершенствование этой структуры.

КОНЦЕПЦИИ IDEF 0 (7) Итеративное моделирование. Разработка модели в IDEF 0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF 0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования.

ИМЕНА И МЕТКИ Имена функций – глаголы или глагольные обороты. Примеры таких имен: производить детали, планировать ресурсы, наблюдать за выполнением, проектировать систему, эксплуатировать, разработать детальные чертежи, изготовить компонент, проверять деталь Имена данных. Стрелки идентифицируют данные или материальные объекты, необходимые для выполнения функции или производимые ею. Каждая стрелка должна быть помечена существительным или оборотом существительного, например: Спецификации, отчет об испытаниях, бюджет, конструкторские требования, конструкция детали, директива, инженер-конструктор, деталь, рабочий

Методология DFD

ДИАГРАММЫ ПОТОКОВ ДАННЫХ (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

ИСТОРИЯ СОЗДАНИЯ Впервые диаграммы DFD были использованы для реорганизации переполненного клерками офиса, относящийся к 20 -м годам. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой двое клерков, обменивающиеся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель, представляющая собой потоковую диаграмму - предвестника DFD.

МЕТОДОЛОГИЯ ГЕЙНА-САРСОНА ИС. В основе данной методологии лежит построение модели В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее нет необходимости.

ОСНОВНЫЕ КОМПОНЕНТЫ DFD Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными потоков данных являются: внешние сущности; системы/подсистемы; процессы; хранилища данных; потоки данных. компонентами диаграмм

ВНЕШНИЕ СУЩНОСТИ Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом, расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений:

СИСТЕМЫ И ПОДСИСТЕМЫ При построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

ПРОЦЕССЫ Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т. д. Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже. Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.

ХРАНИЛИЩЕ ДАННЫХ Накопитель данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на носителе и т. д. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью.

ПОТОК ДАННЫХ Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными носителями, и т. д. Каждый поток данных имеет имя, отражающее его содержание.

ПОСТРОЕНИЕ КОНТЕКСТНЫХ ДИАГРАММ Построение контекстных диаграмм является первым шагом при построении иерархии DFD. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть: наличие большого количества внешних сущностей (десять и более); распределенная природа системы; многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы. Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.

КОНТЕКСТНАЯ ДИАГРАММА

ДЕКОМПОЗИЦИЯ КОНТЕКСТНОЙ ДИАГРАММЫ Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или миниспецификации. При детализации должны выполняться следующие правила: правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме; правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12. 1, 12. 2, 12. 3 и т. д. Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.

ПРИМЕР ДИАГРАММЫ DFD

МИНИСПЕЦИФИКАЦИЯ Миниспецификация является завершением иерархии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев: наличия у процесса относительно небольшого количества входных и выходных потоков данных (2 -3 потока); возможности описания преобразования данных процессом в виде последовательного алгоритма; выполнения процессом единственной логической функции преобразования входной информации в выходную; возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20 -30 строк).

Инструментальное обеспечение структурного анализа и проектирования

ALLFUSION PROCESS MODELER 7 В основе программного продукта BPwin (All. Fusion Process Modeler 7) заложена методология моделирования IDFE 0. Популярность BPwin (All. Fusion Process Modeler 7) дает возможность согласовывать функциональные модели в электронном виде. BPwin (All. Fusion Process Modeler 7) - это продукт компании Computer Associates, он вместе с ERwin Data Modeler (ERwin), Model Manager (Model. Mart) и Data Model Validator (ERwin Examiner), входит в пакет программ All. Fusion Modeling Suite. Использование этого программного комплекса позволяет эффективно обеспечить все аспекты моделирования информационных систем. All. Fusion Process Modeler 7 или как он ранее назывался BPwin – мощный программный продукт с помощью которого, можно проводить моделирование, анализ, описание и последующую оптимизацию бизнес-процессов. С помощью BPwin можно создавать графические модели бизнес-процессов. Графическое изображение схемы выполнения работ, организации документооборота, обмена различными видами информации позволяет визуализировать существующую модель организации бизнеса. Это дает возможность использовать передовые инженерные технологии для решения задач управления организацией. http: //www. interface. ru/fset. asp? Url=/ca/bpwin. htm

СВОЙСТВА BPWIN BPwin является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. BPwin поддерживает три методологии: IDEF 0, DFD и IDEF 3, позволяющие анализировать бизнес с трех ключевых точек зрения: с точки зрения функциональности системы; с точки зрения потоков информации (документооборота) в системе; с точки зрения последовательности выполняемых работ. BPwin проверяет создаваемые модели с точки зрения синтаксиса выбранной методологии, ссылочную целостность между диаграммами, а также выполняет ряд других проверок, чтобы создать правильную модель, а не просто рисунок.

ДИАГРАММЫ IDEF 3 Для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологией – IDEF 3, также называемой workflow diagramming. Методология моделирования IDEF 3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов. IDEF 3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать “сеть переходных состояний объекта”, предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс. С помощью диаграмм IDEF 3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец при закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции организации.

ЭЛЕМЕНТЫ ДИАГРАММЫ IDEF 3 Единицы работы (Unit of Work) - основной компонент диаграммы IDEF 3 близкий по смыслу к работе IDEF 0. Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF 3 различают три типа связей: Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией. Связь предшествования (Precedence) – показывает, что прежде чем начнется работаприемник, должна завершиться работа-источник. Обозначается сплошной линией. Связь поток объектов (Object Flow) – показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками. Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF 3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков: Перекресток слияния (Fan-in Junction) – узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса. Перекресток ветвления (Fan-out Junction) – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно. Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы.

ПРИМЕР ДИАГРАММЫ IDEF 3

МОДЕЛЬ BPWIN Модель, выполненная в BPwin представляет собой набор иерархически упорядоченных диаграмм (не обязательно сделанных в одной методологии, чаще модели бывают смешанными). При размещении на очередной диаграмме некоторого элемента (работы, стрелки…) этот элемент вместе со всеми своими свойствами (которые всегда можно просмотреть или изменить в соответствующем редакторе BPwin) автоматически заносится в словарь BPwin, в результате вместе с графическим изображением моделируемой системы аналитик получает десятки страниц с подробным текстовым описанием системы. Применение универсальных графических языков бизнесмоделирования IDEF 0, IDEF 3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов.

НАВИГАЦИЯ В BPWIN BPwin обладает удобным инструментом для навигации по уровням декомпозиции модели. Это Model Explorer, который по организации очень похож на привычный всем проводник Windows. Работы IDEF 0 показываются в Model Explorer зеленым цветом, DFD – желтым и IDEF 3 – синим. Щелкая мышкой по любой из работ, представленных в проводнике, пользователь может переходить на диаграмму, содержащую выбранную работу. Проводник модели предлагает пользователю улучшенный интерфейс, который включает в себя новую вкладку объектов (Objects), и доработанную вкладку диаграмм (Diagrams). С помощью вкладки объектов можно методом Drag&Drop размещать объекты из словаря на любой диаграмму. С помощью вкладки диаграмм можно просматривать всю иерархию диаграмм, включая Organization Chart, Node Tree, Swim Lane, FEO, и IDEF 3 Scenario.

BPWIN ПОДДЕРЖИВАЕТ СЛОВАРИ ДЛЯ СЛЕДУЮЩИХ ОБЪЕКТОВ: Работы; Стрелки; Хранилища данных; Внешние ссылки; Перекрестки; Объекты ссылок; Атрибуты; Центры затрат; Сущности; Ресурсы; Роли; Группы ролей; Свойства, определяемые пользователем (UDP); Ключевые слова UDP.

ГЕНЕРАТОР ОТЧЕТОВ Генератор отчетов имеет мощный инструмент отчетов Report Template Builder, с помощью которого можно легко и быстро создавать различные отчеты о модели. С его помощью можно также создавать шаблоны для отчетов, которые можно будет многократно использовать впоследствии, а также преобразовывать отчеты в формат txt (. CSV), HTML или RTF.

ДИАГРАММЫ ДЕРЕВА УЗЛОВ (NODE TREE DIAGRAM) К модели BPwin можно добавлять дерево узлов, которое показывает иерархию всех работ модели на одной диаграмме. Диаграмма дерева узлов имеет вид традиционного иерархического дерева, где верхний узел (прямоугольник) соответствует работе с контекстной диаграммы, а последующие нижние узлы представляют собой дочерние уровни декомпозиции. Можно также создать диаграмму дерева узлов лишь для некоторой части модели, тогда верхним узлом диаграммы будет та работа декомпозиции, с которой вы захотите начать моделирование.

ДИАГРАММЫ ТОЛЬКО ДЛЯ ПОКАЗА (FOR EXPOSITION ONLY {FEO} DIAGRAM) К модели всегда можно добавить диаграмму FEO. Чаще всего это делается, для того чтобы проиллюстрировать разные сценарии развития процесса, показать модель с других точек зрения, вырезать важный кусок из сложной диаграммы, не портя при этом саму диаграмму. К любой диаграмме модели в BPwin, будь то контекстная диаграмма или одна из диаграмм декомпозиции можно добавлять произвольное число FEO диаграммы характерны тем, что они не подлежат синтаксической проверке со стороны BPwin, поскольку, они могут являться лишь частью синтаксически правильной диаграммы.

СХЕМЫ ОРГАНИЗАЦИИ (ORGANIZATION CHARTS). Для того чтобы наглядно представить структуру организации к любой модели в BPwin 4. 0 можно добавить схему организации. Схемы организации BPwin имеют традиционную древовидную иерархическую структуру, на вершине которой находится один прямоугольник, от которого идут ветвления к нескольким нижестоящим. Каждый прямоугольник в схеме организации соответствует конкретной роли или должности, например президента или вице-президента. Перед тем как добавить к модели схему организации, необходимо определить группы ролей, роли и, возможно, ресурсы. Сначала нужно создать одну или более группу ролей в словаре групп ролей, задав критерий, объединяющий роли, которым соответствуют схожие функции в организации. Затем в словаре ролей описать роли, которым будут соответствовать прямоугольники в схеме организации

SWIM LANE DIAGRAMS. Swim Lane диаграммы можно добавлять к любой модели в BPwin для более наглядного изображения течения процесса. Эти диаграммы используют методологию IDEF 3 и показывают горизонтальные полосы, которые представляют участие в процессе ролей.

СТОИМОСТНЫЙ АНАЛИЗ BPwin дает аналитику метрику - стоимостной анализ, основанный на работах (Activity Based Costing, ABC) и свойства, определяемые пользователем (User Defined Properties, UDP). Встроенный в BPwin механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности. Механизм вычисления расходов на основе выполняемых действий (Activity-Based Costing, ABC) - это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа. ABС является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации. Стоимостной анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостной анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания в функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия. С помощью стоимостного анализа можно решить такие задачи как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь). Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем (User Defined Properties, UDP). Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report.