2867

Теория систем и системный анализ

Книга

Информатика, кибернетика и программирование

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

Русский

2012-10-20

6.53 MB

364 чел.


Предисловие

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

Для взаимопонимания и эффективного взаимодействия этих разных категорий специалистов необходимы:

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

К сожалению, в настоящее время, только небольшая часть специалистов (с обеих сторон) может похвастаться наличием таких умений. Более того, многие отечественные специалисты, до сих пор, не осознают такой необходимости.

Данная проблема, на самом деле, уже имеет продолжительную и не только отечественную историю. Известно, например, что один из основоположников искусственного интеллекта американец Дж. Вейценбаум еще в 70-х годах прошлого столетия сетовал на то, что «к сожалению, многие университеты предлагают студентам учебные программы, которые позволяют учащимся выбирать путь, ориентированный только на освоение языков и процедур программирования без должного внимания к анализу и проектированию, и даже поощряют их в этом. Когда такие студенты завершают курс обучения, они оказываются в положении людей, научившихся прекрасно говорить на иностранном языке, но которые, попытавшись написать что-нибудь на этом языке, обнаруживают, что им самим сказать буквально нечего».

Не удивительно, поэтому, что 85% программных средств, разрабатываемых, например, для информационной поддержки бизнеса, по данным университета Карнеги Меллон оказываются неэффективными и просто выбрасываются в урну ввиду несоблюдения методологии и технологии разработки.

При этом профессионалы в области программирования (например, М. Фаулер, Г. Буч и т.д.) подчеркивают, что основной (чаще всего возникающий) риск при разработке программного обеспечения состоит не в создании плохой программы, а в создании программы, не соответствующей требованиям, т.е. бесполезной.

Современные специалисты по компьютерным технологиям (и, в частности, выпускники таких бакалавриатов как «прикладная информатика» и «математическое обеспечение и администрирование информационных систем» и т.д.) должны быть профессионалами в области информационно-аналитической деятельности. Это связано с тем, что на них обычно возлагаются:

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

Для подготовки выпускников указанных выше специальностей к решению данных задачи и читается, в частности, дисциплина «теория систем и системный анализ».


Содержание

Предисловие 3

Содержание 5

Тема 1. Системные исследования 8

1.1. Структура самостоятельного научного направления 8

1.2. Структура системных исследований 10

1.3. Эволюция системного подхода 13

Вопросы для повторения 15

Резюме по теме 15

Тема 2. Моделирование и анализ систем. Основные подходы 16

2.1. Традиционный системный подход 16

2.1.1. Особенности и проблемы традиционного системного подхода и системного анализа 16

2.1.2. Причины существования проблем традиционного системного подхода и системного анализа 22

2.2. Объектно-ориентированный подход 29

2.2.1. Особенности объектно-ориентированного подхода 29

2.2.2. Необходимость интеграции объектного и системного подходов 34

2.3. Системология – системный подход ноосферного этапа развития науки 36

2.3.1. Основные понятия 36

2.3.2. Системология – язык теории организации, логистики и инжиниринга бизнеса 40

2.3.3. Системологический и объектно-ориентированный подход 43

Вопросы для повторения 46

Резюме по теме 46

Тема 3. Технологии системного моделирования 47

3.1. Технология системно-структурного моделирования и анализа «3-View Modeling» 47

3.1.1. Диаграммы потоков данных: нормативная система; построение модели; словарь данных; спецификация процесса 47

3.1.2. Диаграммы «сущность-связь»: нотация Чена; нотация Баркера; построение модели 64

3.1.3. Диаграммы переходов состояний 76

3.2. Стандарты системного моделирования и анализа серии «Icam DEFinition» 80

3.2.1. Стандарт функционального моделирования IDEF0 80

3.2.2. Стандарт информационного моделирования IDEF1 89

3.2.3. Стандарт моделирования баз данных IDEF1X 91

3.2.4. Стандарт моделирования сценариев IDEF3. 95

3.2.5. Стандарт моделирования онтологий IDEF5 99

3.3. CASE-инструментарий системного моделирования и анализа 108

3.3.1. Назначение и возможности «AllFusion Process Modeler/BPwin» 108

3.3.2. Особенности «BPwin» 113

3.3.3. Недостатки инструментария системного моделирования 115

Вопросы для повторения 117

Резюме по теме 117

Тема 4. Технология объектного моделирования и анализа 118

4.1. UML – язык объектного моделирования 118

4.1.1. Сущности: структурные; поведенческие; группирующие; аннотационные 118

4.1.2. Отношения 121

4.1.3. Диаграммы 122

4.1.4. Процесс объектно-ориентированного моделирования/проектирования: начальная фаза; исследование; построение; внедрение; дополнительные средства 126

4.2. Требования к объектному моделированию бизнес-систем 143

4.2.1. Внешняя модель бизнес-системы 145

4.2.2. Внутренняя модель бизнес-системы 148

4.2.3. Пример UML-модели бизнес-системы 150

4.2.4. Пример модели информационного обеспечения бизнеса 151

4.3. CASE-инструментарий объектного моделирования и анализа 160

4.3.1. Назначение и возможности «IBM Rational Software Architect» 160

4.3.2. Интерфейс «IBM Rational Software Architect» 162

4.3.3. Представление модели в «IBM Rational Software Architect»: представление вариантов использования; логическое представление; представление компонент; представление размещения 164

4.3.4. Недостатки инструментария объектного моделирования 168

Вопросы для повторения 170

Резюме по теме 170

Тема 5. Технология системно-объектного моделирования и анализа 171

5.1. Методология системно-объектного моделирования и анализа 171

5.1.1. Системологический подход «Узел-Функция-Объект» 171

5.1.2. Адаптивная нормативная система УФО-анализа 175

5.1.3. Классификация бизнес-систем 180

5.2. Процедура системно-объектного моделирования и анализа 184

5.2.1 Алгоритм УФО-анализа. 184

5.2.2. Примеры УФО-моделей. 191

5.3. CASE-инструментарий системно-объектного моделирования и анализа 200

5.3.1. Назначение и возможности «UFO-toolkit» 200

5.3.2. Особенности функционирования «UFO-toolkit» 205

5.3.3 Технология представление моделей в «UFO-toolkit» 208

Вопросы для повторения 214

Резюме по теме 214

Тема 6. Графический язык моделирования бизнес-процессов bpmn. 215

6.1. Назначение и область применения. 215

6.2. Диаграммы бизнес-процессов (BPD). 215

6.2.1. Элементы потока. 216

6.2.2. Соединяющие элементы. 218

6.2.3. Зоны ответственности и артефакты. 219

6.2.4. Правила соединения Элементов потока. 221

6.3. Соотношение BPMN, XPDL, BPEL, BPML. 222

6.3.1. Стандарты SGML и XML 223

6.3.2. XPDL 225

6.3.3. BPEL 229

6.3.4. BPML 234

6.3.5. Соотношение языков. 237

6.4. CASE-инструментарий бизнес-моделирования в нотации BPMN. 241

6.4.1. Назначение и возможности. 241

6.4.2. Особенности функционирования и интерфейса. 244

6.4.3. Примеры моделей в нотации BPMN. 252

6.4.4. Недостатки моделирования в нотации BPMN. 254

Вопросы для повторения 257

Резюме по теме 257

Вместо заключения 258

Глоссарий 267

Список литературы 283


Тема 1. Системные исследования

Цели и задачи изучения темы

Целью изучения данной темы является ознакомление с системными исследованиями как самостоятельным научным направлением.

При этом ставятся следующие задачи:

  •  ознакомление со структурой самостоятельного научного направления;
  •  структурирование системных исследований как самостоятельного научного направления;
  •  изучение эволюции системного подхода и его принципов.

1.1. Структура самостоятельного научного направления

Рассмотрим основные компоненты самостоятельного научного направления и их взаимодействие, обеспечивающее его функциональную целостность.

Схема взаимодействия компонент самостоятельного научного направления представлена на рисунке 1.1. Описание схемы заимствовано из работ Г.П. Мельникова.

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

Цель исследовательской деятельности – познание наблюдаемых и потенциальных свойств объекта исследований, являющегося первым необходимым компонентом научного направления. Результат исследовательской деятельности – знания его (объекта) текущего состояния, предыстории становления и умения на достаточно серьезных основаниях прогнозировать его будущее и делать выводы о его поведении, в том числе и в необычных для него условиях.

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

Отработанные приемы наблюдения и эксперимента для получения новых феноменологических, эмпирических знаний об объекте представляют собой методики исследований, также являющиеся необходимым компонентом научной дисциплины.

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

Выведение на основе новых феноменологических знаний и ранее установленных концептуальных знаний новых логически устанавливаемых знаний о данном объекте обеспечивается следующим компонентом научной дисциплины – методом исследования. Метод представляет собой способ теоретического освоения наблюдаемого и выявленного в эксперименте, ориентированный на определенную феноменологию и концепцию.

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

О существовании самостоятельной научной дисциплины (научного направления) можно говорить в тех случаях, когда достаточно четко сформировались границы ее объекта, сложились методики получения новых феноменологических знаний, существует концепция или теория данной дисциплины. Для существования самостоятельной научной дисциплины, кроме того, должен существовать метод (или набор методов) данной научной дисциплины и должна сформироваться определенная методология. Лишь в этом случае возможна эффективная исследовательская деятельность, имеющая в своем составе все необходимые компоненты: объект, методики, метод, теорию или, хотя бы, концепцию и методологию.

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

При анализе природы научной дисциплины представляется полезным учитывать мнения основоположников системологии о соотношении формального и содержательного.

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

«Стремление к сущностному познанию – важнейшая часть системной методологии любой научной дисциплины. Подмена сущностного рассмотрения конструктами и логически оправданными моделями есть отступление от системной методологии».

1.2. Структура системных исследований

Любая концепция системного подхода функционирует и развивается в рамках самостоятельного научного направления, носящего название системные исследования. Рассмотрим специфику этого направления с целью уточнения места и особенностей основного предмета нашего рассмотрения, то есть системологии.

Системные исследования – одно из самых современных и молодых научных направлений. Они представлены, в настоящее время, системным подходом, общей или абстрактной теорией систем и системным анализом. Данные дисциплины составляют определенные аспекты или стороны современных системных исследований. По своим задачам названные компоненты системных исследований, выходят за рамки существующего сегодня дисциплинарного членения науки и техники. Получаемые этими компонентами результаты применимы к целым комплексам научных и технических дисциплин [1]. Главным из этих компонентов является системный подход, имеющий методологическую природу и общенаучный междисциплинарный характер [2]. Ведущая, ключевая роль системного подхода обусловлена его положением в структуре взаимодействия компонентов системных исследований.

В рамках системных исследований используются средства концептуального и методологического анализа в соединении с формальным аппаратом современной логики и некоторых разделов математики. Специалистами в этой области разрабатываются принципы, на основе которых разрабатываются системные модели объектов произвольной природы и системные методы их исследования. Результатом этих исследований и разработок, с учетом специфики подхода, являются, во-первых, методы анализа особого класса природных и социальных объектов, наиболее адекватным названием которых можно считать термин «сложные системы», а, во-вторых, средства систематизации, классификации и упорядочения научных (и не только научных) знаний.

Системные исследования, в целом, и системный подход, в частности, представляют собой определенный этап в развитии методов познания, методов исследовательской и конструкторской деятельности, способов описания природы естественных или искусственных объектов, то есть определенный этап в развитии науки.

Схема на рисунке 1.2 иллюстрирует функции каждого из компонентов современных системных исследований по аналогии с функциями объекта, теории (концепции), метода, методики и методологии самостоятельной научной дисциплины (научного направления) [3, 4].

Главной целью научно-исследовательской деятельности является познание свойств и сущности  объекта, который  в  рамках  системных исследований

представляет собой систему, как предельную абстракцию объекта исследований произвольной природы.

Накопление, хранение и передачу знаний об объекте (системе) обеспечивает концепция или теория, обслуживающая данное научное направление, которая в рамках системных исследований представляет собой общую или абстрактную теорию систем, как теорию (концепцию) предельной степени абстракции. Из множества существующих определений этой теории можно упомянуть следующее.

Общая теория систем — это научная и методологическая концепция исследования объектов, представляющих собой системы. Она тесно связана с системным подходом и является конкретизацией его принципов и методов. Первый вариант общей теории систем был выдвинут Людвигом фон Берталанфи, основная идея которого состоит в признании изоморфизма законов, управляющих функционированием системных объектов.

Получение новых феноменологических, эмпирических знаний об объекте (системе) обеспечивают методики исследований, которые в рамках системных исследований должны представлять собой системный анализ, как единственно возможный способ получения данных о предельно абстрактном объекте, то есть системе. Из множества существующих определений этого анализа можно упомянуть следующие.

Системный анализ — это совокупность приемов научного познания, представляющая собой последовательность действий по установлению структурных связей между переменными или элементами исследуемой системы. Опирается на комплекс общенаучных, экспериментальных, естественнонаучных методов. Системный анализ возник в эпоху разработки компьютерной техники. Успех его применения при решении сложных задач во многом определяется современными возможностями информационных технологий. Н.Н. Моисеев приводит, по его выражению, довольно узкое определение системного анализа: «Системный анализ — это совокупность методов, основанных на использовании ЭВМ и ориентированных на исследование сложных систем — технических, экономических, экологических и т.д. Результатом системных исследований является, как правило, выбор вполне определенной альтернативы: плана развития региона, параметров конструкции и т.д. Поэтому истоки системного анализа, его методические концепции лежат в тех дисциплинах, которые занимаются проблемами принятия решений: исследование операций и общая теория управления».

Выведение на основе новых феноменологических и ранее установленных концептуальных знаний новых знаний, логически устанавливаемых, о данном объекте обеспечивается методом исследования. Метод, как средство выведения новых знаний о предельно абстрактных объектах (системах), в рамках системных исследований является системным подходом. Из множества существующих определений этого подхода можно упомянуть следующее.

Системный подход — это методическое направление исследования, в основе которого лежит рассмотрение объекта как целостного множества элементов в совокупности отношений и связей между ними, то есть рассмотрение объекта как системы. Говоря о системном подходе, можно говорить о некотором способе организации наших действий, таком, который охватывает любой род деятельности, выявляя закономерности и взаимосвязи с целью их более эффективного использования. При этом системный подход является не столько методом решения задач, сколько методом постановки задач. Как говорится, «Правильно заданный вопрос — половина ответа». Это качественно более высокий, нежели просто предметный, способ познания.

Эффективность всей научной деятельности за счет согласования и усовершенствования всех ее компонентов, особенно в «нештатных» ситуациях, обеспечивается методологией, которая в рамках системных исследований представляет собой диалектический принцип системности.

Рассмотренный способ представления структуры взаимодействия компонентов системных исследований позволяет предположить, что с увеличением сложности, общности, абстрактности объекта исследований методы и методики исследований должны все в большей степени соответствовать системному подходу и системному анализу. Системная концепция или теория конкретного научного направления при этом должны все более соответствовать абстрактной теории систем, а методология – принципам диалектики.

Анализ специфики и структуры системных исследований показывает, таким образом, что системный подход, в общем, и системология, в частности, представляют собой универсальный метод изучения и исследования сложных объектов произвольной природы. Это и делает знание основных положений системологического подхода в настоящее время чрезвычайно актуальным, а их использование в научной практике чрезвычайно эффективным и продуктивным.

1.3. Эволюция системного подхода

Понимание места и роли системологии в рамках науки и конкретного научного направления позволяет рассмотреть ее специфические особенности более подробно. Рассмотрим эти особенности путем сравнения современной системологической концепции с предшествующей системной.

Широкое внедрение системного подхода во всех сферах научной, конструкторской и управленческой деятельности, как и любая существенная перестройка, является процессом длительным и противоречивым, обусловленным, в первую очередь, продолжением формирования и развития самого системного подхода как самостоятельного научно-методологического направления. В ходе своего развития и совершенствования системный подход не сразу обретает признаки и черты, окончательно свободные от влияния аналитического этапа развития науки и полностью соответствующие современному ноосферному этапу. Среди существующих концепций системного подхода такими чертами обладает только концепция, которая называется системологической или просто системологией. [2, 3].

Данная концепция обладает существенными преимуществами, выгодно отличающими ее от известных ранее концепций и уже привычных. Эти преимущества могут быть проиллюстрированы в ходе сравнительного анализа фундаментальных принципов, лежащих в основе любой концепции системного подхода. Это связано с тем, что системный подход, как существенный аспект ноосферного этапа развития науки, в целом, и системных исследований, в частности, принципиально ориентирован на применение для выполнения своих задач диалектических принципов: системности, целостности, иерархичности и развития [1, 5, 6]. Сравнительный анализ применения основополагающих диалектических принципов традиционным системным подходом и системологическим (системологией), результаты которого приведены в таблице 1.1, показывает, что первый в значительной степени продолжает использовать методологические установки прошедшего аналитического этапа развития науки и, следовательно, малоэффективен и бесперспективен в современных условиях.

Таблица 1.1. – Сравнение системных подходов.

Системный подход

Системология

Принцип системности:

Понятие системы многозначно (более 40 определений). Понятия «мера» или «степень системности» отсутствуют. Объекты рассматриваются как системы только при определённых условиях [7].

Принцип системности:

Понятие системы однозначно (предельно абстрактно). Введены понятия «мера» или «степень системности» для рассмотрения любого объекта как системы, имеющей определённую меру [5].

Принцип целостности и многоаспектности:

Учитывается либо только структурная целостность, когда природа связываемых элементов считается несущественной, либо только субстанциальная целостность, когда не учитываются связи между частями целого [8, 9].

Принцип целостности и многоаспектности:

Учитывается комплексный характер целостности системы, что обеспечивает взаимосогласование структуры и субстанции системы при её взаимодействии со средой. Основной аспект целостности – функциональный [10].

Принцип иерархичности:

Учитывается иерархичность только внутренней структуры системы, что обеспечивает исследование объектов методом, так называемого, «серого (светлого) ящика» [11].

Принцип иерархичности:

Учитывается, в том числе иерархичность структуры внешней для системы среды, что обеспечивает исследование объектов методом «всё более и более светлого ящика» [5, 11].

Принцип развития:

Рассматриваются только статические параметры системы. Не рассматриваются причины возникновения системы и этапы её становления. Нет понятия «адаптация системы» [7, 10].

Принцип развития:

Рассматриваются, в том числе, динамические характеристики системы, что обеспечивает понимание причин её возникновения и этапов становления. Введено понятие адаптации системы [3, 8].

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

Основным результатом последовательного применения принципов диалектики системологией является ее более выраженная и более универсальная методологическая направленность. Общепринятый системный подход может функционировать в качестве методологического средства преодоления барьеров конкретного научного познания при возникновении «нештатных ситуаций» или «методологических порочных кругов», но ограничено [12]. Системология же представляет собой, по сути дела, ориентированое на методологическое использование изложение понятий и принципов диалектики. Интерпретированная в терминах конкретной науки системология, может выполнять в этой науке методологические функции неограниченно, «в том числе при выборе таких оптимальных методов исследования частных задач, которые ... откроют возможность рассмотрения объекта исследования с разных позиций без утраты целостного и сущностного о нем представления» [4, с. 42].

Одновременно, в связи с тем, что в настоящее время «проблема организации и улучшения ноосферы приобретает особое значение», системология может дополнительно использоваться как средство «диалектической обработки» создаваемого конкретной наукой знания, то есть как средство «организации» ноосферы [12, с. 191].

Названные преимущества системологии позволяют широко применять ее при исследовании слабоструктурированных и слабоформализуемых проблемных областей, представляющих собой основное поле деятельности современной науки.

Вопросы для повторения

  1.  Нарисуйте схему самостоятельного научного направления.
  2.  Опишите причины возникновения системных исследований.
  3.  Назовите компоненты системных исследований.
  4.  Дайте определение системного подхода.
  5.  Что такое системный анализ?
  6.  Для решения каких проблем применяется системный анализ?
  7.  Дайте определения принципам системного подхода.
  8.  В чем отличия традиционного системного подхода от системологии?

Резюме по теме

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


Тема 2. Моделирование и анализ систем. Основные подходы

Цели и задачи изучения темы

Целью изучения данной темы является ознакомление с основными подходами к моделированию и анализу сложных систем: с традиционным системным (системно-структурным) подходом, с объектно-ориентированным подходом и современным системным подходом, соответствующим ноосферному этапу развития науки (системологией).

При этом ставятся следующие задачи:

  •  ознакомление с проблемами традиционного системного подхода и системного анализа;
  •  изучение причин существования проблем традиционного системного анализа;
  •  освоение особенностей объектно-ориентированного подхода;
  •  обоснование необходимости интеграции системно-структурного и объектно-ориентированного подходов;
  •  изучение основных понятий системологии;
  •  сопоставление системологии и основных научно-практических дисциплин, направленных на рационализацию организационных систем (теории организации, логистики и инжиниринга бизнеса), а также системологии и объектно-ориентированного подхода.

2.1. Традиционный системный подход

2.1.1. Особенности и проблемы традиционного системного подхода и системного анализа

Как известно, современным информационным системам (ИС) и информационным технологиям (ИТ) присуща сложность. Она обусловлена, с одной стороны, «неудовлетворительными способами описания поведения больших дискретных систем», а, с другой стороны, слабой структурированностью и «сложностью реальных предметных областей», из которых, в настоящее время, в основном и исходит заказ на разработку [13, с. 22]. При этом считается, что системный анализ сложных объектов является тем средством, которое обеспечивает возможность решения различных научных, деловых, управленческих и производственных слабоструктурированных и слабоформализуемых проблем [14, 15].

Некоторые методы системного анализа, оказавшиеся весьма эффективными в самых различных областях человеческой деятельности, возведены в ранг государственных стандартов по анализу и проектированию сложных объектов и процессов. Например: система стандартов Icam Definition в США или SSADM – методология структурного системного анализа и проектирования, стандартизованная в Великобритании.

В систему стандартов Icam Definition [16, 17, 18], в частности, входит стандарт IDEF0 (FIPS183), предназначенный для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. Данный документ представляет собой оформление (по инициативе Министерства обороны США) в виде стандарта технологии анализа сложных систем SADT (Structured Analysis and Design Technique), разработанной в период с 1969 по 1973 годы группой аналитиков во главе с Дугласом Т. Россом.

Эти методы успешно применяются для решения различных задач, например, при управлении финансами, планировании производства, организации материально-технического обеспечения, построении систем диагностики, автоматизации производства и проектирования, организации системы образования, управлении космическими средствами связи и т.д. [19].

