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

58 профессионального уровня разработчиков. Следовательно, группы встраиваются в структуру организации.
Каждая из этих групп может требовать различных наборов навыков.
Поэтому имеет смысл выровнять структуры групп разработчиков про- граммного обеспечения в соответствии с архитектурой после того, как она будет определена. Однако чаще встречается ситуация, когда перво- начальная группа разработчиков оказывает влияние на архитектуру, а не наоборот. Это ошибка, которой следует избегать, поскольку в результа- те обычно получается архитектура, далекая от идеала. "Закон Конвея" утверждает, что "если у вас есть четыре группы, работающих над ком- пилятором, то вы получите четырехпроходный компилятор". Практиче- ски часто непреднамеренно создаются архитектуры, которые являются отражением организации, создающей архитектуру [14].
Однако так же справедливо будет сказать, что это несколько идеали- зированное представление не всегда реально, поскольку, по причинам чисто прагматичным, реальная структура коллектива и доступные на- выки представляют весьма ощутимое ограничение того, что могло бы быть, и разработчику следует это учитывать.
Архитектура способна оказывать воздействие на задачи компании- разработчика. Сконструированная на основе определенной архитектуры успешная система предоставляет компании возможность укрепиться в данном сегменте рынка. Такая архитектура предусматривает дальней- шее эффективное производство, вследствие чего компания может от- корректировать свои задачи и, воспользовавшись своим новым пре- имуществом, занять соответствующую нишу рынка. Таким образом, существует обратная связь от системы к компании-разработчику и кон- струируемым ею системам.
14. Архитектура помогает в процессе обучения. Архитектура, со- держащая описание взаимодействия элементов в рамках требуемого поведения, может послужить своеобразной инструкцией, вводящей но- вых участников проекта в курс дела. Этим дополнительно подтвержда- ется утверждение о том, что одной из основных функций программной архитектуры является организация и содействие общению между пред- ставителями различных заинтересованных групп.
15. Архитектура представлена в каждой системе. Каждая система имеет архитектуру, даже если эта архитектура формально не докумен- тирована или система слишком проста. Обычно документирование ар- хитектуры представляет собой очень ценное средство. Документиро- ванные архитектуры имеют тенденцию быть более продуманными - а, следовательно, более эффективными, чем недокументированные, по- скольку процесс записи архитектуры естественным образом ведет к все- стороннему обдумыванию.
Если архитектура не документируется, трудно (если не невозможно) доказать, что она соответствует утвержденным требованиям в терминах адресных характеристик, таких как удобство обслуживания, заимство- вание передового опыта и так далее.

59
В заключение этого раздела следует отметить, что архитектура име- ет особую область применения [14]. В области разработки программно- го обеспечения можно встретиться с различными формами архитекту- ры. Например, помимо понятия архитектура программного обеспечения можно столкнуться с такими понятиями, как корпоративная архитекту- ра, системная архитектура, организационная архитектура, архитектура информации, архитектура аппаратного обеспечения, архитектура при- ложения, архитектура инфраструктуры и так далее. Можно услышать также и другие термины, каждый из которых определяет особую об- ласть разработки архитектуры.
К сожалению, в отрасли IT-технологий не существует соглашения о значении каждого из этих терминов или их отношениях друг к другу, в результате чего одни и те же термины могут иметь разные значения
(омонимы), а два или более терминов могут обозначать одно и то же
(синонимы). Однако об области применения некоторых из этих терми- нов можно сделать вывод на основании рис. 2.3. Если внимательно изу- чить рисунок и описание, то определенно можно найти элементы, с ко- торыми вы не согласны или элементы, которые в вашей организации используются по-другому. Но в этом и смысл – показать, что термины используются в отрасли, но по поводу их значений нет согласия.
Рис. 2.3. Основные термины ИТ-отрасли
Элементы, показанные на рисунке 2.3: архитектура программного обеспечения (Software), главная тема данного раздела, как было определено выше; архитектура аппаратного обеспечения (Hardware), которое включает такие элементы, как ЦПУ, память, жесткие диски, периферийные устройства, например, принтер, а также элементы, используемые для их соединения; архитектура организации (Organization), которая включает элементы, имеющие отношение к бизнес-процессам, структурам организации,

