Анализ и разработка моделей информационных процессов и структур

Министерство образования и науки Российской Федерации 
 
ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ 
УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР) 
 
 
 
 
Н.В. Зариковская 
 
 
 
 
 
 
 
 
 
 
 
 
Анализ и разработка моделей информационных 
процессов и структур 
 
Учебное пособие 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Томск, 2018 

Зариковская Н.В. Анализ и разработка моделей информационных 
процессов и структур. Учебное пособие - Томск: Изд-во ТУСУР, 2018. - 
189 с. 
 
Рассмотрены 
вопросы 
применение 
современных 
языков 
и 
инструментов для моделирования предметной области автоматизации. 
Приведены современные парадигмы и инструменты моделирования, 
возможности различных инструментов по описанию предметной области 
автоматизации на различных этапах создания информационных систем. 
Особое 
внимание 
уделено 
объектно-ориентированному 
анализу 
и 
проектированию на базе инструмента Enterprise Architect и методологии 
структурного анализа и проектирования на базе AllFusion Modeling Suite.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
© Зариковская Н.В. 2018 
© Томский 
государственный 
университет 
систем 
управления 
и 
радиоэлектроники (ТУСУР) 

ОГЛАВЛЕНИЕ 

ВВЕДЕНИЕ………………………………………………………………….
5

Глава 1. Характеристика современных языков моделирования бизнеспроцессов ……………………………………………………………………
6

1.1. Формальное представление потока работ ……………………….
8

1.2. 
Некоторые, 
наиболее 
известные 
стандарты 
описания 

бизнес-роцессов…………………………………………………………….
9

1.3. Моделирование бизнес процессов на основе BPMN-диаграмм
12

1.4. Стандарт для описания метамоделей MOF и стандарт обмена 

моделями и метамоделями XMI …………………………………………..

26

Глава 
2. 
Описание 
бизнес-процессов 
как 
один 
из 
этапов 

автоматизации…..

40

2.1. Способы описания бизнес-процессов …………………………....
40

2.2. Классическая методология описания бизнес-процессов.…….....
41

2.3. Современные методологии описания бизнес-процессов………..
43

2.4. Основы методологии разработки информационных систем на  

базе моделей предметной области………………………………………….
50

2.5.
Методология 
функционального 
моделирования 
SADT 

(Structured Analysis and Design Technique)....................................................
59

2.6.
Построение 
информационной 
модели 
системы.  

Проектирование баз данных ………..............................................................
63

2.7. Методологии, применяемые для разработки средних и  

крупных информационных систем ………………………………………...
72

Глава 3. Введение в унифицированный язык моделирования (UML)…...
76

3.1. История унифицированного языка моделирования …………….
76

3.2. Структура унифицированного языка моделирования …….........
78

3.3. Типы диаграмм UML 2.0 .……………………….………………..
79

3.4. Строительные блоки UML 2.0…………………………..………..
81

3.5. Отношения …………………………………………………..….…
88

3.6. Диаграммы……………………………………..…………………..
101

3.6.1. Диаграммы структуры ……………………………………….
101

3.6.2. Диаграммы поведения………………………………………..
109

3.7. Общие механизмы UML ………………………………………….
115

3.8. Архитектура системы в RUP (Rational Unified Process)……….... 118

Глава 
4.
Объектно-ориентированный 
подход 
к 
разработке 

программного обеспечения ………………………………………………....
121

4.1. Трехуровневая модель приложения ……………………………...
122

4.2. Методологии объектно-ориентированного подхода ……………
126

4.3. Рекомендации по созданию модели анализа……………...…….. 132
4.4. Объектно-ориентированное проектирование ……………..…….
133

4.5. Модели системы ………………………………………………….
142

4.6. Методы проектирования ………………………………………...
145

4.7. 
Унифицированный 
процесс 
разработки 
программного 

обеспечения ………………………………………………………………..
146

Глава 5. Требования при разработке программного обеспечения ……..
153

5.1. Виды требований……………………………………………..….
153

5.2. Анализ и сбор требований ……………………………………....
156