Однако, специалисты по консалтингу [20, 21], в обязанности которых входит применение этих методов на практике, и специалисты по разработке программного обеспечения (ПО) [22] оценивают их следующим образом:

  •  DFD-диаграммы (составная часть технологии 3VM) разработаны для проектирования программного обеспечения и ориентированы на системных аналитиков и программистов и не учитывают особенности восприятия менеджерами своей предметной области. Для описания бизнес-процессов менеджерам требуются более мощные выразительные средства, чем описание входов и выходов на диаграммах потоков данных.
  •  SADT-технология (стандарт IDEF0) разработана как средство моделирования и анализа любых систем. Однако в настоящее время оказалось, что её выразительных средств недостаточно для моделирования, например ИС. В результате данная технология практически используется относительно редко (менее чем в 10% существующих CASE-средств). Для создания динамических моделей требуется использование дополнительных специальных расширений или других средств, с которыми SADT плохо согласуется.
  •  SSADM-методология является специализированным средством систематизации и стандартизации процессов (этапов, задач и документов) создания ИС и не предназначена для анализа и моделирования бизнес-систем и бизнес-процессов. Для обеспечения понимания событий, которые происходят в реальном мире и которыми проектируемая система должна управлять, строится модель пользователя, но не бизнес-системы, так как для этого нет необходимых средств.
  •  Кроме того, стандарты SADT (IDEF0) и SSADM приспособлены только для хорошо специфицированных и стандартизованных «западных» бизнес-процессов, что делает их практически непригодными для отечественного рынка.

Методы системного анализа, основанные на потоковых диаграммах (DFD: предназначенные в первую очередь для моделирования информационных процессов), оцениваются еще и следующим образом: «Диаграммы потоков данных обеспечивают удобное описание функционирования компонент системы, но не снабжают аналитика средствами описания деталей этих компонент, а именно, какая информация преобразуется процессами и как она преобразуется» [20, с. 53]. «Их практическое применение высокоэффективно, как правило, только для отражения информационных структур бизнес-процесса, оптимизация которого проведена уже другими средствами» [23].

Одной из существенных проблем при использовании методологий моделирования IDEF, по мнению, например, специалистов проектировщиков, является дальнейшее использование результатов в практической работе, например при внедрении или создании корпоративной ИС: «Часто оказывается, что применить результаты длительной работы достаточно сложно» [23, 24]. При этом профессиональные аналитики заявляют о несоответствии SADT требованиям «кибернетического стандарта» на моделирование бизнес-процессов [25].

Методология «моделирования в терминах системы», созданная усилиями специалистов BAAN, ориентирована исключительно на разработку программных продуктов и не удобна для описания самих бизнес-процессов [23, 24].

Кроме того, в литературе отмечаются следующие проблемы традиционных методов системного структурного анализа [15, 26 - 28]:

  •  методы и результаты решения существуют только для относительно простых классов систем, а для более сложных развиваются методы упрощения;
  •  несмотря на существующие попытки, не достаточно разработаны методы описания процессов адаптации и эволюции систем в связи со слабой изученностью развивающихся и самоорганизующихся систем;
  •  при наличии возможности описать (до определенного уровня сложности), что представляет собой процесс или объект, не существует способов показать мотивацию, смысл и взаимосвязь между действиями и сущностями, т.е. почему он именно такой;
  •  «строгие формальные основания этих систем ведут к крайней скудости выразительных возможностей и ограниченности сферы применения» [28, с. 89].

В [29, 30] приведен обзор существующих методов анализа и моделирования сложных систем, в котором относительно самых конструктивных методов, основанных на формализованном представлении системы, отмечается следующее:

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

В работе [31] отмечается, что анализ и моделирование систем с помощью средств моделирования случайных процессов или теории массового обслуживания «…зачастую носят кустарный характер и уже не соответствуют современным запросам практики. Они приводят, по мере возрастания сложности задач, к значительному увеличению трудоемкости подготовки моделей…. Эти обстоятельства снижают эффективность имитационного моделирования и препятствуют его широкому распространению как инструмента повседневного использования…» [31, с. 202].

Как известно, при использовании традиционных методов системного анализа создается обычно три или более вида моделей (3-View Modeling – 3VM: DFD – функциональная диаграмма потоков данных, ERD – информационная диаграмма «сущность-связь», STD – диаграмма переходов состояний [32]) одного и того же объекта, каждая из которых имеет свою понятийную, терминологическую и графическую базу, и при этом применяются разные инструментальные средства [19, 20, 33]. Это обстоятельство приводит к необходимости проведения специального сквозного контроля диаграмм одного или разных типов, т.е. соответственно вертикального и горизонтального балансирования диаграмм, для выявления весьма вероятных ошибок [20]. Данная ситуация обусловлена несовершенством традиционного системного подхода, в рамках которого отсутствуют концептуальные средства, связывающие между собой функцию объекта, его субстанцию (состав элементов), его структуру и динамику процессов.

Рекордисткой в этом отношении является известная инструментальная система анализа и моделирования ARIS Toolset, которая обеспечивает четыре «взгляда» на модель (Процессы, Функции, Данные, Организация) и для каждого взгляда поддерживает три уровня анализа (требования, спецификация, внедрение), каждый из которых состоит из своего комплекта моделей различных типов. Всего инструмент может построить 85 типов моделей, из которых 57 типов предназначено для моделирования процессов. Примечательно, что в работе [34], в которой автор, помимо обзора методов и средств моделирования, явно рекламирует эту систему, подчеркивается необходимость «интеграции результатов моделирования в рамках общего проекта или общей модели».

Существующие методы системного структурного анализа являются либо процедурно-ориентированными, либо ориентированными на данные [19, 20, 22, 33]. Следовательно, результаты, полученные с их помощью, не могут быть эффективно использованы при разработке ПО средствами технологии объектно-ориентированного программирования (object-oriented programmingOOP), которая в настоящее время является основной и самой перспективной.

Более того, установлено (см. например [13]), что все методы системного структурного анализа полностью ортогональны принципам объектно-ориентированного проектирования. Данное обстоятельство обусловлено, например, тем, что традиционные методы системного анализа не обеспечивают выявления иерархии классов предметной области (не используют в рамках своих процедур концептуальных классификационных моделей), а также не поддерживают объектно-ориентированную концепцию инкапсуляции.

Очень показательны для проводимого в данном пункте анализа попытки применения при выполнении объектно-ориентированного проектирования (object-oriented designOOD) упомянутых выше методов структурного системного анализа (например, 3VM). Относительно конкретных диаграмм, например диаграмм ERD, в [32, с. 24-25] сделаны следующие выводы: «Применение ERD очень выгодно, однако при работе с этими средствами возникают определенные трудности. Во-первых, идентифицированные сущности не всегда соответствуют понятиям области приложения, особенно когда аналитик пытается создать сущности в третьей нормальной форме. Во-вторых, ERD не подходят для идентификации объектов, не хранящих данные; в эту категорию часто попадают, например, объекты, распознающие происхождение событий или осуществляющие функции контроля». В общем, авторы приходят к следующему выводу: «Методы 3VM, весьма полезные для идентификации компонентов или объектов, не позволяют, тем не менее, идентифицировать подходящее множество объектов для разрабатываемой системы. Процесс обнаружения объектов все ещё управляется мнениями, интуицией и инсайтом» [32, с. 26].

Следствием ортогональности системного анализа и OOD является, таким образом, проблема использования результатов анализа при проектировании объектно-ориентированного ПО. Специалисты отмечают, что на этапе анализа лучше использовать методы 3VM, IDEF и т.д., так как «аналитик имеет дело с бизнес-процессами, по сути, являющимися функциями». Однако, с точки зрения проектирования ПО, конечно, необходимо использовать объектные методы (на основе UML) особенно в случае разработки сложных программных приложений. При этом, естественно, «описание бизнес-процессов должно делаться в том же средстве, в котором на последующих этапах работ будет проектироваться ИС» [35 - 37]. Это и создает противоречие.

В настоящее время, существуют проблемы принципиального характера и в рамках самого объектно-ориентированного подхода, а именно при проведении объектно-ориентированного анализа (object-oriented analysisOOA).

В соответствии с требованиями этой методологии любую систему на этапе анализа необходимо представить в канонической форме. Эта форма представления системы включает в себя две ортогональных иерархии: иерархию объектов и иерархию классов. Предполагается, что такая объектно-ориентированная декомпозиция системы, позволяет вскрыть ее полную архитектуру, т.е. структуру объектов и структуру классов. При этом свойства объектов (их поведение и т.д.) в, так называемой, объектной модели, определяет соответствующий класс в иерархии классов, описывающей моделируемую предметную область.

«Объектно-ориентированная методика позволяет значительно повысить качество и продуктивность разработки программного обеспечения. Однако извлечь из нее выгоду можно только тогда, когда правильно определено множество объектов. Подходящее множество объектов для конкретной области приложения обеспечивает повторное применение системы и возможности ее расширения, а также гарантируют качество и продуктивность потенциальных улучшений, присущих объектно-ориентированной парадигме. Без формальных методов определения объектов разработчики программного обеспечения рискуют остаться просто хакерами на объектном уровне» [32, с. 23].

Однако в литературе по объектно-ориентированному подходу отмечается, что «к сожалению, пока не разработаны строгие методы классификации и нет правила, позволяющего выделять классы и объекты. … Как и во многих технических дисциплинах, выбор классов является компромиссным решением» [13, с. 147]. Неудивительно, поэтому, что основной проблемой OOA и OOD считается отсутствие обоснованного метода «выбора правильного набора абстракций для описания заданной предметной области» [13, с. 56], т.е. метода построения иерархии классов или концептуальной классификационной модели предметной области (или модели онтологии [38]).

Существующие методики OOA на сегодняшний день предлагают эвристические правила идентификации классов и объектов, основанные на опыте классификации в других науках [13], а специалисты по системному анализу дополняют построение диаграмм информационным анализом, основанным на лингвистике (LIA: Linguistic-based Information Analysis) [32].

При этом специалисты по моделированию поведения сложных систем утверждают, что объектно-ориентированный стиль неестественен и не удобен для описания и имитации поведения бизнес-систем. «Для поведенческого моделирования бизнес-систем, особенно на ранних его стадиях, более удобен традиционный процессо-ориентированный структурный стиль мышления с использованием наглядных графо-аналитических выразительных средств» [39, с.8]. По мнению данного автора «эффективное моделирование поведения бизнес-системы может быть осуществлено на основе интеграции процессо- и объектно-ориентированного подходов» [39, с.9].

Специалисты по консалтингу и CASE-технологиям считают, что «диаграммные техники, отражающие специфику объектного подхода, гораздо менее наглядны и плохо понимаемы непрофессионалами» в сравнении с системно-структурными техниками [40, с.44].

Cледует отметить, что оценка перспектив развития методов и средств системного анализа и моделирования в работе [41] и по ныне не утратила своего значения. До сих пор разработка эффективных «проблемно-инвариантных» методов, «допускающих непосредственный перенос в другие прикладные области» вызывает большие трудности. Эти трудности по-прежнему связаны с «усложнением исследуемых систем, их «глобальностью», существенным использованием в них человеческого фактора и, главное, переходом к уникальным проектам», где применение количественных методов анализа в их обычной аналитической форме с применением традиционной логики становится затруднительным. По-видимому, делают вывод авторы названной работы (и это справедливо и в настоящее время), речь идет «не только о способах редукции сложных задач к доступному уровню за счет их жесточайшей специализации, но и о переходе к иным средствам, существенно учитывающим возможности человека-исследователя при описании систем». Решение данной задачи, по мнению авторов, состоит в создании «адаптивных, управляемых проблемно-инвариантных процедур» системного анализа, адекватных характеру изучаемых объектов [41, с. 145-146].

Таким образом, проблемы системного анализа в связи с особенностями объектно-ориентированного подхода могут быть сформулированы следующим образом:

  •  невозможность моделирования систем высокого уровня сложности, требуемого в настоящее время;
  •  недостаточный учет динамических аспектов и процессов развития реальных систем;
  •  ограниченность выразительных возможностей и сфер применения (отсутствие содержательной системной теории целостного объекта);
  •  невозможность адекватного описания причинно-следственных связей и собственно системных отношений;
  •  несоответствие требованиям ООА и OOD;
  •  отсутствие рационального подхода к выбору классов и объектов в ходе системного анализа при разработке объектных приложений.

Это свидетельствует об актуальности создания новых системных методов анализа и моделирования, в том числе для решения проблем объектно-ориентированной методологии, на основе интеграции принципов системного и объектного подходов, а также концептуального классификационного моделирования.

2.1.2. Причины существования проблем традиционного системного подхода и системного анализа

Рассмотрим причины существования недостатков методов традиционного системного анализа и причины несоответствия этих методов требованиям OOD [26, 27, 42].

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

Недостатки существующих методов системного анализа обусловлены тем, что в нормативных системах, описывающих эти методы, отсутствуют [26]:

  •  строгая и формализуемая, но адекватная действительности концепция системы, реализующая все принципы системного подхода;
  •  средства описания специфических содержательных системных свойств и отношений и, в частности, «системного эффекта»;
  •  системная теория и формальный аппарат, учитывающие принципиальное отличие понятия «система» от понятия «множество», отмечаемое, например, еще в [6].

Последнее обстоятельство, собственно, и не позволяет обеспечить инкапсуляцию выявляемых объектов (необходимую при OOD), так как система (в традиционном системном анализе и системном подходе) рассматривается как множество элементов, свойств, состояний и т.д. [например: 41, 43, 44], внутреннее содержание которого не может быть скрыто, в отличие от действительно системного подхода, акцентирующего внимание на целостности и функционировании системы [5, 6, 45].

Рассмотрим это обстоятельство более подробно.

Сравнительный анализ системного и теоретико-множественного подходов однозначно свидетельствует о том, что эти подходы принципиально противоположны и ни один из них не сводим к другому, что обусловлено, в частности, следующим [6]:

  •  Во-первых, в концепции множества изначально заложена первичность элемента (части) по отношению к множеству (целому). Множество существует тогда и только тогда, когда тем или другим образом заданы его элементы. В системной же концепции первичным является понятие системы (целого), которая уже потом может быть (а может и не быть) представлена в виде совокупности взаимодействующих частей.
  •  Во-вторых, теоретико-множественный подход характеризуется абсолютной неразборчивостью, т.е. позволяет рассматривать как одно множество любую совокупность любых явлений (с учетом известных парадоксов). Системный же подход претендует на рассмотрение действительности (предметной области) в виде естественно взаимодействующих системных образований, что накладывает определенные ограничения на представление совокупности явлений в виде одной системы.
  •  В-третьих, теоретико-множественный подход (как следует из выше сказанного) характеризуется гносеологичностью, так как реальные объекты не имеют теоретико-множественной природы. Системный же подход, по своему замыслу, ориентирован на описание целостной природы реальных объектов и, таким образом характеризуется онтологичностью, так как реальные объекты имеют системную природу.

Применение, следовательно, для формального описания системных отношений (методов и процедур анализа систем) аппарата теории множеств или другого, сводимого к теоретико-множественному, фактически сводит на нет специфические особенности и преимущества системного подхода. Тем не менее, например, в стандарте IDEF0 (FIPS183), система определяется как совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу, т.е. в теоретико-множественном смысле [46 - 48].

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

По поводу роли формального аппарата и математических методов в системных исследованиях отмечается, например в [14, 15, 19], что «основное содержание системного анализа заключено не в формальном математическом аппарате, описывающем «системы» и «решение проблем» и не в специальных математических методах, … а в его концептуальном, т.е. понятийном аппарате, в его идеях, подходе и установках». При этом в работе [49, с. 73-74] подчёркивается, что «реальные системы не полностью поддаются описанию с помощью математических моделей» и что аналитические (т.е. формальные) методы непригодны для изучения живых и, следовательно, социальных (организационных) систем. Кроме того, «использование математики переносит акцент с содержания на структуру явления» [49, с. 86]. При этом теоретические системные построения, основанные на результатах физико-математических наук, автор упомянутой работы называет теориями жёстких систем, применение которых к экономическим и организационным системам позволяет создать количественные модели чрезвычайно бедные, однако, по своему содержанию [49, с. 103]. Более того, там же подчёркивается, что если теория связана только с понятиями структуры и цели и не связана с понятиями субстанции и содержания, то бесполезно ожидать появления конкретных полезных приложений такой системной теории [49, с. 103].

При применении методов математической статистики зачастую предполагается независимость, одинаковая распределённость и нормальность используемых совокупностей случайных величин [50, 51]. Однако, «данные предположения, как правило, не выполняются, и это обстоятельство может приводить к потере точности и достоверности результатов моделирования …. Хотя в моделировании существуют приемы сведения данных к виду, пригодному для использования традиционных методов статистики, эти методы часто носят эвристический характер либо приспособлены для изучения частной модели» [50, с. 19].

«Трудности практического использования моделей математического программирования связаны, прежде всего, с обеспечением полноты, точности и достоверности исходных данных, необходимых для модели, с учетом динамики функционирования системы и с многокритериальным характером выбора варианта структуры [52, с. 16].

При этом весьма показательным является не принятие стандарта математического моделирования – IDEF2, которое «было вполне естественным, так как при реализации математической модели приходилось либо жертвовать ее точностью, либо ... самой возможностью что-то моделировать, ввиду чего никогда нельзя было с полной уверенностью говорить о соответствии математической модели функциональной» [23].

Таким образом, именно использование чисто формальных математических средств является одной из причин определенной ограниченности существующих методов системного анализа организационных систем и их несоответствия содержательному по своей природе объектно-ориентированному подходу. С этой точки зрения весьма существенным для данного исследования является введение еще В.М. Глушковым понятия обобщённых динамических систем (организмы, предприятия, государства и т.д.), которые принципиально не могут быть описаны классической математикой [53, 54].

Кроме того, объекты системного анализа, как правило, являются не строго и не точно определенными. Это позволяет оставаться актуальным известному предупреждению Н. Винера о том, что применение точных формул к вольно определяемым понятиям есть не что иное, как обман и пустая трата времени [55], а также резкому суждению А. Эйнштейна о том, что математика может доказать что угодно и использоваться как отличнейшее средство водит за нос даже самого себя, а главное состоит в содержании, а не в математике [56].

Почему же до сих пор не существует теории систем, как такой же фундаментальной и самостоятельной теории, какой является теория множеств? Почему же описывая и моделируя системы, зачастую, используют аппарат именно теории множеств?

Среди, очевидно, целого ряда известных причин, обуславливающих данную ситуацию, обратим внимание на следующее [27]. Любая научная теория, особенно обслуживаемая формальной системой, для выполнения своих многообразных функций (информативной, систематизирующей, прогностической, объяснительной) должна обладать средствами, позволяющими осуществлять процедуры анализа и синтеза описываемых данной теорией объектов. Совершенно очевидно, что теоретико-множественный подход в лице теории множеств такими средствами обладает, что и подвигает, так сказать «пользователей», на применение этой теории для решения конкретных задач, в частности задач системного анализа.

А как обстоят дела в этом смысле у «традиционного» системного подхода?

Существующие варианты системных подходов (их анализ, например, в работе [57]) используют такое понятие системы (в настоящее время более 40 определений; например уже в работе [58] собрано 35), которое, не обуславливает (не задает) определенной возможности для проведения операций анализа или синтеза объектов как систем, т.е. с учетом специфических системных отношений. Данные операции либо вообще остаются без определения, либо определяются с помощью теоретико-множественных средств с потерей возможности целостного представления системы. А, как известно, «системные представления, построенные при игнорировании признака целостности, оказываются неэффективными или даже дают заведомо ошибочные результаты» [57, с. 73].

Например, в одном из самых первых вариантов системного подхода система определялась как средство решения проблем, но конструктивных подходов к анализу и синтезу таких средств не предлагалось [59]. В более поздних вариантах система рассматривается как упорядоченное определенным образом множество взаимосвязанных между собой компонент той или иной природы, характеризующееся единством (целостностью), которое выражается в интегральных свойствах и функциях множества [60, 61]. При этом заданная возможность теоретико-множественного анализа и синтеза таких систем (как множеств) исключает конструктивное определение специфической целостности системы и причины появления её интегральных, т.е. собственно системных свойств. В теории организации, например, система определяется как целое, созданное из частей и элементов, для целенаправленной деятельности. При этом системе приписывается стремление к сохранению структуры, потребность в управлении и сложная зависимость свойств от входящих в нее элементов [62]. Все эти характеристики, однако, имеют в рамках данной теории исключительно лингвистическое описание.

Совершенно очевидно, что в названных концепциях способы анализа и синтеза систем с учетом их специфических системных отношений не заданы, не определены. Такая же ситуация существует и в рамках формализованных системных построений. Практически все формальные определения системы или непосредственно, или после своего раскрытия имеют теоретико-множественный характер, в рамках которого либо затруднено проведение анализа и синтеза систем, либо фактически не учитывается целостность этих систем. Довольно большая коллекция таких определений представлена, например в работах [29 и 41].

В классическом труде [8], описывающим так называемый феноменологический системный подход, исходное целостное представление системы в виде декартова произведения множеств входных (X) и выходных (Y) объектов: S  XY, является представлением «черного ящика», процедура анализа которого как системы, естественно, не определена. Для обеспечения анализа и синтеза систем в названной работе вводится функциональное представление системы: S: XY. Уточнение последнего представления осуществляется путем введения понятия глобальной реакции системы: R: (CX) Y, которое, в свою очередь, зависит от множества внутренних состояний (C) системы. Введение в рассмотрение множества внутренних состояний обеспечивает возможность анализа и синтеза функциональных систем в представлении [8] теоретико-множественными средствами, однако, ценой отказа от целостного системного представления. Последнее обстоятельство обусловлено тем, что для определения системы (при таком ее понимании) исследователь, по сути дела, обязан рассматривать внутренности данной системы и не ее целостность.

Таким образом, включение в формальное определение системы кроме (или вместо) множества ее элементов множества свойств или состояний, а также различных вариантов отношений между ними ничего не меняет по существу данной проблемы. Например, в работе [31] система моделируется с помощью, так называемых, кусочно-линейных агрегатов, образовываемых с помощью трех множеств: входов, выходов и состояний. Решая, безусловно, с помощью такого подхода ряд практических задач для некоторых классов систем, тем не менее, невозможно обеспечить целостное рассмотрение системы и «инкапсуляцию» ее свойств, необходимую в ходе OOD.

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

В работе же [63] в понятие системы включается только совокупность свойств объекта, но не сам объект. Таким образом, системность отрывается от субстанции, что делает невозможным моделирование и анализ ее реализации, без которой реальное существование системы становится проблематичным.

Даже если применяются, чисто логические методы исследования систем или мощный алгебраический аппарат, сама система все равно определяется через понятие множества каких-либо входящих в систему сущностей [например: 64, 65]. Включение же в определение системы понятия среды [например: 66 - 69] фактически еще более усложняет процедуры анализа и синтеза объектов как систем, так как затрудняет определение границ системы.

При этом необходимо иметь в виду, что представление системы в виде множества ее взаимосвязанных элементов (свойств, состояний и т.п.) рано или поздно приводит, в конце концов, к паре множеств: множеству элементов (свойств, состояний и т.п.) и множеству связей (отношений), заданному на первом множестве. Это, в свою очередь, приводит к пониманию системы как модели, т.е. как некоторому средству описания реально существующих объектов. В настоящее же время общепризнанно, что системность является неотъемлемым атрибутом действительности, т.е. имеет не гносеологический, а онтологический статус [например: 6 и 70].

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

