Ссылки

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

1. внешние документы
2. внутренние документы
3. нормативные документы
4. неправительственные документы
5. и т.д.

Архитектурные цели и ограничения

На выбор архитектуры влияют следующие факторы:

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

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

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

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

Критерии оценки также могут относиться к вариантам изменений, в которых отражаются возможные варианты будущих изменений:

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

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

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

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

• Бизнес-факторы: новые и измененные бизнес-процессы и цели
• Технологические факторы: адаптация системы к новым платформам, интеграция с новыми компонентами
• Изменения профайла типичного пользователя
• Изменения, связанные с потребностью интеграции с другими системами
• Изменения области, связанные с переносом функциональности из внешних систем

Представление вариантов использования

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

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

1. Название варианта использования.
2. Краткое описание варианта использования.
3. Полезные описания потока событий варианта использования. Это может быть описание всего потока событий или его участков для важных моментов или сценариев варианта использования.
4. Полезные описания отношений с участием варианта использования, таких как отношение включения или расширения, или ассоциации связи.
5. Перечисление диаграмм, связанных с вариантом использования.
6. Полезные описания особых требований варианта использования. Это может быть описание всех особых требований или важных подразделов.
7. Важные изображения пользовательского интерфейса, иллюстрирующие вариант использования.
8. Реализации этих вариантов использования должны быть включены в логическое представление.

Логическое представление

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

Для сложной системы логическое представление может быть описано в нескольких разделах:

1. Обзор

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

2. Архитектурно значимые пакеты проекта

   Для каждого важного пакета включите раздел со следующей информацией:

   1. Название.
   2. Краткое описание.
   3. Диаграмма с важными классами и пакетами внутри пакета. Для лучшего понимания на этой диаграмме могут быть показаны классы и из других пакетов, если это необходимо.
   4. Для каждого класса в пакете укажите его имя, краткое описание, а также, возможно, описание его функций, операций и атрибутов. Также опишите важные взаимосвязи, если это помогает лучшему пониманию диаграмм.
3. Реализации вариантов использования

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

   Для каждой важной реализации варианта использования включите раздел со следующей информацией:

   1. Название реализуемого варианта использования.
   2. Краткое описание варианта использования.
   3. Полезные описания потока событий - проекта реализации варианта использования. Это может быть описание всего потока событий - проекта или его участков для важных моментов или сценариев варианта использования.
   4. Перечисление диаграмм взаимодействия или классов, связанных с вариантом использования.
   5. Полезные описания производных требований реализуемого варианта использования. Это может быть описание всех производных требований или важных подразделов.

Архитектурно значимые элементы проекта

Для того чтобы упростить выбор архитектурно значимых элементов, далее приведены примеры таких элементов и описаны их особенности:

• Элемент модели, выражающий одну из важных абстрактных концепций в проблемной области, например:
  • Полетный план в системе управления воздушным движением.
  • Работник в системе расчета заработной платы.
  • Клиент телефонной компании.

• Элемент модели, используемый многими другими элементами модели.
• Элемент модели, выражающий один из важных механизмов (служб) системы
• Механизмы проекта
  • Хранение данных (хранилище, база данных, память).
  • Связь (RPC, многоадресная рассылка, служба посредников).
  • Обработка ошибок или механизм восстановления.
  • Отображение и прочие общие интерфейсы (окна, ввод данных, условия сигналов и пр.).
  • Механизмы параметров.

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

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

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

Критерии того, что считать архитектурно значимым, будут уточняться в итерациях проекта, по мере того как будут раскрываться технические трудности и возрастать понимание системы. Однако следует ограничить число архитектурно значимых элементов модели максимум 10%. В противном случае размывается само понятие архитектуры, и все превращается в архитектуру.

При определении архитектурно значимых элементов и включении их в логическое представление следует принять во внимание также следующие аспекты:

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

Представление процессов

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

Для каждой группы процессов включите раздел со следующей информацией:

1. Название.
2. Участвующие процессы.
3. Взаимодействие процессов в виде диаграмм связей, на которых представлены процессы со своими собственными нитями управления. Для каждого процесса кратко опишите его поведение, время существования и параметры связи.

Представление развертывания

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

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

Это представление создается на основе документа Рабочий продукт: модель развертывания.

Представление реализации

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

1. Обзор

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

2. Уровни

   Для каждого уровня включите раздел со следующей информацией:

   1. Название.
   2. Диаграмма компонентов, показывающая подсистемы реализации и их зависимости импорта.
   3. Если это необходимо, схему связей уровней с элементами в логическом представлении и представлении процессов.
   4. Список подсистем реализации, расположенных на уровне. Для каждой подсистемы реализации укажите следующее:
   5. • Имя, псевдоним, краткое описание и описание ее назначения.
      • Если это необходимо, связи подсистемы реализации с элементами в логическом представлении и представлении процессов. Часто подсистема реализации соответствует одной или нескольким подсистемам из логического представления.
      • Если подсистема реализации содержит архитектурно значимые подсистемы реализации и/или
        каталоги, отразите это в структуре.
        
      • Если подсистема реализации не отображается однозначно на каталог реализации, то включите также описание соответствия подсистемы реализации и каталогов и файлов реализации.

Представление данных

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

Обычно указывается следующее:

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

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

Масштаб и производительность

В этом разделе описаны архитектурно значимые параметры объемные и временные характеристики системы. В их состав включается следующее:

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

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

Качество

В этом разделе описываются основные показатели качества, которые определяют архитектуру. В их состав включается следующее:

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

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