5.3. Инженерия требований ПО ………………………………….…..
158

5.4. Верификация и формализация требований ……………………..
160

5.5. Объектно-ориентированная инженерия требований…………….
161

5.6. Модель анализа требований. Определение объектов……………
168

5.7. Трассирование требований……………………………………….
170

5.8. Способ описания функциональных требований к системе…….
171

5.9. Управление требованиями на базе стандартов IBM Rational…..
175

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ……………….…..
187

 

ВВЕДЕНИЕ 

 

Принципиальными 
факторами, 
влияющими 
на 
структуру 

информационных 
систем 
и 
технологические 
процессы 
обработки 

информации, 
являются 
функциональные 
бизнес-процессы, 
потоки 

динамически изменяющихся данных, организация данных в сложные 
структуры. Такой подход в анализе и проектировании систем обусловил 
наибольшее распространение определенных видов CASE-технологий, 
отраженных в стандартах UML, IDEF0, DFD, IDEF3 и IDEF1X, а также 
соответствующих программных инструментах почти всех ведущих фирм –
производителей программного обеспечения.  

Одним из факторов, от которых зависит успех проекта, является 
наличие строгого стандарта языка моделирования, включающего элементы 
модели – фундаментальные концепции моделирования и их семантику, 
нотацию – визуальное представление элементов моделирования, и 
руководство по использованию языка – правила применения его элементов 
в рамках построения тех или иных типов моделей программного 
обеспечения.  
Данное учебное пособие посвящено характеристике современных 
языков моделирования бизнес-процессов и описанию их роли и места в 
общем процессе проектирования информационных систем, представлению 
наиболее 
известных 
стандартов 
описания 
бизнес-процессов, 
моделированию бизнес-процессов на основе BPMN-диаграмм. Приводятся 
основы методологии разработки информационных систем на базе моделей 
предметной области. А также содержит сведения об объектноориентированном подходе к разработке программного обеспечения. 
Представлена характеристика UML-2 с примерами на базе Enterprise 
Architect. Дана развернутая характеристика унифицированного процесса 
разработки программного обеспечения. 

Помимо вышесказанного, показан процесс анализа и управления 

требованиями, способы их описания, документирования и трассировки.  

 
 

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

исполнения и координации (Workflow Management Systems). Количество 
подобных 
информационных 
систем 
(интеграционных 
платформ 
и 
серверов), в основу которых на формальном уровне заложена базовая 
концепция интеграции распределенных ресурсов (как программных 
систем, так и человеческих ресурсов) для выполнения некоторой общей 
задачи, увеличивается очень быстрыми темпами. При этом новые решения 
приводят к появлению новых задач, адресованных системам исполнения 
потоков работ. 
К основным из них можно отнести: 
строгую формализацию описаний потоков работ на некотором языке 
при построении автономных систем исполнения потоков работ (вне 
контекста конкретного варианта их использования); 

предоставление системой разработки потоков работ (являющейся 
частью интеграционного сервера) развитых средств по созданию и 
модификации описаний потоков работ, поскольку основной контингент 
пользователей подобных систем составляют исполнители на местах – 
аналитики, менеджеры (т. е. люди, неискушенные в программировании 
маршрута потока работ с использованием некоторых формальных языков). 
При этом должен использоваться наиболее интуитивно понятный 
обычному 
пользователю 
способ 
формирования 
потоков 
работ 
– 
визуальные диаграммы (так как практически каждый управляющий 
процессом человек привык применять для таких целей некоторое 
прикладное средство, такое как, например, диаграммы активности 
деятельности UML). Таким образом, помимо эффективного «языка 
программирования» 
потоков 
работ 
пользователям 
должна 
быть 
представлена 
удобная 
графическая 
нотация 
для 
их 
описания 
с 

достаточным уровнем абстракции; 

