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

42
Стандарт рекомендует для каждого представления фиксировать от- раженные в нем взгляды и интересы, роли лиц, которые заинтересованы в таком взгляде на систему, причины, обуславливающие необходимость такого рассмотрения системы, несоответствия между элементами одно- го представления или между различными представлениями, а также различную служебную информацию об источниках информации, датах создания документов и пр.
Стандарт IEEE 1471 отмечает необходимость использования архи- тектуры системы для решения следующих задач:
1.
Анализ альтернативных проектов системы.
2.
Планирование перепроектирования системы, внесения измене- ний в ее организацию.
3.
Общение по поводу системы между различными организация- ми, вовлеченными в ее разработку, эксплуатацию, сопровождение, приобретающими систему или продающими ее.
4.
Выработка критериев приемки системы при ее сдаче в эксплуа- тацию.
5.
Разработка документации по ее использованию и сопровожде- нию, включая обучающие и маркетинговые материалы.
6.
Проектирование и разработка отдельных элементов системы.
7.
Сопровождение, эксплуатация, управление конфигурациями и внесение изменений и поправок.
8.
Планирование бюджета и использования других ресурсов в проектах, связанных с разработкой, сопровождением или эксплуата- цией системы.
9.
Проведение обзоров, анализ и оценка качества системы.
В стандартах IEEE Std 1472000 и IEEE 1471 определяются также следующие термины, связанные с определением архитектуры.
Система – это набор компонентов, объединенных для выполнения определенной функции или набора функций. Термин “система” охваты- вает отдельные приложения, системы в традиционном смысле, подсис- темы, системы систем, линейки продуктов, семейства продуктов, целые корпорации и другие агрегации, имеющие отношение к данной теме.
Система существует для выполнения одной или более миссий в своем окружении (IEEE 1471). Здесь несколько терминов, которые следует пояснить.
Окружение, или контекст, определяет ход и обстоятельства эконо- мических, эксплуатационных, политических и других влияний на сис- тему.
Миссия – это применение или действие, для которого одно или не- сколько заинтересованных лиц планируют использовать систему в со- ответствии с некоторым набором условий.
Заинтересованное лицо – это физическое лицо, группа или организа- ция (или ее категории), которые заинтересованы в системе или имеют связанные с ней задачи.

43
Говоря об архитектуре программных систем, прежде всего надо оп- ределить понятие “программная система”. Распространено такое опре- деление:
“ Программная система – это совокупность системных, прикладных и сервисных программ, обеспечивающих решение некоторой совокуп- ности задач”.
Программные системы могут входить в состав программных ком- плексов. Обычно это более масштабные системы в рамках больших тех- нических и организационных систем. Системы, в свою очередь могут состоять из подсистем. Архитектурные решения необходимы на каждом из этих уровней.
Любая система может рассматриваться с разных точек зрения: пове- денческой (динамической), структурной (статической), логической
(удовлетворение функциональным требованиям), физической (распре- деленность), реализации (как детали архитектуры представляются в ко- де) и т.п. В результате можно рассматривать получаем различные архи- тектурные представления (view). Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рас- сматривающие специфические свойства программной системы.
Классическим источником комплекса архитектурных точек зрения и представлений, построенных в системе координат “вопрос-уровень де- тализации” является модель Захмана [12]. Каждое архитектурное пред- ставление является результатом ответа на вопрос (Как? Что? Где? и т.п.) в контексте необходимого уровня абстракции. Например, физическая модель данных (Physical Data Model) является ответом на вопрос “что?” в контексте технологической модели, а логическая модель данных, от- вечая на тот же вопрос, находится на один уровень абстракции выше – в контексте системной или логической модели.
В информационных технологиях понятие архитектур используется в следующих областях: функциональная архитектура (бизнес-архитектура); системная архитектура (программных систем); технологическая или инфраструктурная архитектура; информационная архитектура (организация данных).
Следует отметить, что в определениях архитектуры часто употреб- ляется слово “компонент”. Большая часть определений архитектуры не определяет термин “компонент”. Стандарт IEEE 1471 намеренно ос- тавляет это понятие неопределенным, чтобы оно соответствовало мно- жеству толкований, возможных в отрасли. Компонент может быть логи- ческим или физическим, технологически-независимым или технологи- чески-связанным, крупно- или мелкогранулированным.
Определение термина "компонент" по спецификации UML 2.0 дается в достаточно широком смысле, что позволяет охватить различные эле- менты архитектуры [11]:
Компонентом называется модульная часть системы, которая инкап- сулирует ее содержимое; воплощение компонента является замещае- мым в его окружении. Поведение компонента определяется в терминах

44 предоставляемого и требуемого интерфейсов. Таким образом, компо- нент используется в качестве типа, соответствие которого описывается этими двумя интерфейсами, предоставляемым и требуемым (объединяя как статическую, так и динамическую их семантику).
Хотя в отрасли программного обеспечения не существует общепри- знанного определения понятия "архитектура”, имеет смысл рассмотреть и другие определения, чтобы можно было установить сходство между ними. Рассмотрим следующие определения, в которых курсивом выде- лены основные характеристики термина в каждом отдельном определе- нии.
Архитектура – это:
1) набор значимых решений по поводу организации системы программ- ного обеспечения;
2) набор структурных элементов и их интерфейсов, при помощи кото- рых компонуется система, вместе с их поведением, определяемым во взаимодействии между этими элементами;
3) компоновка элементов в постепенно укрупняющиеся подсистемы, а также стиль архитектуры, который направляет эту организацию – элементы и их интерфейсы, взаимодействия и компоновку. Такое определение дает Крачтен – создатель RUP (Rational Unified Process)
[15].
Архитектура программы или компьютерной системы - это структу-
ра или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними. [9].
Архитектура – это структура организации и связанное с ней поведе-
ние системы. Архитектуру можно рекурсивно разобрать на части, взаи- модействующие посредством интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы [16].
Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур про- граммы и взаимодействий между этими структурами, которые состав- ляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной.
Проектные решения предоставляют концептуальную основу для разра- ботки системы, ее поддержки и обслуживания [3].
В заключение приведем определение архитектуры программного обеспечения, данного в SWEBOK (Software Engineering Body of
Knowledge) – документе, подготовленном комитетом Software Engineer- ing Coordinating Committee, в который вовлечено сообщество IEEE
Computer Society [7]. Назначение SWEBOK – в объединении знаний по инженерии программного обеспечения (разработке программного обес- печения).
По SWEBOK в строгом значении архитектура программного обеспе- чения (software architecture) – описание подсистем и компонентов про- граммной системы, а также связей между ними. Архитектура пытается

