Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование сложных бизнес-объектов на основе системного анализа. Монография
.pdf
читаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:
− ограничение количества функциональных блоков на диаграмме тремяшестью. Верхний предел (шесть) заставляет разработчика использовать
иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы
оправдать ее создание;
− ограничение количества подходящих к одному функциональному блоку
(выходящих из одного функционального блока) интерфейсных дуг четырьмя.
Если говорить о недостатках данного стандарта, то необходимо упомянуть о некоторой субъективности получаемых моделей: полученные модели
напрямую зависят от компетенции разработчика. Впрочем, данный недостаток
в той или иной мере присущ абсолютно всем методологиям моделирования
бизнес-процессов.
Например, рассмотрим рисунок 5.3. Поток «Подготовленное рабочее ме-
сто» можно трактовать и как вход, и как механизм.
Рисунок 5.3. Субъективность IDEF0-диаграмм
IDEF0-модель представляет собой результат скоординированной кол-
лективной работы, при которой авторы на базе собранной первоначальной информации об объекте моделирования, и передают их другим участникам проекта для рассмотрения и формулирования замечаний. Порядок требует, чтобы
каждый эксперт, у которого есть замечания к диаграмме, сделал их письменно
и передал автору диаграммы. Данный цикл продолжается до тех пор, пока диаграммы, а затем и вся модель не будут приняты.
91
Рисунок 5.4. Процесс моделирования с использованием стандарта IDEF0
92
Ценность модели (проекта) определяется ее приемлемостью для экспертов. Данная приемлемость достигается следующими путями:
− постоянным рецензированием экспертами развивающейся модели,
что обеспечивает необходимый уровень соответствия (адекватности)
модели существующему или предполагаемому моделируемому объекту в том понимании, которое соответствует мнению экспертов;
− периодическим обсуждением диаграмм, частей модели в целом на
техническом совете, решение которого (оформленное в виде протокола) позволяет автору продолжить уточняющее моделирование или
закончить его ввиду достаточности детализации и приемлемости проекта (модели).
В коллектив, занимающийся проектированием (моделированием), должны входить следующие участники (рисунок 5.5):
− руководитель проекта;
− авторы (разработчики) модели;
− технический совет;
− эксперты в предметной области;
− библиотекарь.
Рисунок 5.5. Структура взаимодействия участников проекта
При проведении работ с привлечением сторонних организаций может
создаваться технический совет, обеспечивающий взаимодействие всех участников проекта, работающих как в составе проектирующей организации, так и вне
ее. Выполняемая функция (роль, которую выполняет участник проекта) не зависит от должности. Один и тот же человек может выполнять несколько функций. Однако роль каждого участника проекта индивидуальна, должна быть определена и зависит от рассматриваемой части проекта.
93
Принципы коллективной работы в IDEF0-методологии гарантируют, что
окончательная версия IDEF0-модели будет верной, так как модель корректируется по результатам рецензирования частей модели, оформленных в виде папок.
Более подробная детализация достигается построением необходимого количества диаграмм. По новым частям модели делаются новые замечания, вносятся
новые изменения. Окончательная модель соответствует представлениям автора
и экспертов о системе, смоделированной с данной точки зрения и для данной
цели.
5.3 IDEF3 (Integration Definition for Function Modeling)
IDEF3 представляет собой способ описания процессов, основной целью
которого является обеспечение структурированного метода, используя который
можно описать процессы в предметной области как упорядоченную последовательность событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу. IDEF3 является стандартом документирования
бизнес-процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарий –
описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки
детали в цеху и изменение её свойств после прохождения каждого этапа).
Технология IDEF3 хорошо приспособлена для сбора данных, требующих для проведения структурного анализа системы. В отличие от большинства
технологий моделирования бизнес-процессов, IDEF3 не имеет жестких синтаксических или семантических ограничений, делающих неудобным описание неполных или семантических ограничений, делающих неудобным описание неполных или нецелостных систем [75]. Кроме того, системный аналитик (автор
модели) избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области.
Технология IDEF3 также может быть использована как метод проектирования бизнес-процессов. IDEF3-моделирование органично дополняет традиционное моделирование с использованием стандарта IDEF0. Стандарт IDEF3
предназначен для описания бизнес-процессов нижнего уровня и содержит объекты – логические операторы, с помощью которых показывают альтернативы и
места принятия решений и в бизнес-процессе, а также объекты – стрелки, с помощью которых показывают временную последовательность работ в бизнеспроцессе (рисунок 5.6).
94
Рисунок 5.6. Схема бизнес-процесса в стандарте IDEF3
Рассмотрим взаимодействие стандартов IDEF0 и IDEF3. Как правило,
модели IDEF3 используются для иллюстрирования вызовов листовых функциональных блоков IDEF0 (т.е. блоков, не имеющих диаграмм декомпозиции).
Как правило, при работе с пластиковой карточкой клиент не производит
всех доступных ему при этом действий, выполняя ограниченный набор операций. Допустим, при оплате покупки не производится снятие наличных, а при
проверке баланса состояние счета вообще не изменяется. Системный аналитик
может декомпозировать функциональный блок «Обработать операций с кредиткой», создав дополнительные блоки для оплаты покупок, снятия наличных,
проверки баланса и т.п. Вместо этого можно создать отдельные IDEF3-модели
для каждого из этих действий.
Семантика построения моделей IDEF0 и IDEF3 предполагает соблюдение четких правил. Подробную информацию о построении моделей можно получить в стандартах и публикациях (например, см. [24, 71, 75]).
5.4 Структурный анализ потоков данных DFD
(Data Flow Diagrams)
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы)
и представляются в виде сети, связанной потоками данных. Главная цель таких
средств – продемонстрировать, как каждый процесс преобразует свои входные
данные в выходные, а также выявить отношения между этими процессами.
Также, как и диаграммы IDEF0, диаграммы потоков данных моделируют систему как набор действий, соединенных друг с другом стрелками. Диаграммы
потоков данных также могут содержать два новых типа объектов: объекты, собирающие и хранящие информацию – хранилища данных и внешние сущности
– объекты, которые моделируют взаимодействие с теми частями системы (или
другими системами), которые выходят за границы моделирования.
95
Рисунок 5.7. DFD-схема бизнес-процесса «Заключить договор на автострахование»
в нотации Гейна-Сарсона
96
Диаграммы потоков данных известны очень давно. В фольклоре упоминается следующий пример использования DFD для реорганизации переполненного клерками офиса, относящийся к 20-м годам. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой – каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил
схему реорганизации, в соответствии с которой двое клерков, обменивающиеся
множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель,
представляющая собой потоковую диаграмму - предвестника DFD.
На рисунке 5.7 приведен пример DFD-схемы бизнес-процесса «Заключить договор на автострахование», разработанной в нотации Гейна-Сарсона.В
отличие от стрелок в IDEF0, которые иллюстрируют отношения, стрелки в DFD
показывают, как объекты (включая и данные) реально перемещаются от одного
действия к другому. Построение DFD-диаграмм в основном ассоциируется с
разработкой программного обеспечения, поскольку нотация DFD изначально
была разработана для этих целей.
Для изображения DFD традиционно используются две различные нотации:
Йордана – Де Марко (Yourdon – DeMarco) и Гейна-Сарсона (Gane-Sarson, названа в честь Криса Гейна (Chris Gane) и Тришам Сарсона (Trish Sarson)). Нотации аналогичны, за исключением форм объектов. Подробно ознакомиться с
особенностями нотаций можно в [54, 71, 75]
5.5 UML (Unified Modeling Language)
Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования
и документирования компонентов программного обеспечения, бизнеспроцессов и других систем. Язык UML одновременно является простым и
мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей
сложных систем самого различного целевого назначения [67].
UML позволяет представить модели сложной системы в различных
взаимосвязанных аспектах. Для иллюстрации использована модель «4+1» (The
4+1 View Model of Architecture), которая была предложена Филиппом Кручтеном (Philippe Kruchten) из компании Rational в 1995 году (рисунок 5.8).
Модель предлагает простой и понятный способ описания архитектуры
сложных систем, который состоит в использовании пяти различных категорий
или представлений (views):
− логическое представление: что система должна выполнять в тер-
минах конечных пользователей;
− процессное представление: учитывает некоторые нефункциональ-
ные требования к системе, включая производительность и доступность;
97
− физическое представление: рассматривает нефункциональные тре-
бования, такие как доступность, надежность, устойчивость, производительность, масштабируемость;
− представление уровня разработки: описывает фактическую органи-
зацию модулей системы, разделение ее на подсистемы, которые
могут разрабатываться независимо;
− сценарии (модель сложной системы): объединяют все представле-
ния вместе. Сценарии использования описываются как последовательность взаимодействия объектов и процессов. Они отражают
наиболее важные требования, которым должна удовлетворять система.
Логическое представление
(диаграмма вариантов
использования)
Конечный пользователь
Внешние и внутренние
структурные отношения
Модель сложной
системы
Процессное представление
(диаграммы поведения)
Системный интегратор
Производительность и
масштабируемость
компонентов системы
Общая модель сложной системы Детальная модель сложной системы
Рисунок 5.8. Общая схема взаимосвязей моделей
Представление уровня
разработки
(диаграмма классов)
Разработчики
Отношения между компонентами
программного обеспечения
Физическое представление
(диаграммы реализации)
Системный администратор
Топология взаимосвязей и
коммуникаций компонентов
системы
Статическая
модель
сложной
системы
Динамическая
модель
сложной
системы
В рамках языка UML все представления о модели сложной системы
фиксируются в виде специальных графических конструкций, получивших название диаграмм. В терминах языка UML определены следующие виды диаграмм (таблица 5.1):
− диаграмма вариантов использования (use case diagram);
− диаграмма классов (class diagram);
− диаграммы поведения (behaviour diagrams):
o диаграмма состояний (statechart diagram);
o диаграмма деятельности (activity diagram);
o диаграммы взаимодействия (interaction diagrams):
диаграмма последовательности (sequence diagram);
диаграмма кооперации (collaboration diagram);
98
− диаграммы реализации (implementation diagrams):
o диаграмма компонентов (component diagram);
o диаграмма развертывания (deployment diagram).
Таблица 5.1. Основные диаграммы UML
Наименование
диаграммы и опи-
сание
1. Диаграмма вариантов использования (use case dia-
gram)
Пример
Диаграммы вариантов использования описывает функциональное назначение системы. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Конкретная
цель диаграмм вариантов использования – это документирование вариантов использования (все, входящее в сферу применения системы),
действующих лиц (все вне этой сферы) и связей между ними.
2. Диаграмма классов (class diagram)
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. Диаграмма
классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. На данной диаграмме не указывается информация о временных аспектах функционирования системы.
99
Наименование
диаграммы и опи-
сание
Пример
3. Диаграммы поведения (behaviour diagrams)
3.1 Диаграмма состояний (statechart
diagram)
3.2 Диаграмма деятельности (activity
diagram)
Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. Таким
образом, диаграмма состояний используется для моделирования поведения объектов системы при переходе из одного состояния в другое.
Диаграммы деятельности используются для моделирования процесса
выполнения операций. Применяемая в них графическая нотация во
многом похожа на нотацию диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения состояний и
переходов. Отличие заключается в семантике состояний, которые используются для представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий.
100
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]