Tuesday, September 24, 2013

Отличительные особенности целеориентированного моделирования

В предыдущих постах я описал новую методологию моделирования целеориентированных систем, которая сейчас находится в стадии активной разработки. Причиной её создания стали новые подходы, новая идеология и, соответственно, новые потребности, которые появились в автоматизации управления в последнее время. Фокус современной автоматизации от простого исполнения последовательности функций смещается на достижение нетривиальных “целей”. Появляется необходимость в более масштабной, иногда даже, тотальной автоматизации. Безусловно, классические методы никто не отменял. И их принципиально можно продолжать использовать для работы. Но тот небольшой опыт, который у нас накопился к настоящему времени, показывает моделировать ЦОАСУ классическими методами довольно сложно.

Проблемы начинаются уже с того, что понятие “цели” в классических методологиях, как правило, отсутствует. Для ЦОАСУ же оно является ключевым. Поэтому приходится вводить специальные обозначения, корректировать стандартную нотацию, чтобы корректно описать систему в требуемых терминах. Такая работа больше похоже на пытку с выкручиванием рук, чем на моделирование.

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

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

  • Специализация на автоматизации управления в многоуровневых социально-экономических системах. Многие применяемые в настоящее время методологии создавались для решения достаточно разных по своей сути задач. IDEF/SADT, например, создавался как средство для функционального анализа крупных бизнес систем. RUP/UML изначально затачивался под проектирование объектно-ориентированного ПО. Это является более общей задачей, чем, собственно, автоматизация управления. Скажем, компьтерная игра - это программа, которая может быть описана при помощи UML, но при этом системой управления она не является. SysML - это слегка причесаная версия UML, которая преподносится как средство системного анализа, однако от своего предшественника он практически не отличается. BPML сфокусирован на бизнес-процессы и практически полностью игнорирует цели, для достижения которых эти процессы создаются. Есть методологии, которые создавались для автоматизации в технических системах типа SCADA и являются слишком низкоуровневыми для описания управления в многоуровневых человеко-машинных система. Этот перечень можно продолжать достаточно долго.

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

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

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

В ЦОАСУ моделировании масштабируемость реализована по всем предусмотренным размерностям:
    • Масштабирование внешнего мира реализовано через иерархию контекстов-сред.
    • Масштабирование ролей происходит через иерархические групповые роли. Одна такая роль представляет собой “сверх-человека”, который выполняет всю работу огранизации, отдела или группы - в зависимости от выбранного уровня
    • Масштабирование функций происходит через групповые функции являющимся укрупненными функциональными блоками, как в IDEF0.
    • Масштабирование информации происходит при помощи информационных иерархий - цели дробятся на подцели, базовые факты (наблюдения) агрегируются в высокоуровневые факты (интерпретации)
    • И, наконец, масштабирование средств автоматизации, как это и есть на самом деле, реализуется иерархическим дроблением систем АСУ на подсистемы и, в конечном итоге, на элементарные компоненты.

  • Синтез - сопоставление модели реальному миру. Анализ, выполняемый при моделированиии систем, заставляет нас выполнять абстрагирование, упрощение, дробление сложных концепций на более мелкие и простые. Этим как раз и занимается большинство существующих методологий. Но, порой необходимо посмотреть, как созданная абстрактрая модель соотносится с реальным миром. Для этого требуется сложить из отдельных кусочков целостную картину, т.е. провести операцию обратную анализу - синтез. Поэтому в ЦОАСУ моделировании есть ряд интересных возможностей:
    • Синтез структуры АСУ через назначение/делегирование полномочий / ролей реальным физическим объектам. Возможно сопоставление одной-единственной логической структуры системы управления на нескольким различным физические структурам.
    • Синтез функций АСУ используя модель непрерывного управления или НОРД цикла. Работа любого активного элемента рассматривается как обработка информации в состояниях Наблюдаю-Ориентируюсь-Решаю-Действую.
    • Синтез целей управления АСУ происходит через приведение отдельных целей к целям верхнего порядка. И далее, сопоставление высокоуровневых целей управления реальным бизнес-целям моделируемой организации.

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

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

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

  • Полнота. Если перечислить из чего состоит система управления в реальном мире, то получится следующее:
    • Элементы, из которых состоит система и среда, которые поставляют или получают информацию, на которые направлены действия, а также взаимосвязи между ними.
    • Функции, которые выполняет система управления, совершая определенную работу
    • Данные, или информация, на основе которой функционирует система
    • А также средства автоматизации, которые улучшают или замещают работу людей-управленцев. Это может быть либо разрабатываемая АСУ, либо другие системы с которыми требуется взаимодействовать нашей системе.

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

В ЦОАСУ модель содержит не только все требуемые элемены, но и все возможные зависимости между ними - связи между элементами, данными, функциями, элементами и данными, данными и функциями и т.д.

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

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

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

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

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

Я думаю, что упомянул не все особенности нашей методики. Если что-то новое прийдет на ум, я обязательно об этом напишу в следующих постах. Следите за блогом. До новых встреч!

2 comments:

  1. Методология проектирования подразумевает использование необходимого (какого?) для этого инструментария (наверняка автоматизированного), чего в посте я не обнаружил.

    ReplyDelete
    Replies
    1. Действительно, у нас есть первая версия GOMA Modeler Tool. К сожалению, она не в свободном доступе.

      Delete