Microsoft Word впвс book 2011 sev pa doc

2.2 Проектирование архитектуры ВсС 
2.2.1 Архитектурная платформа и критерии проектирования архитектуры 
В рамках архитектурного проектирования возникают вопросы: как 
формируется элементная база системы, как разработчик выбирает ведущие 
аспекты проекта и откуда он берет внешние ограничения проекта (критерии 
проектирования). Очевидно, что разработка каждого проекта “с нуля” будет 
крайне неэффективна и практически невозможна. Различные разработчики 
используют некоторые готовые элементы, компоненты, решения и т.д. Откуда 
они берутся? 
Ответом на эти вопросы является понятие платформы или архитектурной 
платформы. Можно пытаться рассматривать архитектурную платформу как 
некоторое обобщение виртуальной машины, зафиксированной для создания 
очередной функциональной надстройки. Однако это не вполне удачно, так как в 
этом случае упущены многие существующие платформы, которые определяют 
не только функциональность. Как было отмечено выше, архитектурная 
платформа является объединением таких элементов процесса проектирования 
как: 
• аспектное пространство процесса проектирования (перечень аспектов 
проектирования); 
• модель (модели) вычислений; 
• внешние факторы, задающие допустимые соотношения между отдельными 
аспектами (критерии проектирования); 
• перечень зафиксированных шаблонов повторного использования; 
• элементная база. 
В общем случае при выборе той или иной А-платформы разработчик сразу 
же оказывается в определенных рамках, диктуемых выбранной платформой. А-
платформа определяет состав и взаимную важность аспектов процесса 
проектирования. Она диктует определенные характеристики элементной базы, 
определяя тем самым допустимые соотношения между отдельными аспектами. 
А-платформа, в частности, являясь реализуемой или виртуальной А-моделью, 
предлагает или подразумевает некоторые способы реализации шаблонов 
повторного использования. А-платформа определяет одну или несколько MoC, 
которые она “воплотит” при реализации. Соотношение этих параметров и дает 
разработчику возможность выбирать те или иные А-платформы для решения 
конкретной задачи. 
Если вернуться к рассмотрению поведенческого аспекта проектирования, 
то А-платформа играет тут огромную роль, определяя (фиксируя) MoC. 
Поведенческий аспект очень важный при проектировании ВсС, но далеко не 
единственный, поэтому могут сложиться ситуации, когда выбранная А-
платформа удовлетворяет разработчика практически по всем пунктам, но 

---

78 
предоставляемая ею MoC, абсолютно не подходит для решения задачи. Именно 
из-за распространенности таких случаев для А-платформы определяется такая 
характеристика, как реконфигурируемость. 
Реконфигурируемость А-платформы определяется как способность к 
изменению “воплощаемой” при реализации MoC. Конечно же, наличие такого 
свойства “разумно усложняет жизнь разработчику”, так как требует 
дополнительных усилий при работе с А-платформой, но зачастую дает 
ощутимый выигрыш. В общем случае реконфигурируемость может иметь 
разный характер (или способ реализации): 
• на этапе проектирования, когда конфигурированию подлежат те или иные 
методики; 
• на этапе реализации, когда устанавливаются те или иные параметры 
компиляции или используются различные компоненты элементной базы; 
• на этапе исполнения, когда система позволяет гибко адаптировать 
функциональность. 
Реконфигурируемость А-платформы может быть обеспечена введением 
широкого перечня электронных компонентов элементной базы, различных по 
функциональным характеристикам и физическим параметрам, но совпадающим 
по выводам, использованием языков высокого уровня и условной компиляции 
для описания шаблонов реализации, введением в состав платформы элементов 
программируемой логики и многим другим. 
В некоторых случаях, когда А-платформа не имеет внутренних 
возможностей изменить MoC, внесением таких изменений должен заниматься 
сам разработчик. Обычно для этого делается некоторая реализация выбранной 
А-платформы, после чего она достраивается “сверху” до уровня “воплощения” 
желаемой MoC, адекватной решаемой задаче. При дальнейшем проектировании 
созданная надстройка вместе с базовой А-платформой рассматриваются как 
новая платформа, удовлетворяющая критериям выбора. Надстройка над А-
платформой, созданная с целью изменить или скорректировать MoC А-
платформы, называется операционной средой. Особо следует отметить, что MoC 
А-платформы может нуждаться в изменении не только вследствие несовпадения 
с выбранной согласно специфике задачи, но и из-за ошибок элементов самой А-
платформы. Таким образом, именно операционная среда призвана исправлять 
все обнаруженные ошибки БИС и ПО, входящих в базовую вычислительную 
платформу.