45 определить внутреннюю структуру получаемой системы, задавая спо- соб, которым система организована или конструируется.
Хотя приведенные определения несколько отличаются, можно ви- деть немалую степень сходства. Например, большинство определений указывают на то, что архитектура связана со структурой и поведением, а также только со значимыми решениями, может соответствовать некото- рому архитектурному стилю, на нее влияют заинтересованные в ней лица и ее окружение, она воплощает решения на основе логического обоснования.
Таким образом, можно видеть, что слова «архитектура программ- ной системы» обычно довольно согласованно понимаются специали- стами на уровне подсознания, и достаточно несогласованно определя- ются. По мнению Н. Михайловского [18], сложилось два основных класса определений архитектур – конструктивные и идеологические.
Основные идеологические определения архитектуры ПС таковы:
1. Архитектура ИС – это набор решений, наиболее существенным об- разом влияющих на совокупную стоимость владения системой.
2. Архитектура ИС – это набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения.
Оба эти определения согласованы в том смысле, что если ключевое решение приходится изменять при изменении бизнес-технологии в рам- ках бизнес-видения, то резко возрастает стоимость владения системой.
Следствием этих определений является понимание важности принятия архитектуры системы как стандарта предприятия, ввиду значимости архитектурных решений и их устойчивости по отношению к изменени- ям бизнес-технологии. Еще одно важное следствие первого определения
– архитектура системы на самом деле должна строиться еще на стадии технико-экономического обоснования системы.
Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы: что делает система; на какие части она разделяется; как эти части взаимодействуют; где эти части размещены.
2.2. Почему важна архитектура
Наверное, следующее высказывание подтвердит значимость архи- тектуры ПС [18]. Архитектура – это то, за что увольняют системного архитектора и руководителя проекта. Кто-то может заметить, что проек- ты на самом деле проваливаются из-за неправильной организации про- цесса разработки. Не отрицая этого, можно сказать, что известно гораз- до больше успешных систем, построенных в “кривом процессе” разра- ботки, чем успешных систем с “кривой архитектурой”
Вначале остановимся на вопросе, почему важна архитектура про- граммной системы с технической точки зрения. В этом контексте следу- ет привести три основных фактора, которые отмечает Л. Басс [9].

46 1. Взаимодействие между заинтересованными лицами. Программная архитектура – это универсальная абстракция системы, на основе кото- рой все или почти все заинтересованные в системе лица могут искать взаимопонимания, вести переговоры, находить компромиссы. В этом плане архитектура – это общий язык, на котором можно сформулиро- вать, обсудить и решить те или иные проблемы на уровне доступном для комплексного изучения человеком.
Каждое заинтересованное в программной системе лицо – заказчик, пользователь, руководитель проекта, программист и т. д. – требует вне- дрить в систему различные характеристики, основа для которых закла- дывается в архитектуре. Пользователю необходимо, чтобы система бы- ла надежной и доступной в любой момент. Заказчика интересует, чтобы программная система была реализована без расхождений с графиком и бюджетом. Менеджер озабочен не только соблюдением временных и финансовых ограничений. Но и возможностью организации при помо- щи архитектуры относительно независимой работы различных групп разработчиков, их четкого и управляемого взаимодействия. Архитектор думает о том, какие стратегии позволят ему решить все эти задачи.
2. Начальные проектные решения. Программная архитектура содер- жит сведения о том, какие решения были приняты на ранних этапах разработки системы. Значимость подобного рода сведений не ограничи- вается удельным весом этих этапов относительно оставшихся операций разработки и сопровождения. Именно в это время впервые появляется возможность анализа проектных решений, определяющих дальнейшую разработку системы.
Начальные проектные решения труднее всего принять, а по мере разработки – скорректировать. При этом последствия наиболее сущест- венны. Архитектура определяет ограничения реализации. Реализацию следует разделить на ряд установленных архитектурой элементов.
Взаимодействие между этими элементами должно производиться в ус- тановленном архитектурой порядке. Обязательства каждого элемента в отношении других элементов должны исполняться согласно требовани- ям архитектуры. Решения о распределении ресурсов также накладывают определенные ограничения на реализацию.
Проблема в том, что конструкторы, работающие над отдельными элементами, иногда не имеют об этих решениях ни малейшего пред- ставления. Рассматриваемые решения подразумевают разделение задач, благодаря которому решения менеджера в плане трудовых и вычисли- тельных ресурсов реализуются наилучшим образом. От конструкторов отдельных элементов требуется знание их спецификаций, однако во всем, что касается компромиссных архитектурных решений, они могут пребывать в полном неведении. Архитекторы, напротив, обычно не яв- ляются экспертами в области разнообразных аспектов построения алго- ритмов и тонкостей языков программирования, но именно ответственны за принятие архитектурных компромиссов.
Архитектура определяет организационную структуру. Стандарт- ный способ разделения труда по разработке крупной системы предпола-