Назад в библиотеку

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

Авторы: Steven J. Bleistein, Pradeep Ray

Перевод: С.В. Даниев

Источник: http://dpnm.postech.ac.kr/

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

1 Введение

Самоуправляемые системы были предложены в качестве следующего уровня развития в области компьютерных технологий. Количество сетей, систем и устройств, а также достижений в аппаратной части, выросло в геометрической прогрессии настолько, что стало не возможно менеджерам идти в ногу с ними, и человеческих талантов недостаточно, чтобы обеспечить менеджеров необходимым. Самоуправляемые системы являются решением с искусственным интеллектом, предлагающее удовлетворить потребность в управлении сложными сетями автономно, избавляя от вмешательства человека, технического обслуживания и управления [5].
В то время как автономные вычисления предназначены для достижения высокоуровневых бизнес-целей сложным образом, разработка методологии самоуправляемых систем отстает. Системы сбора требований в современных методологиях собирают требования на более низких уровней абстракции, и не обеспечивают средствами для сбора и проверки требований с более высоких уровней (бизнес-целей). Поскольку бизнес-цели самоуправляемых систем становятся все более амбициозными и двигаются в стратегическом уровне организации, проектирование систем в соответствии с высоким уровнем абстрактных бизнес-целей становится критичным для успеха.
Работа организована следующим образом: начинается с определения собственного систем управления в разделе 2. Затем переходит к обсуждению агент-ориентированных методологий и их недостатков, в разделе 3. Раздел 4 объясняет целеориентированный подход к агент-ориентированному проектирования для заполнения пробела, и определяет набор рекомендаций для целеориентированный разработки методологии. В разделе 5 обсуждаются основы для целеориентированной методологии предлагая высокоуровневый, многослойный шаблон дизайна и некоторые методы, заимствованные из целеориентированной методологий сбора требований к проектированию программного обеспечения.  В разделе 6 показан пример целеориентированного подхода к проектированию самоуправляемых систем.

2 Определение самоуправляемых систем

Самоуправляемые системы – вычислительные системы, которые могут управлять собой в соответствии с высокого уровневыми целями, которые администраторы системны определяют для них [8]. IBM относится к такого рода систем, как к «автономные вычислениям» [2] ссылаясь на четыре аспекта самоуправления: самоконфигурацию самооптимизацию, самовосстановления и самозащиту [3]. В настоящее время эти аспекты рассматриваются в качестве отдельных решений самоуправляемых систем. В будущем IBM предвидит постепенные шаги эволюции самоуправляемых систем, в которой различия размываются, а общие свойства «самообеспечения» становятся в общей архитектуре [8].
IBM предусматривает применение этой технологии в высоко стратегических путях, за пределами сетевого обслуживания. IBM приводит примеры массового распространения технологий в розничной торговле, здравоохранении и электронных услугах [5].
Самоуправляемые системы, на самом деле, являются интерактивными коллекциями автономных «элементов» [8], или, точнее, автономных агентов. Эти агенты управляют своим внутренним поведением и отношениями с другими автономными агентами в соответствии с политикой, установленной менеджерами или другими агентами. Поведения автономных элементов запрограммированы на условия целей более высокого уровне. Это обязывает агентов разрешать детали поведения, отношений и связи на лету [13]. Таким образом, дизайн самоуправляемых систем зависит , в частности, от агент-ориентированной методологии проектирования.
В настоящем документе предлагается парадигма методологии проектирования собственного управления на основе целеориентированной методологии, а также развитие высокоуровневых шаблонов проектирования. В настоящем документе изложены рекомендации к такой методологии, а также анализ последних технологий в сборе требований к ПО, целевое моделирования, а также интегрированное управление сетями и услугами.

3 Агент-ориентированные методологии проектирования самоуправляемых системах

На концептуальном уровне в текущей агент-ориентированной методологии, как правило,  сбор требований начинается на более низком уровне по отношению к бизнес-целям и задачам предлагаемого решения. Как правило, они ориентированы прежде всего на отдельные модели агента, а затем переходят в один слой выше для моделирования взаимодействия между агентами, в так называемом «обществе».
На самом деле, большая часть методик –  расширения объектно-ориентированной методологии разработки программного обеспечения, и, следовательно,  чем-то похожи [6]. С позиции агент-моделирования, основное внимание уделяется ролям и обязанностям отдельных агентов. На высшем «социальном уровне» подход рассматривает взаимодействие агентов в системе с точки зрения индивидуальных ролей и обязанностей, как организацию [14].
Некоторые методики придерживаются подхода «сверху вниз» с точки зрения моделирования «общества» интерактивных агентов на основе индивидуальных ролей и обязанности агентов. По существу общество декомпозируется сверху вниз на агентов. Роли и обязанности агентов предназначены для удовлетворения высокоуровневых технических требований, которые предположительно поддерживают цели бизнес-уровня.
Однако, «сверху вниз» означает только направление анализа. Это не определяет отправную точку. Хоть методики по направлению анализа могут быть «сверху вниз», они полагаются на достаточно хорошо определенный набор требований в самом начале. Этого мало для поддержки проекта, когда стартовый набор требований с точки зрения бизнеса намного выше уровня, целей и задач. Таким образом, существует разрыв в текущей методологии дизайна сложных самоуправляемых систем с точки зрения согласования требований к системе с высоким уровнем бизнес-стратегий и целей.