Например, во множестве «Города России» любой исследователь в ходе анализа будет выявлять именно населенные пункты, имеющие статус города, а не что-либо ещё; во множестве «Животные заповедников» – животных (не их части, не их сообщества и т.п.), про которых известно, что они живут в заповедниках. В ходе же системного анализа, например, системы «Город» или системы «Биоценоз» разные аналитики выявят разные части (подсистемы), в зависимости не только от целей анализа, но и от своих субъективных предпочтений [например, 71]. Причем, с точки зрения именно традиционного системного подхода, все они будут иметь для своих действий одинаковые основания, т.е. полное их отсутствие, так как путь (способ) анализа системы в рамках упомянутых и наиболее распространенных системных концепций априорно не определен. В публикациях аналитиков об этом так прямо и говорится: «Это значит, что мы можем увидеть, выделить и изучить в городе столько систем, сколько захотим или сколько требует реальная практика управления» [72, с. 93].

По отношению к процедуре синтеза в традиционных системных подходах (в сравнении с теоретико-множественным) существует аналогичное положение. В рамках теоретико-множественного подхода отношение части к целому строго задано заранее оговоренными правилами «сборки» частей в целое в виде соответствующих операций над множествами. В рамках же обсуждаемых системных подходов процедура синтеза системы в нечто еще более целое опять становится зависящей от субъекта исследования, его понимания текущей ситуации, так как простое декларирование функционирования системы в среде или подчиненности системы (выходов системы) некоторой цели, если не оговариваются отношения со средой или что это за цели, чьи они, откуда берутся, остается не более чем лозунгом, ровным счетом ничего не дающим для обоснованного проведения операции синтеза. Данная ситуация в системных исследованиях даже получила свое особое наименование: системный эффект или эмерджентность свойств целого. При этом признается, что в ходе синтеза целого (системы) из его частей (подсистем) возникают принципиально новые свойства, но механизм синтеза или, как его еще называют, «алгоритм сборки» остается до сих пор тайной за семью печатями [например 73]. И в этом нет ничего удивительно, так как в наиболее распространенных системных подходах процедура синтеза (путь соединения объектов как систем, а не как множеств) не задана в принципе.

Например, множество «Города России» можно однозначно описать (синтезировать) путем объединения множеств «Города области…»; множество «Животные заповедников» – путем объединения множеств «Животные заповедника №…». Синтезирование же системы «Город» из подсистем населенного пункта такого вида или системы «Биоценоз» из частей, представляющих собой различные виды организмов, проживающих на данной территории, в значительной степени является эвристической процедурой, которую разные исследователи могут и будут выполнять по разному.

Имеющиеся попытки алгоритмизировать процедуры анализа и синтеза в системных исследованиях сводятся к подмене термина «анализ» более красивым термином «декомпозиция», а термина «синтеза» – термином «агрегирование». При этом о самих процедурах декомпозиции и агрегирования ничего не говорится [7].

В заключении следует отметить, что ни один метод традиционного системного анализа не использует понятия класса при осуществлении своих процедур и построении моделей, т.е. в принципе не использует концептуальных классификационных моделей, применение которых обязательно при осуществлении OOA [например 13, 74]. Поэтому при использовании традиционных системных методов для проведения OOD все равно приходится выходить за их рамки и использовать дополнительные средства [32, 75].

В общем сложившаяся ситуация хорошо охарактеризована известным специалистом по CASE-технологиям, консалтингу и реинжинирингу Г.Н. Коляновым: «Однако разработка программных средств поддержки реорганизации бизнес-процессов вызывает значительные затруднения по причинам отсутствия единого теоретического аппарата и достаточно полных методических основ системного анализа бизнес-процессов, общих математических моделей бизнес-процессов и формальных методов их создания и исследования, а также программных средств их реализации» [40, с.11].

Таким образом, основными причинами существования проблем и недостатков методов традиционного системного анализа и их несоответствия объектной парадигме является теоретико-множественный и вообще чисто формальный подход к понятию системы, а также отсутствие в их арсенале инструментальных средств классификационного моделирования. Следовательно, справедливыми, пока, остаются высказанные в работе [76] слова о непреодолимых трудностях, с которыми сталкиваются исследователи при создании комплексных социально-экономических моделей, т.е. моделей организационных систем, при использовании традиционных формальных средств. По справедливому мнению авторов: «Для этого необходимы не нынешние способы агрегирования, а некое целостно-укрупненное отображение внутренне сложных полиструктурных элементов посредством иных методов» [76, с. 262].

2.2. Объектно-ориентированный подход

2.2.1. Особенности объектно-ориентированного подхода

Одним из самых распространенных видов моделирования в настоящее время является моделирование с применением различных информационных технологий, т.е. построение и использование компьютерных моделей в виде прикладных программ различного назначения (программных приложений). Создание этих приложений может осуществляться традиционными методами, основанными на алгоритмах, процедурах и данных, а также более современными – объектно-ориентированными, основанными на концептуальном моделировании предметной области. При этом общепризнанно, что «если код приложения генерируется не на основе описания предметной области, то невозможно построить эффективное приложение со сложной бизнес-логикой» [77, с. 215].

Рассмотрим в соответствии с [13, 78 – 87] основные понятия объектно-ориентированной методологии создания программного обеспечения (ПО), а также средства стандартного унифицированного языка объектного моделирования (UMLUnified Modelling Language).

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

Объектно-ориентированное моделирование и разработка ПО осуществляются путем последовательного выполнения [13, 78]:

  •  Объектно-ориентированного анализа (object-oriented analysis – OOA), при котором моделируемая и разрабатываемая системы анализируются с точки зрения классов и объектов, выявленных в предметной области.
  •  Объектно-ориентированного проектирования (object-oriented design – OOD), при котором путем объектной декомпозиции создается объектная модель разрабатываемой системы.
  •  Объектно-ориентированного программирования (object-oriented programming – OOP), при котором программа представляется в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.

В соответствии с требованиями OOA и OOD для построения объектной модели сложной системы её необходимо представить в канонической форме. Эта форма представления системы включает в себя две ортогональных иерархии: иерархию классов и иерархию объектов [13, 78]. Предполагается, что такая объектно-ориентированная декомпозиция системы, позволяет вскрыть ее полную архитектуру, т.е. структуру классов и структуру объектов.

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

При этом свойства (состояние и поведение) объектов, как экземпляров классов, в объектной модели, определяет соответствующий класс в иерархии классов, описывающей моделируемую предметную область. Главной же задачей OOA и OOD считается «выбор правильного набора абстракций для описания заданной предметной области» [13, с. 56], что подчеркивает важность концептуального классификационного моделирования в процессе объектно-ориентированной разработки.

Концептуальная база методологии объектно-ориентированного моделирования включает в себя четыре главных взаимосвязанных понятия [13, 78 – 82]: абстрагирование, иерархия, инкапсуляция и модульность.

Абстрагирование – способ выделения существенных характеристик некоторого объекта (абстракций), отличающих его от всех других видов объектов и, таким образом, четко определяющих его концептуальные границы.

Иерархия – способ упорядочения абстракций (классов) по уровням.

Инкапсуляция – способ отделения элементов объекта (класса), определяющих его устройство, от элементов, определяющих его поведение (т.е. отделение реализации от интерфейса).

Модульность – способ разложения системы на связанные, но относительно самостоятельные части (модули).

Объектно-ориентированное моделирование, проектирование и программирование в обязательном порядке основано на использовании названных понятий при описании классов и объектов.

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

Между классами могут существовать следующие отношения:

  •  Наследование – такое отношение между классами, при котором класс повторяет описание состояния и поведения суперкласса (одного – одиночное наследование; нескольких – множественное наследование). Данное отношение является основным при выявлении иерархии классов предметной области. Узкие, специализированные классы в иерархии, от которых создаются экземпляры (объекты), называются конкретными классами. Общие классы, от которых экземпляры не производятся, называются абстрактными классами. Самый общий класс в иерархии классов называется базовым или корневым.
  •  Ассоциация – отношение семантической зависимости, показывающее какие роли классы играют друг для друга. Ассоциации различаются по мощности: «один-к-одному», «один-ко-многим», «многое-ко-многим».
  •  Агрегация – отношение, соответствующее отношению «часть-целое» между объектами данных классов.
  •  Использование – может рассматриваться как разновидность отношения ассоциации, при котором одна из сторон (клиент) пользуется услугами или ресурсами другой стороны (сервера). Кроме того, использование может рассматриваться как один из аспектов отношения наследования, так как подкласс, наследуя состояние и поведение класса, выступает в роли его клиента. Так же клиентом класса является его экземпляр (объект), который использует атрибуты и операции данного класса.

При этом операция рассматривается как услуга, которую класс может предоставить своим клиентам. Как правило, эти операции бывают следующих видов:

  •  Модификатор – операция изменения состояния объекта.
  •  Селектор – операция считывания состояния объекта (без изменения состояния).
  •  Итератор – операция, организовывающая доступ ко всем частям объекта в строго определенной последовательности.
  •  Конструктор – операция создания и/или инициализации объекта.
  •  Деструктор – операция, освобождающая состояние объекта и/или разрушающая сам объект.

Описание объекта включает в себя описание его состояния, которое характеризуется перечнем атрибутов, соответствующих классу, экземпляром которого является данный объект, и их текущими значениями. Кроме того, описание объекта включает также описание его поведения (функции), которое характеризуется методами, реализующими операции класса, экземпляром которого является данный объект.

Объединяя понятия состояния и поведения объекта, можно ввести понятие роли или ответственности объекта. Ответственность объекта имеет две стороны – знания, которые объект поддерживает, и действия, которые объект может исполнить. Она выражает смысл его предназначения и место в системе. Ответственность понимается как совокупность всех услуг и всех контрактных обязательств объекта. Следовательно, состояние и поведение объекта определяют его роль в системе, а она, в свою очередь, необходима соответствующему классу для выполнения его ответственности.

При выявлении структуры объектов моделируемой системы между объектами устанавливаются различные связи (посредством передачи сообщений), представляющие собой «физическое или концептуальное соединение между объектами». Связи обозначают равноправные или «клиент-серверные» отношения между объектами. «Наиболее желательной является функциональная связность, при которой все элементы…тесно взаимодействуют в достижении определенной цели» [13, с. 139]. Участвуя в связях, объект может выполнять одну из трех ролей:

  •  актора – при которой объект может воздействовать на другие объекты, но сам никогда не подвергается их воздействию (активный объект);
  •  сервера – при которой объект может только подвергаться воздействию со стороны других объектов, но никогда не выступает в роли воздействующего объекта (пассивный объект);
  •  агента – при которой объект может быть и активным, и пассивным.

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

Классы и объекты выявляются (обнаруживаются, открываются) на этапе OOA и в совокупности составляют словарь предметной области. На этапе OOD могут понадобиться новые классы, объекты и механизмы их взаимодействия для обеспечения поведения, требуемого моделью, которые приходится уже изобретать.

При проведении OOA и OOD необходимо осуществлять декомпозицию области приложения и разрабатываемой информационной системы. Для обеспечения такой декомпозиции в соответствии с объектно-ориентированным подходом (ООП) используются абстрагирование и иерархия [13, 78]. Однако в настоящее время задача объектно-ориентированной декомпозиции и выделения классов и объектов не имеет законченного формального решения. «Объектно-ориентированная методика позволяет значительно повысить качество и продуктивность разработки программного обеспечения. Однако извлечь из нее выгоду можно только тогда, когда правильно определено множество объектов. Подходящее множество объектов для конкретной области приложения обеспечивает повторное применение системы и возможности ее расширения, а также гарантирует качество и продуктивность потенциальных улучшений, присущих объектно-ориентированной парадигме. Без формальных методов определения объектов разработчики программного обеспечения рискуют остаться просто хакерами на объектном уровне» [32, с. 23].

При этом в литературе по объектно-ориентированному подходу отмечается, что «к сожалению, пока не разработаны строгие методы классификации и нет правила, позволяющего выделять классы и объекты. … Как и во многих технических дисциплинах, выбор классов является компромиссным решением» [13, с. 147]. Существующие методики OOA на сегодняшний день предлагают эвристические правила идентификации классов и объектов, основанные на опыте классификации в других науках. При этом разные авторы предлагают различные наборы базовых классов для объектного моделирования и проектирования. Например, в работе [88] предлагается набор: Осязаемые предметы, Роли, События, Взаимодействие. В работе [89] предлагается следующий набор: Люди, Места, Предметы, Организации, Концепции, События. В работе [90] предлагается такой набор: Структуры, Другие системы, Устройства, События, Разыгрываемые роли, Места, Организационные единицы.

Наличие разных вариантов и отсутствие каких-либо обоснований этих вариантов свидетельствует о том, что, на сегодняшний день, системные методы классифицирования, позволяющие обоснованно выделять классы и объекты, в объектно-ориентированной технологии пока еще не применяются.

2.2.2. Необходимость интеграции объектного и системного подходов

В настоящее время компонентная методология разработки ИС является базовой методологией создания программного инструментария информационно-аналитического сопровождения деятельности организационных систем. При этом, являясь развитием объектно-ориентированного подхода, данная методология использует все его понятия и принципы. Однако, объектно-ориентированный анализ и проектирование (OOAD) не располагают какими-либо собственными методами анализа и моделирования предметной области, для которой разрабатывается программное приложение, так как изначально предназначены для моделирования ПО. Отсутствуют даже методы простого выявления необходимых для моделирования классов и объектов. Использование же широко рекламируемого языка UML не изменяет ситуации, так как, по справедливому замечанию специалистов (например, М. Фаулера), это только язык, а не метод [81].

Одним из оснований для подобных высказываний является определение понятия «метод», предложенное, например, в работе [91]. Кратко оно может быть представлено в следующем виде: «Метод – есть система правил и приемов достижения определенных результатов, исходящая из знания закономерностей исследуемого предмета, помогающая исследователю выбрать существенное, наметить путь восхождения от известного к неизвестному». Данное определение позволяет утверждать, например, что карточки CRC (Класс – Ответственность – Кооперация) не могут рассматриваться как метод выявления классов предметной области. Подобные карточки являются способом представления информации, который призван облегчить ее последующий анализ. Никакой связи с закономерностями предметной области или каких-либо подходов к выявлению в предметной области существенного они не имеют. Это то же самое, что библиотечная картотека. Сама по себе она есть только удобный способ хранения информации. Для анализа и классификации этой информации применяются совершенно другие методы.

По той же самой причине Рациональный Унифицированный Процесс разработки ПО, как модель жизненного цикла ПО, может рассматриваться только как метод его разработки и управления ей, но не как метод анализа и моделирования той предметной области, для решения проблем в которой и проводится разработка. Доказательством такого понимания может служить, например, работа [92], в которой описание технологического процесса моделирования предметной области, названное «моделированием производства», содержит подробные объяснения необходимости этого моделирования, описание исполнителей и артефактов, общее описание технологического процесса, показывающее место модели предметной области, общие рекомендации по переходу к модели программной системы и т.д. Вопрос моделирования предметной области как таковой не рассматривается и везде остается «одной строчкой». Как моделировать производство так и не объясняется. При этом предложение использовать для него средства моделирования ПО не обосновывается.

Кажущееся естественным применение методов системного анализа, изначально предназначенных для моделирования производства, в рамках OOAD оказывается малоэффективным. Данное обстоятельство обусловлено тем, что методы традиционного системного анализа (именуемого в литературе также структурным или системно-структурным) «полностью ортогональны принципам объектно-ориентированного проектирования» [13, с. 161]. Специалисты по системному анализу приходят к однозначному выводу, что при использовании традиционных системных методов для проведения OOAD все равно приходится выходить за их рамки и использовать дополнительные средства, так как современные методы такого анализа «не позволяют, тем не менее, идентифицировать подходящее множество объектов для разрабатываемой системы. Процесс обнаружения объектов все еще управляется мнениями, интуицией и инсайтом» [32, с. 26].

Отмеченная выше ортогональность обусловлена тем, что традиционные методы системного (или системно-структурного) анализа не связаны с выявлением иерархии классов предметной области, т.е. не решают задачи концептуального классификационного моделирования (ККМ). Таким образом, традиционный системный анализ не поддерживает такие обязательные принципы объектного подхода, как абстрагирование и иерархию.

К сожалению, в литературе по OOAD также, кроме сетований на то, что «рецептов для поиска классов не существует», не предлагается путей решения задачи ККМ, хотя и утверждается, что это основная задача OOAD [например, 13 и 78]. Например, вся литература от Rational Software (под редакцией «трех друзей») ограничивается только рекомендациями общего характера. При этом подчеркивается, что они не знают ни методик построения классификаций, ни даже самого понятия «хорошая классификация». Попытки строить классификации имеются, но они осуществляются на уровне интуиции и экспертных знаний специалистов конкретной предметной области без привлечения какого-либо методического обеспечения, представленного, например, в работах [91 или 93].

Кроме того, традиционные методы системного (или системно-структурного) анализа не поддерживают объектно-ориентированную концепцию инкапсуляции (отделение интерфейса объекта от его реализации). Последнее обстоятельство, в свою очередь, обусловлено тем, что система в традиционном системном анализе и системном подходе (как уже было отмечено выше) всегда рассматривается как множество или элементов, или свойств, или состояний и т.д. В концепции же множества изначально заложена первичность элемента (части) по отношению к множеству (целому). Множество существует тогда и только тогда, когда тем или другим образом заданы его элементы. Теоретико-множественное понимание системы, собственно, и не позволяет обеспечить в ходе традиционного системного анализа инкапсуляцию выявляемых объектов (необходимую при OOAD), так как множество есть явление, внутреннее содержание которого не может быть скрыто. Сущностью же действительно системной концепции («pure system»), на самом деле, является выделение в первую очередь целого, которое уже потом будет (а может и не будет) представлено в виде совокупности взаимодействующих частей (подсистем). На это давно уже обращали внимание ведущие методологи системных исследований [например, 6], однако до сих пор это не нашло практического воплощения в технологиях и инструментах системного анализа (см. далее).

Необходимо подчеркнуть также, что методы традиционного системного анализа и объектно-ориентированный анализ направлены на выявление различных структур исследуемой системы. В системном (системно-структурном) анализе речь идет о функциональной структуре (вход, процесс, выход, связующие потоки) без внимания к реализующим эти функции объектам (субстанции). В OOAD речь идет о структуре объектов (и классов) системы. Функциональность (поведение) этих объектов рассматривается с точки зрения ответственности компонент ПО, так как объектный подход есть результат развития технологии программирования, а не анализа и моделирования действительности. Потеря при этом способности адекватно отображать соотношения вход-выход и потоковые процессы является его (объектного подхода) большим недостатком, резко снижающим эффективность моделирования реальных (а не программных) явлений [37]. Дело в том, что реальная (не виртуальная) действительность целиком и полностью состоит из проточных объектов, постоянно преобразующих входные потоки в выходные. Например, реальный сервер для своего существования должен поддерживаться не только потоками входящей энергии и запасных частей, но и потоками данных, которые кто-то как-то должен периодически туда добавлять, и потоками исполняемого кода, необходимого для обеспечения его функционирования в постоянно меняющихся условиях. Только тогда в ответ на запрос он сможет удовлетворить клиента. Иначе, его просто выключат и выбросят.

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

2.3. Системология – системный подход ноосферного этапа развития науки

2.3.1. Основные понятия

Рассмотрим кратко основные понятия функциональной системологии, описанные в работах [2, 5, 27, 45, 94 - 96].

Система – функциональный объект, функция которого обусловлена функцией объекта более высокого яруса (функцией надсистемы).

Функция системы – роль, предназначение системы в надсистеме, которая проявляется в наличии функциональных связей рассматриваемой системы.

Функциональные связи системы – связи с другими системами в конкретной надсистеме.

Поддерживающие связи системы – функциональные связи ее подсистем. Они создают структуру системы. При этом подсистемы находятся в узлах этой структуры и поддерживают функционирование (функциональные связи) системы.

Подсистема – функциональный объект нижнего яруса иерархии системы, составляющий вместе с другими объектами ее субстанцию.

Таким образом, функции подсистем обусловлены функцией системы, функция системы – функцией надсистемы и т.д.

Внешняя детерминанта системы (функциональный запрос надсистемы) – явление обуславливания функции системы функцией надсистемы.

Внутренняя детерминанта системы – в действительности проявляемая общая функция системы (ее функционирование). Эта детерминанта определяет функции подсистем (частные функции системы) и их взаимосвязи, т.е. субстанциальные и структурные характеристики системы.

Адаптация системы к запросу надсистемы – приближение внутренней детерминанты системы к ее внешней детерминанте. Критерием адаптированности является отношение между возможностями системы и функциональными требованиями надсистемы. Совершенной или оптимально адаптированной является система, у которой внутренняя детерминанта равна внешней.

Свойство системы (или валентность) определяется как способность поддерживать (при определенных условиях) связи одних видов и препятствовать осуществлению связей других видов. Любая же связь рассматривается как проявление между системами процесса обмена (т.е. потока) элементами, представляющими собой субстанции определенных глубинных ярусов связанных систем. При этом принято говорить об экстенциальных валентностях, если связи в действительности существуют, и об интенциальных (или потенциальных) валентностях, если связей в действительности нет. В первом случае способности системы проявлены как реально существующие свойства-связи, во втором случае свойства системы не проявлены, но они существуют как способности (возможности).

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

В зависимости от пути проявления целостности, как основного признака системности, рассматривается два вида систем: внутренние и внешние.

Внутренняя система (система-явление) – это целостное образование, к которому можно применить процедуры членения, представляя эту систему в виде некоторой структуры составляющих частей [6].

Внешняя система (система-класс) – это класс объектов общей природы, объединенных некоторой целостной сущностью. Элементы такой системы «могут не обладать ни пространственной, ни временной общностью, ни даже генетической связью… Важна лишь общность природы образующих систему объектов» [6, с. 69].

Как видно из этого описания, концепция системы, предлагаемая системологией, четко и однозначно определяет отношение «часть-целое» или «целое-часть». Это отношение является специфическим системным отношением, не сводимым к отношению между множествами и не описываемым теоретико-множественными средствами [6]. Оно называется отношением поддержания функциональной способности целого [5]. Совершенно очевидно, таким образом, что рассмотренная системная концепция задаёт вполне определённые, конкретные возможности для проведения операций анализа или синтеза систем как функциональных объектов в упомянутом выше смысле, т.е. является конструктивной.

Рассмотрим подробно процесс формирования (становления) системы, так как при его анализе понятийный аппарат системной концепции проявляется достаточно полно.

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

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

Фактическое функционирование системы в ранее вакантном узле надсистемы (новая внутренняя детерминанта системы) становится причиной возникновения противоречия между функциональными и поддерживающими потоками уже системы. Это противоречие становится причиной формирования подсистем с определенными поддерживающими систему функциями и т.д.

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

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

Чем глубже адаптирована система к функциональному запросу надсистемы, тем ярче проявляются ее существенные для надсистемы свойства, тем выше степень сформированности её сущности, тем меньше избыточность её свойств. Система, у которой область возможных состояний в результате адаптации к запросу надсистемы, не просто покрывает, а максимально близка к области требуемых функциональных состояний, называется оптимально адаптированной или совершенной [5]. Такие системы представляют собой четко сформированные, ярко проявляющиеся, вполне устойчивые явления определенной сущности. При этом процесс адаптации системы к функциональному запросу, который периодически сам изменяется, рассматривается в системологии как эволюция системы.

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

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

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

