Слайд 1ПРОЕКТИРОВАНИЕ ПО ИС
Тема № 3 «Методология структурного анализа и проектирования»
Слайд 2Принципы проектирования
Процесс перехода от первичного описания системы в виде технического
задания к ее описанию в виде набора стандартных документов (проектной
документации), достаточных для создания системы, называется проектированием.
Все наиболее распространенные методологии анализа и проектирования информационных систем при построении моделей базируются на ряде общих принципов:
Принцип декомпозиции («разделяй и властвуй») - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения. Применительно к проектированию информационных систем, данный принцип подразумевает разбиение на модули (модели или их элементы).
Слайд 3Принципы проектирования
Принцип иерархического упорядочивания - принцип организации составных частей проблемы
в иерархические древовидные структуры с добавлением новых деталей на каждом
уровне. Этот принцип предписывает рассматривать процесс построения модели системы на разных уровнях абстрагирования и детализации в рамках фиксированных представлений. Таким образом, проектирование можно представить как поуровневый спуск от наиболее общих и абстрактных моделей системы к более частным и детальным. При разработке программного обеспечения с помощью объектно-ориентированного подхода данный принцип получил название «наследование» – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой.
Слайд 4Принципы проектирования
Принцип концептуальной общности заключается в следовании единой философии на
всех стадиях жизненного цикла (например, структурный анализ → структурное проектирование
→ структурное программирование → структурное тестирование).
Принцип абстрагирования заключается в выделении суще-ственных элементов системы и отвлечения от несущественных. Другими словами, этот принцип предписывает включать в модель только те элементы проектируемой системы, которые имеют прямое отношение к выполнению системой своих функций.
Принцип формализации заключается в необходимости стро-гого методического подхода к решению проблемы и описании системы на формальном языке, пригодном для ее анализа, проектирования и разработки, а также автоматизированной генерации кода и БД.
Слайд 5Принципы проектирования
Принцип унификации предписывает унифицированное представление и обозначение одного и
того же элемента или однотипных элементов в разных моделях.
Принцип логической
независимости заключается в концен-трации внимания на логическом проектировании в целях обеспечения независимости от физической реализации.
Принцип многомодельности представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описать различные аспекты сложной системы. Это означает, что модель системы (метамодель) имеет некоторое число взаимосвязанных представлений, каждое из которых адекватно отражает некоторый аспект структуры или поведения системы.
Слайд 6Принципы проектирования
Принцип непротиворечивости заключается в согласованности элементов моделей и самих
моделей между собой.
Принцип информационной закрытости (инкапсуляции – encapsulation, англ.)
– согласно этому принципу содержание внутреннего устройства элементов системы должно быть скрыто. Этот принцип предписывает обмен информацией между элементами системы только в минимально необходимом объеме и ограничение доступа к операциям и данным каждого из них.
Принцип полиморфизма (polymorphy, англ.) – принцип построения элементов модели так, чтобы они могли принимать различные внешние формы или поведение в зависимости от обстоятельств (свойство родственных элементов решать схожие по смыслу проблемы разными способами).
Слайд 7Классификация моделей информационнных систем
При анализе и, особенно, при проектировании системы
должны быть построены ее полные и непротиворечивые модели. При этом
под моделью понимается совокупность взаимосвязанных абстрактных элементов с возможным указанием их свойств, поведения и связей между ними.
Классифицировать модели можно по следующим признакам.
По строгости описания:
неформальные – представлены в неструктурированном виде и дают общее представление о моделируемой системе. Недостаточно наглядны (особенно при сложном взаимодействии между объектами) и неприемлемы для какого-либо количественного анализа и обработки автоматическими средствами;
Слайд 8Классификация моделей информационнных систем
формальные:
описательные – модели, где сведения представлены с
помощью специальных документов (бланков, форм, анкет, таблиц и т.п.);
графические –
модели представляют собой схемы, чертежи, графы, диаграммы и т.д. Наиболее наглядны и получили широкое распространение при проектировании с помощью CASE-средств;
математические - представляют модель на языке математических отношений в виде функциональных зависимостей, систем алгебраических или дифференциальных уравнений, логических выражений и т.д.
Слайд 9Классификация моделей информационнных систем
По степени физической реализации (логической независимости):
логические –
описывают состав, структуру, состояние или поведение элементов системы без привязки
к языкам или средам программирования, техническим средствам и т.д., что обеспечивает гибкость в выборе и быстрый переход с одной программно-аппаратной платформы на другую;
физические – описывают элементы системы в соответствии с принятой физической реализацией этих элементов (языками программирования, СУБД, устройствами, и т.д.);
По степени отображения динамики происходящих процессов:
статические – описывают состав и структуру системы;
динамические – описывают поведение системы и/или ее отдельных элементов (явно или не явно присутствует время).
Слайд 10Классификация моделей информационнных систем
По отображаемому аспекту:
Функциональные описывают функции системы, возможные
варианты ее использования. Могут быть как динамическими, так и статическими
моделями;
Информационные описывают состав и структуру данных. Относятся к статическим моделям;
поведенческие описывают состояния системы и/или ее отдельных элементов и переходы между ними, взаимодействие элементов, алгоритмы обработки информации. Относятся к динамическим моделям;
Компонентные описывают состав и структуру программных и аппаратных средств. Относятся к статическим моделям;
Смешанные характеризуют сразу несколько аспектов системы.
Слайд 11Классификация моделей информационнных систем
На стадиях формирования и анализа требований изначально
начинают с построения неформальных моделей (содержательного описания предметной области), постепенно
переходя к формальным.
Аналогично на стадии проектирования, начинают с создания формальных логических моделей и заканчивают физическими. Логические и физические модели, описывающие все аспекты системы, являются одним из самых важных результатов проектирования. Этот набор должен быть достаточным для дальнейшей реализации системы на стадии кодирования.
Максимально упростить и формализовать процессы формирования моделей системы позволяют современные CASE-средства (Computer Aided Software Engineering – автоматизированная разработка программного обеспечения).
Слайд 12CASE-технологии анализа и проектирования
CASE-технология представляет собой методологию проектирования информационных систем,
набор методов, нотаций и инструментальных средств, позволяющих в наглядной форме
(в виде диаграмм) моделировать предметную область, анализировать модель системы на всех этапах разработки и сопровождения системы и разрабатывать приложения в соответствии с информационными потребностями пользователей.
Основная цель CASE-технологий заключается в максимальной автоматизации стадий анализа и проектирования систем с целью построения формальных и непротиворечивых моделей системы.
Вторая, не менее важная, цель использования CASE-технологий – вынесение части деятельности (чем больше, тем лучше) из стадии кодирования в стадию проектирования.
Слайд 13CASE-технологии анализа и проектирования
Основные функции CASE-средств:
централизованное хранение в единой базе
данных проекта (ре-позитарии) всей информации об информационной системе в течение
всего жизненного цикла
прямое проектирование программного обеспечения и баз данных
обратное проектирование (реинжиниринг). В этом случае порядок использования CASE-средства обратный – от текста программы или базы данных на диске к логической модели
синхронизация моделей системы с ее физической реализацией. При изменении модели системы могут быть автоматически внесены необходимые изменения в физическую реализацию или наоборот
автоматическое тестирование моделей на наличие ошибок
автоматическая генерация документации
Слайд 14CASE-технологии анализа и проектирования
Большинство современных CASE-средств основано на методологиях структурного
и/или объектно-ориентированного анализа и проектирования информационных систем. Выбор того или
иного подхода (парадигмы ) подразумевает следование ему и на стадии кодирования (согласно принципу концептуальной общности). Их отличие друг от друга заключается в выборе способа декомпозиции системы (задачи). Если за основу принимается функциональная (алгоритмическая) декомпозиция, то речь идет о структурном подходе, если объектная – об объектно-ориентированном.
В последнюю пару десятилетий объектно-ориентированный подход становится все более популярным. В тоже время категорично утверждать, что он самый «правильный» и надо разрабатывать системы только на его основе - нельзя.
Слайд 15CASE-технологии анализа и проектирования
Выбор подхода зависит от специфики решаемой задачи.
Как правило, структурный подход лучше подходит для автоматизации задач, оперирующих
большими объемами «пассивных» данных и ориентированных на использование реляционных баз данных (например, учет, сбор статистики, математические и инженерные расчеты, анализ данных). Объектно-ориентированный подход в основном ориентирован на решение задач, в которых четко прослеживается деление системы на взаимодействующие между собой сущности (например, управление техническими объектами или технологическими процессами, мониторинг). Наиболее характерна эта особенность для распределенных систем. Современные CASE-средства обеспечивают возможность как структурного (процедурного, функционального), так и объектно-ориентированного программирования.
Слайд 16Сущность структурного анализа и проектирования
При анализе и проектировании структурным подходом
принято называть метод исследования системы, основанный на представлении ее в
виде иерархии взаимосвязанных функций. Обычно описание системы начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со всё большим числом уровней. Разбиение на уровни производится с ограничением числа элементов на каждом из них. Описание каждого уровня включает в себя только существенные для этого уровня элементы (принцип абстрагирования). Процесс разбиения продолжается вплоть до конкретных процедур, дальнейшая детализация которых не имеет смысла. При этом автоматизируемая система должна сохранять целостное представление, в котором все составляющие ее компоненты взаимоувязаны (принцип согласованности).
Слайд 17Методологии структурного анализа и проектирования
Схематично применение структурного подхода может быть
выражено следующей схемой.
Показанная на рисунке схема не означает, что построение
моделей должно строго соответствовать указанному порядку – одна за другой. Как правило, разработка каждой последующей модели начинается еще до полного завершения разработки предыдущей, а иногда и параллельно.
Слайд 18Основы функционального анализа и проектирования систем
При разработке функциональной модели обычно
сначала строится модель существующей организации работы - модель AS-IS (как
есть). Эта модель строится на основе должностных инструкций, приказов, отчетов, нормативной документации и т.д. Она позволяет выяснить, «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Анализ модели позволяет понять, где находятся слабые места, в чем будут состоять преимущества новых процессов и насколько глубоким изменениям подвергнется существующая организация деятельности предприятия (компании, отдела). Признаками неэффективной организации могут быть:
бесполезные, неуправляемые и дублирующие работы;
работы без результата;
неэффективный документооборот.
Слайд 19Основы функционального анализа и проектирования систем
Найденные в модели недостатки исправляются
при создании модели TO-BE (как будет) – модели новой организации
работы предприятия. Модель TO-BE нужна для анализа альтернативных путей решения задачи и выбора наилучшего из них. Распространенная ошибка при создании модели TO-BE - это создание идеализированной модели. Пример - создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD-BE (как должно было быть).
Слайд 20Основы функционального анализа и проектирования систем
Построение системы на основе модели
AS-IS приводит к автоматизации предприятия по принципу «все оставить как
есть, только чтобы компьютеры стояли», т.е. система будет автоматизировать несовершенные бизнес-процессы и дублировать, а не заменять существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.
Построение системы на основе модели SHOULD-BE приведет к тому, что такая система просто не будет использоваться.
Наиболее эффективная технология построения функциональной модели заключается в разработке модели TO-BE на основе предварительно построенных моделей AS-IS и SHOULD-BE.
Слайд 21Методология SADT
Методология SADT (Structured Analysis and Design Technique, методология структурного
анализа и проектирования) представляет собой совокупность методов, правил и процедур,
предназначенных для построения функциональной модели системы.
Начало разработки методологии было положено Дугласом Россом (США) в середине 60-х годов. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT, что привело в 1981 г. к публикации ее части, называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Последняя редакция стандарта IDEF0 была выпущена в декабре 1993 г. (National Institute Standards and Technology, NIST).
Слайд 22Назначение и состав методологии IDEF0
IDEF0 рекомендована для использования Госстандартом РФ
и активно применяется в отечественных госструктурах (например, в Государственной Налоговой
Инспекции РФ).
IDEF0 при описании функционала информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:
описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);
создать описание системы и ее внешнего окружения до определения окончательных требований к ней. Иными словами, с помощью данной методологии можно постепенно выстраивать и анализировать систему даже тогда, когда трудно еще представить ее воплощение.
Слайд 23Назначение и состав методологии IDEF0
IDEF0 может применяться на ранних этапах
создания широкого круга систем. Она может быть использована для анализа
функций существующих систем и их улучшения.
Основу методологии IDEF0 составляет графический язык описания процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм:
• контекстную диаграмму;
• диаграммы декомпозиции;
• диаграммы дерева узлов;
• диаграммы только для экспозиции (for exposition only, FEO).
Слайд 24Назначение и состав методологии IDEF0
Контекстная диаграмма (диаграмма верхнего уровня), являясь
вершиной древовидной структуры диаграмм, показывает назначение системы (основную функцию) и
ее взаимодействие с внешней средой. В каждой модели только одна контекстная диаграмма. После описания основной функции выполняется функциональная декомпозиция, т.е. определяются функции, из которых состоит основная. Далее функции делятся на подфункции и так далее, до достижения требуемого уровня детализации системы. Диаграммы, которые описывают каждый такой фрагмент системы, называются диаграммами декомпозиции. После каждого сеанса декомпозиции проводятся сеансы экспертизы – эксперты указывают на соответствие реальных процессов созданным диаграммам. Найденные несоответствия устраняются, после чего приступают к дальнейшей детализации процессов.
Слайд 25Назначение и состав методологии IDEF0
Диаграмма дерева узлов показывает иерархическую зависимость
функций (работ), но не связи между ними. Их может быть
сколько угодно, поскольку дерево можно построить на произвольную глубину и с произвольного узла.
Диаграммы для экспозиции (FEO – for exposition only) строятся для иллюстрации отдельных фрагментов модели с целью отображения альтернативной точки зрения на происходящие в системе процессы (например, с точки зрения руководства).
Методология IDEF0 нашла широкое признание и применение благодаря простой графической нотации, используемой для построения модели. Главными компонентами модели являются диаграммы. На них отображаются функции системы в виде прямоугольников и связи между ними и внешней средой посредством стрелок.
Слайд 26Назначение и состав методологии IDEF0
Использование всего лишь двух графических примитивов
(прямоугольник и стрелка) позволяют быстро объяснить правила и принципы построения
диаграмм IDEF0 людям, незнакомым с этой методологией. Это достоинство позволяет подключить и активизировать деятельность заказчика по описанию бизнес-процессов, используя при этом формальный и наглядный графический язык.
Основные элементы графической нотации IDEF0:
Слайд 27Назначение и состав методологии IDEF0
Прямоугольник представляет собой работу (процесс, деятель-ность,
функцию или задачу), которая имеет фиксированную цель и приводит к
некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали»).
Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок:
вход (input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Стрелки входа всегда рисуются входящими в левую грань работы;
Слайд 28Назначение и состав методологии IDEF0
управление (control) – управляющие, регламентирующие и
нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В
соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);
Слайд 29Назначение и состав методологии IDEF0
выход (output) – материал или информация,
которые представляют результат выполнения работы. Выход отвечает на вопрос «Что
является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;
механизм (mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;
вызов (call) – стрелка указывает, что некоторая часть работы выполняется за пределами рассматриваемого блока. Стрелки выхода рисуются исходящими из нижней грани работы.
Слайд 30Понятие бизнес-процесса
Бизнес-процесс – совокупность взаимосвязанных мероприятий или задач, направленных на
достижение конечной цели (создание определенного продукта или услуги для потребителей).
Обобщенное
представление бизнес-процесса в IDEF0:
Три вида бизнес-процессов:
Управляющие – управляют функционированием системы.
Операционные – составляют основной бизнес компании и создают основной поток доходов.
Поддерживающие – обслуживают основной бизнес.
Слайд 31Пример «Сеть бизнес-процессов банка»
Слайд 40ICOM-коды и нумерация блоков
ICOM-коды (от Input, Control, Output и Mechanism)
предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу
стрелки (I, С, О или М), и порядковый номер. Входные и выходные дуги пересчитываются сверху вниз, а дуги управлений и механизмов – слева направо (так, как расположены на родительской диаграмме по отношению к родительскому блоку).
Особые ситуации возникают, когда дуги «входят в тоннель» между диаграммами. Дуга «входит в тоннель» в следующих случаях:
она является внешней дугой, которая отсутствует на родительской диаграмме (дуга имеет скрытый источник);
она касается родительского блока, но не появляется на диаграмме, которая его декомпозирует (дуга имеет скрытый приемник).
Слайд 41ICOM-коды и нумерация блоков
Тоннельные дуги от скрытого источника начинаются круглыми
скобками, чтобы указать, что эти дуги идут из какой-то другой
части модели, прямо извне модели или они не важны для родительской диаграммы и поэтому на ней не изображаются.
Тоннельные дуги со скрытым приемником заканчиваются круглыми скобками, чтобы отразить тот факт, что такая дуга идет к какой-то другой части модели, выходит из нее или не будет более в этой модели рассматриваться.
Тоннельные дуги со скрытым приемником часто используются в том случае, если они должны связываться с каждым блоком диаграммы-потомка. Изображение таких дуг может привести к существенному загромождению данной диаграммы и ее потомков.
Слайд 42ICOM-коды и нумерация блоков
Таким образом, «вхождение в тоннель» для дуг
используется чаще всего для упрощения описания системы – тогда, когда
диаграммы в модели становятся слишком сложными для чтения и понимания.
Каждый блок на диаграммах должен иметь свой номер. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня - цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т.д. Контекстная диаграмма имеет обозначение «А - 0», диаграмма декомпозиции первого уровня - «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»).
Слайд 43Дерево диаграмм
На рисунке показано типичное дерево диаграмм (диаграмма дерева узлов)
с нумерацией.
Слайд 44Пример построения модели IDEF0
Контекстная IDEF0-диаграмма процесса выполнения лабораторной
работы
Слайд 45Пример построения модели IDEF0
IDEF0-диаграмма декомпозиции процесса выполнения лабораторной
работы
Слайд 46Назначение и состав методологии DFD
При построении функциональной модели системы альтернативой
методологии SADT (IDEF0) является методология диаграмм потоков данных (Data Flow
Diagrams, DFD). В отличие от IDEF0, предназначенной для проектирования систем вообще, DFD предназначена для проектирования информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом при построении функциональной модели TO-BE.
Как и в IDEF0 основу методологии DFD составляет графический язык описания процессов. Авторами одной из первых графических нотаций DFD (1979г.) стали Эд Йордан (Yourdon) и Том Де Марко (De Marko).
Слайд 47Назначение и состав методологии DFD
Модель системы в нотации DFD представляет
собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является
единицей описания системы и располагается на отдельном листе. Модель системы содержит контекстную диаграмму и диаграммы декомпозиции.
Принципы построения функциональной модели с помощью DFD аналогичны принципам методологии IDEF0. Вначале строится контекстная диаграмма, где отображаются связи системы с внешним окружением. В дальнейшем выполняется декомпозиция системы с построением иерархии диаграмм.
Согласно DFD источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.
Слайд 48Нотации DFD модели
В методологии DFD используются две нотации: Йордана-Де Марко
(Yourdan-De-Marko) и Гейна-Сарсона (Gane-Sarson). В настоящее время наиболее распространенной является
нотация Гейна-Сарсона (Gane-Sarson).
Слайд 49Нотации DFD модели
Поток данных определяет информацию (материальный объект), передаваемую через
соединение от источника к приемнику. Поток данных имеет имя, отражающее
его содержание. Стрелка показывает направление потока данных. В отличие от IDEF0 стрелки потоков на DFD могут отображаться входящими и выходящими из любой грани внешней сущности, процесса или накопителя данных.
Процесс (в IDEF0 – функция, работа) представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Каждый процесс должен иметь имя. Номер процесса служит для его идентификации и ставится с учетом декомпозиции. В отличие от IDEF0 вложенность процессов обозначается через точку (например, в IDEF0 – «236», в DFD – «2.3.6»).
Слайд 50Нотации DFD модели
Накопитель (хранилище) данных представляет собой абстракт-ное устройство для
хранения информации, которую можно в любой момент поместить в накопитель
и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Накопителю обязательно должно даваться уникальное имя и номер в пределах всей модели (всего набора диаграмм).
Внешняя сущность (терминатор) представляет собой материальный объект или физическое лицо, выступающие как источник или приемник информации. Определение некоторого объекта, субъекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ проектируемой информационной системы. В связи с этим, внешние сущности, как правило, отображаются только на контекстной диаграмме DFD.
Слайд 51Пример построения модели DFD
Контекстная DFD-диаграмма процесса выполнения лабораторной
работы
Слайд 52Пример построения модели DFD
DFD-диаграмма декомпозиции процесса выполнения лабораторной
работы
Слайд 53Дуги на DFD диаграмме
Дуги на DFD-диаграмме изображаются линиями со
стрелками. На DFD-диаграммах могут использоваться следующие типы дуг:
однонаправленные сплошные
– отражают направление потоков объектов (данных);
двунаправленные сплошные – обозначают обмен данными между блоками;
однонаправленные штриховые – обозначают управляющие потоки между блоками.
Как и в IDEF0-методологии, дуги могут разветвляться и соединяться, могут «входить в тоннель» между диаграммами. Синтаксис и семантика тоннелирования дуг соответствуют методологии IDEF0.
Слайд 54Расширения DFD для систем реального времени
Для моделирования особенностей
поведения систем реального времени П. Вард (P. Ward) и С.
Меллор (S. Mellor) предложили использовать на DFD дополнительные элементы.
Квазинепрерывный поток - поток данных, непрерывный во времени. Отображается линией с двумя стрелками на конце.
Управляющий процесс – процесс, формирующий сигналы управления на выходе.
Управляющий процесс
Управляющий поток – управляющая информация, запускающая процесс (подсистему) или изменяющая ход его выполнения.
Слайд 55Расширения DFD для систем реального времени
Накопитель управлений – накопитель
управляющих потоков.
Пример использования новых элементов на DFD
Слайд 56Назначение и состав методологии IDEF3
Методология IDEF3 (Integrated Definition Process Description
Capture Method), являющаяся частью семейства стандартов IDEF, была разработана в
конце 1980-х годов для закрытого проекта ВВС США с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур.
IDEF3 — структурный метод, показывающий причинно-следственные связи и события, как организована работа и какие пользователи работают с моделируемой системой.
Данная методика не имеет жёстких синтаксических и семантических ограничений. Очень часто IDEF3 используют как метод, дополняющий IDEF0. Каждый функциональный блок IDEF0 может быть представлен в виде отдельного процесса IDEF3.
Слайд 57Назначение и состав методологии IDEF3
Основа методологии — сценарий (Scenario) бизнес-процесса,
описывающий последовательность изменений свойств объекта в ходе процесса. Сценарий сопровождается
документооборотом, который состоит из документов, определяющих структуру и последовательность процесса, и документов, отображающих ход его выполнения.
Действие в IDEF3 называется единицей работы (Unit of Work, UOW) и обозначается прямоугольником. Действия именуются глаголами или отглагольными существительными. Каждому действию назначается уникальный номер.
Связи задают последовательность действий. Все связи однонаправленные. Обычно стрелки рисуют слева направо, выходящими из правой и входящими в левую сторону блоков, либо сверху вниз (что является лишь соглашением, а не нормируется).
Слайд 58Назначение и состав методологии IDEF3
Выделяют три вида связей:
Слайд 59Назначение и состав методологии IDEF3
Одно действие может порождать несколько или
для выполнения действия требуется завершение нескольких действий. Для описания ветвлений
процессов используют соединения.
Слайд 60Назначение и состав методологии IDEF3
Соединения «и» инициируют выполнение конечных действий.
Все действия, присоединенные к сворачивающему соединению «И», должны завершиться, прежде
чем начнется выполнение следующего действия: после обнаружения пожара инициируются включение пожарной сигнализации, вызов пожарной охраны, и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных действия завершены.
Соединения «и»
Слайд 61Назначение и состав методологии IDEF3
Соединение «исключающее ИЛИ» означает, что вне
зависимости от количества действий, связанных со сворачивающим или разворачивающим соединением,
инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением, сможет начаться: студент не может одновременно быть направлен на лекции по двум разным курсам
Соединения «исключающее ИЛИ»
Слайд 62Назначение и состав методологии IDEF3
Связи нечеткого отношения соединение «ИЛИ» в
основном определяется и описывается непосредственно аналитиком: соединение J2 может активизировать
проверку данных чека и/или проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных – при оплате наличными. И то, и другое действие инициируются при частичной оплате как чеком, так и наличными
Соединения «ИЛИ»
Слайд 63Назначение и состав методологии IDEF3
Для моделирования асинхронного или синхронного поведения
используются соответствующие виды соединений.
В IDEF3 используется два типа диаграмм, представляющих
описание одного и того же сценария в разных ракурсах:
Диаграммы описания последовательности этапов процесса (Process Flow Description Diagrams, PFDD) документируют последовательность и описание стадий обработки в рамках исследуемого бизнес-процесса. Описание производится с точки зрения стороннего наблюдателя. Ключевыми элементами являются понятия, процесс, логика процесса.
Диаграммы перехода состояния объекта (Object State Transition Network, OSTN) используются для иллюстрации трансформаций, которые происходят на каждой стадии бизнес-процесса. При этом описание производится с точки зрения самого объекта.
Слайд 64Назначение и состав методологии IDEF3
Деталь поступает в окрасочный цех, подготовленной
к окраске. В процессе окраски наносится один слой эмали при
высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя(недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки
Пример PFDD диаграммы
Слайд 65Назначение и состав методологии IDEF3
Пример OSTN диаграммы
Состояния объекта (детали) и
изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются
окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.
Слайд 66 Пример IDEF3-модели разработки базы данных
Слайд 67 Основы построения поведенческих моделей
После определения функций системы и разработки
информационной основы, следующим шагом является проектирование поведения системы. Поведенческая модель
системы показывает, за счет чего достигается требуемая функциональность и какие данные используются для ее обеспечения. Таким образом, поведенческая модель напрямую базируется на функциональной и информационной моделях системы.
Для построения поведенческой модели часто используются блок-схемы алгоритмов. Как правило, их строят для функций (процессов), показываемых на последних уровнях диаграмм декомпозиции IDEF0 и DFD. Для DFD блок-схемы алгоритмов являются более удачным решением, чем описание элементарных процессов в виде миниспецификаций.
Слайд 68 Методология ARIS
Методология построения интегрированных информационных систем (Architecture of Integrated
Information Systems, ARIS) разработана в компании IDS Scheer AG, Германия,
реализует принципы структурного анализа и представляет собой множество различных методик, интегрированных в рамках системного подхода. ARIS поддерживает несколько типов моделей:
Слайд 69 Методология ARIS
организационные модели или группа «Оргструктура», описывающие структуру системы
– иерархию организационных подразделений, должностей и конкретных лиц, многообразие связей
между ними, а также территориальную привязку структурных подразделений
функциональные модели или группа «Функции», используемые для описания стратегических целей компании, их иерархии, а также функции, выполняемые в организации для достижения этих целей
информационные модели или группа «Информация», с помощью которых описывается структура информации, используемая в повседневной деятельности организации, и вопросы ее применения для выполнения функций
модели управления или группа «Процессы», используемые для описания бизнес-процессов, а также взаимодействия между структурой, функциями и информацией.
Слайд 70 Методология ARIS
Взаимосвязь и взаимосогласованность типов моделей в системе ARIS
графически изображают в виде «домика» ARIS:
Подход методологии ARIS к
описанию процессов основывается на рассмотрении деятельности организации с четырех точек зрения: взгляд на организационную структуру, взгляд на данные (потоки и структура), взгляд на функции (функциональные иерархии), взгляд на контроль и управление (сводные модели бизнес-процессов)
Слайд 71 Методология ARIS
Также в методологии ARIS вводят определение фазовой модели,
которая характеризует этапы создания информационных систем и подходы, применяемые к
описанию моделей бизнес-процессов:
Слайд 72 Методология ARIS
Согласно концепции ARIS, модель организации структурируется в соответствии
с концепцией жизненного цикла информационных систем, который представляется в виде
последовательности этапов жизненного цикла. Жизненный цикл в концепции ARIS представлен в виде 3 уровней фазовой модели:
1. Определение требований
2. Спецификация проекта
3. Описание реализации
Методология ARIS включает в себя большое количество нотаций, допускающих гибкое создание различных моделей организации, в том числе и поведенческих. К числу наиболее значимых и практически используемых относятся модели, реализуемые в среде ARIS Express, представленные в следующей таблице:
Слайд 74 Модель eEPC
Основная модель ARIS – eEPC (extended Event-driven Process
Chain – расширенная модель цепочки процессов, управляемых событи-ями).
По существу,
модель eEPC расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинст-вами и недостатками.
Слайд 75 Модель eEPC
Для понимания смысла нотации eEPC достаточно рассмотреть основные
типы объектов и связей. На рисунке представлена простейшая модель eEPC,
описывающая фрагмент бизнес-процесса предприятия.
Связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» или
инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных правилах:
Слайд 76 Модель eEPC
каждая функция должна быть инициирована событием и должна
завершаться событием
в каждую функцию не может входить более одной стрелки,
«запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции
Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса.
Слайд 80 Расширенная нотация eEPC
Следует отметить, что eEPC является аналогом классического
WFD-стандарта (IDEF3). Cтандарт WFD расшифровывается как Work Flow Diagram и
представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня. У диаграммы потоков работ имеется и другое название — диаграмма алгоритмов.
Слайд 81 Модель BPMN
BPMN (Business Process Model Notation) — спецификация,
разработанная в 2001-2004 годах специально созданной некоммерческой организацией Business Process
Management Initiative (BPMI). Она создавалась для способствования стандартизации бизнес-процессов.
После слияния в 2005 году с некоммерческим объединением Object Management Group (OMG), занимающимся разработкой и продвижением объектно-ориентированных технологий и стандартов, было выпущено две версии нотации – 1.2 (январь 2009 года) и 2.0 (январь 2011 года).
На данный момент OMG насчитывает 62 вендора программного обеспечения, поддерживающих и предлагающих ПО с поддержкой BPMN.
Слайд 82 Модель BPMN
BPMN – это еще одна графическая нотация для
описания бизнес-процессов. Основной целью разработки BPMN было получение нотации, легко
понимаемой всеми пользователями: от бизнес-аналитика, создающего первые наброски описаний процессов, к техническим специалистам, отвечающим за реализацию этих процессов в системе, и, наконец, до людей, которые управляют этими процессами и контролируют их работу.
На данный момент в России BPMN используется ИТшниками, а не бизнес-пользователями, последние предпочитают EPC, но наблюдается тенденция к все большему использованию BPMN из-за появления многочисленного ПО, в основе которого лежит именно нотация BPMN. BPMN нагляднее и проще для восприятия, но из-за привычки к EPC и тотального внедрения ARIS она не получила должного внимания и развития среди бизнеса (хотя в ARIS BPMN тоже поддерживается).
Слайд 83Моделирует
Не моделирует
Бизнес процессы
Потоки данных
Потоки сообщений
Ассоциации данных с действиями
Организационную структуру
Функциональные
схемы
Стратегии
Модель данных
Область применения
Нотация BPMN обычно используется для построения диаграмм
процессов нижнего уровня, описание процессов верхнего уровня для неё нетипично.
Слайд 84Моделирование в BPMN осуществляется посредством диаграмм =>
что помогает пользователям
быстро понимать логику процесса
Моделирование в BPMN
Очень важно, что диаграммы
BPMN понятны интуитивно.
Слайд 854 категории
Элементы моделирования в BPMN
При выполнении процесса могут
происходить различные события, оказывающие влияние на ход процесса: старт процесса,
его завершение, смена статуса документа, получение сообщения и многое другое. События – необязательные элементы, поэтому на диаграмме процесса в нотации BPMN они могут не отображаться.
Процесс, отображаемый в виде диаграммы, представляет собой упорядоченный набор действий, выполняемых с целью получения результата. Логические операторы предназначены для пропуска потока операций по альтернативным или параллельным ветвям.
Слайд 86 Объекты потока управления: события (events)
Событие
изображаются окружностью
означают какое-либо происшествие
в мире
инициируют действия или их результат
согласно расположению в процессе
события могут быть :
начальные (start)
промежуточные (intermediate)
завершающие (end)
Событие – это то, что происходит в течение бизнес-процесса и оказывает влияние на его ход. Чаще всего событие имеет причину (триггер) или воздействие (результат).
Слайд 87 Объекты потока управления: события (events)
Указание специфики выполняется за счет
дополнительного графического изображения (иконки, маркера), помещенного внутрь основного символа. В
дополнение к этому символы событий могут иметь различный вид контура и фоновый цвет.
Слайд 88Действие
Свёрнутый подпроцесс (collapsed subprocess) - сложное действие, содержащее диаграмму бизнес
процессов
Множественные экземпляры (multiple instances) действия показывают: одно действие выполняется многократно
Ad-hoc
подпроцесс (ad-hoc subprocess) содержит задания
Циклическое действие (loop activity) выполняется, пока условие цикла верно
Развёрнутый подпроцесс (expanded subprocess) - составное действие, скрывающее детали реализации процесса
Задание (task) - единица работы, элементарное действие в процессе
Объекты потока управления: действия (activities)
Действие представляет собой деятельность, выполняемую внутри бизнес-процесса. Действие может быть как элементарным, так и неэлементарным (составным).
Слайд 90Оператор
Обозначение
Исключающее ИЛИ, управляемое данными (data-based exclusive gateway). Для ветвления -
поток управления направляется лишь по одной исходящей ветви. Для синхронизации
- ожидает завершения выполнения одной входящей ветви и активирует выходной поток
Исключающее ИЛИ, управляемое событиями, (event-based exclusive gateway) направляет поток управления лишь по той исходящей ветви, на которой первой произошло событие
Оператор И (parallel gateway), использующийся для ветвления, разделяет один поток управления на несколько параллельных. Все исходящие ветви активируются одновременно
Включающее ИЛИ (inclusive gateway) активирует одну или более исходящих ветвей, в случае, когда осуществляется ветвление
Объекты потока управления: логические операторы (gateways)
Термин шлюз (gateway) подразумевает пропускное устройство, которое либо позволяет осуществлять переход через шлюз, либо нет.
Слайд 924 категории
Элементы моделирования в BPMN
Объекты потока управления связаны
друг с другом соединяющими объектами. Существует три вида соединяющих объектов:
потоки управления, потоки сообщений и ассоциации.
Входящий последовательный поток может соединяться с любым участком на объекте (левая и правая стороны, верхняя и нижняя части), то же относится и к исходящему последовательному потоку. Поток сообщений также обладает этим свойством.
Слайд 93Соединяющие элементы
Соединяющие объекты
Слайд 94 Пример 3
Процесс разрешения разногласий с помощью голосования по e-mail
Слайд 954 категории
Элементы моделирования в BPMN
Пулы (участники) и дорожки
отражают распределение обязанностей. Пул или дорожка обозначает организацию, роль или
систему. Дорожки позволяют иерархически делить пулы и другие дорожки.
Слайд 96Роли - визуальный механизм организации различных действий в категории со
сходной функциональностью
Пул (область) олицетворяет участника процесса. Содержит несколько объектов потока
управления, соединяющих объекты и артефакты
Дорожки - часть пула. Дорожки организовывают и классифицируют действия
Роли
С помощью пулов и дорожек изображается распределение ролей и обязанностей при выполнении действий.
Слайд 984 категории
Элементы моделирования в BPMN
Рассматриваемые как артефакты элементы
нотации не являются исполнительными и служат для облегчения читаемости и
анализа моделируемых бизнес-процессов.
Слайд 99Артефакты позволяют разработчикам отображать дополнительную информацию в диаграмме
Данные
(показывают читателю,
какие действия требуют выполнения и/или что они производят)
Группа (группировка)
(позволяет объединять
различные действия, но не влияет на поток управления в диаграмме)
Текстовая аннотация
(способ предоставления дополнительной информации для изучающего схему BPMN)
Артефакты
Слайд 101Диаграммы бизнес-процессов позволяют описывать бизнес-процессы и помогают читателям быстро понимать
процесс и легко ориентироваться в его логике. В BPMN-модели можно
выделить три типа подмоделей:
Частные бизнес-процессы
Процессы взаимодейс-твия
Использование BPMN
BPMN описывает множество типов моделирования и допускает создание сквозных бизнес-процессов.
Слайд 102Частные (внутренние) бизнес-процессы описывают внутреннюю деятельность организации. Они представляют бизнес-процессы
в общепринятом понимании (business processes или workflows)
Использование BPMN: частные
бизнес-процессы
Один частный бизнес процесс может быть отображен в одном или более документах, но при любых условиях он должен быть закончен внутри организации.
Слайд 103Абстрактные (открытые) бизнес-процессы отображают взаимодействие между двумя частными бизнес-процессами. В
открытом бизнес процессе показываются только те действия, которые участвуют в
коммуникации с другими процессами
Использование BPMN: абстрактные бизнес-процессы
Таким образом, абстрактный процесс показывает окружающим последовательность событий, с помощью которой можно взаимодействовать с данным бизнес-процессом.
Слайд 104Процесс взаимодействия (глобальный) отображает взаимодействия между двумя и более сущностями.
Взаимодействия определяются последовательностью действий, обрабатывающих сообщения между участниками
Использование BPMN:
процессы взаимодействия
Процессы взаимодействия могут помещаться в пул.
Слайд 105В событие «старт процесса» не может входить ни одна стрелка
потока управления
Из события «завершение процесса» не может исходить ни одна
стрелка потока управления
Из события «источник сообщения» (в событие «получатель сообщения») может исходить (входить) максимум одна стрелка потока сообщений
Правила синтаксиса
Слайд 106Позволяет следить за влиянием окружающей бизнес-среды на процесс
Позволяет объединять исполнителей
в группы (пулы и дорожки)
Позволяет моделировать взаимодействие с внешними объектами
Позволяет
детально представить процесс
Возможно описать не только рабочий процесс, но и документооборот
О плюсах BPMN
Слайд 107Много типов блоков. Можно описать одно и то же, но
разными методами
При моделировании линейных процессов со множеством исполнителей можно получить
размазанную по вертикали, трудно читаемую схему
Нотация не позволяет указать стоимость выполнения того или иного действия в денежном выражении
Об ограничениях BPMN
Слайд 108 Организационная структура
Описание бизнес-процессов компании предваряется составлением модели организационной структуры
компании.
Организационная структура — документ, устанавливающий количественный и качественный состав подразделений предприятия
и схематически отражающий порядок их взаимодействия между собой. Структура предприятия устанавливается исходя из объёма и содержания задач, решаемых предприятием, направленности и интенсивности, сложившихся на предприятии информационных и документационных потоков, и с учётом его организационных и материальных возможностей.
Для описания организационной структуры компании ARIS предлагает нотацию ORG.
Слайд 110 Типы связей в Organizational Chart (ORG)
Типы связей: Имеет в
подчинении (Is superior), Связан с (Is assigned to), Принадлежит (Belongs
to), Является организационным управляющим (Is Organization Manager for), Имеет в своем составе (Has member), Состоит из (Is composed of), Располагает (Is located at), Взаимодействует с (Cooperates with), Содержит (Subsumes), Занимает (Occupies).
Слайд 111 Диаграмма цепочки добавленной стоимости (VAD)
Аналог классического стандарта DFD. Используется
для описания бизнес-процессов верхнего уровня.
Дополнительным отличием данной модели от
других процессных моделей является то, что информационные и материальные потоки на схеме VAD изображаются не стрелками, а объектами (кластерами). При этом для каждого типа потока используется свой объект.
Элементы диаграммы:
Слайд 112 Диаграмма цепочки добавленной стоимости (VAD)
Слайд 113 Модель данных
Для описания структуры входных и выходных информационных потоков
бизнес-процессов предприятия применяется модель данных. Для моделирования данных при этом
используется модель «сущность-связь» (ERM - Entity Relationship Model). Модель данных таким образом позволяет создать структуру базы данных.
Модель данных содержит следующие основные элементы:
Entity — сущность (таблица);
Attributes — атрибут сущности (поле таблицы);
Primary Key — уникальный атрибут сущности (первичный ключ таблицы);
Foreing Key — внешний ключ таблицы;
Relationship — отношения между сущностями (связь между таблицами)
Слайд 114 Модель данных
Сущность – это реальный или абстрактный объект, представляющий
интерес для задач в конкретной области деятельности
Атрибуты – это свойства,
описывающие типы сущностей
Первичный ключ – уникальный идентификатор объекта
Внешний ключ – ссылка на первичный ключ другого объекта
Отношение – это логическая связь между сущностями
