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