2.3.2. Системология – язык теории организации, логистики и инжиниринга бизнеса

Существенной полезной особенностью функциональной системологии является ее адекватность теории организации, логистике и инжинирингу бизнеса, о чем свидетельствуют результаты сравнительного анализа понятийного аппарата системологии и упомянутых методологий теоретического освоения и практического использования организационных систем.Для сравнения выберем конкретные понятия теории организации, логистики и инжиниринга бизнеса.

Результаты сопоставления понятий, законов и принципов теории организации с понятиями функциональной системологии представлены в таблице 2.1. Из таблицы хорошо видно сходство, например, понятий «общий потенциал организации» и «частный потенциал организации» с понятиями «функциональные свойства» и «поддерживающие свойства». При этом, очевидно, что явление или закон синергии представляет собой, по сути дела, ни что иное, как конкретное проявление системологического принципа системности. Очевидно, можно даже утверждать, что организация, в которой не проявляется явление синергии, грубо говоря, вообще не является системой (либо является системой с очень маленькой мерой системности [5]). Очень близким, например, к понятию теории организации «миссия организации» является системологическое понятие «внешняя детерминанта (запрос надсистемы)».

Таблица 2.1. Теория организации и системология.

Теория организации

Функциональная системология

Организационная система.

Функциональный объект, функция которого обусловлена функцией объекта более высокого порядка.

Миссия организации.

Запрос надсистемы (внешняя детерминанта системы) в виде вакантного узла надсистемы.

Потенциал организации.

Область возможных функциональных состояний системы (потенциальная валентность).

Общий потенциал организации.

Общая функция системы (внутренняя детерминанта системы); функциональные связи (свойства).

Частный потенциал организации.

Частная функция системы (функция подсистемы); поддерживающая связь (свойство).

Закон синергии.

Принцип системности (системный эффект).

Закон приоритета целого над частью.

Отношение поддержания функциональной способности целого.

Принцип приоритета цели над функцией.

Выбор внутренней детерминанты в соответствии с внешней детерминантой.

Принцип приоритета функции над элементами и структурой.

Формирование внутренних поддерживающих свойств (субстанции и структуры) в соответствии с функциональными свойствами (внутренней детерминантой).

Принцип соответствия между поставленными целями и выделенными ресурсами.

Соответствие области возможных функциональных состояний исходного материала области требуемых состояний вакантного узла надсистемы.

Результаты сопоставления понятий и принципов логистики с понятиями функциональной системологии представлены в таблице 2.2.

Таблица 2.2. Логистика и системология.

Логистика

Функциональная системология

Логистическая система.

Функциональный объект, функция которого обусловлена функцией объекта более высокого порядка.

Поток.

Связь как проявление процесса обмена элементами глубинных ярусов связанных систем.

Запас.

Исходный материал.

Логистическая цепь.

Структура связей системы (поддерживающих).

Логистический процесс.

Функциональные (связи) свойства логистической системы.

Принцип системности.

Отношение поддержания функциональной способности целого.

Принцип интегральной оптимальности.

Выбор внутренней детерминанты в соответствии с внешней детерминантой.

Способность логистической системы к целенаправленному приспосабливающемуся поведению.

Формирование внутренних поддерживающих свойств (субстанции и структуры) в соответствии с областью требуемых состояний вакантного узла надсистемы, адаптация.

Из таблицы видно сходство, например, логистического понятия «поток» с понятием функциональной системологии «связь», а также то, что логистический принцип системности представляет собой, по сути дела, проявление в логистической системе системологического отношения поддержания функциональной способности целого.

Результаты сопоставления понятий инжиниринга бизнеса с понятиями функциональной системологии представлены в таблице 2.3.

Таблица 2.3. Инжиниринг бизнеса и системология.

Инжиниринг бизнеса

Функциональная системология

Внешняя модель (П-модель) бизнеса.

Модель функциональных связей.

Внутренняя модель (О-модель) бизнеса.

Модель поддерживающих связей.

Образ будущей компании (спецификация целей).

Внешняя детерминанта (предельная внутренняя детерминанта) системы.

Бизнес-процесс.

Формирование из потенциально пригодного исходного материала на глубинном ярусе системы определенной субстанции для обмена по функциональной связи с окрестностной системой.

Почему компания делает то, что она делает?

Функциональный запрос надсистемы (детерминантный анализ).

Почему компания делает то, что она делает таким образом?

Текущая внутренняя детерминанта системы (партитивное классифицирование).

Усовершенствование бизнеса.

Адаптация системы.

Реинжиниринг бизнеса.

Эволюция системы.

Из таблицы видно сходство, например, мероприятий по определению «почему компания делает то, что она делает» с процедурой определения функционального запроса надсистемы.

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

2.3.3. Системологический и объектно-ориентированный подход

Традиционные методологии разработки программных систем ориентированы на описание данных и процедур, но не на описание сущностей реального мира и их поведение. Поскольку инжиниринг бизнеса ориентирован на реальные бизнес-структуры и бизнес-процессы, а не на формальные данные и процедуры, традиционные подходы оказались неадекватными. Объектно-ориентированный подход является единственным подходом, позволяющим описывать как сущности, так и их реальное поведение. Кроме того, он обеспечивает создание прозрачных, легко модифицируемых моделей бизнеса и ИС, допускающих повторное использование отдельных компонент. Именно поэтому, в настоящее время, объектно-ориентированная методология анализа, моделирования и разработки ИС является базовой методологией создания программного инструментария для реинжиниринга бизнес-процессов [97].

Сравним основные понятия системологии и объектно-ориентированной методологи.

Главным предметом исследования системологии является «система», объектно-ориентированная методология опирается на понятие «объект». Концептуальное сходство системологического и объектно-ориентированного подходов (ООП) основывается, в первую очередь, на сходном понимании природы системы и объекта, соответственно.

С точки зрения системологии, как уже было отмечено, система – есть функциональный объект, функция которого обусловлена функцией объекта более высокого яруса, т.е. надсистемой [5]; а объект, с точки зрения ООП, представляет собой предмет или сущность, имеющую определенное функциональное назначение в данной предметной области [13, 78].

При этом, вроде бы за небольшим внешним текстуальным сходством, определений системы и объекта скрывается их глубокое концептуальное единство, состоящее в том, что оба понятия не определяются в терминах теории множеств и не рассматриваются как разновидности понятия «множество». Рассмотрение же системы как множества, свойственное традиционному системному подходу, приводит к невозможности поддержать средствами соответствующего системного анализа инкапсуляцию, являющуюся неотъемлемой составной частью ООП и обеспечивающую разделение внешней и внутренней стороны объекта.

Объектно-ориентированная методология в значительной степени опирается также на следующие основные понятия [13, 79]:

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

Анализ этих понятий и результатов их сравнения с понятиями системологии позволяет выявить глубокую аналогию основных положений ООП и системологического подходов.

С точки зрения дихотомии «класс/объект» в системологии рассматривается два вида систем: системы-классы и системы-явления (называемые в [6] внешними и внутренними системами соответственно).

При этом в настоящее время нам удалось обеспечить единство содержательного и формального рассмотрения обоих видов систем как функциональных объектов. Рассмотрение систем-явлений предметной области позволяет оценить её с точки зрения целостности, устойчивости функционирования, глубины и оптимальности адаптации. Рассмотрение систем-классов предметной области позволяет оценить её с точки зрения естественности (онтологичности) и функционального соответствия объективным запросам систем более высокого порядка [45, 94].

С точки зрения дихотомии «интерфейс/реализация» в системологии рассматривается два вида свойств: функциональные и поддерживающие.

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

С точки зрения контрактного проектирования и, в частности, понятия «ответственности», которое выражает предназначение объекта в системе через совокупность его контрактных обязательств, в системологии рассматриваются понятия внутренней детерминанты и внешней детерминанты, которая и определяет выбор внутренней.

Сходство представленных понятий имеет большое значение, как для системологии – с точки зрения выявления еще одной важной области её применения: объектно-ориентированного проектирования современного ПО; так и для фундаментального теоретического обоснования и развития самой объектно-ориентированной методологии.

Кроме того, требование исследования иерархии объектов и иерархии классов в ходе объектно-ориентированного анализа системы находится в полном согласии и соответствии с требованиями системологии, в которой предполагается необходимость детерминантного анализа внутренних систем предметной области (систем-явлений или экземпляров) и внешних систем (систем-классов). Следовательно, системологический подход позволяет проанализировать полную и целостную архитектуру рассматриваемой системы в соответствии с требованиями методологии OOAD. При этом рассмотрение внутреннего и внешнего аспекта системности характерно именно для системологии и ни в какой другой концепции системного подхода не используется.

Связь между системологией и объектно-ориентированным подходом представлена в таблице 2.4.

Таблица 2.4. Объектный подход и системология.

Объектный подход

Системология

Объект.

Система-явление (внутренняя система).

Класс.

Система-класс (внешняя система).

Объектно-ориентированная декомпозиция.

Системная декомпозиция, на основе отношения поддержания функциональной способности целого.

Структура (иерархия) объектов.

Партитивная (цело-частная) классификация.

Структура (иерархия) классов.

Таксономическая (родо-видовая) классификация.

Контрактное программирование (клиент-сервер).

Внешняя детерминанта (запрос надсистемы) – Внутренняя детерминанта (функция системы, соответствующая запросу).

Варианты использования (прецеденты).

Внутренняя детерминанта.

Главная задача объектно-ориентированного проектирования: выбор правильного набора абстракций (классов).

Метод построения классификаций, отражающих существенные свойства предметной области: системологический классификационный анализ.

Объектно-ориентированное мировоззрение, при котором «требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области» [13, с. 54], и системологическое мировоззрение, при котором предметная область рассматривается как иерархия функциональных объектов (систем-явлений), находящихся в отношении поддержания функциональной способности целого [5], а также как иерархия систем-классов, находящихся в том же отношении [94], таким образом, совершенно сходятся. Можно даже утверждать, что такие составные части объектно-ориентированной методологии как OOA и OOD есть, по сути своей, ни что иное, как изложение системологии в терминах программной инжинирии.

Вопросы для повторения

  1.  Назовите основные проблемы традиционного системного подхода.
  2.  В чем состоит основное отличие понятия «система» от понятия «множество»?
  3.  Что такое объектно-ориентированный анализ?
  4.  Что такое объектно-ориентированное проектирование?
  5.  Что такое объектно-ориентированное программирование?
  6.  Назовите основные понятия объектно-ориентированного подхода.
  7.  Что такое «UML»?
  8.  Зачем необходима интеграция системно-структурного и объектно-ориентированного подходов?
  9.  Дайте определение системы как функционального объекта?
  10.  Что такое связь между системами с точки зрения системологии?
  11.  Что такое внешняя детерминанта?
  12.  Что такое внутренняя детерминанта?
  13.  Что такое адаптация системы?
  14.  Что такое эволюция системы?
  15.  Какие понятия теории организации соответствуют каким понятиям системологии?
  16.  Какие понятия логистики соответствуют каким понятиям системологии?
  17.  Какие понятия инжиниринга бизнеса соответствуют каким понятиям системологии?
  18.  Какие понятия объектно-ориентированного подхода соответствуют каким понятиям системологии?

Резюме по теме

В данном разделе рассмотрены основные подходы к моделированию и анализу сложных слабоформализованных систем. При этом изучены проблемы традиционного системного подхода и системного анализа, а также причины их существования. Кроме того, показаны особенности объектно-ориентированного подхода и обоснована необходимость интеграции системно-структурного и объектно-ориентированного подходов. Приведены основные понятия системологии, которые сопоставлены с основными понятиями дисциплин, направленных на рационализацию организационных систем (теории организации, логистики и инжиниринга бизнеса), а также с основными понятиями объектно-ориентированного подхода.


Тема 3. Технологии системного моделирования

Цели и задачи изучения темы

Целью изучения данной темы является теоретическое и практическое освоение технологий системно-структурного моделирования и анализа сложных систем.

При этом ставятся следующие задачи:

  •  изучение технологии моделирования «3-View Modeling» (технологий построения DFD, ERD и STD-диаграмм);
  •  изучение стандартных методов системно-структурного анализа, описанных серией федеральных стандартов США «Icam Definition»;
  •  изучение CASE-инструментария системно-структурного моделирования и анализа (AllFusion Process Modeler).

3.1. Технология системно-структурного моделирования и анализа «3-View Modeling»

3.1.1. Диаграммы потоков данных: нормативная система; построение модели; словарь данных; спецификация процесса

По мнению специалистов в области системного анализа [19, 20, 22, 32, 33, 47, 48, 98] для решения задач анализа и проектирования некоторого объекта необходимо моделировать:

  •  функции этого объекта, например, с помощью диаграмм потоков данных – DFD (Data Flow Diagrams);
  •  отношения между данными, которые в нем используются, например, с помощью диаграмм «сущность – связь» – ERD (Entity-Relationship Diagrams);
  •  поведение объекта (события), например, с помощью диаграмм переходов состояний – STD (State Transition Diagrams).

Рассмотрим графические средства построения этих диаграмм, а также вспомогательные текстовые средства (спецификацию процесса и словарь данных), обеспечивающие точное определение их компонент (см. рис. 3.1. и [20]).

Таким образом, с помощью DFD-диаграмм изображаются функции (процессы), накопители (хранилища) данных и связывающие их потоки. При этом идентифицируются внешние по отношению к системе источники и адресаты данных. Каждый процесс может быть детализирован с помощью DFD-диаграммы нижнего уровня или, в конце концов, описан в виде спецификации процесса. Структура потоков данных и определения их компонент, а также содержимое хранилищ описывается в словаре данных. Модель данных хранилища раскрывается с помощью ERD-диаграммы. Если моделируется система реального времени, то дополнительно поведение системы описывается с помощью STD-диаграммы. Данная технология системно-структурного анализа используется при построении моделей в рамках британской стандартной методологии анализа и проектирования систем SSADM.

Рассмотрим технологию 3VM в первую очередь в соответствии с работой [20], а также работами [22, 32, 98] подробнее.

Диаграммы потоков данных (DFD) являются средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Нормативная система

Для изображения DFD-диаграмм традиционно используются две различные нотации: Йордана и Гейна-Сарсона. Алфавит, используемый для построения DFD-диаграмм, представлен в таблице 3.1.

Таблица 3.1. Нормативная система (нотация) DFD.

Элемент алфавита

Нотация

Йордана

Нотация

Гейна-Сарсона

Поток данных

Используется для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. На диаграммах изображаются именованными стрелками, ориентация которых указывает направление потока.

Процесс

Используется для моделирования процесса преобразования входного потока в выходной. Его имя должно содержать глагол в неопределенной форме с последующим дополнением (например, «Вычислить высоту»). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы, который совместно с номером диаграммы уникален во всей модели.

Хранилище (накопитель) данных

Используется для моделирования данных (или даже физических компонент), которые будут сохраняться между процессами. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

Внешняя сущность (терминатор)

Используется для моделирования сущностей вне системы (контекстных сущностей), являющихся источником или приемником системных данных. Ее имя должно содержать существительное, например, «Склад». Предполагается, что объекты, представленные такими сущностями, не должны участвовать ни в какой обработке.

Управляющий поток

Используется для моделирования связи, через которую передается управляющая информация. Его имя не должно содержать глаголов, а только существительные и прилагательные. Обычно управляющий поток имеет дискретное, а не непрерывное значение. Это может быть, например, сигнал, представляющий состояние или вид операции.

Имеются следующие типы управляющих потоков:

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

б) А-поток (activator flow) – поток управления, который может изменять выполнение процесса. Используется для обеспечения непрерывности выполнения процесса до тех пор, пока поток «включен» (т.е. течет непрерывно); с «выключением» потока выполнение процесса завершается. Это – аналог переключателя лампы, которая может быть как включена, так и выключена.

в) E/D-поток (enable/disable flow) – поток управления, который может переключать выполнение процесса. Течение по Е-линии вызывает выполнение процесса, которое продолжается до тех пор, пока не возбуждается течение по D-линии. Это аналог выключателя с двумя кнопками: одной для включения света, другой для его выключения. Можно использовать 3 типа таких потоков: Е-поток, D-поток, E/D-поток.

Управляющий процесс 

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

Управляющее хранилище

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

Групповой узел

Используется для моделирования расщепления и объединения потоков.

Узел-предок

Используется для связывания входящих и выходящих потоков между детализируемым  процессом и детализирующей DFD-диаграммой.

Неиспользуемый узел

Используется для моделирования ситуации, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел.

Узел изменения имени

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

Текст

В свободном формате в любом месте диаграммы.

Построение модели

Главная цель построения модели в виде иерархического множества DFD-диаграмм заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Для достижения этого рекомендуется пользоваться следующими правилами [20]:

  1.  Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.
  2.  Не загромождать диаграммы несущественными на данном уровне детализации сущностями.
  3.  Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов; эти две работы должны выполняться одновременно, а не одна после завершения другой.
  4.  Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения восприятия диаграмм, при этом не рекомендуется использовать аббревиатуры.
  5.  Однократно определять функционально идентичные процессы на самом верхнем уровне иерархии, где такой процесс необходим, и ссылаться на него на нижних уровнях иерархии.
  6.  Пользоваться простейшими диаграммными техниками: если что-либо возможно описать с помощью DFD-диаграмм, то это и необходимо делать, а не использовать для описания более сложные объекты.
  7.  Отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры.

В соответствии с этими рекомендациями процесс построения модели разбивается на следующие этапы [20]:

  1.  Идентификация внешних (контекстных) объектов, с которыми система должна быть связана.
  2.  Расчленение множества требований и организация их в основные функциональные группы.
  3.  Идентификация основных видов информации, циркулирующей между системой и внешними объектами.
  4.  Предварительная разработка контекстной диаграммы, на которой основные функциональные группы представляются процессами, внешние (контекстные) объекты – внешними сущностями, основные виды информации – потоками данных между процессами и внешними сущностями.
  5.  Изучение предварительной контекстной диаграммы и внесение в неё изменений по результатам ответов на возникающие при этом изучении вопросы по всем её частям.
  6.  Построение контекстной диаграммы путём объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
  7.  Формирование DFD-диаграммы первого уровня на базе процессов предварительной контекстной диаграммы.
  8.  Проверка основных требований по DFD-диаграмме первого уровня.
  9.  Декомпозиция каждого процесса текущей DFD-диаграммы с помощью детализирующей диаграммы или спецификации процесса.
  10.  Проверка основных требований по DFD-диаграмме соответствующего уровня.
  11.  Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.
  12.  Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям.
  13.  После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимаемости модели.
  14.  Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов.

Важную специфическую роль в модели играет специальный вид DFD-диаграммы – контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а также, как правило, единственный процесс, отражающий главную цель или природу системы насколько это возможно. И хотя контекстная диаграмма выглядит тривиальной, несомненная ее полезность заключается в том, что она устанавливает границы анализируемой системы. Каждый проект должен иметь ровно одну контекстную диаграмму, при этом нет необходимости в нумерации единственного ее процесса.

Декомпозиция DFD-диаграммы осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD-диаграммы нижнего уровня. DFD-диаграмма первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме. Построенная диаграмма первого уровня также имеет множество процессов, которые в свою очередь могут быть декомпозированы. Таким образом строится иерархия DFD-диаграмм с контекстной диаграммой в корне дерева. Этот процесс декомпозиции продолжается до тех пор, пока процессы могут быть эффективно описаны с помощью коротких (до одной страницы) спецификаций процессов.

При таком построении иерархии DFD-диаграмм каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Так, например, если мы детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его с помощью DFD-диаграммы, содержащей три процесса, то их номера будут иметь следующий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уровень, т.е. для процесса 2.2 получим 2.2.1, 2.2.2. и т.д.

Пример иерархии DFD-диаграмм, описывающих систему управления лифтом, аналогичную представленной в работе [32] (Elevator Control SystemECS), подготовленный с применением инструментального пакета BPwin, изображен на рисунках 3.2 – 3.7. Дополнительные возможности нотации позволяют, в частности, с помощью двойных стрелок отличить материальные потоки от информационных. Данный пример используется далее для описания различных аспектов технологии моделирования 3VM.

Диаграммы (3.2 – 3.7) построены с учетом следующих требований к системе управления лифтом [32, стр. 15-17]:

  •  лифт используется для перевозки людей в 40-а этажном офисном здания обычным способом (при вызове лифта с этажа он должен останавливаться при попутном движении; лифт не должен менять направления, пока едущие в нем пассажиры не достигнут назначенных этажей; пустой лифт должен стоять там, где он остановился последний раз);

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

Словарь данных

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

Словарь данных представляет собой определенным образом организованный список всех элементов, составляющих потоки данных системы с их точными определениями. Это дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонент хранилищ.

Определение элементов данных в словаре осуществляется с помощью описаний следующих видов [20]:

  •  описанием характеристик потоков и хранилищ, изображенных на DFD-диаграммах;
  •  описанием композиций данных, движущихся вдоль потоков, т.е. комплексных данных, которые могут расчленяться на элементарные (например, «Адрес» содержит «Индекс», «Город», «Улица» и т.д.);
  •  описанием композиций данных в хранилище.

Для каждого потока данных в словаре необходимо хранить имя потока, его тип и атрибуты. Информация по каждому потоку состоит из ряда словарных статей, каждая из которых начинается с ключевого слова – заголовка соответствующей статьи, которому предшествует символ «@».

Типы потоков определяются в словаре как:

  •  простые (элементарные) или групповые (комплексные) потоки;
  •  внутренние (существующие только внутри системы) или внешние (связывающие систему с другими системами) потоки;
  •  потоки данных или потоки управления;
  •  непрерывные (принимающие любые значения в пределах диапазона) или дискретные (принимающие определенные значения) потоки.
  •  Атрибуты потока данных включают:
  •  имена-синонимы потока данных в соответствии с узлами изменения имени;
  •  определение с помощью БНФ-нотации (см. далее) в случае группового потока;
  •  единицы измерения потока;
  •  диапазон значений для непрерывного потока, типичное его значение и информацию по обработке экстремальных значений;
  •  список значений и их смысл для дискретного потока;
  •  список номеров диаграмм, в которых поток встречается;
  •  список потоков, в которые данный поток входит;
  •  комментарий, включающий дополнительную информацию (например о цели введения данного потока).

БНФ-нотация позволяет формально описать расщепление/объединение потоков. Поток может расщепляться на собственные отдельные ветви, на компоненты потока-предка или на то и другое одновременно.

При расщеплении/объединении потока существенно, чтобы каждый компонент потока-предка являлся именованным. При объединении подпотоков нет необходимости осуществлять исключение общих компонент, а при расщеплении подпотоки могут иметь такие общие (одинаковые) компоненты.

Точные определения потоков содержатся в словаре данных, а не на диаграммах. Например, на диаграмме может иметься групповой узел с входным потоком Х и выходными подпотоками Y и Z. Однако, это вовсе не означает, что соответствующее определение в словаре данных обязательно должно быть X=Y+Z. Это определение может быть следующим: Х=А+В+С; Y=A+B; Z=B+C. Такие определения хранятся в словаре данных в так называемой БНФ-статье.

БНФ-статья используется для описания компонент данных в потоках данных и в хранилищах. Ее синтаксис имеет следующий вид:

@БНФ = <простой оператор> ! <БНФ-выражение>,

где <простой оператор> есть текстовое описание, заключенное в «/», а <БНФ-выражение> есть выражение в форме Бэкуса-Наура, заключенное в «[ ]» и допускающее следующие операции и отношения: =      означает «композиция из»;   +   – означает «И»;   !   – означает «ИЛИ»;   ()   – означает, что компонент в скобках не обязателен;   {}   – означает итерацию компонента в скобках;   « »   – означает литерал.

Итерационные скобки могут иметь нижний и верхний предел, например:

3 {болт} 7 – от 3 до 7 итераций

1 {болт} – 1 и более итераций

{шайба} 3 – не более 3 итераций

БНФ-выражение может содержать произвольные комбинации операций:

@БНФ = [ винт ! болт + 2 {гайка} 2 + (прокладка) ! клей ]

Ниже приведен пример описания потока данных подсистемы принятия решений ECS «№ текущего этажа» (рис. 3.3 – 3.6) с помощью БНФ-статьи:

@ИМЯ = № текущего этажа

@ТИП = Простой, внутренний, дискретный поток данных

@БНФ = [«1» ! «2» ! … ! «39» ! «40»]

Далее приведен пример описания входных потоков данных блока формирования управляющих сигналов на примере потока «Перегрузка», а также выходных потоков этого блока на примере потока «Стоп» (рис. 3.7):

@ИМЯ = перегрузка

@ТИП = Простой, внутренний, дискретный поток данных

@БНФ = [«0» ! «1»]

@ИМЯ = стоп

@ТИП = Простой, внешний, дискретный поток управления

@БНФ = [«0» ! «1»]

Спецификация процесса

Спецификация процесса (СП) используется для описания процесса, когда нет необходимости детализировать его с помощью DFD-диаграммы (т.е. если он невелик и его описание может занимать не более одной страницы текста). СП представляет собой описание алгоритма, соответствующего данному процессу и трансформирующего входные потоки данных в выходные. Множество всех СП является полной спецификацией системы. СП содержит номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса.

Известно большое число разнообразных методов, позволяющих задать тело процесса: от структурированного  естественного  языка или псевдокода до визуальных языков проектирования (типа FLOW-форм), а также формальных языков программирования.

Независимо от используемого метода СП должна начинаться со следующих ключевых слов:

@ВХОД = <имя символа данных >

@ВЫХОД = <имя символа данных>

@СПЕЦПРОЦ

где <имя символа данных> соответствующее имя из словаря данных.

Например, для процессов формирования массивов (рис. 3.5 и 3.6),

@ВХОД = Назначение этажа в лифте; № текущего этажа; Стоп по назначению

@ВЫХОД = Массив назначений

@СПЕЦПРОЦ

Сформировать очередь №№ этажей, назначенных в лифте

@

@ВХОД = Вызов лифта с этажа вверх; Вызов лифта с этажа вниз; № текущего этажа; Стоп

@ВЫХОД = Массив вызовов

@СПЕЦПРОЦ

Сформировать очередь №№ вызвавших этажей

@

Иногда в СП задаются пред- и пост-условия выполнения данного процесса. В пред-условии записываются объекты, значения которых должны быть   истинны перед началом выполнения процесса, что обеспечивает определенные гарантии безопасности для пользователя. Аналогично, в случае наличия пост-условия гарантируется, что значения всех входящих в него объектов будут истинны при завершении процесса.

СП должна удовлетворять следующим требованиям [20]:

  •  для каждого процесса нижнего уровня должна существовать одна и только одна спецификация;
  •  спецификация должна определять способ, но не метод преобразования входных потоков в выходные;
  •  спецификация должна стремиться к ограничению избыточности: не следует переопределять то, что уже было определено на диаграмме или в словаре данных;

Ниже рассматриваются некоторые наиболее часто используемые методы задания СП.

Структурированный естественный язык является разумной комбинацией строгости языка программирования и читабельности естественного языка.  Он состоит из подмножества слов, организованных в определенные логические структуры, арифметических выражений и диаграмм. В состав структурированного языка входят следующие основные символы:

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

Управляющие конструкции структурированного языка имеют вид:

Последовательная конструкция:

ВЫПОЛНИТЬ функция1

ВЫПОЛНИТЬ функция2

ВЫПОЛНИТЬ функцияЗ

Конструкция выбора:

ЕСЛИ<условие>ТО

ВЫПОЛНИТЬ функция1

ИНАЧЕ

ВЫПОЛНИТЬ функция2

КОНЕЦЕСЛИ

Итерация:

ДЛЯ <условие>

ВЫПОЛНИТЬ функция

КОНЕЦДЛЯ

Или

ПОКА <условие>

ВЫПОЛНИТЬ функция

КОНЕЦПОКА

При использовании структурированного естественного языка приняты следующие соглашения [20]:

  •  логика процесса выражается в виде комбинации последовательных конструкций, конструкций выбора и итераций;
  •  ключевые слова ЕСЛИ, ВЫПОЛНИТЬ, ИНАЧЕ и т.д. должны быть написаны заглавными буквами;
  •  слова или фразы, определенные в словаре данных, должны быть написаны заглавными буквами;
  •  глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать);
  •  логика процесса должна быть выражена четко и недвусмысленно.

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

Проектирование СП с помощью таблиц решений (ТР) заключается в задании матрицы, отображающей множество входных условий во множество выходных действий.

ТР состоит из двух частей. Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа «да-нет». Нижняя часть ТР используется для определения действий, т.е. ТО-части оператора ЕСЛИ-ТО. 

Левая часть ТР содержит наименования условий и действий, а в правой части перечисляются все возможные комбинации условий и, соответственно, указывается, какие конкретно действия и в какой последовательности выполняются, когда определенная комбинация условий имеет место.

Построение ТР рекомендуется осуществлять путем выполнения следующих шагов [20]:

  1.  Идентифицировать все условия (или переменные), участвующие в описываемом процессе. Идентифицировать все значения, которые каждая переменная может иметь.
  2.  Вычислить число комбинаций условий.
  3.  Идентифицировать каждое из возможных действий, которые могут вызываться в описываемом процессе.
  4.  Построить пустую таблицу, включающую все возможные условия и действия, а также номера комбинаций условий.
  5.  Выписать и занести в таблицу все возможные комбинации условий.
  6.  Редуцировать комбинации условий (если это возможно).
  7.  Проверить каждую комбинацию условий и идентифицировать соответствующие выполняемые действия.
  8.  Выделить комбинации условий, для которых в данном процессе нет выполняемых действий.
  9.  Обсудить построенную таблицу.

Поясним вышесказанное на примере СП управления движением лифта (рис. 3.7, процесс №1) и СП управления остановкой лифта (рис. 3.7, процесс №2) (см. таблицы 3.2 и 3.3 соответственно).

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

Таблица 3.2. Таблица решений процесса управления движением лифта

Условия

1

2

3

4

5

6

7

8

9

Вн

0

0

0

0

0

0

1

1

1

Нн

0

0

0

1

1

1

0

0

0

Вв

0

0

1

0

0

1

0

0

1

Нв

0

1

0

0

1

0

0

1

0

Действия

В

0

0

1

0

0

0

1

1

1

Н

0

1

0

1

1

1

0

0

0

Таблица 3.3. Таблица решений процесса управления остановкой лифта

Условия

1

2

3

4

5

6

7

8

9

10

11

12

13

14

П

0

0

0

0

0

0

0

0

0

0

0

0

0

1

Сн

0

0

0

0

0

0

0

0

0

0

0

0

1

*

Свв

0

0

0

0

0

0

1

1

1

1

1

1

*

*

Снв

0

0

0

1

1

1

0

0

0

1

1

1

*

*

В

0

0

1

0

0

1

0

0

1

0

0

1

*

*

Н

0

1

0

0

1

0

0

1

0

0

1

0

*

*

Действия

С

0

0

0

1

1

0

1

0

1

1

1

1

1

1

Обсудим построенные таблицы. Данные таблицы визуализируют обычную логику работы лифта в офисном здании. Согласно табл. 3.2, если из лифта было назначено движение вниз или вверх, то независимо от вызовов лифт будет выполнять эти назначения. При этом назначений вверх и вниз одновременно быть не может, что обеспечивается формированием очереди №№ этажей, назначенных в лифте (см. рис. 3.5). При отсутствии назначений будут выполняться вызова с этажей, которые по той же причине (см. рис. 3.6) не могут быть одновременно и вверх, и вниз. Согласно табл. 3.3 наличие перегрузки или требования остановится из лифта вызывают безусловную остановку. Требования остановится с этажа выполняются только при попутном движении лифта. Управляющий сигнал «С» при наличии требования на остановку с этажа (вызова с этажа) в случае, когда лифт стоит (В = 0; Н = 0), используется для открывания двери на вызвавшем этаже механической системой лифта.

Вариантом таблицы решений является дерево решений (ДР), позволяющее взглянуть на процесс условного выбора с позиции схемы. Обычно ДР используется при малом числе действий и когда не все комбинации условий возможны, а ТР – при большом числе действий и когда возможно большое число комбинаций условий. На основе ТР легко осуществляется автоматическая кодогенерация.

Визуальные языки проектирования являются относительно новой, оригинальной методикой разработки СП. Они базируются на основных идеях структурного программирования и позволяют определять потоки управления с помощью специальных иерархически организованных схем.

Одним из наиболее известных подходов к визуальному проектированию СП является подход с использованием FLOW-форм. Каждый символ FLOW-формы имеет вид прямоугольника и может быть вписан в любой прямоугольник любого другого символа. Символы помечаются с помощью предложений на естественном языке или с использованием математической нотации.

Символы FLOW-форм приведены на рисунке 3.8. Каждый символ является блоком обработки. Каждый прямоугольник внутри любого символа также представляет собой блок обработки.

На рисунке 3.9 приведен пример использования данного подхода при проектировании СП, обеспечивающего упорядочивание определенным образом элементов массива и являющегося  фрагментом  алгоритма  сортировки  методом «поплавка» [20].

Дальнейшее развитие FLOW-формы получили в диаграммах Насси-Шнейдермана. На этих диаграммах символы последовательной обработки и цикла изображаются так же, как и соответствующие символы FLOW-форм. В символах условного выбора и case-выбора собственно условие располагается в верхнем треугольнике, выбираемые варианты – на нижних сторонах треугольника, а блоки обработки – под выбираемыми вариантами. Диаграмма Насси-Шнейдермана для вышеприведенного примера изображена на рисунке 3.10 [20].

3.1.2. Диаграммы «сущность-связь»: нотация Чена; нотация Баркера; построение модели

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

Нотация Чена

Нотация ERD-диаграмм была предложена Ченом. Нотация Чена предоставляет богатый набор средств моделирования данных, включая собственно ERD-диаграммы, а также диаграммы атрибутов и диаграммы категоризации. Эти диаграммные техники используются для моделирования и проектирования как реляционных, так и иерархических и сетевых баз данных.

Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, предметов, состояний, идей и т.п.), обладающих общими характеристиками (атрибутами). Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, Город, а не Москва).

Отношение представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (Имеет, Определяет, Может владеть и т.п.).

Другими словами, сущности представляют собой базовые типы информации, хранимой в базе данных, а отношения показывают, как эти типы данных взаимоувязаны друг с другом. Введение подобных отношений преследует две основополагающие цели:

  •  обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);
  •  использование этой информации различными приложениями. Символы ERD-диаграмм, соответствующие сущностям и отношениям, приведены на рис. 3.11.

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

Неограниченное (обязательное) отношение представляет собой безусловное отношение, т.е. отношение, которое всегда существует до тех пор, пока существуют относящиеся к делу сущности. Ограниченное (необязательное) отношение представляет собой условное отношение между сущностями. Существенно-ограниченное отношение используется, когда соответствующие сущности в системе взаимозависимы.

Для идентификации отношений, в которые вовлекаются сущности, используются связи. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Значение связи характеризует ее тип и, как правило, выбирается из следующего множества:

{«0 или 1». «0 или более», «1», «1 или более», “p : q” ( диапазон )}.

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

  •  1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.
  •  1*n (один-к-многим). Отношения данного типа являются наиболее часто используемыми.
  •  n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и с введением новых отношений).

На рисунке 3.12 приведен пример диаграммы «сущность–связь», моделирующей отношения между сущностями, содержащимися в хранилищах системы управления лифтом, в нотации Чена.

Каждая сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. При этом любой атрибут может быть определен как ключевой.

Детализация сущности осуществляется с использованием диаграммы атрибутов, которая раскрывает характеристики (атрибуты) сущности. Диаграмма атрибутов состоит из детализируемой сущности, соответствующих атрибутов и доменов, описывающих области значений атрибутов.

Пример диаграммы атрибутов, приведен на рис. 3.13. На диаграмме каждый атрибут представляется в виде связи между сущностью и соответствующим доменом, являющимся графическим представлением множества возможных значений атрибута. Все атрибутные связи имеют значения на своем окончании. Для идентификации ключевого атрибута используется подчеркивание имени атрибута.

Сущность может быть разделена и представлена в виде двух или более сущностей-категорий, имеющих общие атрибуты и/или отношения. Эти атрибуты определяются однажды на верхнем уровне для разделяемой сущности (общей сущности) и наследуются на нижнем. Сущности-категории должны иметь и свои собственные атрибуты и/или отношения, а также, в свою очередь, могут быть декомпозированы своими сущностями-категориями на следующем уровне. На промежуточных уровнях декомпозиции одна и та же сущность может быть как общей сущностью, так и сущностью-категорией.

Для демонстрации декомпозиции сущности на категории используется диаграмма категоризации. Такая диаграмма содержит общую сущность, две и более сущности-категории и специальный узел-дискриминатор, который описывает способы декомпозиции сущностей (см. рис. 3.14).

Существуют 4 возможных типа дискриминатора:

  •  Е/М (exclusive/mandatory) – полное и обязательное вхождение – сущность должна быть одной и только одной из категорий декомпозиции.
  •  Е/0 (exclusive/optional) – полное и необязательное вхождение – сущность может быть одной и только одной  из категорий декомпозиции.
  •  VM (inclusive/mandatory) – неполное и обязательное вхождение –сущность должна быть по крайней мере одной из категорий декомпозиции.
  •  I/O (inclusive/optional) – неполное и необязательное вхождение – сущность может быть, по крайней мере, одной из категорий декомпозиции.

Нотация Баркера

Дальнейшее развитие диаграммы «сущность-связь» получили в работах Баркера, предложившего оригинальную нотацию (см. рис. 3.15), которая позволила интегрировать средства описания моделей Чена.

