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

47 гает распределение отдельных частей системы между несколькими группами конструкторов, т.е. декомпозицию обязанностей. Поскольку в состав системной архитектуры входит высокоуровневая декомпозиция системы, именно она служит основой для декомпозиции обязанностей.
Это определяет в свою очередь структуру планирования, определения сроков и бюджета, каналы межгруппового взаимодействия, организа- цию управления конфигурациями и файловой системой, планы и проце- дуры интеграции и др.
3. Переносимая абстракция системы. Программная архитектура – это относительно небольшая вполне доступная для человеческого вос- приятия модель структурирования системы и взаимодействия ее компо- нентов. Помимо прочего эта модель обладает свойством переносимости из системы в систему. Например, ее можно применять в отношении других систем, для которых характерны примерно те же требования к атрибутам качества и функциональным возможностям, и тем самым дать начало полноценному многократному применению.
По мере накопления полезных архитектурных образов и образцов проектирования становится очевидным, что, несмотря на безграничные возможности комбинирования компьютерных программ, сведение вари- антов к относительно небольшому количеству альтернатив в контексте взаимодействия между программами и их сотрудничества может при- нести определенные выгоды. Таким образом, проектная сложность кон- струируемой программы сводится к минимуму. Среди преимуществ этого принципа следует отметить повышенные возможности много- кратного применения, более стандартизованные и простые решения, которые легче понять и распространять, углубление анализа, сокраще- ние длительности отбора и совершенствование способности к взаимо- действию.

48 ментировать процесс разработки и применение тех или иных инстру- ментальных средств. Спецификация требований – это только начало.
Существует масса других ограничений, которые необходимо учитывать при выборе варианта архитектуры программной системы.
1. Влияние на архитектуру оказывают заинтересованные в системе
лица и организации. Они включают среди прочих, заказчика, конечных пользователей, разработчиков, руководителей проекта, специалистов по сопровождению и маркетингу. У разных заинтересованных лиц есть свои представления о свойствах системы. В частности, они высказыва- ют пожелания относительно поведения системы при прогоне, произво- дительности на тех или иных аппаратных средствах, настраиваемости, переносимости на другие платформы, быстрого выхода на рынок и низ- ких затрат на разработку, высокой заработной платы программистов соответствующих специальностей и т. д.
Желательно, чтобы у системы были такие свойства, как высокая производительность, надежность, готовность, совместимость с различ- ными платформами, умеренное потребление памяти, возможность ис- пользования в сети, безопасность, модифицируемость, практичность, способность взаимодействия с другими системами и приемлемое пове- дение. Именно из этих свойств складывается архитектура. От этих ее свойств зависит, понравится ли система заинтересованным лицам.
Трудность в том, что каждое заинтересованное лицо имеет свои представления о свойствах желаемой системы и свои задачи, которые могут иногда быть противоречивыми. Желаемые свойства системы можно изложить в таком артефакте, как перечень требований, что и должен сделать заказчик. Однако такого рода документ, в котором все требования сформулированы достаточно подробно, разработать непро- сто, потому и встречаются они довольно редко. Как правило, архитек- тору приходится исправлять такой документ и улаживать противоречия.
2. Влияние на архитектуру оказывает компания-разработчик. Воз- действие компании-разработчика не исчерпывается доработкой совме- стно с заказчиком требований, предъявляемых к системе. На архитекту- ру оказывает влияние структура и характер организации компании- разработчика [9]. Например, если в компании достаточно много про- граммистов, специализирующихся на клиент-серверных технологиях, то весьма вероятно, что руководство компании будет настаивать на разра- ботке клиент-серверной архитектуры.
Факторы влияния, действующие в рамках компании-разработчика, делятся на три группы: краткосрочные экономические, долгосрочные экономические и организационные. Остановимся на краткой характери- стике этих факторов.
Компании делают прямые инвестиции в различные активы, в част- ности, в существующие варианты архитектуры (разработанные ранее) и основанные на них продукты. В этом случае каждый последующий про- ект мыслится как продолжение ряда подобных систем, а в его смете за- кладывается повторное использование имеющихся средств.