Рисунок 1 Разрыв в нисходящем анализе уровней самоуправляемых систем

3.1 Дилемма текущих методологий

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

3.2 Подводные камни в агент проектах

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

4 Целеориентированное проектирование самоуправляемых систем

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

Рисунок 2 Целеориентированный поподход к преодолению разрыва «сверху-вниз»

4.1 Целеориентированные методологии

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

4.2 Понятия и терминология

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

4.2.1 Функциональные против нефункциональных требований

Большинство программистов знакомы с концепцией функциональных требований (FR). В требованиях системы моделирования, нефункциональные требования (NFR), часто не менее важны, и в зависимости от того, насколько они удовлетворены, зависит успех проекта. NFRs определены как требования к системе, которые не привязаны к какой-либо конкретной функциональности [1].

4.2.2 «Жесткие» цели против «Мягких»

Цели различают между жесткими и мягкими. Различие между ними состоит в измеримости. «Жесткие» выполняются, если измеримые критерии достигнуты. «Мягкие» однако, не имеют конкретных измеримых критериев. Их статус, таким образом, «нечеткий».

4.2.3 Задачи против операционилизаций

«Жесткие» цели на самом низком уровне выполняются с помощью задач. Процессы представления знаний организованы в разработке действий, результаты которых предназначены для удовлетворения или приближения к цели [12]. Процессы определяют задачи. Конечным результатом процесса является достижение. «Мягкие цели» на самом низком уровне удовлетворяются «операционализациям». Различие здесь в том, что агентам не обязательно достигать целей, при помощи фиксированного набор задач. Агенты меняют свое поведение в зависимости от окружающей среды, руководствуясь достижением целей поставленных перед ними [10]. Особенности поведения, необходимых для достижения этих целей не известно, во время исполнения [16].

4.3 Рекомендации в Целеориентированный подходе к Агент-ориентированной методологии проектирования

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

5 Предлагаемый Фреймворк для создания целеориентированных самоуправляемых систем

5.1 Моделирование шаблонов решений «сверху-вниз»

Для многих методик  сбора требований к программному обеспечению обсуждается необходимость моделирования требований от бизнес-целей. Бизнес-цели, как правило, имеют более абстрактный характер, чем функциональные и нефункциональные требования к программному обеспечению, если рассматривать в контексте информационной системы. Работа проектировщика систем – перевести бизнес-абстракции к конкретной логической архитектуре. Это может быть громоздким и запутанным процессом, потому что это требует преодоления двух сложных и разнородных областей: информационных систем и управления бизнесом. Часто это приводит к коммуникационным непониманиям и колебаниям требованиям [11].

Для решения подобных проблем в области электронной коммерции, исследователи из IBM предложили бизнес-шаблоны для надежных, устойчивых, многоразовых компонент для решения общих проблем в области электронного бизнеса, в частности в разработке программного обеспечения [4]. IBM предлагает модели, котрые адресуют решения на разных слоях (от высшего к низшему) от «бизнес-интеграции и композитных структур», до «шаблонов приложения», а затем «шаблонов исполнения».
Рей обобщил это концепцию использования многослойных шаблонов проектирования, как средств разработки комплексных решений для управления бизнес-сетями и услугами, проецируя решения с высокого уровня шаблона бизнес-управления, вниз через логический шаблон, описывающий приложения управления электронным бизнесом,  и, наконец, вниз на платформу или физический уровень [13]. Отображение слоев IBM на обобщенный Фреймворк показано на рисунке 3.

Рисунок 3 Шаблон управления электронным бизнесом

5.2 Разработка полной модели целей «сверху-вниз»

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

Описание: C:\Documents and Settings\MASTER\Рабочий стол\перевод\86-tenswselei2_files\Image_004.jpg

Рисунок 4 Слои  комплексного проектирования «сверху-вниз» для самоуправляемых систем

5.3 Анализ сверху

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

Рисунок 5 Позиционирование решений в  стратегической иерархии

5.4 Иерархия целей в бизнес-стратегии

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

5.5 Систематическое обнаружение цели

Есть большое количество литературы, посвященной обнаружению бизнес-целей с помощью анализа сценариев [7], который эта статья не рассматривает. Анализ сценариев возник в методологии взаимодействия человек-компьютер и поддержкой совместной работы. С того времени, использование случая анализа стало стандартной практикой в разработке программного обеспечения и разработке с использованием UML, а совсем недавно, прецедентов отображений. Прецеденты отображений – более сложное расширение UML, чем варианты использования [20] , которые были предложены в сочетании с GRL в качестве стандарта для нотации требований пользователей в настоящее время рассматривается ITU-T [9]. Выявление целей с помощью сценариев имеет множество преимуществ, которые не будут рассматриваться здесь, однако основным недостатком этого процесса является то, что они являются мощным средствам для в анализа «снизу-вверх».
Сценарий – экземпляр процесса. Процессы – представление знаний, организованное в разработке действий, результаты которых предназначены для удовлетворения или достижения цели [12]. Анализ сценариев является, по сути, средством экстраполяции цели из экземпляров процессов. Однако методология «снизу вверх» не обеспечивает полноты, и корректности модели.

5.6 Шаблоны декомпозиции целей

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


Рисунок 6 Альтернативный шаблон цели

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

Рисунок 7 Композиционный шаблон цели

5.7 Распределение целей на автономных агентов в самоуправляемых системах

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

Заключение

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

Ссылки