60 ролям и ответственности, а также основные области специализации организации; структура информации (Information), включающая структуры, кото- рые упорядочивают информацию.
Архитектура программного обеспечения, архитектура аппаратного обеспечения, архитектура организации и архитектура информации яв- ляются подмножеством целостной архитектуры системы (System). Ар- хитектура корпорации (Enterprise), которая похожа на архитектуру сис- темы тем, что тоже включает элементы, а именно: аппаратное и про- граммное обеспечение и людей. Однако архитектура корпорации более сильно связана с бизнесом, так как она концентрируется на достижении бизнес-целей и занимается такими объектами, как быстрое реагирова- ние на возникающие ситуации и эффективность организации. Архитек- тура корпорации может выходить за границы компании.
Как и следовало ожидать, существуют корреспондирующие формы, например, разработчик архитектуры (разработчик архитектуры про- граммного обеспечения, разработчик архитектуры аппаратного обеспе- чения и так далее) и разработка архитектуры (например, разработка ар- хитектуры программного обеспечения, разработка архитектуры аппа- ратного обеспечения и так далее). После рассмотрения этих определе- ний, многие вопросы остались без ответа.
В чем заключается разница между архитектурой корпорации и архи- тектурой системы? Является ли корпорация системой? Архитектура информации и архитектура данных, которая встречается в некоторых преимущественно-информационных программах - это одно и то же? К сожалению, в отрасли программного обеспечения нет непротиворечи- вых определений этих терминов и их взаимосвязей. Следовательно, можно рекомендовать выбирать термины, подходящие для конкретной организации, и соответствующим образом их определять. Тогда, по крайней мере, можно добиться некоторой непротиворечивости и уменьшить вероятность недопонимания между заинтересованными ли- цами.

61 венно ряд элементов, существующих в раках программного или аппа- ратного обеспечения. В частности модульная структура представляет собой набор модулей системы с указанием их организации. Модульное представление есть отображение этой структуры, документируемое и применяемое теми или иными заинтересованными лицами. Нужно ска- зать, что эти термины (структура и представление) часто используются как синонимы.
По классификации, предложенной в [9], архитектурные структуры подразделяются на три общие группы, в каждую из которых включают- ся элементы определенного характера.
1. Модульные структуры. Элементами таких структур являются мо- дули – блоки реализации. Модули предполагают рассмотрение системы с точки зрения программного кода. Модульные структуры позволяют отвечать на такие вопросы, как: “Какие функциональные требования выполняет данный модуль? К каким программным элементам он может обращаться? Какое программное обеспечение он фактически использу- ет? Между какими модулями установлены отношения обобщения или специализации (например, наследования)?
2. Структуры “компонент и соединитель”. В данном случае эле- ментами являются компоненты (основные единицы вычислений) и со- единители (инструменты взаимодействия между компонентами) перио- да прогона (выполнения). Среди вопросов, на которые отвечают струк- туры “компонент и соединитель”, такие, например, как: “Каковы основ- ные исполнительные компоненты и как происходит их взаимодействие?
Каковы основные совместно используемые хранилища данных? Какие части системы воспроизводятся? Каким образом по системе проходят данные? Какие элементы системы способны выполняться одновремен- но? Какие структурные изменения происходят в системе во время ее исполнения?”
3. Структуры распределения. Структуры распределения демонстри- руют связь между программными элементами, с одной стороны, и эле- ментами одной или нескольких внешних сред, в которых данное про- граммное обеспечение создается и исполняется, – с другой. Они отве- чают на вопросы: “На каком процессоре исполняется данный про- граммный элемент? В каких файлах каждый элемент хранится в ходе разработки, тестирования и конструирования системы? Каким образом программные элементы распределяются между группами разработчиков?”
Перечисленные три структуры соответствуют трем универсальным типам решений, применяемым в ходе архитектурного проектирования: каким образом следует структурировать совокупность блоков кода
(модулей) системы? каким образом следует структурировать совокупность элементов системы, обладающих поведением (компоненты) и демонстрирую- щих взаимодействие (соединители) в период прогона?