49
Следуя своим стратегическим задачам. Компании делают долго- срочные инвестиции в инфраструктуру. В таком случае предполагаемая система мыслится как одно из средств финансирования и расширения этой инфраструктуры.
Определенное влияние на программную архитектуру оказывает ор- ганизационная структура компании-разработчика. Басс Л. [9] приводит пример разработки системы моделирования условий полета для ВВС
США, в которой компания-разработчик привлекла к работе несколько субподрядчиков, обладающих штатом специалистов в данной области.
Специализация разработки подсистем стала возможной благодаря реа- лизованному в архитектуре разделению функций.
3. Влияние на архитектуру оказывают опыт и привычки архитек-
торов. Если у архитектора есть опыт применения того или иного архи- тектурного решения, то, скорее всего, он будет его использовать в по- следующей работе. С другой стороны, если предыдущие попытки при- менения того или иного решения были неудачны, архитектора будет трудно убедить использовать это решение вновь. Решения в арсенале архитектора появляются по мере повышения образовательного уровня и накопления опыта, использования архитектурных образцов и обраще- ния с системами, которые работали плохо или особенно хорошо. Кроме того, многие архитекторы имеют обыкновение экспериментировать с новыми образцами архитектуры и методиками, о которых они узнают из различных источников.
4. Влияние на архитектуру оказывает техническая база. Подготов- ка и опыт архитектора, в частности проявляется в его работе с техниче- ской базой. Определенное воздействие на архитектуру оказывают суще- ствующие в настоящее время технические средства. Здесь может идти речь как о методах работы, принятых в данной отрасли, так и о приемах программной инженерии, распространенных в профессиональном со- обществе, в которое входит архитектор.
5. На архитектуру оказывает влияние ее окружение. Система раз- мещается в некотором окружении, и это окружение оказывает влияние на архитектуру. Окружение определяет границы, в которых должна ра- ботать система, а это влияет на архитектуру. Факторы окружения, влияющие на архитектуру – это миссия бизнеса, которую будет под- держивать архитектура; заинтересованные в системе лица; внутренние
(стандарты организации) и внешние технические ограничения (необхо- димость взаимодействия с внешней системой).
2.4. Архитектурные образцы, эталонные модели и эталонные ва-
рианты архитектуры
Как отмечает Л. Басс, между простейшими “ набросками” архитек- тур и комплексными архитектурами, укомплектованными всей необхо- димой информацией о системах, существуют многочисленные переход- ные этапы. Каждый из этих этапов представляет собой результат приня- тия ряда архитектурных решений, совокупность архитектурных альтер-

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

51
Соответствие может быть как однозначным, так и неоднозначным. В программном элементе может быть реализована как отдельная часть функции, так и несколько функций сразу.
В заключение этого раздела заметим, что эталонные модели, архи- тектурные образцы и эталонные архитектуры не являются вариантами архитектуры. Это не более чем полезные понятия, способствующие фиксации отдельных элементов архитектуры. Каждый из них появляет- ся как результат проектных решений, принимаемых на самых ранних этапах разработки программных систем.
2.5. Что определяет и на что влияет выбранная
архитектура
Свойства программного проекта во многом определяются выбран- ным архитектурным образцом. Те образцы, которые в наибольшей сте- пени подходят для решения конкретной задачи, повышают качество реализации конечного проектного решения. Так что же определяет и на что влияет выбранная архитектура [9, 14]?
1. Архитектура определяет структуру. Термин структура чаще все- го используется при представлении архитектуры. Действительно, струк- тура является важнейшей характеристикой архитектуры. Структурные аспекты архитектуры проявляются многими способами. Структурный элемент может быть подсистемой, процессом, библиотекой, базой дан- ных, вычислительным узлом, системой в традиционном смысле, гото- вым продуктом и т. д. Многие определения архитектуры признают не только сами структурные элементы, но и композиции из структурных элементов, их связи, любые соединительные звенья, необходимые для поддержки этих отношений, интерфейсы и разбиения.
Каждый из этих элементов может быть представлен различными способами. Например, соединительное звено может представлять собой сокет, быть синхронным или асинхронным, быть связанным с конкрет- ным протоколом и т. д. Пример некоторых структурных элементов по- казан на рис. 2.1. На нем изображена диаграмма классов UML, содер- жащая некоторые структурные элементы, которые представляют систе- му обработки заказов. Представлено три класса – OrderEntry,
CustomerManagement и AccountManagement. Класс OrderEntry зависит от класса CustomerManagement и от класса AccountManagement.
Рис. 2.1. Структурные элементы в диаграмме классов

52 2. Архитектура определяет поведение. Наряду с определением структурных элементов любая архитектура определяет взаимодействие между этими структурными элементами. Это такие взаимодействия, которые обеспечивают желаемое поведение системы. Это такие взаи- модействия, которые обеспечивают желаемое поведение системы. На рис. 2.2 представлена диаграмма сценария UML, которая показывает несколько взаимодействий, которые в сумме позволяют системе под- держивать создание заказа в системе обработки заказов.
На рис. 2.2 показано пять взаимодействий. Сначала, деятель Sales
Clerk создает заказ при помощи экземпляра класса OrderEntry. Экземп- ляр класса OrderEntry получает сведения о клиенте при помощи экземп- ляра класса CustomerManagement. Затем экземпляр класса OrderEntry использует экземпляр класса AccountManagement для того, чтобы соз- дать заказ, внести в него элементы заказа, а затем разместить заказ.
Следует заметить, что рис. 2.2 согласуется с рис. 2.1 так, что можно из- влечь зависимости, показанные на рис. 2.1, из взаимодействий, опреде- ленных на рис. 2.2. Эта зависимость отражается в отношении зависимо- сти между соответствующими классами
OrderEntry и
CustomerManagement, как показано на рис. 2.1.
Рис. 2.2. Диаграмма сценария UML
3. Архитектура концентрируется на значимых элементах. Хотя ар- хитектура определяет структуру и поведение, она определяет не все в структуре и поведении. Она занимается только такими элементами, ко- торые оцениваются как значимые. Значимые элементы – это такие эле- менты, которые имеют продолжительное и устойчивое действие, на- пример, главные структурные элементы, элементы, связанные с основ- ным поведением, и элементы, которые определяют значимые свойства,