Билет №8

1. Дать определение функциональных и нефункциональных требований. Привести критерии качества требований.

2. Communication patterns. Рассказать про типы интерфейсов (Message oriented architecture vs Service oriented architecture)

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

• уникальный идентификатор требования;

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

• список вовлеченных пользователей (актеры-участники);

• связанный с требованием сценарий (если есть);

• Предусловия, то, что ожидается, уже имеет место.

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

• Минимальные гарантии, обозначают то, что получат актеры-участники, если цель не была достигнута (например в случае ошибки аутентификации).

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

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

Каждое нефункциональное требование должно включать следующую информацию:

• уникальный идентификатор требования;

• описание требования;

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

Критерии качества требований

• Атомарность требования. Каждое требование должно описывать только одну функцию приложения.

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

• Верифицируемость требования. Каждое требование должно обладать свойством верифицируемости, т. е. для каждого требования должна существовать объективная процедура проверки достижимости требования приложением.

• Понятность и ясность каждого требования.

• Полнота, вместе требования должны давать полное представление о приложении и его возможностях.

• Непротиворечивость, требования должны быть логичными и не вступать в противоречие друг с другом.

2. Communication patterns - Связь моделей

По компоненту типа:

Клиент-серверная архитектура

N-уровневая архитектура

По типу интерфейса:

Сервис-ориентированная архитектура (CORBA, REST / SOAP + XML / JSON)

Типы интерфейса:

• TCP/IP custom protocols

• REST/SOAP + XML/JSON

• CORBA

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

Сообщение ориентированная архитектура (Message Bus)

Ключевые моменты

• асинхронныt коммуникационные компонены больше не ожидают ответа и не подключены друг к другу

• компоненты интерфейса являются сообщения, нет больше вызовов функций

Выгоды от Сообщение- ориентированной архитектуры

􀂃 Поддержка асинхронных и синхронных компонент связи.

􀂃 Поддержка N-слойной архитектуры

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

􀂃 Основана на Open Source Commercial Message Bus

Шина сообщений может быть использована для обмена сообщениями между веб-приложениями, в том числе и плагинами. Разработчик может добавить адресатов в шину сообщений, для каждого пункта назначения. Вы можете зарегистрировать несколько MessageListeners. Клиент посылает сообщение в пункт назначения и шина сообщений доставит это сообщение на каждый MessageListener, который слушает по этому направлению.