предоставление интеграционным сервером создателям описаний 
потоков работ полного набора средств для проверки их работоспособности 
до начала опытной эксплуатации. Такие средства должны включать как 
простые статические верификаторы корректности созданных описаний 
потоков работ, так и динамические отладчики; 
интерактивные средства взаимодействия с пользователями, которые 
являются важной частью интеграционного сервера, поскольку именно 
пользователи управляют ходом выполнения потока работ; 
задачи 
обеспечения 
безопасности 
данных 
и 
поддержки 
транзакционности автоматизированных потоков работ, которые имеют 
большую важность. 
По 
данным 
направлениям 
организациями 
– 
законодателями 
теоретических основ систем исполнения потоков работ выполняется 
большая работа по стандартизации универсальных решений и технологий. 
При этом для создания гибкой расширяемой архитектуры интеграционного 
сервера необходима четкая декомпозиция процесса разработки и 

исполнения потока работ на отдельные этапы и анализ задач, 
возникающих на каждом из них. Ниже рассмотрен подход к созданию 
интеграционного сервера, автоматизирующего весь жизненный цикл 
потока работ от создания до отладки и исполнения. 
 
1.1. Формальное представление потока работ 
 
В основе каждого автоматизируемого потока работ заложено 
понятие так называемой модели потока работ, которая представляет собой 
формализованное 
описание 
потоков 
работ, 
отражающее 
реально 
существующую или предполагаемую деятельность в рамках некоторого 
реального производственного процесса. 
Модель потока работ должна давать ответы на вопросы: 
какие процедуры (функции, работы) необходимо выполнить для 
получения заданного конечного результата; 
в какой последовательности выполняются эти процедуры; 
какие механизмы контроля и управления существуют в рамках 
рассматриваемого потока работ; 
кто выполняет процедуры процесса; 
какие 
входящие 
документы/информацию 
использует 
каждая 
процедура процесса; 
какие исходящие документы/информацию генерирует процедура 
процесса; 
какие ресурсы необходимы для выполнения каждой процедуры 
процесса; 
какая 
документация/условия 
регламентирует 
выполнение 
процедуры; 
какие параметры характеризуют выполнение процедур и процесса в 
целом. 
В настоящее время разрабатываются многочисленные стандарты, 
целью которых является интеграция существующих методов и языков 
моделирования потоков работ и создание единого методического и 
технологического базиса моделирования автоматизированных потоков 
работ. 
Метод SADT (Structured Analysis and Design Technique) создан 
Дугласом Россом (SoftTech, Inc.) еще в 1969 г. и поддерживается 
Министерством обороны США, которое было инициатором разработки 
семейства стандартов IDEF (Integrated DEFinition Methods). Метод SADT 
реализован в одном из стандартов этого семейства – IDEF0, утвержденным 
в качестве федерального стандарта США в 1993 г. Это процессный метод 
управления, т. е. система рассматривается именно как набор потоков работ 
и не строится организационно-штатная структура. Эта модель описывается 
как на естественных языках, так и при помощи диаграмм. В описании 

данной методологии указано, что все диаграммы модели SADT 
взаимосвязаны и организованы в иерархию. 
Вершина иерархии описывает систему в целом, это самое общее 
описание, а в подразделах – описания детализированные. После описания 
системы в целом проводится разбиение ее на крупные фрагменты. Этот 
процесс называется функциональной декомпозицией, а диаграммы, 
которые описывают каждый фрагмент и взаимодействие фрагментов, – 
диаграммами декомпозиции. После декомпозиции контекстной диаграммы 
проводится декомпозиция каждого большого фрагмента системы на более 
мелкие и так далее до достижения нужного уровня подробности описания. 
В конце 1980-х гг. был разработан метод моделирования IDEF3, 
являющийся 
частью 
семейства 
стандартов 
IDEF. 
Предполагалось 
использование метода для моделирования работы ВВС США. С помощью 
этого 
метода 
стало 
возможным 
моделировать 
последовательность 
действий в рамках некоторого процесса. Основой модели IDEF3 служит 
так называемый сценарий процесса, который выделяет последовательность 
действий и подпроцессов анализируемой системы. Главной единицей 
модели IDEF3 является диаграмма. Другой важный компонент модели – 
действие, или в терминах IDEF3 «единица работы» (Unit of Work). Каждое 
действие имеет идентификатор. Существуют связи между действиями 
(однонаправленные стрелки) и три типа таких связей: временное 
предшествование, 
объектный 
поток, 
нечеткое 
отношение 
(вид 
взаимодействия каждый раз оговаривается отдельно). 
Также для описания потоков работ используется моделирование 
потоков данных. Диаграммы потоков данных (Data Flow Diagrams – DFD) 
представляют собой иерархию процессов, которые связаны между собой 
этими потоками. Диаграммы показывают, как обрабатывает информацию 
каждый процесс, как процессы связаны друг с другом, а также как работает 
сама система, каким образом она обрабатывает поступающие данные. 
Качественно новым шагом в моделировании потоков работ стало 
появление нотации Process Modeling Notation (BPMN), представленной 
консорциумом Business Process Management Initiative (BPMI) в 2003 г. Целью 
этого проекта является создание общей нотации для различных категорий 
специалистов: от аналитиков и экспертов до разработчиков ПО. BPMNмодель визуализируются с помощью диаграммы под названием Business 
Process Diagram (BPD). 
 
