3.3.2Методологія, заснована на концепції м-архітектури

У структурі даної методології визначаються такі конструкції як життєвий простір агентів, типи агентів, відносини між агентами і життєвим простором і відносини серед агентів. Агентна архітектура розглядається з двох різних точок зору:

1) як інтелектуальний профіль, що описує спроможність агента вирішувати дану проблему;

2) як енергетичний профіль, що описує «життєву енергію» агента і дозволяє знищення нежиттєздатних агентів.

МАС в розглянутому підході конструюється низхідним способом з використанням абстрактних рівнів, які повинні відповідати наступним правилам:

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

• модель ускладнюється і доповнюється новими властивостями в залежності від ступеня просування від верхніх рівнів до нижніх, нові властивості вводяться в розгляд;

• на даному абстрактному рівні можуть бути застосовані кілька варіантів абстрактного розгляду, що дозволяє аналізувати цю систему з різних точок зору.

Переваги такого підходу:

1. можливість застосування до широкого діапазону МАС від дуже простих до досить складних, що містять як простих реактивних так і складних когнітивних агентів;

2. можливість застосування різних математичних формалізмів;

3. можливість створення МАС з кооперацією різних видів агентів (реактивних і когнітивних);

4. незалежність методології від конкретних мов програмування, так як середовище програмування може бути визначене на нижньому рівні абстракції разом з програмно-апаратною платформою;

5. гнучкість підходу для аналізу і проектування діючих організацій, з можливістю декомпозиції завдань на кожному абстрактному рівні, дотримуючись організаційних необхідностей

3.3.3Методологія Тropos

Методологія Тropos реалізує ідею використання концепції моделювання вимог для побудови системи такою, якою вона повинна бути. У методології можна виділити наступні фази:

1. ранні вимоги;

2. пізні вимоги;

3. проектування архітектури;

4. детальне проектування.

Аналіз вимог в Тropos поділяється на дві стадії – ранній аналіз та пізній аналіз. Ранній аналіз зосереджений на вивченні середовища, в якому АОС буде функціонувати. Пізній аналіз описує функціональні та нефункціональні вимоги до системи.

Зацікавлені сторони представляються як соціальні особистості (актори), залежні один від одного за допомогою цілей, які повинні бути досягнуті, завдань, які повинні бути виконані, і ресурсів, які повинні бути отримані. Каркас моделювання містить стратегічну модель залежностей (діаграма особистостей в Тropos), що показує взаємозалежності між особистостями, також як стратегічна діаграма відносин показує причини, з яких акторам необхідно підтримувати відносини з іншими акторами. При створенні моделей використовуються позначення, представлені на рис. 3.4.

Під час раннього аналізу вимог розробник представляє всі сутності у вигляді соціальних акторів. Така модель дає можливість відповісти на питання «чому?» На додаток до звичайних питань «що?» І «як?» з приводу функціонування системи. На стадії пізнього аналізу вимог модель доповнюється акторами, які описують систему такою, якою вона повинна бути і показують залежності між системою і середовищем.

Рисунок 3.4 – Позначення, використовувані при створенні графічних моделей

У методології Тropos стиль проектування визначається як метакласс організаційної структури, який за допомогою безлічі параметрів проектування впливає на процес розробки.

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

Фаза детального проектування призначена для того, щоб подати додаткові деталі кожного з компонентів системи. Вона складається з процесу визначення того, як завдання призначаються певній особі (актору), реалізованого у вигляді агента на основі зразків соціальної взаємодії. На цьому етапі проектувальник може скористатися каталогом стандартних шаблонів соціальної взаємодії агентів. У інженерії програмного забезпечення шаблони проектування вивчені досить добре. Проте, в них мало уваги приділяється взаємодії програмних сутностей. Соціальні шаблони, що використовуються в Тropos є переробкою шаблонів проектування, більш зосереджених на комунікаційних та інтелектуальних аспектах сутностей, що входять до АОС. Ці шаблони можна розділити на дві категорії: парні шаблони і шаблони посередництва.

Парні шаблони, такі як «замовлення», «запит плану», «підписка», «аукціон» передбачають пряму взаємодію між агентами, що перемовляються. Наприклад, шаблон «аукціон» передбачає участь ініціатора і деякої кількості учасників. Ініціатор організовує і проводить аукціон, інформує учасників про ціни і отримує різні пропозиції. На кожній ітерації ініціатор може прийняти пропозицію, підняти ставку або припинити аукціон.

Шаблони посередництва, такі як «монітор», «брокер», «посол», «обгортка», включають в себе проміжного агента, який допомагає іншим досягти угоди при обміні послугами. Наприклад, у шаблоні брокер проміжний агент запитує послуги у агента, їх надає, для того щоб розподілити їх між агентами, яким ці послуги можуть знадобитися.

Фаза детального проектування включає також розгляд взаємодії акторів і їх поведінки. Для їх представлення можна застосувати мови взаємодії агентів FIPA-ACL або KQML, і їх механізми транспортування повідомлень.

Для побудови всіх представлених вище моделей можна скористатися агентним розширенням мови UML (Agent UML).

Таким чином, методологія Тropos розглядає АОС в сукупності доповнюючих один одного аспектів: соціального, ментального, комунікативного, процесно-орієнтованого, об'єктно-орієнтованого.

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