Файл: Инфрам.pdf

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

54 специалист по сопровождению заинтересован в понятном, непроти- воречивом и документируемом принципе проекта, а также в легко- сти, с которой можно вносить изменения.
Многие пункты из списка интересов являются нефункциональными, т.е. не влияют на функциональность системы (например, интерес по отношению к цене и планированию). Тем не менее, такие интересы формулируют свойства или ограничения системы. Нефункциональные требования очень часто являются самыми значимыми требованиями, поскольку в них заинтересован разработчик архитектуры.
Как видно из этого списка, заинтересованные лица хотят не только то, чтобы система обеспечивала необходимую функциональность, но и массу других нефункциональных требований. К тому же некоторые из требований противоречивы. Задача разработчика архитектуры обеспе- чить компромиссное решение.
При выборе архитектуры необходимо учитывать основные факторы, определяющие:
1) трудоемкость разработки – масштаб; сложность (техническую и логическую); ясность целей.
2) основные цели разработки (цели продукта), вытекающие из требова- ний к системе, – эффективность; расширяемость (масштабируемость, облегчение добавления новых свойств); адаптируемость (облегче- ние смены требований); простота (понимания, реализации); надеж- ность (отсутствие ошибок).
3) цели проекта - удобство сопровождения; стоимость; сроки реализа- ции и т.п.
5. Архитектура воплощает решение на основе логического обосно-
вания. Важнейший аспект архитектуры – ее логическое обоснование.
Важно обеспечить документирование решений, которые привели к соз- данию этой архитектуры, и логическое обоснование таких решений. Эта информация является значимой для многих заинтересованных лиц., особенно для тех, кто должен обслуживать систему. Она имеет опре- деленную ценность для разработчика архитектуры, когда ему нужно пересмотреть логические обоснования принятых решений, чтобы избе- жать ненужного повторения своих действий. Эта информация использу- ется при пересмотре архитектуры, а новому разработчику помогает по- нять принятые ранее решения.
6. Архитектура может соответствовать некоторому архитек-
турному стилю. Архитектурный стиль определяет семейство систем в терминах шаблона организации структуры. Архитектурный стиль опре- деляет номенклатуру компонентов и типов соединительных звеньев, а также набор условий, в соответствии с которыми они могут соединяться
[14]. Большинство архитектур построено на основе систем, которые используют сходные наборы интересов. Сходство может быть опреде- лено как архитектурный стиль, который можно рассматривать как осо- бый вид шаблона, хотя этот шаблон часто является сложным и состав- ным (при одновременном применении нескольких шаблонов). Примеры архитектурных стилей включают распределенный стиль, стиль "каналы

55 и фильтры", стиль с централизованной обработкой данных, стиль, по- строенный на правилах и так далее. Конкретная система может демон- стрировать более одного архитектурного стиля. Как и шаблон, архитек- турный стиль представляет собой кодификацию опыта, для разработчи- ков архитектур желательно использовать этот опыт.
В терминах UML шаблон - это общее решение общей проблемы в данном контексте. Применение архитектурного стиля (или шаблона) несколько облегчает жизнь разработчиков, поскольку стиль обычно до- кументирован в терминах рационального обоснования его использова- ния (меньше придется обдумывать) и в терминах его структуры и пове- дения (придется выработать меньше документации по архитектуре, по- скольку вместо этого можно просто обратиться к стилю).
7. Архитектура определяет ограничения реализации. Реализация от- ражает архитектуру только в том случае, если она соответствует изло- женным в ней проектным решениям. Таким образом, реализацию следу- ет разделить на ряд установленных архитектурой элементов. Взаимо- действие между этими элементами должно производиться в установ- ленном архитектурой порядке. Обязательства каждого отдельного эле- мента в отношении других элементов также должны исполняться со- гласно требованиям архитектуры.
Решения о распределении ресурсов также накладывают на реализа- цию определенные ограничения. Проблема в том, что конструкторы, работающие над отдельными элементами. Иногда не имеют об этих ре- шениях ни малейшего представления. Рассматриваемые ограничения подразумевают разделение задач, благодаря которому менеджерские решения в плане трудовых и вычислительных ресурсов реализуются наилучшим образом. От конструкторов отдельных элементов требуется знание их спецификаций, однако во всем, что касается компромиссных архитектурных решений, они могут пребывать в неведении. Архитекто- ры, напротив, обычно не являются экспертами в области аспектов по- строения алгоритмов и тонкостей языков программирования, однако именно они ответственны за принятие архитектурных компромиссов.
8. Архитектура способствует или сдерживает реализацию атри-
бутов качества системы. Способность или неспособность системы реализовать предполагаемые атрибуты качества в значительной степени обусловлена архитектурой. При этом важно понимать, что сама по себе архитектура не гарантирует ни функциональности, ни качества. На ка- чество системы влияют все решения, вне зависимости от того, на каком этапе ее жизненного цикла они принимаются, будь это этап высоко- уровневого проектирования или этап кодирования. Следовательно, ка- чество нельзя признать полностью находящимся в зоне ответственности архитектурного проектирования. В контексте обеспечения качества хо- рошая архитектура необходима, но не достаточна.
Можно ли, не дожидаясь окончания разработки и размещения сис- темы, утверждать, что те или иные архитектурные решения приняты верно? Будь ответ на этот вопрос отрицательным, задача выбора архи- тектуры потеряла бы всякий смысл – ее можно было бы выбрать произ-

