2D. Задание интерфейсов дочерних модулей

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

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

♦ производителей/потребителей информации;

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

Представление параллелизма документирует:

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

♦ информацию об активности компонента — например, о наличии у него собственного исполняемого потока;

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

Представление размещения документирует:

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

♦ требования по времени — например, о том, что скорость вычислений процессора должна быть не меньше 10 MIPS;

♦ требования по обмену данными — например, о том, что обновление информации должно проводиться не чаще, чем раз в секунду.

Все эти сведения должны быть отражены в документации интерфейсов модулей.

2е. Проверка и уточнение элементов Use Case, сценариев реализации качеств и ограничений, налагаемых на дочерние модули

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

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

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

♦ Пользовательский интерфейс. Выявление запросов пользователей и их представление в форме, ожидаемой модулем поднятия/опускания двери.

♦ Модуль поднятия/опускания двери. Управление силовым приводом, обеспечивающим открытие и закрытие двери. Остановка движения двери при полном закрытии или открытии.

♦ Обнаружение препятствий. Фиксация момента обнаружения препятствий и последующая остановка двери и процессе опускания или перенаправление ее движения.

♦ Виртуальная машина передачи данных. Управление обменом данных с домашней информационной системой.

♦ Виртуальная машина считывания показаний датчиков/управления силовым приводом. Управление взаимодействием с датчиками и силовыми при. водами.

♦ Планировщик. Обеспечение соблюдения детектором препятствий всех требовании по времени.

♦ Диагностика. Управление обменом диагностической информацией с домашней информационной системой.

Ограничения. Существует несколько способов обеспечения соответствия ограничениям родительского модуля.

♦ Декомпозиция соответствует ограничениям. К примеру, ограничение, согласно которому возможно применение только одной операционной системы, можно удовлетворить путем задания этой операционной системы в качестве дочернего модуля. Этим все действия и ограничиваются.

♦ Ограничение удовлетворяется одним-единственным дочерним модулем. К примеру, ограничение, в соответствии с которым необходимо применение специального протокола, можно удовлетворить путем определения для этого протокола дочернего модуля инкапсуляции. Даже при условии назначения для ограничения дочернего модуля оно может быть как удовлетворено, так и не удовлетворено — в зависимости от декомпозиции этого модуля.

♦ Ограничение удовлетворяется несколькими дочерними модулями. К примеру, для реализации всех протоколов, необходимых для передачи данных в Интернете, требуется два модуля (клиент и сервер). Соответствие условию зависит от декомпозиции этих дочерних модулей и их координации.

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

Сценарии реализации атрибутов качества. Сценарии качества также требуют уточнения и распределения между дочерними модулями.

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

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

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

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

Ге сценарии реализации качества, которые в нашем примере признаны архитектурными мотивами, удовлетворяются и уточняются следующим образом.

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

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

♦ Если препятствие (человек или объект) обнаруживается во время опускания гаражной двери, она должна остановиться (или, в качестве альтернативы, открыться) в течение 0,1 с. Этот сценарий делегируется планировщику и модулю обнаружения препятствий.

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

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

Обратите внимание на то, как далеко (или, быть может, недалеко?) мы продвинулись за один шаг: в нашем распоряжении словарь модулей и их обязанностей; Мы рассмотрели множество элементов Use Case и сценариев реализации качества и частично разобрались в их ветвлении. Мы выявили информационные потребности модулей и характер их взаимодействия. Все эти сведения необходимо зафиксировать в логическом обосновании проекта, чем мы и займемся в главе 9 «Документирование программной архитектуры». С другой стороны, мы еще не затрагивали большинство деталей. Мы не знаем языков обмена данными между модулем пользовательского интерфейса и модулем поднятия/опускания двери. Остается неизвестным алгоритм, который будет ответствен за обнаружение препятствий. Мы не имеем даже самого общего представления о взаимодействии критичных и некритичных секций производительности.

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