В нотации Баркера используется только один тип диаграмм: собственно ERD-диаграммы. Сущность на ERD-диаграмме представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно, неполный) и указатели ключевых атрибутов (знак «#» перед именем атрибута). Понятия категории и общей сущности Чена заменяются Баркером на эквивалентные понятия подтипа и супертипа соответственно. Атрибуты сущностей могут быть обязательными и необязательными. Кроме того, атрибуты могут быть описательными (дескрипторами сущности) или входить в состав первичного ключа (уникального идентификатора сущности). Сущность, как правило, может быть полностью идентифицирована своим первичным ключом. Однако, могут быть случаи, когда в идентификации данной сущности участвуют также атрибуты другой сущности-родителя. Кроме первичных ключей могут использоваться альтернативные (возможные) ключи.

Все связи являются бинарными и представляются линиями, соединяющими родительскую сущность с одной или несколькими сущностями-потомками. Для связей должно быть определено имя (выражаемое грамматическим оборотом глагола), степень множественности (один или много объектов участвуют в связи) и степень обязательности (т.е. обязательная или необязательная связь между сущностями). Для множественной связи линия присоединяется к прямоугольнику сущности в трех точках, а для одиночной связи – в одной точке. При обязательной связи рисуется непрерывная линия до середины связи, при необязательной – пунктирная линия. Могут иметь место ситуации, при которых связи данной сущности рассматриваются как взаимоисключающие. Кроме того, связь может быть рекурсивной, а также неперемещаемой, если экземпляр сущности не может быть перенесен из одной связи в другую.

На рис. 3.16 приведен пример ERD-диаграммы, моделирующей отношения между сущностями, содержащимися в хранилищах системы управления лифтом (см. рис. 3.12), в нотации Баркера.

Построение модели

Разработка ERD-диаграммы включает следующие основные этапы [20]:

  •  Идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей.
  •  Идентификация отношений между сущностями и указание типов отношений.
  •  Разрешение неспецифических отношений (отношений n*m).

Рассмотрим эти этапы в соответствии с работой [20] более подробно.

1-й этап построения ERD-диаграммы (или модели данных) является определяющим. Исходной информацией для данного этапа служит содержимое хранилищ данных, зависящее от входящих и выходящих потоков данных, представленных на DFD-диаграмме.

Таким образом, для построения ERD-диаграммы необходимо иметь предварительно построенную DFD-диаграмму. На рисунке 3.17 приведен фрагмент DFD-диаграммы, моделирующей деятельность бухгалтерии предприятия по ведению данных о персонале и начислению зарплаты.

ERD-диаграмма является результатом анализа DFD-диаграммы. При этом первоначально осуществляется анализ хранилища, включающий сравнение содержимого входных и выходных потоков и создание на основе этого сравнения варианта схемы хранилища. Из диаграммы на рис. 3.17 следует, что хранилище должно содержать информацию о всех сотрудниках: имена, адреса, должности, оклады и т.д. Рассмотрим данные и их структуры, содержащиеся во входных и выходных потоках:

Таблица 3.4. Структуры данных для работы бухгалтерии.

ВХОДНЫЕ

СТРУКТУРЫ ДАННЫХ

Нанятые

Дата_найма

Фамилия

таб_номер

адрес

должность

начальная_зарплата

Уволенные

Фамилия

таб_номер

Изменение_адреса

Фамилия

таб_номер

старый_адрес

новый_адрес

Изменение_зарплаты

Фамилия

таб_номер

старая_зарплата

новая_зарплата

дата_изменения

ВЫХОДНЫЕ

СТРУКТУРЫ ДАННЫХ

Адрес_служащего

фамилия

адрес

Подробности_з/пл

фамилия

таб_номер

текущая_зарплата

История_занятости

фамилия

таб_номер

дата_наима

история_карьеры *

     должность

     дата_изменения

история_зарплаты *

     зарплата

Сравнивая входные и выходные структуры данных, отметим следующее:

  •  Поле «адрес» (элемент структуры входного потока «Нанятые») хранит текущий адрес сотрудника, а структура входного потока «Изменение адреса» хранит еще и старый адрес, что не является необходимым, с точки зрения выходных потоков.
  •  Для формирования структуры «История зарплаты» (составной части выходного потока «История занятости»), наоборот, требуется перечислить все оклады сотрудника, поэтому необходимо иметь набор, состоящий из пар («зарплата, дата»), а не просто «старая_зарплата» и «новая_зарплата» (как в структуре входного потока «Изменение зарплаты»).
  •  Аналогичная ситуация и со структурой «Историей карьеры» (другой составной части структуры выходного потока «История занятости»). Отметим, что на диаграмме вообще отсутствует входной поток со структурой данных, определяющей изменения в должности, что является серьезным упущением функциональной модели.
  •  Отметим, что изменение в должности обычно (но не всегда) соответствует изменению в зарплате.

С учётом этих моментов первый вариант схемы хранилища (базы данных) может выглядеть следующим образом:

фамилия

таб_номер

адрес

текущая_зарплата

дата_найма

история_карьеры *

должность

дата_изменения

история_зарплаты *

зарплата

дата_изменения

На следующем шаге осуществляется упрощение схемы за счет устранения избыточности.

Действительно, «текущая_зарплата» всегда является последней записью в «история_зарплата», а «дата_найма» по сути дела всегда содержится в разделах «история_зарплаты» и «история_карьеры». Кроме того, несколько дат в последних разделах одни и те же, поэтому целесообразно создать на их основе единую структуру «история_зарплаты_карьеры» и вводить в нее данные при изменении должности и/или зарплаты. Результатом приведенного рассуждения может быть схема:

фамилия

таб_номер

адрес

история_зарплаты_карьеры *

зарплата

должность

дата_изменения

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

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

сотрудник (таб_номер, фамилия, адрес)

история_зарплаты_карьеры (таб_номер, дата_изменения, должность, зарплата)

Концепции и методы нормализации были разработаны Коддом (Codd), установившим существование трех типов нормализованных схем, названных в порядке уменьшения сложности первой, второй и третьей нормальной формой (соответственно, 1НФ, 2НФ и ЗНФ). Рассмотрим, как преобразовывать схемы к наиболее простой ЗНФ.

Для примера построения ЗНФ предварительно рассмотрим схему, ключ которой выбран в предположении, что заказчик не заказывает одну и ту же книгу дважды в один и тот же день [20]:

заказ_на книгу (имя_заказчика, дата_заказа, ISBN, название, автор, количество, цена, сумма_заказа)

Согласно Кодду, любая нормализованная схема (схема без повторяющихся элементов) автоматически находится в 1НФ независимо от того, насколько сложен ее ключ и какая взаимосвязь существует между ее элементами.

В последней схеме атрибуты «название», «автор», «цена» зависят от части ключа (а именно, от «ISBN»), тогда как атрибут «количество» зависит от всего ключа. Это называется, соответственно, частичной и полной функциональной зависимостью от ключа. По определению схема находится в 2НФ, если она находится в 1НФ и все ее неключевые атрибуты полностью функционально зависят от ключа. Таким образом, для приведения схемы в 2НФ, необходимо избавится от частичной функциональной зависимости. После избавления от нее последняя схема будет выглядеть следующим образом:

заказ_на_книгу (имя заказчика, дата заказа, ISBN, количество, сумма_заказа)

книга (ISBN, автор, название, цена)

Заметим, что возможно упростить ситуацию и дальше: атрибуты «количество» и «сумма_заказа» являются взаимно-зависимыми. По определению схема находится в ЗНФ если она находится в 2НФ и никакой из ее неключевых атрибутов не является зависимым ни от какого другого неключевого атрибута. Поскольку в нашем примере атрибут «сумма_заказа» фактически является избыточным то, для получения ЗНФ, его можно просто удалить.

Иногда для построения ЗНФ необходимо выразить зависимость между неключевыми атрибутами в виде отдельной схемы. Так для сотрудников, работающих по различным проектам, возможна следующая схема [20]:

сотрудник (таб_номер, телефон, почасовая_оплата, N_npoeктa, дата_окончания)

Очевидно, что данная схема находится в 2НФ. Однако «N_npoeктa» и «дата_окончания» являются зависимыми атрибутами. После расщепления схемы получим ЗНФ:

участник проекта (таб_номер, телефон, почасовая_оплата, N_пpoeктa)

проект (N_проекта, дата_окончания)

На практике схемы в форме 1НФ и 2НФ имеют тенденцию возникать при попытке описать несколько реальных сущностей в одной схеме (заказ и книга, проект и сотрудник). ЗНФ является наиболее простым способом представления данных, отражающим здравый смысл. Построив ЗНФ, мы фактически выделяем базовые сущности предметной области.

В завершении данного этапа зафиксируем алгоритм приведения ненормализованных схем в третью нормальную форму [20] (рис. 3.19).

2-й этап построения ERD-диаграммы (модели данных) служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений. На данном этапе некоторые отношения могут быть неспецифическими (n*m – многие-ко-многим). Такие отношения потребуют дальнейшей детализации на этапе 3.

Определение отношений включает выявление связей. Для этого отношение должно быть проверено в обоих направлениях следующим образом: выбирается экземпляр одной из сущностей и определяется, сколько различных экземпляров второй сущности может быть с ним связано, и наоборот. Для примера рассмотрим отношение между сущностями Сотрудник и История_зарплаты_карьеры. У отдельного сотрудника должность и/или зарплата может меняться ноль, один или много раз, порождая соответствующее число экземпляров сущности История_зарплаты_карьеры. Анализируя в другом направлении, видим, что каждый экземпляр сущности История_зарплаты_карьеры соответствует ровно одному конкретному сотруднику. Поэтому между этими двумя сущностями имеется отношение типа 1*n (один ко многим) со связью «один» на конце отношения у сущности Сотрудник и со связью «ноль, один или много» на конце у сущности История_зарплаты_карьеры, что и показано на рис. 3.18.

3-й этап построения ERD-диаграммы (модели данных) предназначен для разрешения неспецифических (многие ко многим) отношений. Для этого каждое неспецифическое отношение преобразуется в два специфических отношения с введением новых (а именно, ассоциативных) сущностей. Рассмотрим пример из работы [20], представленный на рисунке 3.20.

Неспецифическое отношение на рис 3.20 указывает, что Студент может изучать много Предметов, а Предмет может изучаться многими Студентами. Однако мы не можем определить, какой студент изучает какой предмет, пока не введем для разрешения этого неспецифического отношения третью (ассоциативную) сущность Изучение_предмета. Каждый экземпляр введенной сущности связан с одним Студентом и с одним Предметом.

Таким образом, ассоциативные сущности по своей природе являются представлениями пар реальных объектов и обычно появляются на этапе 3.

В заключении отметим, что нотация Баркера являются самой распространенной при построении ERD-диаграмм и используется в Сase-средстве Oracle Designer.

3.1.3. Диаграммы переходов состояний

Диаграммы переходов состояний (STD) предназначены для моделирования и документирования аспектов систем, зависящих от времени или реакции на событие. Они позволяют осуществлять декомпозицию управляющих процессов и описывают отношения между входными и выходными управляющими потоками для управляющего процесса-предка.

С помощью STD-диаграмм можно моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования. Моделируемая система в любой заданный момент времени находится точно в одном из конечного множества состояний. С течением времени она может изменить свое состояние, при этом переходы между состояниями должны быть точно определены. STD-диаграмма состоит из следующих объектов [20]:

Состояние – набор характеристик, описывающих условия устойчивости системы. Находясь в определенном состоянии и имея информацию о прошлой истории системы, можно определить очередное состояние в зависимости от текущих входных событий (потоков). Имя состояния должно отражать реальную ситуацию, в которой находится система, например, Нагревание, Охлаждение и т.п.

Начальное состояние – узел STD-диаграммы, являющийся стартовой точкой для начального системного перехода. STD-диаграмма имеет ровно одно начальное состояние, соответствующее состоянию системы после ее инсталляции (внедрения), но перед началом реальной работы, а также любое (конечное) число завершающих состояний.

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

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

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

«Введенная карта» = true, где Введенная карта – выходной поток управляющего процесса-предка.

Кроме того, для спецификации А-, Т-, E/D-потоков (см. табл. 3.1) имя запускаемого или переключаемого процесса также должно заключаться в кавычки, например:

А: «Получить пароль» – активировать процесс Получить пароль.

Фактически  условие есть некоторое внешнее или внутреннее событие, которое система способна обнаружить и на которое она должна отреагировать определенным образом, изменяя свое состояние. При изменении состояния система обычно выполняет одно или более действий (например, для информационной системы: производит вывод, выдает сообщение на терминал, выполняет вычисления). Таким образом, действие представляет собой отклик, посылаемый во внешнее окружение, или вычисление, результаты которого запоминаются в системе (обычно в хранилищах данных, представленных на DFD-диаграмме, структура и содержание которых представлены на ERD-диаграмме), для того, чтобы обеспечить реакцию на некоторые из планируемых в будущем событий.

На STD-диаграмме состояния представляются узлами, а переходы – дугами (рис. 3.21). Условия (по-другому называемые стимулирующими событиями) идентифицируются именем перехода и возбуждают его выполнение. Действия или отклики на события привязываются к переходам и записываются под соответствующим условием. Начальное состояние на диаграмме должно иметь входной переход, изображаемый потоком из подразумеваемого стартового узла (иногда этот стартовый узел изображается небольшим квадратом и привязывается к входному состоянию).

При построении STD-диаграммы рекомендуется [20] следовать перечисленным ниже правилам:

  •  строить STD-диаграмму на как можно более высоком уровне детализации DFD-диаграммы;
  •  строить как можно более простые STD-диаграммы;
  •  по возможности детализировать STD-диаграммы;
  •  использовать те же принципы именований состояний, событий и действий, что и при именовании процессов и потоков.

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

  •  все ли состояния определены и имеют уникальное имя?
  •  все ли состояния достижимы?
  •  все ли состояния имеют выход?
  •  (для каждого состояния) реагирует ли система соответствующим образом на все возможные условия (особенно на ненормальные)?
  •  все ли входные (выходные) потоки управляющего процесса отражены в условиях (действиях) на STD-диаграмме?

В качестве примера рассмотрим диаграмму переходов состояний для системы управления лифтом (рис. 3.22). Для этого используем DFD-диаграммы этой системы (рис. 3.2 – 3.7).

В ситуации, когда число состояний и/или переходов велико, для проектирования STD-диаграммы могут использоваться таблицы или матрицы переходов состояний. Обе эти нотации позволяют зафиксировать ту же самую информацию, что и диаграммы переходов состояний, но в другом формате.

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

В завершении рассмотрения технологии 3VM следует отметить, что описанные три вида диаграмм и набор дополнительных средств позволяют комплексно визуализировать, формализовать и документировать процессы и потоки в исследуемой системе. Данная технология является весьма полезным средством, однако, только в том случае, если в дальнейшем планируется автоматизация и разработка программных средств методами и языками процедурного программирования.

Таблица 3.5. Матрица переходов состояний ECS.

Занят (движется)

Остановлен

Пуст (стоит)

Перегружен (стоит)

Занят (движется)

прибытие на незапланированный этаж

прибытие на запланированный этаж

Остановлен

лифт готов к движению, «кнопки назначения нажаты»

лифт готов к движению, но кнопки не нажаты

«лифт перегружен»

Пуст (стоит)

«лифт вызван с другого этажа»

«лифт вызван с текущего этажа»

Перегружен (стоит)

«нет перегрузки»

Лифт готов, но перегружен

Отсутствие средств представления характеристик объектов, реализующих процессы и потоки, делает невозможным применение данной технологии при объектно-ориентированной разработке информационной системы.

Выводы

  1.  Для решения сложных проблем используются методы системного анализа, предоставляющие в распоряжение аналитика визуальные графоаналитические средства для построения моделей бизнес-систем и бизнес-процессов.
  2.  Технология системно-структурного анализа 3VM позволяет представить модель системы в виде трех взаимосвязанных диаграмм: функциональной (потоков данных – DFD), информационной (сущность-связь – ERD), динамической (переходов состояний – STD).
  3.  Данная технология является весьма полезным средством в случае автоматизации и разработки программных средств методами и языками процедурного программирования. Применение данной технологии при объектно-ориентированной разработке информационной системы нецелесообразно.

3.2. Стандарты системного моделирования и анализа серии «Icam DEFinition»

3.2.1. Стандарт функционального моделирования IDEF0

Далее рассмотрим стандартные методы системного структурного анализа, описанные серией федеральных стандартов США «Icam Definition», в соответствии с [19, 20, 46 - 48, 98, 99]. Подробную информацию по всем стандартам этой серии можно найти на сайте http://www.idef.com.

Стандарт IDEF0 (FIPS183) предназначен для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. Данный документ представляет собой оформление (по инициативе Министерства обороны США) в виде стандарта технологии анализа сложных систем SADT (Structured Analysis and Design Technique), разработанной группой американских аналитиков во главе с Дугласом Россом в 1973 году.

Метод, предлагаемый стандартом IDEF0, предназначен для функционального моделирования, то есть моделирования выполнения функций объекта, путем создания описательной графической модели, показывающей что, как и кем делается в рамках функционирования предприятия. Функциональная модель представляет собой структурированное изображение функций производственной системы или среды, информации и объектов, связывающих эти функции. Модель строится методом декомпозиции: от крупных составных структур к более мелким, простым. Элементы каждого уровня декомпозиции представляют собой действия по переработке информационных или материальных ресурсов при определенных условиях с использованием заданных механизмов. Каждое действие раскладывается на более мелкие операции по переработке определенной части информационных или материальных ресурсов при определенных условиях с использованием части заданных механизмов. Аналогично раскладываются операции. Последний шаг декомпозиции должен приводить к получению модели, степень детализации которой удовлетворяет требованиям, заданным в самом начале процесса создания модели.

Методология IDEF0 основана на следующих положениях:

  1.  Система и модель. Модель – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. М моделирует А, если М отвечает на вопросы относительно А. Здесь М – модель, А – моделируемый объект (оригинал). Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию. Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит.
  2.  Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме (чаще говорят SADT-диаграмме), основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась.
  3.  Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила описываются ниже с точки зрения технологии SADT. Здесь отмечается только основное из них: все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации.
  4.  Итеративное моделирование. Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования.
  5.  Отделение «организации» от «функций». При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы). Это помогает избежать субъективной точки зрения, навязанной организацией и ее руководством. Организационная структура должна явиться результатом использования (применения) модели. Сравнение результата с существующей структурой позволяет, во-первых, оценить адекватность модели, а во-вторых – предложить решения, направленные на совершенствование этой структуры.

Примеры задач, решаемых на основе методологии моделирования IDEF0:

  •  Анализ и реинжиниринг бизнес-процессов.
  •  Разработка информационной системы управления данными о качестве.
  •  Разработка регламентов и процедур обеспечения качества продукции и создания систем обработки данных о качестве. Функциональная модель позволяет заменить традиционные руководства по качеству в виде описательных текстовых бумажных документов – стандартизованными электронными моделями, целостность и непротиворечивость которых поддерживается автоматически. При необходимости из них всегда можно получить бумажный отчет в привычном виде.
  •  Проектирование информационной инфраструктуры, процедур и регламентов информационного взаимодействия.
  •  Задачи анализа рисков в плане информационной безопасности.

Рассмотрим в соответствии с работой [47] принципы построения диаграмм по технологии SADT (IDEF0).

Графический язык SADT прост и гармоничен. В основе методологии лежат четыре основных понятия.

Первым из них является понятие «функциональный блок». Функциональный блок графически изображается в виде прямоугольника (см. рис. 3.23) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»). Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом: верхняя сторона имеет значение «управление» (control); левая сторона имеет значение «вход» (input); правая сторона имеет значение «выход» (output); нижняя сторона имеет значение «механизм» (mechanism). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Вторым «китом» методологии SADT является понятие «интерфейсная дуга». Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование. По требованию стандарта, наименование должно быть оборотом существительного.

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

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

Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.

При построении SADT-диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто, так как имеется сходство природы входящих и управляющих интерфейсных дуг. Однако, для систем одного класса всегда есть определенные разграничения. Например, в случае рассмотрения предприятий и организаций существуют пять основных видов объектов: материальные потоки (детали, товары, сырье и т.д.), финансовые потоки (наличные и безналичные, инвестиции и т.д.), потоки документов (коммерческие, финансовые и организационные документы), потоки информации (информация, данные о намерениях, устные распоряжения и т.д.) и ресурсы (сотрудники, станки, машины и т.д.). При этом в различных случаях входящими и исходящими интерфейсными дугами могут отображаться все виды объектов, управляющими только относящиеся к потокам документов и информации, а дугами-механизмами только ресурсы.

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

Модель SADT всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0».

В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы в виде краткого описания и зафиксирована точка зрения. Определение и формализация цели разработки SADT-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если мы моделируем деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которую бы мы разрабатывали для того же самого предприятия, но уже с целью оптимизации логистических цепочек. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что в конечном итоге, финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней по отношению к ней (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком). В свою очередь, функциональный блок-предок называется родительским блоком по отношению к дочерним блокам, а диаграмма, к которой он принадлежит – родительской диаграммой. Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность SADT-модели.

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот – отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую «деталь» на входе в функциональный блок «Обработать на токарном станке» не имеет смысла отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в технологии SADT предусмотрено понятие «туннелирование». Обозначение «туннеля» в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока-приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля».

Последним из специфических понятий SADT является понятие «глоссарий». Для каждого из элементов SADT-диаграмм: функциональных блоков, интерфейсных дуг – существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Набор, называемый глоссарием, является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Если технологию SADT рассматривать как аналог технологии DFD, то глоссарий будет выполняет роль словаря данных, используемого при построении DFD-диаграммы.

Обычно SADT-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:

  •  ограничение количества функциональных блоков на диаграмме тремя-шестью. Верхний предел (шесть) заставляет разработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание;
  •  ограничение количества подходящих к одному функциональному блоку интерфейсных дуг четырьмя.

Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, они являются весьма практичными в реальной работе.

Технология SADT содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов [47]:

  •  Создание черновика модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах SADT (IDEF0) называется авторами. Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик модели.
  •  Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах SADT (IDEF0) – читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
  •  Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.

Примеры контекстных SADT-диаграмм и их декомпозиции, подготовленный с применением инструментального пакета BPwin, представлен на рисунках 3.24 – 3. 28.

Наглядность графического языка SADT делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем, на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений на предприятии (в системе).

3.2.2. Стандарт информационного моделирования IDEF1

Стандарт IDEF1 (FIPS 184) предназначен для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы.

Рассмотрим особенности данного стандарта, используя работу [48].

Деятельность любого предприятия можно представить как непрерывное изменение состояния физических и интеллектуальных объектов, имеющих отношение к предприятию, таких как сотрудники, средства производства, производимые продукты, идеи, финансы и т.д. Для эффективного менеджмента этим процессом, каждое изменение того или иного объекта должно иметь свое документальное отображение. Этими отображениями служат личные дела сотрудников, отчеты, рекламная продукция, служебные записки и т.д. Их совокупность называется информационной областью предприятия. Движение информации (например, документооборот) и изменение ее называется информационными потоками. Очевидно, что любому бизнес-процессу, а также любому изменению физических объектов должен соответствовать определенный информационный поток. Более того, руководство, при построении планов развития и управлении деятельностью предприятия, (издавая приказы, распоряжения и т.д.), фактически руководствуется информационными потоками и вносит в них изменения, осуществляя информационный менеджмент.

Стандарт IDEF1 был разработан как инструмент анализа взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия. Целью подобного исследования является структуризация и, при необходимости, дополнение существующей информации, а также обеспечение качественного управления информационными потоками. Необходимость в подобной реорганизации информационной области, как правило, возникает на начальном этапе построения корпоративной информационной системы и методология IDEF1 позволяет наглядно обнаружить слабые места в существующей структуре информационных потоков. Применение IDEF1, как инструмента построения наглядной модели информационной структуры предприятия по принципу «Как должно быть», позволяет решить следующие задачи [48]:

  •  Выяснить структуру и содержание существующих потоков информации на предприятии.
  •  Определить какие проблемы, выявленные в результате функционального анализа и анализа потребностей, вызваны недостатком управления соответствующей информацией.
  •  Выявить информационные потоки, требующие дополнительного управления для эффективной реализации модели.

С помощью IDEF1 происходит изучение существующей информации о различных объектах в области деятельности предприятия. Характерно то, что IDEF1-модель включает в рассмотрение не только автоматизированные компоненты, базы данных и соответствующую им информацию, но также и реальные объекты, такие как сами сотрудники, кабинеты, телефоны и т.д. Назначение методологии IDEF1 состоит в том, чтобы выявить и четко постулировать потребности в информационном менеджменте в рамках деятельности предприятия. В отличие от методов разработки структур баз данных (например, IDEF1X или ERD-диаграмм), IDEF1 является аналитическим методом и используется преимущественно для выполнения следующих действий [48]:

  •  Определения самой информации и структуры ее потоков, имеющей отношение к деятельности предприятия.
  •  Определения существующих правил и законов, по которым происходит движение информационных потоков, и принципов управления ими.
  •  Выяснения взаимосвязей между существующими информационными потоками в рамках предприятия.
  •  Выявления проблем, возникающих вследствие недостатка качественного информационного менеджмента.

Результаты анализа информационных потоков могут быть использованы для стратегического и тактического планирования деятельности предприятия и улучшения информационного менеджмента. Однако основной целью использования методологии IDEF1 все же остается исследование движения потоков информации и принципов управления ими на начальном этапе процесса проектирования корпоративной информационно-аналитической системы, которая будет способствовать более эффективному использованию информационного пространства. Наглядные модели IDEF1 обеспечивают базис для построения мощной и гибкой информационной системы.

Методология IDEF1 позволяет на основе простых графических изображений моделировать информационные взаимосвязи между:

  •  реальными объектами;
  •  физическими и абстрактными зависимостями, существующими среди реальных объектов;
  •  информацией, относящейся к реальным объектам;
  •  структурой данных, используемой для приобретения, накопления, применения и управления информацией.

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

При построении информационной модели проектировщик всегда оперирует с двумя основными глобальными областями, каждой из которой соответствует множество характерных объектов. Первой из этих областей является реальный мир, т.е. совокупность физических и интеллектуальных объектов таких, как люди, места, вещи, идеи и т.д., а также все свойства этих объектов и зависимости между ними. Второй же является информационная область. Она включает в себя существующие информационные отображения объектов первой области и их свойств. Информационное отображение, по существу, не является объектом реального мира, однако изменение его, как правило, является следствием некоторого изменения соответствующего ему объекта реального мира. Методология IDEF1 разработана как инструмент для исследования статического соответствия вышеуказанных областей и установления строгих правил и механизмов изменения объектов информационной области при изменении соответствующих им объектов реального мира.

Центральным понятием методологии IDEF1 является понятие сущности. При этом IDEF1 разделяет элементы структуры информационной области, их свойства и взаимосвязи на классы. Класс сущностей представляет собой совокупность информации, накопленной и хранящейся в рамках предприятия и соответствующей определенному объекту или группе объектов реального мира. Основными концептуальными свойствами сущностей в IDEF1 являются:

  •  Уникальность. Любая сущность может быть однозначно идентифицирована из другой сущности.
  •  Устойчивость. Информация, имеющая отношение к той или иной сущности постоянно накапливается.

Каждая сущность имеет своё имя и атрибуты. Атрибуты представляют собой характерные свойства и признаки объектов реального мира, относящихся к определенной сущности. Класс атрибутов представляет собой набор пар, состоящих из имени атрибута и его значения для определенной сущности. Атрибуты, по которым можно однозначно отличить одну сущность от другой называются ключевыми атрибутами. Каждая сущность может характеризоваться несколькими ключевыми атрибутами. Класс взаимосвязей в IDEF1 представляет собой совокупность взаимосвязей между сущностями. Взаимосвязь между двумя отдельными сущностями считается существующей в том случае, если класс атрибутов одной сущности содержит ключевые атрибуты другой сущности. Имя взаимосвязи всегда выражается в глагольной форме. Если же между двумя или несколькими объектами реального мира не существует установленной зависимости, то, с точки зрения IDEF1, между соответствующими им сущностями взаимосвязь также отсутствует. Каждый из вышеописанных классов имеет свое условное графическое отображение.

На рис. 3.29 приведен пример IDEF1-диаграммы. На ней представлены две сущности с именами «Подразделение ресторана» и «Сотрудник» и взаимосвязь между ними с именем «Работает в».

На рис. 3.30 показан пример анализа взаимосвязи информации при принятии заказа клиента официантом в ресторане.

3.2.3. Стандарт моделирования баз данных IDEF1X

Стандарт IDEF1 является методом изучения и анализа информации, в отличие от очень сходного по терминологии и семантике стандарта IDEF1X (в рамках которого используются ERD-диаграммы), предназначенного для разработки реляционных баз данных. IDEF1X создан на основе совершенствования стандарта IDEF1 с учетом таких требований, как простота для изучения и возможность автоматизации. IDEF1X-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF). В стандарте IDEF1X, кроме того, уточнены основные понятия ERD-диаграмм.

Сущность (Entity) – множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:

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

Каждая сущность может обладать любым количеством связей с другими сущностями модели.

Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь – это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.

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

Сущность является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 3.31, 3.32). Каждой сущности присваиваются уникальные имя и номер, разделяемые косой чертой «/» и помещаемые над блоком.

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей:

  •  каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка;
  •  каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
  •  каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
  •  каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае – неидентифицирующей. Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка (рис. 3.33). Мощность связей может принимать следующие значения: N – ноль, один или более, Z – ноль или один, Р – один или более. По умолчанию мощность связей принимается равной N.

Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).

Пунктирная линия изображает неидентифицирующую связь (рис. 3.34). Сущность-потомок в неидентифицирующей связи будет не зависимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (рис. 3.34). Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена атрибутов, после которых следуют буквы FK в скобках (рис. 3.34).

3.2.4. Стандарт моделирования сценариев IDEF3.

Стандарт IDEF3 предназначен для документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев.

Рассмотрим особенности данного стандарта, используя работу [48].

Сценарием называется описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление о его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

  •  Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса.
  •  Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов.
  •  Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта.
  •  Содействовать принятию оптимальных решений при реорганизации технологических процессов.
  •  Разрабатывать имитационные модели технологических процессов, по принципу «Как будет если...».

Существуют два типа диаграмм в стандарте IDEF3, представляющих описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams – PFDD), а ко второму – диаграммами Состояния Объекта в Процессе его Трансформации (Object State Transition Network – OSTN).

Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD (см. рис. 3.35 и [48]) документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN (см. рис. 3.36 и [48]) используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.