62 каким образом установить связи между системой и непрограммными структурами среды (например, с процессорами, файловыми систе- мами, сетями, группами разработчиков и т. д.)?
Наиболее распространенные и полезные программные структуры приведены на рис. 2.4.
Рис. 2.4. Программные структуры
Модульные структуры делятся на следующие разновидности.
1.
Декомпозиция. В качестве блоков выступают модули, между которыми установлены отношения “является подмодулем…”. Таким образом, крупные модули в рекурсивном порядке разлагаются на меньшие, и этот процесс завершается только тогда, когда меньшие модули становятся вполне понятными. Модули в рамках этой струк- туры часто используются в качестве отправной точки для после- дующего проектирования – архитектор перечисляет блоки, с кото- рыми ему предстоит работать, и в расчете на более подробное проек- тирование, а также реализацию, распределяет их между модулями.
Структура декомпозиции в значительной степени обеспечивает мо- дифицируемость системы – при этом складывается ситуация, когда наиболее вероятные изменения приходятся на долю нескольких не- больших модулей.
2.
Варианты использования. Блоками этой важной, но не слишком распространенной структуры могут быть либо модули, либо (когда требуется более мелкая структура) процедуры или ресурсы интер- фейсов модулей. Между такими блоками устанавливаются отноше- ния использования. Структура использования полезна при конструи- ровании систем, которые легко расширяются дополнительными функциями, либо предлагают возможность быстрого извлечения по- лезных функциональных подмножеств. Способность без труда раз- бить рабочую систему на ряд подмножеств подразумевает возмож- ность инкрементной разработки – многофункционального конструк- торского приема.
3.
Многоуровневые. Если отношения использования в рамках этой структуры находятся под строгим, особым образом осуществляемом контроле, возникает система уровней – внутренне связанных набо-

63 ров родственных функций. В рамках строгой многоуровневой струк- туры уровень N может обращаться к услугам только в том случае, если они представлены уровнем N-1. На практике это правило суще- ствует в виде многочисленных вариантов, которые частично снима- ют приведенное структурное ограничение. Уровни во многих случа- ях проектируются в виде абстракций (виртуальных машин), которые, стараясь обеспечить переносимость, скрывают детали своей реали- зации нижележащих уровней от вышележащих.
4.
Класс или обобщение. Блоки модулей в рамках этой структуры называются классами. Отношения между ними строятся по образцам
“наследуют от…” и “являются экземпляром…”. Данное представле- ние способствует анализу коллекций сходного поведения или сход- ных возможностей (например, классов, которые наследуют от дру- гих классов) и параметрических различий, фиксация которых произ- водится путем определения подклассов. Структура классов позволя- ет анализировать вопросы повторного использования и инкремент- ного введения функциональности.
Структуры “компонент и соединитель”.
Среди структур данного вида выделяются следующие структуры.
1.
Процесс или сообщающиеся процессы. Подобно другим струк- турам “компонент и соединитель”, эта является ортогональной по отношению к модульным структурам, поскольку она связана с дина- мическими аспектами исполняемой системы. В качестве блоков в данном случае выступают процессы или потоки, связь между кото- рыми устанавливается путем передачи данных, синхронизации и/или операций исключения. Здесь, как и во всех остальных структурах
“компонент и соединитель”, действует отношение прикрепления, демонстрирующее связь компонентов друг с другом. Структура про- цессов существенно облегчает конструирование рабочей производи- тельности и готовности системы.
2.
Параллелизм. Данная структура позволяет архитекторам выяв- лять перспективы параллелизма и локализовать возможности состя- заний за ресурсы. В качестве блоков выступают компоненты, а со- единители играют роль “логических потоков”. Логическим потоком называется такая последовательность вычислений, которую впослед- ствии, в ходе процесса проектирования, можно связать с отдельным физическим потоком. Структура параллелизма задействуется на ранних этапах проектирования и способствует выявлению требова- ний к организации параллельного исполнения.
3.
Совместно используемые данные или репозиторий. В состав данной структуры входят компоненты и соединители, обеспечиваю- щие создание, хранение и обращение к данным постоянного хране- ния. Она наилучшим образом приспособлена к таким ситуациям, ко- гда система структурирована на основе одного или нескольких репо- зиториев совместно используемых данных.
4.
Клиент-сервер. Эта структура предназначена для систем, скон- струированных в виде группы взаимодействующих клиентов и сер-

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