- •«Белгородский государственный национальный исследовательский университет»
- •Теория систем и системный анализ
- •Предисловие
- •Содержание
- •Тема 1. Системные исследования 9
- •Тема 2. Моделирование и анализ систем. Основные подходы 18
- •Тема 3. Технологии системного моделирования 50
- •Тема 4. Технология объектного моделирования и анализа 125
- •4.2. Требования к объектному моделированию бизнес-систем 151
- •4.3. Case-инструментарий объектного моделирования и анализа 170
- •Тема 5. Технология системно-объектного моделирования и анализа 182
- •Тема 6. Графический язык моделирования бизнес-процессов bpmn. 231
- •Тема 1. Системные исследования
- •1.1. Структура самостоятельного научного направления
- •1.2. Структура системных исследований
- •1.3. Эволюция системного подхода
- •Вопросы для повторения
- •Резюме по теме
- •Тема 2. Моделирование и анализ систем. Основные подходы
- •2.1. Традиционный системный подход
- •2.1.1. Особенности и проблемы традиционного системного подхода и системного анализа
- •2.1.2. Причины существования проблем традиционного системного подхода и системного анализа
- •2.2. Объектно-ориентированный подход
- •2.2.1. Особенности объектно-ориентированного подхода
- •2.2.2. Необходимость интеграции объектного и системного подходов
- •2.3. Системология – системный подход ноосферного этапа развития науки
- •2.3.1. Основные понятия
- •2.3.2. Системология – язык теории организации, логистики и инжиниринга бизнеса
- •2.3.3. Системологический и объектно-ориентированный подход
- •Вопросы для повторения
- •Резюме по теме
- •Тема 3. Технологии системного моделирования
- •3.1. Технология системно-структурного моделирования и анализа «3-View Modeling»
- •3.1.1. Диаграммы потоков данных: нормативная система; построение модели; словарь данных; спецификация процесса
- •Нормативная система
- •Построение модели
- •Словарь данных
- •3 {Болт} 7 – от 3 до 7 итераций
- •1 {Болт} – 1 и более итераций
- •Спецификация процесса
- •3.1.2. Диаграммы «сущность-связь»: нотация Чена; нотация Баркера; построение модели
- •Нотация Чена
- •Нотация Баркера
- •Построение модели
- •3.1.3. Диаграммы переходов состояний
- •3.2. Стандарты системного моделирования и анализа серии «Icam deFinition»
- •3.2.1. Стандарт функционального моделирования idef0
- •3.2.2. Стандарт информационного моделирования idef1
- •3.2.3. Стандарт моделирования баз данных idef1x
- •3.2.4. Стандарт моделирования сценариев idef3.
- •3.2.5. Стандарт моделирования онтологий idef5
- •3.3. Case-инструментарий системного моделирования и анализа
- •3.3.1. Назначение и возможности «AllFusion Process Modeler/bPwin»
- •3.3.2. Особенности «bPwin»
- •3.3.3. Недостатки инструментария системного моделирования
- •Вопросы для повторения
- •Резюме по теме
- •Тема 4. Технология объектного моделирования и анализа
- •4.1.1. Сущности: структурные; поведенческие; группирующие; аннотационные
- •Структурные сущности
- •Поведенческие сущности
- •Группирующие сущности
- •Аннотационные сущности
- •4.1.2. Отношения
- •4.1.3. Диаграммы
- •4.1.4. Процесс объектно-ориентированного моделирования/проектирования: начальная фаза; исследование; построение; внедрение; дополнительные средства
- •Начальная фаза проекта (Inception)
- •Исследование (Elaboration)
- •Построение (Construction)
- •Внедрение (Transition)
- •Дополнительные средства
- •4.2. Требования к объектному моделированию бизнес-систем
- •4.2.1. Внешняя модель бизнес-системы
- •4.2.2. Внутренняя модель бизнес-системы
- •4.2.3. Пример uml-модели бизнес-системы
- •4.2.4. Пример модели информационного обеспечения бизнеса
- •4.3. Case-инструментарий объектного моделирования и анализа
- •4.3.1. Назначение и возможности «ibm Rational Software Architect»
- •4.3.2. Интерфейс «ibm Rational Software Architect»
- •4.3.3. Представление модели в «ibm Rational Software Architect»: представление вариантов использования; логическое представление; представление компонент; представление размещения
- •Представление вариантов использования
- •Логическое представление
- •Представление компонент
- •Представление размещения
- •4.3.4. Недостатки инструментария объектного моделирования
- •Вопросы для повторения
- •Резюме по теме
- •Тема 5. Технология системно-объектного моделирования и анализа
- •5.1. Методология системно-объектного моделирования и анализа
- •5.1.1. Системологический подход «Узел-Функция-Объект»
- •5.1.2. Адаптивная нормативная система уфо-анализа
- •5.1.3. Классификация бизнес-систем
- •5.2. Процедура системно-объектного моделирования и анализа
- •5.2.1 Алгоритм уфо-анализа.
- •5.2.2. Примеры уфо-моделей.
- •5.3. Case-инструментарий системно-объектного моделирования и анализа
- •5.3.1. Назначение и возможности «ufo-toolkit»
- •5.3.2. Особенности функционирования «ufo-toolkit»
- •5.3.3 Технология представление моделей в «ufo-toolkit»
- •Торгово-закупочная деятельность
- •Вопросы для повторения
- •Резюме по теме
- •Тема 6. Графический язык моделирования бизнес-процессов bpmn.
- •6.1. Назначение и область применения.
- •6.2. Диаграммы бизнес-процессов (bpd).
- •6.2.1. Элементы потока.
- •6.2.2. Соединяющие элементы.
- •6.2.3. Зоны ответственности и артефакты.
- •6.2.4. Правила соединения Элементов потока.
- •6.3. Соотношение bpmn, xpdl, bpel, bpml.
- •6.3.1. Стандарты sgml и xml
- •6.3.5. Соотношение языков.
- •6.4. Case-инструментарий бизнес-моделирования в нотации bpmn.
- •6.4.1. Назначение и возможности.
- •6.4.2. Особенности функционирования и интерфейса.
- •6.4.3. Примеры моделей в нотации bpmn.
- •6.4.4. Недостатки моделирования в нотации bpmn.
- •Вопросы для повторения
- •Резюме по теме
- •Вместо заключения
- •Представление dfd-диаграммы с помощью уфо-модели
- •Представление idef0-диаграммы с помощью уфо-модели.
- •Представление bpmn-диаграммы с помощью уфо-модели.
- •Глоссарий
- •Список литературы
Представление компонент
Представление компонент содержит информацию о библиотеках кода, исполняемых файлах, динамических библиотеках и других компонентах моделей. Компонент – это физический модуль кода. Представление компонентов системы позволяет увидеть связи между этими модулями. Представление компонент содержит [82]:
Компоненты, являющиеся физическими модулями кода.
Диаграммы компонентов.
Пакеты, являющиеся группами связанных компонентов. Как и в случае классов, повторное использование является одним из мотивов объединения компонентов в пакеты. Группу связанных компонентов системы легко можно использовать в других приложениях при условии, что связи между этой группой и другими тщательно отслеживаются.
Представление компонент более всего используется теми участниками проекта, кто отвечает за управление кодированием, компиляцию и размещение приложения. Часть компонентов – это библиотеки кода. Остальные – это динамические компоненты, такие, как исполняемые файлы или файлы динамических библиотек (.dll). Разработчики с помощью этого представления смогут понять, какие библиотеки кода были созданы, и какие классы содержатся в каждой из них.
Представление размещения
Последнее представление Rational Rose – это представление размещения. Оно соответствует физическому размещению системы, которое может отличаться от ее логической архитектуры. Например, система может иметь логическую трехуровневую архитектуру. Иными словами, интерфейс может быть логически отделен от бизнес-логики, а она, в свою очередь, от базы данных. Однако размещение системы может быть и двухуровневым. Интерфейс может находиться на одном компьютере, а остальные две части – на другом.
Представление размещения отражает также и такие проблемы, как отказоустойчивость системы, ширина полосы пропускания по сети, восстановление после сбоев и время отклика. В представление размещения входят [82]:
Процессы, являющиеся потоками (threads), исполняемыми в отведенной для них области памяти.
Процессоры, включающие компьютеры, способные обрабатывать данные. Любой процесс выполняется на одном или нескольких процессорах.
Устройства, то есть любая аппаратура, не способная обрабатывать данные. К числу таких устройств относятся, например, терминалы ввода-вывода и принтеры.
Диаграмма размещения, на которой обозначены процессоры и устройства сети, а также физические соединения между ними. Кроме того, на диаграмме размещения изображают еще и процессы, и обозначают, какие процессы выполняются на каких компьютерах.
Как и в предыдущем случае, из представления размещения может извлечь пользу вся работающая над проектом команда, так как оно позволяет понять, как будет физически размещена система. Основными ее пользователями, однако, будут участники работы, отвечающие за распределение приложения.
4.3.4. Недостатки инструментария объектного моделирования
Рассмотрим недостатки пакета Rational Rose в соответствии в данными, приведенными в работе [37].
Средство моделирования Rational Rose в последнее время получает все большее распространение для целей анализа деятельности предприятий. Подтверждение этому факту легко найти в Internet, проанализировав требования, которые формулируют различные компании к кандидатам на разработку информационных систем. В большинстве случаев в состав требований обязательно включается знание Rational Rose и языка моделирования UML.
Кроме того, часто приходится слышать и читать, что UML и Rational Rose являются универсальными средствами, которые вполне подходят и для моделирования бизнес-процессов. Так, на сайте компании «Интерфейс Ltd» (партнера фирмы Rational Software) приводятся следующие слова вице-президента Rational Роджера Оберга: «Rational Rose стала стандартом при разработке приложений и бизнес-моделировании». Там же, в свое время, было опубликовано следующее сообщение: «Корпорация Rational Software объявила о выходе Rational Rose 2000е – новой версии CASE-средства визуального проектирования информационных систем, позволяющего моделировать как компоненты программного обеспечения, так и бизнес-процессы». Там же опубликована статья А. Новичкова «Эффективная разработка программного обеспечения с использованием технологий и инструментов компании Rational», в конце которой приводится рекомендация: «Есть смысл приобретать AnalystStudio для проведения бизнес-моделирования. Для данных целей набор содержит все необходимое». На сайте другого партнера фирмы Rational Software, компании «АйТи», утверждается: «Rational Rose 2000 предназначено для создания сложных коммерческих приложений и корпоративных информационных систем и ориентировано на аналитиков, разработчиков архитектуры и программистов».
При этом AnalystStudio – это набор продуктов фирмы Rational Software, рекомендованный аналитикам и включающий в себя Rational Rose, как основной продукт, и Rational Unified Process, Rational Requisite PRO, Rational ClearQuest и Rational SoDA, как дополнительные.
По мнению автора работы [37], «предложение использовать Rational Rose в такой неоправданно широкой области – серьезное заблуждение. Во всяком случае, на рынке CASE-средств давно присутствуют и успешно используются инструменты, существенно лучше реализующие потребности аналитика при описании и анализе деятельности предприятия». При этом в качестве более пригодного для моделирования бизнеса инструмента называется пакет BPwin, а по поводу Rational Rose указываются следующие недостатки.
Rational Rose не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения бизнес-моделей, содержащаяся в дополнительном наборе рекомендаций или методике RUP, которая сопровождает пакет Rational Rose, предлагает диаграммы вариантов использования или прецедентов (Use Case) и диаграммы деятельности (Activity) для описания бизнес-процессов. Однако эти диаграммы позволяют описать лишь малую часть сведений, которые нужны для моделирования бизнес-процессов и которые представляются, например, средствами IDEF0. Кроме того, дуги Use Case и Activity диаграмм не имеют тех смысловых типов, которые были указаны для дуг SADT.
По мнению автора работы [37], некие синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, не объединены в законченную и понятную систему. Этим диаграммам (что, наверное, главное) не дается никакой интерпретации, объясняющей, как их применять при моделировании. Действительно, что означает, что два процесса соединены стрелкой – просто последовательность их исполнения или, например, то, что второй процесс обрабатывает некоторые (какие?) результаты деятельности первого. А может быть, наоборот, для работы первого процесса необходима некая (какая?) информация, которую подготавливает второй? Точно так же непонятно, как интерпретировать связи «процесс-состояние», «состояние-состояние» и др. Поэтому Rational Rose допускает построение синтаксически корректных Activity-диаграмм, не просто не имеющих смысла с точки зрения моделируемого объекта, но вообще не поддающихся объяснению с позиции здравого смысла [37].
По этим причинам пользователям Rational Rose при разработке Use Case и Activity-диаграмм приходится придумывать свои оригинальные синтаксические соглашения и давать свою интерпретацию имеющимся, чтобы отразить всю существенную для анализируемого процесса информацию. Например, чтобы имитировать три вида характерных для SADT входящих в процесс стрелок – вход, механизм, управление – можно каждую из них подкрашивать своим цветом, а для того, чтобы отличить входящие документы от исходящих, можно использовать пунктирные и сплошные стрелки. Другими словами, пользователь Rational Rose вынужден разрабатывать свои формализмы для получения методики построения моделей и анализа бизнес-процессов. При этом, возможно, придется не только разрабатывать свою методику, но и отклоняться от стандартов UML. Зачем это делать, если существует апробированная и признанная во всем мире IDEF0 (а также другие стандартные, средства и языки, например IDEF3), а преимущества стандартного подхода совершенно очевидны.
Даже если удастся придумать, как реализовать в Rational Rose соглашения IDEF0, или разработать свою методологию анализа бизнес-процессов, не уступающую IDEF0 и органично реализуемую в Rational Rose, то система все равно не научится «читать» разработанные модели. Дело в том, что это в ней не заложено изначально, а, следовательно, обработка и анализ моделей будут целиком на плечах аналитика. Или же придется разрабатывать свои процедуры выдачи отчетов, которые будут ориентированы на отсутствующие в стандартном UML (но имеющиеся в IDEF0) синтаксические соглашения. Но и это еще не все, поскольку не будет решена задача поддержки и контроля синтаксиса для разработанной пользователем методологии, и, следовательно, не будет никакой гарантии корректности разработанной модели.
Поэтому при необходимости проведения работ, где анализ бизнес-процессов играет важнейшую роль, выбор в качестве средства моделирования продуктов фирмы Rational Software является серьезной ошибкой.