На рис. 3.35 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее на дальнейшую обработку. Прямоугольники на диаграмме PFDD называются функциональными элементами, единицами работы или элементами поведения (Unit of Behavior – UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки являются отображением перемещения детали между UOB-блоками в ходе процесса. Они бывают следующих видов:

  •  Предшествование – сплошная одинарная стрелка, связывающая UOB в соответствии с последовательностью выполнения работ. Рисуется слева направо или сверху вниз.
  •  Отношение – пунктирная одинарная стрелка, использующаяся для изображения различного вида связей между UOB.
  •  Поток объектов – сплошная стрелка с двумя наконечниками, используемая для описания того факта, что объект, порождаемый одной работой, используется для выполнения другой.

Объект, обозначенный J1 – называется перекрестком (junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (fan-in junction) и разветвления (fan-out junction) стрелок. Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J». Классификация возможных типов перекрестков приведена в таблице 3.6.

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией понимается представление каждого UOB с помощью отдельной IDEF3 диаграммы.

Таблица 3.6.  Возможные перекрестки в стандарте IDEF3.

Обозначе-ние

Наименова-ние

Слияние стрелок (Fan-in Junction)

Разветвление стрелок (Fan-out Junction)

Asynchronous AND

Все предшествующие процессы должны быть завершены.

Все следующие процессы должны быть запущены.

Synchronous AND

Все предшествующие процессы завершены одновременно.

Все следующие процессы запускаются одновременно.

Asynchronous OR

Один или несколько предшествующих процессов должны быть завершены.

Один или несколько следующих процессов должны быть запущены.

Synchronous OR

Один или несколько предшествующих процессов завершаются одновременно.

Один или несколько следующих процессов запускаются одновременно.

XOR Exclusive OR)

Только один предшествующий процесс завершен.

Только один следующий процесс запускается.

Например, можно декомпозировать UOB «Окрасить деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рисунке, а та, соответственно, родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1», «1.2» и т.д.

Если диаграммы PFDD представляет технологический процесс «c точки зрения наблюдателя», то другой класс диаграмм IDEF3 – OSTN позволяет рассматривать тот же самый процесс «c точки зрения объекта». Состояния объекта (в данном случае детали, см. рис. 3.36) и Изменение состояния являются ключевыми понятиями OSTN-диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными одинарными стрелками. Каждая стрелка имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ею изменение состояния объекта. Таким образом, OSTN-диаграмма представляет собой аналог STD-диаграммы технологии 3VM.

С точки зрения основного примера, рассматриваемого в данном разделе (ресторана), стандарт IDEF3 является удобным средством анализа и документирования процессов (сценариев) приема гостей в различных ситуациях (например: ресторан «fast food» или вечерний ресторан; обычный обед/ужин, заказанное мероприятие, праздничный ужин, завтрак), а также технологических процессов приготовления различных блюд. На рисунках 3.37 и 3.38 представлен пример сценария приема гостей в вечернем ресторане при обслуживании обычного обеда/ужина (подготовлен с помощью BPwin (IDEF3)).

3.2.5. Стандарт моделирования онтологий IDEF5

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

Однако фундаментальные и естественные науки не обладают достаточным инструментарием для того, чтобы полностью охватить область, представляющую интерес для онтологического исследования. Например, существует большое количество сложных формаций или систем, созданных и поддерживаемых человеком, таких как производственные фабрики, военные базы, коммерческие предприятия и т.д. Эти формации представляют собой совокупность взаимосвязанных между собой объектов и процессов, в которых эти объекты тем или иным образом участвуют. Онтологическое исследование подобных сложных систем позволяет накопить ценную информацию об их работе, результаты анализа которой будут иметь решающее значение при проведении процесса реорганизации существующих и построении новых систем.

Методология IDEF5 обеспечивает наглядное представление данных, полученных в результате обработки онтологических знаний, в простой естественной графической форме.

Рассмотрим особенности данного стандарта, используя работу [48].

Онтологический анализ обычно начинается с составления словаря терминов, который используется при обсуждении и исследовании характеристик объектов и процессов, составляющих рассматриваемую систему, а также создания системы точных определений понятий, соответствующих этим терминам. Кроме того, документируются основные логические взаимосвязи между понятиями. Результатом этого анализа является онтология системы или же совокупность терминов, точных определений их понятий и взаимосвязей между ними.

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

В любой системе существует две основные категории предметов: сами объекты, составляющие систему (физические и интеллектуальные) и взаимосвязи между этими объектами. В терминах онтологии, понятие взаимосвязи однозначно описывает или, другими словами, является точным дескриптором зависимости между объектами системы в реальном мире, а термины – являются, соответственно, точными дескрипторами самих реальных объектов.

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

Процесс построения онтологии, согласно методологии IDEF5 состоит из пяти основных действий:

  1.  Изучение и систематизирование начальных условий. В рамках этого действия устанавливаются основные цели и контексты проекта по разработке онтологии, а также распределяются роли между членами проекта.
  2.  Сбор и накапливание данных. На этом этапе происходит сбор и накапливание необходимых начальных данных для построения онтологии.
  3.  Анализ данных. Эта стадия заключается в анализе и группировке собранных данных и предназначена для облегчения построения терминологии.
  4.  Начальное развитие онтологии. На этом этапе формируется предварительная онтология, на основе отобранных данных. Создается и документируется словарь терминов. Описываются правила и ограничения, согласно которым на базе введенной терминологии могут быть сформированы достоверные утверждения, описывающие состояние системы.
  5.  Уточнение и утверждение онтологии. Заключительная стадия процесса. Построение модели, которая на основе существующих утверждений, позволяет формировать необходимые новые утверждения.

Для поддержания процесса построения онтологий в IDEF5 существуют специальные онтологические языки: схематический язык (Schematic Language – SL) и язык доработок и уточнений (Elaboration Language – EL). SL является наглядным графическим языком, специально предназначенным для изложения компетентными специалистами в рассматриваемой области системы основных данных в форме онтологической информации (рис. 3.39).

Этот несложный язык позволяет естественным образом представлять основную информацию в процессе развития онтологии и дополнять существующие онтологии новыми данными. Язык SL позволяет строить разнообразные типы диаграмм и схем в IDEF5. Основная цель всех этих диаграмм – наглядно и визуально представлять основную онтологическую информацию. EL представляет собой структурированный текстовой язык, который позволяет детально характеризовать элементы онтологии.

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

Как правило, наиболее важные и заметные зависимости между объектами всегда являются преобладающими, когда конкретные люди высказывают свои знания и мнения, касающиеся той или иной системы. Подобные взаимосвязи явным образом описываются языками IDEF5. Всего существует четыре основных вида схем, которые наглядно используются для накопления информации об онтологии в достаточно прозрачной графической форме.

  1.  Диаграмма классификации. Диаграмма классификации обеспечивает механизм для логической систематизации знаний, накопленных при изучении системы. Существует два типа таких диаграмм: диаграмма строгой классификации (Description Subsumption – DS) и диаграмма естественной или видовой классификации (Natural Kind Classification – NKC). Основное отличие диаграммы DS заключается в том, что определяющие свойства классов высшего и всех последующих уровней являются необходимым и достаточным признаком принадлежности объекта к тому или иному классу. На рисунке 3.40 приведен пример такой диаграммы, построенной на основе тривиальной возможности классификации многоугольников по количеству углов. Из геометрии известно точное математическое определение многоугольника, суть определяющих свойств родительского класса. Определяющим свойством каждого дочернего класса дополнительно является количество углов в многоугольнике. Очевидно, зная это определяющее свойство для любого многоугольника, можно однозначно отнести его к тому или иному дочернему классу. С помощью диаграмм DS, как правило, классифицируются логические объекты. Диаграммы естественной классификации или же диаграммы NKC, наоборот, не предполагают того, что свойства класса являются необходимым и достаточным признаком для принадлежности к ним тех или иных объектов. В этом виде диаграмм определение свойств класса является более общим. Пример такой диаграммы также приведен на рис. 3.40.

  1.  Композиционная схема. Композиционные схемы (Composition Schematic) являются механизмом графического представления состава объектов онтологии и фактически представляют собой инструменты онтологического исследования по принципу «Что из чего состоит». В частности, композиционные схемы позволяют наглядно отображать состав объектов, относящихся к тому или иному классу. На рисунке 3.41 изображена композиционная схема шариковой ручки, относящейся к классу шариковых автоматических ручек. В данном случае шариковая ручка является системой, к которой мы применяем методы онтологического исследования. С помощью композиционной схемы мы наглядно документируем, что авторучка состоит из нижней и верхней трубки, нижняя трубка в свою очередь включает в себя кнопку и фиксирующий механизм, а верхняя трубка включает в себя стержень и пружину.
  2.  Схема взаимосвязей. Схемы взаимосвязей (Relation Schematic) позволяют разработчикам визуализировать и изучать взаимосвязи между различными классами объектов в системе. В некоторых случаях схемы взаимосвязей используются для отображения зависимостей между самими же классовыми взаимосвязями. Мотивацией для развития подобной возможности послужило то тривиальное правило, что все вновь разработанные концепции всегда базируются на уже существующих и изученных. Это тесно согласуется с теорией, суть которой состоит в том, что изучение любой системы часто происходит от частного к общему, то есть, происходит изыскание и исследование новой частной информации, влияющее на конечные характеристики более общей концепции, к которой эта информация имела прямое отношение. Исходя из этой гипотезы, естественным способом изучения новой или плохо понимаемой взаимосвязи является соотнесение ее с достаточно изученной взаимосвязью.
  3.  Диаграмма состояния объекта. Диаграмма состояния объекта (Object State Schematic) позволяет документировать тот или иной процесс с точки зрения изменения состояния объекта. В происходящих процессах могут произойти два типа изменения объекта: объект может поменять свое состояние или класс. Между этими двумя видами изменений по сути не существует принципиальной разницы: объекты, относящиеся к определенному классу в начальном состоянии в течение процесса могут перейти к дочернему или просто родственному классу. Например, полученная в процессе нагревания теплая вода, уже относится не к классу ВОДА, а к его дочернему классу ТЕПЛАЯ ВОДА. Однако при формальном описании процесса, во избежание путаницы, целесообразно разделять эти виды изменений и для такого разделения используется обозначение следующего вида: «класс: состояние». Например, теплая вода будет описываться следующим образом: «вода: теплая», холодная – «вода: холодная» и так далее. Таким образом, диаграммы состояния в IDEF5 наглядно представляют изменения состояния или класса объекта в течение всего процесса. Пример такой диаграммы приведен на рис. 3.42.

Суммируя вышеизложенное, отметим, что строение и свойства любой системы могут быть эффективно исследованы и задокументированы при помощи следующих средств: словаря терминов, используемых при описании характеристик объектов и процессов, имеющих отношение к рассматриваемой системе, точных и однозначных определений всех терминов этого словаря и классификации логических взаимосвязей между этими терминами. Набор этих средств, по сути, и является онтологией системы, а стандарт IDEF5 предоставляет структурированную графоаналитическую методологию, с помощью которой можно наглядно и эффективно разрабатывать, поддерживать и изучать эту онтологию.

Онтология ресторанного бизнеса может быть представлена с помощью средств, предлагаемых стандартом IDEF5, например, следующим образом. На рисунке 3.43 представлена композиционная схема ресторана. На рисунке 3.44 представлена диаграмма классификации (NKC) видов информации, необходимой для функционирования ресторана.

Схема взаимосвязей может быть составлена как для классов представленных в композиционной схеме, так и для классов представленных на диаграмме классификации. Схема взаимосвязей классов информации (см. рис. 3.44) будет подобна диаграмме IDEF1, однако, будет учитывать большее число ее видов.

Диаграмма состояний объекта с точностью до обозначений будет подобна диаграмме OSTN стандарта IDEF3, если в качестве объекта будет выбран посетитель ресторана.

В заключении рассмотрения серии стандартов Icam Definition следует отметить, что упомянутые стандарты представляют собой хорошо структурированную и продуманную аналитическую технологию. Данная серия стандартов аналогична технологии 3VM, однако, является, с одной стороны, более строгой и формализованной, а, с другой стороны, обладающей более широкими возможностями. При этом функционально технология DFD в более формализованном виде и с дополнительными возможностями представлена в стандарте IDEF0 (SADT), технология ERD – в стандарте IDEF1X, технология STD – в стандарте IDEF3 (OSTN-диаграммы). Стандарт же IDEF5 обеспечивает все эти и другие возможности в менее формализованном виде, расширяя, таким образом, сферу применения данной серии стандартов.

Опыт применения технологии Icam Definition показывает, что комплексное использование рассмотренных стандартов позволяет проанализировать систему (предметную область) достаточно целостно. Стандарты данной технологии являются конструктивно дополняющими друг драга частями. Это позволяет при их совместном использовании в рамках итерационного процесса обнаруживать и устранять неточности, ошибки или пропуски информации. Например, при разработке функциональной SADT-модели ресторана, в первоначальном варианте этой модели были пропущены информационные потоки  «меню» и «цены», необходимые для приема заказа от посетителя. Информационный анализ процесса приема заказа с помощью IDEF1-диаграммы позволил выявить и устранить этот пропуск, так как потребовал в явном виде определить все необходимые данные.

 

 

Несмотря на перечисленные достоинства технологии Icam Definition, она обладает всеми недостатками, приведенными при завершении рассмотрения технологии 3VM.

Выводы

  1.  Для решения сложных проблем используются методы анализа, предоставляющие в распоряжение аналитика визуальные графоаналитические средства для построения моделей бизнес-систем и бизнес-процессов.
  2.  Технология системно-структурного анализа, представленная несколькими стандартами серии Icam Definition, аналогична технологии 3VM. При этом DFD-даграммы в более формализованном виде и с дополнительными возможностями соответствуют стандарту функционального моделирования IDEF0 (SADT), ERD-диаграммы – стандарту информационного моделирования IDEF1, STD-диаграммы – стандарту моделирования сценариев IDEF3 (OSTN-диаграммы).
  3.  Стандарт же онтологического моделирования IDEF5 обеспечивает все эти и другие возможности в менее формализованном виде. Комплексное использование рассмотренных стандартов позволяет проанализировать систему (предметную область) достаточно целостно. Недостатки данной технологии аналогичны технологии 3VM.

3.3. CASE-инструментарий системного моделирования и анализа

3.3.1. Назначение и возможности «AllFusion Process Modeler/BPwin»

Реорганизация или реинжиниринг бизнес-процессов уже довольно давно является отдельной дисциплиной; в этой области рынка работает множество компаний, услуги которых весьма ценятся. С точки зрения профессионалов, ключевым моментом успеха проекта по реорганизации является коммуникация между всеми группами лиц, заинтересованных в выполнении задачи. Это взаимодействие достигается посредством составления различных моделей, которые отображают бизнес-процессы и понятны всем участникам проекта. Одновременно модель служит для формализации и документирования существующего состояния дел и изучения возможностей улучшения работы [100].

На рынке существует несколько технологий, которые предназначены для моделирования бизнес-процессов и позволяют облегчить обмен информацией. Инструменты для разработки, моделирования и анализа получили название CASE-средств. Понятие CASE-средства охватывает самые различные инструменты, которые служат для компьютерного анализа и моделирования, и инструменты для анализа бизнес-процессов представляют собой лишь небольшую часть всего семейства. Однако именно изучение бизнес-процессов является ключевым моментом при разработке любого приложения и позволяет четко и однозначно определить задачи, которые стоят перед разработчиками. Таким образом, инструменты анализа бизнес-процессов, кроме решения основной задачи, являются также неотъемлемой частью начального этапа разработки жизнеспособной информационной системы [100].

В качестве примера инструмента моделирования и анализа бизнеса рассмотрим (используя работы [100103], а также сайт компании «Interface Ltd.») широко распространенный пакет BPwin или, как теперь он называется, AllFusion Process Modeler (производитель компания «Computer Associates»).

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

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

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

С помощью BPwin пользователь может сделать свою работу более продуктивной. Действия и другие объекты создаются буквально несколькими щелчками мыши, а затем легко отбуксированы в нужное место. Интерфейс BPwin, выполненный в стиле «проводника» облегчает навигацию и редактирование сложных процессов с иерархической структурой. Развитые возможности изменения масштаба представления позволяют быстро найти и сосредоточиться на необходимой для работы части модели процесса.

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

BPwin имеет широкие возможности по представлению диаграмм. Графическое представление модели может быть изображено при помощи различных цветов, шрифтов и прочих параметров представления, которые выделяют важные или, наоборот, тушируют незначительные аспекты модели. Эта незначительная на первый взгляд возможность является ключевой во время представления и обсуждения модели с заказчиком или экспертами предметной области, т.к. правильно подобранное графическое представление позволяет им быстрее сориентироваться в модели [100].

BPwin автоматизирует решение многих вспомогательных задач, которые обычно связаны с построением модели процесса, и обеспечивает логическую строгость, необходимую для достижения корректных и согласованных результатов. BPwin отслеживает связи в диаграммах, сохраняя их целостность при внесении изменений в модель. Динамическая «подсветка» объектов служит подсказкой при построении модели и предостерегает от повторения распространенных ошибок в моделировании. Кроме этого, BPwin поддерживает заданные пользователем свойства, что позволяет вносить соответствующую вашим потребностям информацию.

BPwin позволяет:

  •  Обеспечить эффективность операций, рассматривая текущие бизнес-операции через мощные инструменты моделирования.
  •  Совершенствовать бизнес-процессы, формулируя и определяя альтернативные реакции на воздействия рынка.
  •  Быстро исключать непродуктивные операции, легко и интуитивно сопоставляя операционные изменения. Неэффективные, неэкономичные или избыточные операции могут быть легко выявлены и, следовательно, улучшены, изменены или вовсе исключены – в соответствии с целями компании.

Различные варианты оформления с гибким использованием шрифтов, цвета и других средств форматирования придают документам большую наглядность. Пользователь может просматривать и распечатывать общее представление своей модели в виде древовидных диаграмм. С помощью средства создания FEO диаграмм (For Exposition Only) вариации модели или проблемной области можно проанализировать, не внося изменений в основную модель. Возможности настройки пользовательских палитр цветов позволяют легко адаптировать вид документов в соответствии с особенностями принтера или демонстрационного проектора без внесения изменений в саму модель.

Функциональность BPwin заключается не только в рисовании диаграмм, но и в проверке целостности и согласованности модели. BPwin обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании, таких, как «зависание» связей при переходе от диаграммы к диаграмме, нарушение ассоциации связей в различных диаграммах модели и т.п. Кроме того, интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели [100].

BPwin позволяет адаптироваться к постоянно меняющимся реалиям современного рынка. Конкуренция предполагает мгновенную реакцию на новые возможности, угрозы и потребности покупателей. Сегодня постоянные изменения стали нормой. Поскольку бизнес-процессы становятся все более сложными, требуются решения, представляющие интегрированный взгляд на функционирование компании. Таким решением и является новый BPwin (или AllFusion Process Modeler).

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

Анализ сложных бизнес-процессов зачастую может потребовать привлечения целого коллектива специалистов. Создание комфортной среды для их работы может быть осуществлено путем масштабирования BPwin для поддержки корпоративных бизнес-моделей за счет интеграции с системой управления моделированием ModelMart. ModelMart поддерживает мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания «компонент» модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на различных платформах [100].

BPwin совмещает в одном инструменте средства моделирования функций (IDEF0), потоков данных (DFD) и потоков работ (IDEF3), координируя эти три основных аспекта бизнеса для соответствия потребностям бизнес-аналитиков и системных аналитиков. BPwin позволяет повторно использовать ключевую информацию моделирования с точки зрения базовых аспектов, чтобы определить точки конфликтов и, в конечном счете, достичь их согласования.

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

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

Моделирование потоков работ или логики выполнения процессов позволяет рассмотреть конкретный процесс, проанализировать операции, из которых он состоит, а также точки принятия решений, влияющих на его ход.

BPwin предоставляет средства для изучения операций и управления операциями на различных уровнях детализации. Например, иногда бывает важно сосредоточиться на определенной части бизнеса организации. BPwin позволяет вам разделить сложный процесс на множество управляемых частей, обеспечивая группам разработчиков модели возможность сосредоточиться на интересующих их аспектах. В итоге, эти различные аспекты могут быть согласованы и объединены, чтобы составить единый, целостный взгляд на ваше предприятие. BPwin позволяет вам объединить раздельные модели в единую согласованную модель и достигнуть согласования проекта. BPwin помогает вам понять общее влияние изменений на существующие бизнес-процессы, обеспечивая быструю и эффективную адаптацию.

Встроенный механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности Механизм вычисления расходов на основе выполняемых действий (Activity-Based Costing, ABC) – это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа.

Одним из важнейших средств BPwin является генератор отчетов. На деле, генератор отчетов RPTwin представляет собой автономный продукт и позволяет генерировать подробные и многогранные отчеты по модели. Вместе с BPwin устанавливается набор стандартных отчетов, которые позволяют осветить модель с различных сторон. Отчеты обычно сопровождают окончательный вариант модели бизнес-процессов, созданной при помощи BPwin, и содержат информацию, размещение которой на модели сделало бы ее трудной для восприятия. Например, отчет может содержать подробное описание каждого элемента диаграммы, что помогает представить себе назначение данного элемента без дополнительных разъяснений со стороны системного аналитика, создававшего диаграмму. Кроме того, существуют отчеты, которые предназначены для самого системного аналитика, например, отчет по целостности модели [100 - 103].

BPwin может генерировать отчеты непосредственно в формате MS Excel и Word для последующей обработки и использования в других приложениях. Связь с ERwin (моделирование данных в стандарте IDEF1X) позволяет сократить время проектирования и разработки сложных информационных систем. Для системных аналитиков тесная интеграция BРwin с инструментом проектирования баз данных открывает уникальные возможности по созданию действительно комплексных систем, в которых ERwin служит для описания информационных объектов системы, в то время как BPwin отражает функциональные особенности предметной области. Связывая сущности и атрибуты модели данных с информацией о выполняемых действиях, можно продолжить анализ процессов на новом уровне с одновременной перекрестной проверкой моделей процессов и данных.

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

3.3.2. Особенности «BPwin»

  •  Интуитивно-понятный графический интерфейс, который быстро и легко осваивается, что позволяет сосредоточиться на анализе самой предметной области, не отвлекаясь на изучение инструментальных средств. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами.
  •  BPwin автоматизирует многие задачи, обычно связанные с построением моделей процессов, обеспечивая семантическую точность, необходимую для гарантии правильных и согласованных результатов. Подсветка объектов упрощает построение модели, исключая часто встречающиеся ошибки моделирования.
  •  BPwin может быть настроен для сбора информации, существенной для кокретного бизнеса. Эта информация становится сразу же доступной через генератор отчетов BPwin и может быть экспортирована в другие программы, например, Microsoft Word и Excel.
  •  BPwin поддерживает диаграммы Swim Lane, предоставляя эффективный механизм для визуализации и оптимизации сложных бизнес-процессов. Диаграммы Swim Lane координируют сложные процессы и функциональные ограничения и позволяют вам видеть процессы, роли и обязанности во всем их многообразии.
  •  Новая структура словаря модели делает ввод и управление информацией быстрым и простым. Этот настраиваемый интерфейс электронных таблиц прост в применении и предоставляет отличный механизм для распространения моделей, независимо от того, вводите вы данные вручную или импортируете их.
  •  Контекстные диаграммы для описания границ системы, области действия, назначения объектов. Иерархическая структура диаграмм, облегчающая последовательное уточнение элементов модели. Декомпозиционные диаграммы для описания особенностей взаимодействия различных процессов. BPwin также поддерживает автоматическую настройку размеров диаграмм и возможность изменения масштабов изображения моделей.
  •  Организационные структуры оказывают огромное влияние на определение и выполнение бизнес-процессов. BPwin поддерживает явное определение ролей, а это определяет и категоризирует задачи или работы, составляющие бизнес-процессы. Основываясь на ролях, определенных пользователем, BPwin формирует организационные диаграммы.
  •  BPwin обеспечивает совместное и повторное использование технологий моделирования бизнес-процессов (IDEF0), потоков работ (IDEF3) и потоков данных (DFD).
  •  BPwin полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (ABC) и оптимизирована для анализа процессов. Развитые средства подготовки отчетов и двунаправленный интерфейс со специализированным инструментарием ABC облегчают реализацию корпоративной стратегии на основе управления хозяйственной деятельностью.
  •  Собственный генератор отчетов. Report Template Builder (RTB) – это новый генератор отчетов, общий для ERwin и BPwin, создающий разнообразные отчеты и Web-страницы. Вы можете определять шаблоны отчетов, применяя их затем к любым своим моделям. Подход «определить однажды – применять повторно и повсюду» позволяет организации быстро создавать и продвигать стандарты отчетности. RTB поддерживает множество форматов, включая RTF, HTML, XLS (Excel) и текст.
  •  Интерфейс к средствам имитационного моделирования. Для моделирования сложных условий деятельности BPwin предлагает интерфейс к имитационному программному обеспечению (например, Arena). Это позволяет использовать готовые модели для изучения изменяющегося во времени (динамического) взаимодействия бизнес-процессов. Распределение ресурсов и потоки могут быть оптимизированы для достижения эффективной загрузки. Имитационное моделирование позволяет в динамике проанализировать воздействие изменений. Прежде чем эти изменения будут произведены, можно проверить различные сценарии и обеспечить тем самым принятие оптимального решения.
  •  Поддерживаемые операционные системы Windows 95 – ХР.

Пакет BPwin интегрирован с другими программными продуктами, дополняющими его функциональные возможности.

ERwin – средство моделирования баз данных №1 в мире. Уникальная особенность BPwin – возможность удостовериться в том, что информационная модель оптимально согласуется с потребностями бизнес-процесса. BPwin обеспечивает двунаправленную синхронизацию с ERwin. Использование BPwin позволяет проверить качество и согласованность моделей данных ERwin, получить важную информацию о том, как и где используются данные, и обеспечить ее доступность в нужный момент и в нужном месте. Такая интеграция гарантирует, что новые распределенные системы и хранилища данных в действительности будут соответствовать потребностям вашего бизнеса.

Для системных аналитиков тесная интеграция BРwin с ERwin открывает возможности по созданию действительно комплексных систем, в которых ERwin служит для описания информационных объектов системы, в то время как BPwin отражает функциональные особенности предметной области. Связывая сущности и атрибуты модели данных с информацией о выполняемых действиях, Вы можете продолжить анализ процессов на новом уровне с одновременной перекрестной проверкой моделей процессов и данных.

ModelMart – среда для работы группы проектировщиков над одним проектом. Возможности обмена информацией о моделях между BPwin и ERwin еще более расширяются при использовании продукта ModelMart, при этом данные об объектах и атрибутах могут синхронизироваться динамически в процессе моделирования. Информация, переданная в процессе такой синхронизации, может быть обработана развитыми средствами ModelMart для управления изменениями, анализа последствий и формирования отчетов.

AllFusion – линейка продуктов для поддержки всех стадий разработки программного обеспечения. BPwin входит в семейство продуктов AllFusion для поддержки всех стадий жизненного цикла разработки программного обеспечения (аналог Rational Suite). Туда, в частности, входит линейка CASE-средств AllFusion Modeling Suite (ERwin, BPwin, ModelMart, Paradigm Plus, ERwin, Examiner) и средства управления проектами. Совместное применение этих продуктов обеспечивает прочный фундамент для построения, развертывания и управления приложениями. При этом не накладываются ограничения на выбор базовых технологий, методов и платформ разработки. AllFusion предлагает моделирование и управление процессами, проектами, изменениями, конфигурациями.

Paradigm Plus – средство проектирования компонентов программного обеспечения и кодогенерации. BPwin интегрирован с Paradigm Plus – средством моделирования компонентов программного обеспечения и генерации объектного кода на основе созданных моделей. Двусторонняя связь между BPwin и Paradigm Plus позволяет импортировать смоделированные бизнес-процессы в Paradigm Plus как «юз-кейсы» (use cases) и экспортировать «юз-кейсы» в BPwin.

Model Navigator – продукт для просмотра моделей ERwin и BPwin с возможностью генерации отчетов. Зачастую необязательно приобретать много лицензий BPwin, когда кому-то из пользователей требуется лишь просмотр моделей, а не их редактирование. Model Navigator, своеобразный «viewer», обеспечивает динамический просмотр моделей, а также содержит полный спектр средств для формирования отчетов.

Arena – система имитационного моделирования. BPwin имеет интерфейс к средствам имитационного моделирования, ведущим из которых является Arena. Это позволяет использовать готовые модели для изучения изменяющегося во времени (динамического) взаимодействия бизнес-процессов. Распределение ресурсов и потоки могут быть оптимизированы для достижения эффективной загрузки. Имитационное моделирование – создание компьютерной модели системы (физической, технологической, финансовой и т. п.) и проведение на ней экспериментов с целью наблюдения/предсказания. (Подробнее об имитационном моделировании см. на сайте www/interface.ru).

3.3.3. Недостатки инструментария системного моделирования

Анализируя пакет BPwin (и, таким образом, SADT-технологию (стандарт IDEF0), стандарт IDEF3, а также DFD-технологию), следует сказать, что первые стандарты разрабатывались как средства моделирования и анализа любых систем, последняя технология – именно информационных систем. Однако, в настоящее время оказалось, что выразительных средств SADT и IDEF3 недостаточно для моделирования систем информационных, и, кроме того, SADT, IDEF3 и DFD не поддерживают объектно-ориентированного проектирования. В результате данные технологии практически используется относительно редко (менее чем в 10% существующих CASE-средств) [20].

Будучи основанным на системных структурных методах пакет BPwin предусматривает построение двух или трех моделей одного и того же объекта: функциональной (активностной), информационной (данных), а также динамической. Это обстоятельство приводит к необходимости проведения специального сквозного контроля диаграмм одного или разных типов, т.е. соответственно вертикального и горизонтального балансирования диаграмм, для выявления весьма вероятных ошибок [20]. При этом для создания динамических моделей требуется использование дополнительных специальных расширений или других средств, с которыми SADT плохо согласуется [20].

Жесткие искусственные ограничения на число блоков в диаграмме, а также принципиально ограниченное количество типов связей и типов отношений (взаимодействий) между блоками не позволяют гарантировать во всех случаях адекватность модели объекту и затрудняют понимание диаграмм.

Кроме того, изображение функциональных связей каждого элемента на SADT-диаграммах в виде входа, управления, механизма (или ресурса) и выхода не обеспечивается никаким методом распределения связей в конкретных случаях по данным категориям. Результатом этого является представление, например, производственного подразделения как элемента, ресурсом которого изображаются люди, которые в нем работают, т.е. которые составляют, на самом деле, его части, а не входы [98].

«Диаграммы потоков данных обеспечивают удобное описание функционирования компонент системы, но не снабжают аналитика средствами описания деталей этих компонент, а именно, какая информация преобразуется процессами и как она преобразуется» [20, с. 53]. Их практическое применение высокоэффективно, как правило, только для отражения информационных структур бизнес-процесса, оптимизация которого проведена уже другими средствами. DFD ориентированы на системных аналитиков и программистов и не учитывают особенности восприятия менеджерами предметной области.

Кроме того, в статье [25] отмечается, что наименьший вред организации принесет инструментарий моделирования, «лишающий разработчика той части «творческих» возможностей, которые ведут к разнообразию представления организационных моделей». Данное требование непосредственным образом связано с тем, что инструментарий моделирования должен быть средством поддержки принятия решений, а не художественного творчества. При этом степень соответствия этому требованию инструментария, использующего нотацию SADT (IDEF0), оценивается как крайне низкая.

Рассмотренные технологии и инструментарий приспособлены для хорошо специфицированных и стандартизованных «западных» бизнес-процессов. При моделировании больших, сложных, иерархических систем создаваемые диаграммы становятся слишком сложными для понимания и корректировки.

Ну и основная, очевидно, проблема состоит в том, что существует процедурно-ориентированный вариант технологий (3VM, Icam Definition) и вариант, ориентированный на данные, однако, не существует объектно-ориентированного варианта.

Вопросы для повторения

  1.  Что такое методология системного анализа 3VM?
  2.  Опишите процесс построения модели информационной системы с помощью DFD-диаграмм.
  3.  Что такое ERD-диаграммы? Для чего они используются?
  4.  Что такое STD-диаграммы?
  5.  Опишите процесс построения модели производственной системы с помощью IDEF0-диаграмм.
  6.  Для чего применяются стандарты моделирования IDEF1 и IDEF1Х?
  7.  В чем специфика моделирования процессов в соответствии со стандартом IDEF3?
  8.  Что такое стандарт моделирования онтологий IDEF5?
  9.  Опишите назначение и возможности CASE-инструментария системно-структурного моделирования и анализа (AllFusion Process Modeler).
  10.  Что такое ФСА? Какие процедуры осуществляются в связи с этим с помощью AllFusion Process Modeler?

Резюме по теме

В данном разделе рассмотрены технологии системно-структурного моделирования и анализа сложных систем: технология моделирования «3-View Modeling»; стандарты системно-структурного анализа серии «Icam Definition»; а также CASE-инструментарий системно-структурного моделирования и анализа (AllFusion Process Modeler).


Тема 4. Технология объектного моделирования и анализа

Цели и задачи изучения темы

Целью изучения данной темы является теоретическое и практическое освоение технологий объектного моделирования и анализа сложных систем.

При этом ставятся следующие задачи:

  •  изучение сущностей, отношений и диаграмм универсального языка моделирования, а также процедуры объектного моделирования;
  •  ознакомление с требованиями к объектному моделированию организационных систем и их информационного обеспечения;
  •  изучение CASE-инструментария объектного моделирования и анализа (IBM Rational Software Architect).

4.1. UML – язык объектного моделирования

Объектно-ориентированное моделирование, как и методы системного анализа, предполагает использование некоторой нормативной системы, т.е. языка, состоящего из набора символов, имеющих определенное значение (семантику), и правил манипулирования ими (синтаксиса).

В настоящее время благодаря усилиям концерна Object Management Group (OMG) создан единый стандарт языка объектного моделирования – Unified Modelling Language (UML).

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

Нормативная система языка UML включает два вида символов: сущности и отношения, а также правила создания комбинаций из этих символов, т.е. диаграммы. Кроме того, существуют механизмы расширения языка для уточнения семантики символов сущностей и отношений при моделировании конкретной предметной области.

Рассмотрим основные элементы нормативной системы языка UML, используя работы [13, 79, 81 - 86, 104 - 106].

4.1.1. Сущности: структурные; поведенческие; группирующие; аннотационные

Сущности – это символы, являющиеся основными элементами объектной модели. Принято использовать четыре вида сущностей при построении моделей: структурные, поведенческие, группирующие, аннотационные.

Структурные сущности

Структурные сущности (Structural things) представляют собой символы статических частей объектной модели, соответствующие концептуальным или физическим элементам системы.

Класс (Class) – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой (рис. 4.1).

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

Экземпляр (Instance) – конкретная реализация абстракции (класса, прецедента, компонента и т.д.) или объект, графически представляемый как класс с подчеркнутым именем (рис. 4.1), после которого может следовать двоеточие (:) и имя класса, от которого производится данный объект. Методы объекта представляют собой реализации соответствующих операций класса и, как правило, не указываются.

Активный класс (Active class) – класс, объекты которого могут инициировать управляющее воздействие, и вовлечены в один или несколько процессов или потоков. Изображается также как класс, но толстыми линиями.

Признак видимости может принимать одно из трех значений:

  •  + – открытый (public) – может использовать любой класс или объект;
  •  # – защищенный (protected) – может использовать любой потомок класса;
  •  - – закрытый (private) – может использовать только данный класс.

Интерфейс (Interface) – совокупность операций, которые определяют набор услуг, предоставляемых классом или компонентом, т.е. описание видимого извне поведения элемента (рис. 4.2). Определяет спецификации операций (сигнатуры), но не их реализацию и присоединяется к реализующему его классу или компоненту.

Кооперация (Collaboration) – представляет взаимодействия элементов, которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых (рис. 4.2).

Прецедент / Вариант использования (Use case) – описание последовательности выполняемых системой действий, в результате которых образуется наблюдаемый результат, значимый для какого-нибудь определенного актора (рис. 4.2).

Компонент (Component) – физически заменяемая часть системы, соответствующая некоторому набору интерфейсов и обеспечивающая их реализацию (рис. 4.3). Как правило, это физическая упаковка логических элементов (файлы), таких как классы, интерфейсы и кооперации.

Узел (Node) – элемент реальной (физической) системы, существующей во время функционирования программного комплекса и представляющий собой вычислительные ресурсы (объем памяти, скорость обработки) (рис. 4.3).

Поведенческие сущности

Поведенческие сущности (Behavioral things) представляют собой символы динамических составляющих объектной модели.

Взаимодействие (Interaction) – обмен сообщениями между объектами для достижения определенной цели (рис. 4.4).

Состояние (Statechart) – алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события (рис. 4.4).

Активность (Activity) – алгоритм поведения, определяющий последовательность процессов, осуществляемых объектом или происходящих с объектом на протяжении его жизненного цикла (рис. 4.4).

Группирующие сущности

Группирующие сущности (Grouping things) представляют собой символы, организующие различные компоненты объектной модели. Это блоки, на которые можно разложить модель.

Пакет (Package) – механизм организации элементов (структурных, поведенческих и группирующих сущностей) модели в группы (рис. 4.5). В отличие от компонентов носят чисто концептуальный характер.

Аннотационные сущности

Аннотационные сущности (Summary things) представляют собой пояснительные символы объектной модели.

Примечание (Note) – символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов (рис. 4.6).

4.1.2. Отношения

Отношения – это символы, связывающие различные сущности. В языке определено четыре вида отношений: обобщение, ассоциация, зависимость и реализация.

Обобщение (Generalization) – отношение (потомок-родитель), при котором специализированный элемент (потомок) может быть подставлен вместо обобщенного элемента (родителя) (рис. 4.7). Потомок наследует структуру и поведение своего родителя.

Ассоциация (Association) – отношение связи (соединения) между объектами (рис. 4.7). На графическом изображении ассоциации могут присутствовать дополнительные обозначения кратности, ролей или меток.

Агрегирование – разновидность ассоциации, т.е. ассоциация между целым и его частями (рис. 4.7).

Композиция - такое отношение агрегирования, при котором часть является неотъемлемой составляющей целого (рис. 4.7).

Зависимость (Dependency) – отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой (см. рис. 4.8).

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

4.1.3. Диаграммы

Диаграммы – это совокупности правил соединения различных символов языка моделирования. Диаграмма представляет собой связанный граф, вершинами которого являются сущности, а ребрами – отношения. Любая диаграмма представляет собой модель некоторого аспекта разрабатываемой системы. Предусмотрены следующие виды диаграмм (правил соединения символов):

Диаграмма вариантов использования/прецедентов (Use case diagram) – диаграмма поведения, показывающая функции моделируемой системы и ее связи с другими системами, т.е., в случае разработки программного обеспечения, требования пользователей. Диаграмма состоит из множества прецедентов, классов (акторов: пользователей или любых других внешних систем) и отношений между ними (рис. 4.9).

Проектирование системы осуществляется путем реализации на каждой итерации одного или нескольких вариантов использования. Данная диаграмма является основой для моделирования поведения и тестирования системы.

На данной диаграмме показаны следующие виды отношения между прецедентами: расширение и использование.

Связь типа «расширение» применяется в тех случаях, когда один вариант использования подобен другому, но несет несколько другую нагрузку и, в связи с этим, необходимо описать изменение в обычном поведении системы.

Связь типа «использование» применяется в тех случаях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования и нет смысла копировать его описание.

Диаграмма классов (Class diagram) – структурная диаграмма, показывающая структуру классов предметной области. Диаграмма состоит из классов, интерфейсов, коопераций и отношений между ними (рис. 4.10). Абстрактные классы, от которых не производятся экземпляры, помечаются курсивом.

Классы на диаграмме отражают понятия и представления пользователей о соответствующей предметной области, т.е. названная диаграмма является ее концептуальной моделью.

Диаграмма объектов (Object diagram) структурная диаграмма, показывающая объектную модель системы, состоящую из множества экземпляров классов (объектов) и отношений между ними.

Диаграмма взаимодействия – диаграмма поведения, показывающая взаимодействие нескольких объектов, например, в рамках одного варианта использования. Взаимодействия изображаются с помощью диаграммы последовательностей (Sequence diagram), подчеркивающей временную последовательность событий (рис. 4.11), или диаграммы кооперации (Collaboration diagram), подчеркивающей структурную организацию объектов, посылающих и принимающих сообщения (рис. 4.12).

Диаграмма состояний (Statechart diagram) – диаграмма поведения, показывает поведение одного объекта в нескольких вариантах использования. Диаграмма представляет автомат, включающий в себя состояния, переходы, события и виды действий. Данная диаграмма акцентирует внимание на поведении объекта, зависящем от последовательности событий, и особенно важна при описании поведения классов, интерфейсов и коопераций.

Диаграмма деятельности (Activity diagram) – диаграмма поведения, показывающая поведение разрабатываемой системы вместе с управляющей структурой. Диаграмма представляет автомат и подчеркивает переходы потока управления от одной деятельности к другой (рис. 4.13). Может отображать несколько объектов в нескольких вариантах использования или реализацию метода. Позволяет определять параллельные процессы.

Сообщения: 1 – открыть сейф; 2 – деньги в первый мешок; 3 – деньги во второй мешок; 4 – деньги в третий мешок.

Диаграмма компонентов (Component diagram) – диаграмма, показывающая организацию совокупности компонент (файлов) и их зависимости.

Диаграмма развертывания (Deployment diagram) – диаграмма, показывающая узлы и отношения между ними (физическое размещение компонент в аппаратных средствах).

Применение языка UML существенно облегчается за счет следующих механизмов:

  •  спецификаций (specifications) – текстовых описаний синтаксиса и семантики соответствующих элементов модели (диаграммы);
  •  принятых делений (common divisions) – в соответствии с дихотомией «класс/объект» и дихотомией «интерфейс/реализация»;
  •  механизмов расширения (extensibility mechanisms) – обеспечивающих расширение синтаксиса и семантики языка.

Предусмотрены следующие механизмы расширения языка:

  •  стереотипы (stereotypes), позволяющие расширять словарь языка и представлять на основе существующих элементов новые специфичные для конкретных проблем элементы модели;
  •  помеченные значения (tagged values), позволяющие расширять свойства элементов языка и представлять новые атрибуты и новую информацию в спецификацию элемента;
  •  ограничения (constraint), позволяющие расширять семантику элементов языка и определить новые или изменить старые правила.

UML не зависит от процесса его использования или метода моделирования. Однако, лучше всего он поддерживает Рациональный Унифицированный Процесс (Rational Unified Process – RUP) изготовления программных продуктов.

В общих чертах процесс анализа и моделирования системы в терминах UML представляет собой последовательность следующих шагов:

  •  Анализ внешних по отношению к данной систем и формулирование требований к моделируемой системе с их точки зрения. Результаты этого шага представляются в виде диаграммы прецедентов.
  •  Уточнение потоков событий в прецедентах, например, в виде диаграммы деятельности или текстового документа.
  •  Определение типов объектов (классов) и их свойств, с помощью которых можно будет реализовать деятельность в прецедентах. Результаты этого шага представляются в виде диаграммы классов.
  •  Декомпозиция моделируемой системы и представление ее модели в виде диаграммы кооперации (взаимодействия объектов).

Консорциум OMG начал разрабатывать UML 2.0, чтобы преодолеть существенные недостатки ранних версий. В число проблем, которые пытаются решить архитекторы стандарта UML 2.0, входит проблема разбухания ранних версий и недостатки в определении семантики. В процессе работы над новым стандартом возникла необходимость включить в него поддержку разработки на базе моделей (Model-Driven Development – MDD) и, в частности, подхода к такой разработке с позиций архитектуры на базе моделей (Model-Driven ArchitectureMDA). В результате стандартизации языка моделирования общественными усилиями был разработан очень громоздкий и сложный вариант стандарта. По мнению известных экспертов [106, с. 34] «Кажется, конечный результат полностью противоречит благим намерениям, породившим радикальный пересмотр стандарта. Многочисленные концепции моделирования, плохо определенная семантика и облегченные механизмы расширения UML 2.0 затрудняют его изучение и применение в MDD» ... «Язык UML 2.0 в некоторых отношениях превосходит предыдущие версии, но его громоздкость и сложность могут создать проблемы для пользователей, разработчиков инструментальных средств и рабочих групп OMG, развивающих этот стандарт».

4.1.4. Процесс объектно-ориентированного моделирования/проектирования: начальная фаза; исследование; построение; внедрение; дополнительные средства

В данном пункте представлено описание стандартного процесса объектно-ориентированной разработки информационного (программного) обеспечения бизнеса – Рационального Унифицированного ПроцессаРУП (Rational Unified Process). Для его составления использованы работы [79 и 81].

Основным направляющим фактором разработки ПО является его системная архитектура. Архитектура программной системы представляет собой совокупность существенных решений, охватывающих ее структурные и поведенческие аспекты, использование (функциональность), производительность, гибкость, возможность повторного использования компонент, полноту, ограничения и компромиссы, а также эстетические вопросы. Выбор архитектуры должен учитывать аспекты рассмотрения создаваемого программного продукта представленные на рисунке 4.14 и в таблице 4.1, из которых точка зрения вариантов использования (прецедентов) является основной.

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

Таблица 4.1. Аспекты представления системной архитектуры.

Вид

Аспект представления

Диаграммы представления UML

Статики

Динамики

Прецедентов.

Варианты использования системы конечным пользователем, ее поведение.

Прецедентов.

Деятельности, состояний и взаимодействия.

Проектирования.

Поддержка функциональных требований. Словарь предметной области (классы, интерфейсы, кооперации).

Классов и объектов.

Последовательности и кооперации.

Процессов.

Процессы и потоки, с точки зрения производительности, пропускной способности, масштабируемости.

– « –

Деятельности, состояний и взаимодействия.

Реализации.

Компоненты и файлы с точки зрения сборки системы и управления конфигурацией версий.

Компонентов.

– « –

Развертывания.

Узлы физической системы с точки зрения распределения, поставки и установки.

Развертывания.

– « –

Данный эффект достигается вследствие того, что РУП состоит из фаз, в которых достигаются конкретные хорошо определенные цели и принимается решение о переходе к следующей фазе: начало, исследование, построение, внедрение. При этом  каждая фаза состоит из итераций, содержащих рабочие процессы, соответствующие этапам жизненного цикла ПО. В каждой фазе и на каждой итерации основные усилия сосредотачиваются на различных аспектах процесса разработки. В таблице 4.2 показан общий вид этого процесса.

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

Одно прохождение четырех фаз процесса называется циклом разработки. Если после этого работа над проектом не заканчивается, то полученный продукт продолжает развиваться и снова проходит цикл из четырех фаз, каждая из которых состоит из рабочих процессов, представленных в таблице 4.3.

Таблица 4.2. Фазы и рабочие процессы РУП.

Рабочие процессы:

Начало

Исследование

Построение

Внедрение

Моделирование

бизнес-процессов