1.2. Стандарты описания бизнес-процессов 
 
Одной из основных целей разработки стандартов (особенно 
стандартов языков описаний является обеспечение переносимости 
разработки между различными системами (табл. 1.2, рис. 1.1). Именно 
такую цель заявляли разработчики BPEL (табл. 1.1). Эти стандарты нашли 

свою реализацию в программных продуктах фирм, специализирующихся в 
разработке 
инструментов, 
автоматизирующих 
процесс 
создания 
программного обеспечения (табл. 1.2). 
 
Таблица 1.1. Cписок популярных стандартов, связанных с описанием 
бизнес-процессов 

 

Стандарт 
Авторы/Текущие 

разработчики
Краткое описание 

Business Process 
Modeling Notation 
(BPMN) 

Создан Business
Modeling & Integration. 
В настоящее время 
передан Object 
Management Group 
(OMG)

Система графических обозначений для 
наглядного визуального представления 
схемы бизнес-процесса. На сегодня это, 
пожалуй, наиболее популярная нотация 
для визуализации схем БП 

Unified Modeling 
Language (UML) 

Был разработан в 
Rational Software. 
Передан Object 
Management Group 
(OMG) 

Для описания бизнес-процессов 
используются диаграммы активностей, 
которые несколько схожи с нотацией 
BPMN. После передачи BPMN в OMG, 
он, вероятно, целиком или частично 
войдет в UML

Business Process 
Executable 
Language (BPEL) 

Разрабатывается 
Organization for the 
Advancement of 
Structured Information 
Standards (OASIS) 

Представляет собой xml-нотацию для 
описания бизнес-процессов. 
Рассматривает бизнес-процесс как 
связанную последовательность вебсервисов. Совместная разработка IBM, 
BEA, Microsoft, SAP, Siebel. 
Первоначально назывался BPEL4WS 
(Business Process Execution Language for 
Web Services), сейчас полное название – 
WS-BPEL (Web Services Business Process 
Execution Language). Основной 
недостаток – ориентация только на 
автоматические процессы

XML Process 
Definition 
Language (XPDL) 

Разрабатывается 
Workflow 
Management 

Coalition 
http://www.wfmc.org/ 

Конкурентный с BPEL формат (XMLформат для обмена информацией между 
средствами анализа бизнес-процессов и 
BPM-системами). В отличие от BPEL, в 
XPDL нет жесткой привязки к вебсервисам, а используется абстрактное 
понятие внешнего приложения, кроме 
того, имеется явное определение 
пользователей и ролей
 
Диаграмма BPD имеет два основных достоинства. 
Во-первых, она проста в использовании и понимании. Применяя ее 
на 
начальном 
уровне сложности, 
можно найти общий 
язык с 
нетехническим персоналом. Во-вторых, поднимаясь на более высокий 
уровень сложности описания, можно постепенно подойти к естественному 

отображению на языке исполнения потоков работ. Определяя достаточный 
уровень абстракции, нотация BPMN позволяет наглядным образом 
описывать 
модели 
потоков 
работ 
безотносительно 
среды 
их 
функционирования. На базе такой «скелетной» реализации процесса 
можно получать различные варианты «исполняемого кода». Помимо этого, 
графическая нотация BPMN 1.0 определяет ряд дополнительных 
функциональных возможностей, делающих ее наиболее выгодным 
средством для перевода реальных потоков работ в формальную объектную 
модель: 
широкий набор элементов декларации потока работ, сочетающий 
простоту визуализации и богатую выразительность; 
возможность экспорта в распространенных форматах описания 
потоков работ, таких как диаграммы активности UML 1.0 и 2.0 ввиду 
схожей базовой метамодели. 
 
Таблица 1.2. Инструментальная поддержка нотаций моделирования 
 и языков программирования 

 

Инструмент
Нотация (Язык моделирования)
Язык программирования

Power Designer 

ebXML 
BPSS 
v 
1.01,1.04; 

BPEL4WS 
1.1; 
WSBPEL 
2.0; 

Analisis; BPMN 1.0; DFD; Servise 
Oriented 
Architecture; 
Sybase 

WorkSpace Business Architecture 
Process

Analisis; 
C#; 
C#2; 
C++; 

Eclipse Modeling Framework; 
IDL-CORBA; Java: Java 1.x; 
PowerBuilder; 
Visual 
Basic.NET 2005; XML-DTD; 
XML-Schema

Enterprise Architect 

UML-2; ArcGIS; ArchMate; BPMN 
1.0; 
1.1; 
2.0; 
DFD; 

CodeEngineering; ErikssonPenker; 
SOMF; SPEM; Strategic Modeling; 
User Interface; Web Modeling

Action Script; C; C#; C++; 
Delphi; Java; PHP; Pyton; 
VBNet; Visual Basic 

Process 
Modeler(BPwin)

ERwin Data 
Modeler(ERwin)

Rational Rose

Power Designer

Enterprise 
Architect

Текст программы. Языки: C#, C#2, 
IDL-CORBA, Java, Java5, Visual 
Basic.Net, Visual Basic 2005, 
XML-DTD, XML-Schema.

Текст программы. Языки: C,C++, C#, 
IDL-CORBA, Java,  Visual Basic, PHP, 
Delphi, Python, VB.NET

СУБД Платформы: Access, 
SQL-Server, ORACLE, Postgre 
SQL, DB2...(Всего- 54 шт.)

СУБД Платформы: Access, SQL, 
dBASE, Excel, Extreme Sample 
Database 2005

СУБД Платформы: Access, 
SQL-Server, ORACLE, DB2/UDB, 
DB2/zOC, FoxPro, Informix, Ingris, 
iSeries, MySQL, ODBC/Generic, 
Progress, Red Brick, SAS, SYBase, 
Sybase IQ, Teradata

[XML]

[XML]

 

 
Рис. 1.1. Взаимодействие основных инструментальных средств  
при разработке приложений 
 
1.3. Моделирование бизнес-процессов на основе BPMN-диаграмм 
 
BPMN – это нотация, основанная на построении блок-схем, для 
моделирования бизнес-процессов, она принята как стандарт OMG в 
феврале 2006 г. Нотация предназначена для описания действий или 
активностей (activities), выполняемых организациями для управления и, 
если необходимо, для улучшения своих бизнес-процессов. Корпорация 
Oracle предлагает ряд инструментов для поддержки жизненного цикла 
BPM. 
Проектирование новых или описание существующих бизнеспроцессов. Oracle Business Process Architect, компонент Oracle Business 
Process Analysis Suite, может использоваться для этой задачи. Он 
предоставляет 
компании 
широкие 
возможности 
моделирования 
и 
проектирования 
бизнес-процессов, 
IT-систем, 
ландшафтов 
и 
организационных структур. Бизнес-аналитики могут моделировать бизнеспроцесс, используя BPMN.