56 вольно! На самом деле существуют методики оценки архитектур. Так в монографии Л. Басса [9] дан метод анализа архитектурных решений
ATAM (Architecture Tradeoff Analysis Method).
9. Архитектура облегчает анализ изменений и их организацию. В продолжении своего жизненного цикла программные системы обычно часто претерпевают изменения, которые во многих случаях реализуются с некоторыми трудностями. Любая архитектура предполагает разделе- ние всех возможных изменений на следующие категории: локальные, нелокальные и архитектурные. Для внесения локальных изменений дос- таточно откорректировать соответствующий отдельный элемент. Нело- кальное изменение требует корректировки нескольких элементов. Од- нако базовые архитектурные принципы при этом остаются неизменны- ми. Архитектурные изменения затрагивают сущность взаимодействия между элементами – образец архитектуры – и в большинстве случаев предполагают корректировку всей системы.
Для принятия решений о необходимости внесения изменений, уста- новления наименее опасных путей, оценки последствий предполагае- мых изменений, определения последствий и расстановки приоритетов относительно требуемых изменений – для всего этого требуется под- робный анализ взаимоотношений, производительности и поведения программных элементов системы. Все эти задачи прописаны в должно- стной инструкции архитектора. Средством приобретения знаний. Доста- точных для принятия решений о предполагаемых изменениях следует считать анализ архитектуры.
10. Архитектура облегчает эволюционное макетирование. Любую архитектуру можно проанализировать и смоделировать в качестве маке- та. Процесс разработки от этого выигрывает в двух отношениях.
Система становится исполняемой на раннем этапе жизненного цикла продукта. ЕЕ точность повышается по мере замены элементов макета полноценными версиями программного обеспечения.
Из того, что система довольно рано становится исполняемой, следу- ет, что потенциальные проблемы, связанные с производительностью, выявляются на ранних этапах ее жизненного цикла.
Каждый из этих факторов снижает риск разработки.
11. Архитектура позволяет более точно рассчитать стоимость и
сроки создания системы. Рассчитав стоимость и составив график, руко- водитель может, во-первых, получить необходимые ресурсы, а во- вторых, узнать, удовлетворительно ли состояние проекта. Расчеты стоимости на основе блоков системы оказываются точнее тех, которые базируются на общих знаниях о системе. Организационная структура проекта определяется его архитектурой. Расчеты по блокам лучше по- ручить не руководителю проекта. а участникам соответствующей груп- пы разработчиков. Они, во-первых, справятся с этой задачей точнее, а во-вторых, будут ощущать ответственность за соблюдение установлен- ных сроков.
12. Архитектура оказывает влияние на окружение. Создание архи- тектуры изменяет окружение с технологической точки зрения – может

57 также изменить среду в терминах навыков, доступных в пределах орга- низации. Когда речь идет о преимущественно программных системах, то следует учитывать конкретные аспекты окружения. Для того чтобы
ПС работала, ее запускают на некотором аппаратном обеспечении. По- этому результирующая система представляет собой сочетание про- граммного и аппаратного обеспечения, и именно это сочетание позволя- ет добиться таких характеристик, как надежность и производитель- ность.
Стандарт IEEE Std 12207 – 1995, IEEE Standard for Information Tech- nology – Software Life Cycle Process (Стандарт IEEE по информацион- ным технологиям – Процессы жизненного цикла приложения) опреде- ляет систему иначе, чем стандарт IEEE 1471, который концентрируется на преимущественно-программных системах [14]:
Системой называется интегрированный комплекс, состоящий из одного или более процессов, аппаратных устройств, программ, средств и людей, предоставляющий возможность удовлетворить данную по- требность или условие.
Техническое описание “A configuration of the Rational Unified Process for System Engineering (RUP SE)” [1] содержит похожее определение:
Системой называется набор ресурсов, предоставляющий сервисы, которые используются предприятием для выполнения цели или миссии бизнеса. Компоненты системы обычно состоят из аппаратного обеспе- чения, программного обеспечения, информационных ресурсов и со- трудников.
В области системного проектирования компромисс достигается за счет реализации системы в большей или меньшей степени теми или иными компонентами. Так, если ключевой фактор – производитель- ность, то принимается решение реализовать определенные элементы системы аппаратными устройствами. В другом случае чтобы предоста- вить удобную для покупателей систему, принимается решение предос- тавить клиентский интерфейс не программой, а человеком.
Интересно отметить, что системное проектирование особенно заин- тересовано в том, чтобы рассматривать программное, аппаратное обес- печение и людей как равноценные понятия, избегая, таким образом, неверных заключений, в которых аппаратные устройства рассматрива- ются как элементы второго сорта по сравнению с программными или наоборот.
13. Архитектура оказывает влияние на структуру и задачи компа-
нии-разработчика. Архитектура обусловливает структуру системы, в частности набор блоков программ, которые надлежит реализовать, а потом интегрировать в рамках системы. Группы разработчиков уком- плектовываются именно по блокам; операции в рамках процессов раз- работки, тестирования и интеграции также выполняются в отношении блоков. Согласно графикам и бюджетам ресурсы выделяются частями на отдельные блоки. Если компания наработала опыт конструирования семейств сходных систем, она будет вкладывать средства в повышение