Файл: Учебное пособие.doc

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

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

Шаблон для документирования интерфейсов

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

Индивидуальность интерфейса. Если у элемента несколько интерфейсов, их нужно как-то отличать друг от друга. Как правило, для этого интерфейсам присваиваются имена, в некоторых случаях сопровождающиеся указанием номера версии.

Предоставляемые ресурсы, Основным предметом документирования любо го интерфейса должны быть предоставляемые им ресурсы. Они определяются синтаксисом, семантикой (описывающей следствия их применения) и ограничениями по использованию. Существует ряд нотаций, предназначенных для документирования синтаксиса интерфейса. Одна из них — язык описания интерфейсов (interface definition language, IDL), разработанный рабочей группой OMG, — применяется в сообществе CORBA. С помощью специальных языковых конструкций этого языка описываются типы данных, операции, атрибуты и исключения. Семантическую информацию можно выразить только в комментариях. В большинстве программных языков есть встроенные средства спецификации сигнатур элементов, примером чему — заголовочные файлы (.h) в С и спецификации пакетов в Ada. Наконец, на языке UML синтаксическая информация об интерфейсе выражается через стереотип «interface». Для интерфейса необходимо хотя бы ввести имя; кроме того, архитектор волен составить для него сигнатуру.

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

Семантика ресурса. Здесь приводится описание результатов вызова ресурса, в частности:

• присваивание значений данным, к которым может обращаться актер, вызывающий рассматриваемый ресурс, — от простого задания значения возвращаемого аргумента до обновления центральной базы данных;

• события и сообщения, сигнализируемые/отправляемые в результате обращения к ресурсу;

• предполагаемое поведение других ресурсов как результат обращения к рассматриваемому ресурсу (к примеру, если данный ресурс уничтожит некий объект, то последующие попытки обращения к этому объекту будут приводить к новому результату — ошибке);

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

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

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

Определения типов данных. Если какой-либо ресурс интерфейса задействует тип данных, отличный от предусмотренного соответствующим языком программирования, архитектор должен привести определение типа данных. Если он определен в другом элементе, достаточно установить ссылку на его документацию. Как бы то ни было, программисты, которые пишут элементы, обращаясь к такому ресурсу, должны знать: а) как объявлять переменные и константы типа данных; б) как в рамках этого типа данных записывать литеральные значения; в) какие операции и сравнения применимы к членам типа данных; и г) как преобразовывать значения этого типа данных в данные других типов.

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

Характерная для интерфейса изменчивость. Предполагает ли данный интерфейс возможность конфигурирования элемента? Подобные параметры конфигурации (configuration parameters), а также их воздействие на семантику интерфейса подлежат документированию. В качестве примеров изменчивости можно привести емкость видимых структур данных и рабочие характеристики соответствующих алгоритмов. Для каждого параметра конфигурации архитектор должен зафиксировать имя, диапазон значений и время связывания его фактических значений.

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

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

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

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

4.4.Методы анализа архитектуры

4.4.1.Метод анализа компромиссных архитектурных решений – комплексный подход к оценке архитектуры

Метод анализа компромиссных архитектурных решений (Architecture Tradeoff Analysis Method, ATAM) — комплексной универсальной методики оценки программной архитектуры. В соответствии со своим названием этот метод обнаруживает степень реализации в архитектуре тех или иных задач по качеству, а также (исходя из допущения о том, что любое архитектурное решение влияет сразу на несколько задач по качеству) механизм их взаимодействия — другими словами, их взаимозаменяемость.

Основное назначение АТАМ состоит в том, чтобы выявить коммерческие задачи, поставленные в контексте разработки системы и проектирования архитектуры. Вкупе с участием заинтересованных лиц это помогает специалистам по оценке сфокусироваться на тех элементах архитектуры, которые играют первостепенную роль для реализации упомянутых задач.

4.4.1.1.Этапы АТАМ

Операции оценки по методу АТАМ распадаются на четыре этапа.

На нулевом этапе — «Установление партнерских отношений и подготовка» — руководители группы оценки проводят неофициальные совещания с основными ответственными за проект лицами и прорабатывают подробности предстоящей работы. Представители проекта посвящают специалистов по оценке в суть проекта, тем самым повышая квалификацию некоторых из них. Эти две группы принимают согласованные логистические решения: где и когда встречаться, кто предоставит лекционные плакаты и с кого пончики и кофе. Кроме того, они согласовывают предварительный перечень заинтересованных лиц (перечисляя их не по именам, а по ролям) и устанавливают сроки и получателей сводного отчета. Они также организуют снабжение специалистов по оценке архитектурной документацией — если, конечно, таковая существует и может оказаться полезной. Наконец, руководитель группы оценки объясняет руководителю проекта и архитектору, какую информацию им следует предоставить на первом этапе, и при необходимости помогает им составить соответствующие презентации.

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

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

Четыре этапа АТАМ, их участники и приблизительный график представлены в табл. 5.2.

Таблица 4.21

Этапы АТАМ и их характеристики

4.4.2.Метод анализа стоимости и эффективности — количественный подход к принятию архитектурно-проектных решений

Метод анализа стоимости и эффективности (Cost Benefit Analysis Method, CBAM) базируется на методе АТАМ и обеспечивает моделирование затрат и выгод, связанных с принятием архитектурно-проектных решений, и способствует их оптимизации. Методом СВАМ оцениваются технологические и экономические факторы, а также сами архитектурные решения.

4.4.2.1.Контекст принятия решений

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

Рисунок 4.4 – Контекст метода анализа стоимости и эффективности (СВАМ)

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