Главная картинка статьи №33

Основные объекты и связи, представленные в виде компонентов архитектур программных продуктов


Введение

Уважаемые коллеги!

Ход прошлой встречи мы закончили на том, что обсудили основные характеристики архитектур программных продуктов и базисные требования, которые способствуют их формированию.

Наша сегодняшняя, надо заметить, непродолжительная встреча будет сконцентрирована на рассмотрении объектов, из которых состоят современные архитектуры и связям между ними. Оговоримся, сегодняшняя статья будет довольно конспективной и аспекты, касающиеся направления разработки кода программных продуктов, этики программирования и подобных тем затронуты нами не будут.

Основные объекты аналитической архитектуры программного обеспечения

Современные архитектуры программных продуктов базируются на основе компонентной модели разработок. Под компонентом мы будем понимать модуль системы или отдельный программный продукт, назначение которого состоит в обработке и инкапсуляции его содержимого. Результаты деятельности «черного ящика» должны быть гармонизированы с остальными частями программного продукта. Таким образом, поведение компонента, как основного объекта архитектуры программного продукта, определяется тремя основными группами требований:

  1. Требованиями к внешнему интерфейсу, через который осуществляется взаимодействие с остальными частями архитектуры;
  2. Требования к внутреннему интерфейсу/структуре данных, которые определяют характеристики компонента, его преимущества и недостатки;
  3. Требования к функционалу, интегрирующему внешнее и внутреннее поведение компонента и преобразующему данные в единый формат на основе которого становится возможным взаимодействие между модулями архитектуры программного продукта.

Объект, как элемент архитектуры программного обеспечения, должен поддерживать статические (элементы структуры) и динамические (бизнес процессы) связи компонентов и в зависимости от типа связи поддерживать определенную, спроектированную для конкретных целей, функциональность.

Каждый реализованный объект должен удовлетворять требованиям, предъявляемым к архитектуре программного обеспечения, быть в состоянии поддерживать заданный уровень качества и надежности программного продукта. Особенно важно понимание того, что уровень производительности объекта будет определяться производительностью его самого слабого звена, если способ реализации одного из требований к компоненту будет предполагать дополнительные ресурсные затраты:

  • Время на обработку событий;
  • Правила, процедуры и алгоритмы обработки;
  • И т.д.

Важно четко определить к какому компоненту разработка будет относиться.

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

Адекватная архитектура отличается тем, что она в состоянии балансировать и распределять значимость компонентов (а соответственно и их загрузку) равномерным «слоем» между всеми составляющими её объектами. Это позволяет снизить перегруженность и значимость отдельных объектов и повысить универсальность архитектуры в целом и её возможную производительность, но так как процесс развития архитектуры процесс динамический, архитектурное проектирование должно следовать этим принципам на протяжении всего жизненного цикла программного продукта.

Развитие каждого объекта, являющегося частью архитектуры должно идти в соответствии с развитием архитектуры. Такой принцип позволит избежать появления «узких горлышек» и создать оптимальные, для конкретных условий и организаций, объекты и архитектуру программных продуктов.

Рассматривать типы объектов более подробно, здесь, мы не видим смысла, так как эта отдельная активность, которая больше относится к области программной инженерии. Часть вопросов касающихся объектов и из взаимозависимости с архитектурами и архитектурным проектированием, мы рассмотрим далее, но детально изучать их мы не видим смысла.

После того, как изучены объекты с необходимым уровнем подробности, имеет смысл приступить к теме их связи, которая несет дополнительные характеристики, как положительные, так и негативные, которые мы рассмотрим далее.

Связи между объектами архитектуры

Для осознания возможностей, целей и потенциальных задач применения компонентной архитектуры программного обеспечения, проведем аналогию между архитектурами в строительном проектировании и в архитектурном проектировании программных продуктов.

Автор современного витка строительства серийных сооружений, французский архитектор (оставивший свой «след» и в Москве) Ле Корбюзье, оказал существенное влияние на разработки и массовое применение унифицированных строительных блоков.

Разрабатывая архитектуру зданий и сооружений, француз своей основной целью видел создание не просто отдельного здания (компонента), а пространственной композиции (архитектура), воспринимая строительные блоки примерно так же, как его предшественники-зодчие воспринимали кирпичи.

Результат своей работы Корбюзье представлял в виде архитектурно - пространственного ландшафта, основанного на повсеместном и многоразовом применении блоков, узлов и других составляющих, позволяющих возводить здания и связывать их в единый комплекс, довольно быстро и качественно.

Подобный подход был революцией в строительстве 30-хх годов прошлого века. Отметим, идея была, действительно, новой и эволюционной и проекты, реализованные самим Корбюзье, впечатляли. Дальнейшее развитие этой технологии, без надлежащего контроля, привело к тренду создания советских новостроек конца 50-х и продолжается сейчас в массовом строительстве.

В области информационных технологий ситуация не сильно отличается. Архитектурное проектирование, во многом, является вполне персонализированным ремеслом, влияние отдельной личности в котором можно минимизировать, но исключить вряд ли. В соответствии с развивающейся областью программной инженерии, компоненты являются строительными блоками, с помощью которых создаются архитектуры программных продуктов.

Применение готовых или почти готовых и проверенных компонент смещает основной фокус внимания с объектов на аспект их связи\интеграции. Это предъявляет дополнительные требования к программным архитектурам, которые должны быть совместимы и максимально сочетаемы друг с другом.

Если переложить на бизнес язык понятие компонента, то в общем смысле он представляет собой «часть» конкретного бизнес процесса, а связь между ними приводит процесс в действие и обеспечивает достижение поставленного результата.

Оптимально разработанные связи будут способствовать не только достижению конечного результата, как суммы результатов отдельных компонентов, но и могут «привнести» бонусы, выраженные в виде дополнительной функциональности, быстродействии, надежности и пр. характеристиках, которые могут быть достигнуты за счет эффекта эмерджентности.

Под эмерджентностью мы будем понимать дополнительные свойства, приобретаемые набором компонент, соединенных в единую систему, за счет использования связей между ними и, как возможное следствие, преобразование потенциально не задействованных ранее свойств в явные результативные эффекты. С упорством шизофреников мы повторимся вновь о том, что для достижения основных и дополнительных эффектов важны не только «архитектурные» планы, но и конкретная реализация, доведенная до практического совершенства.

От того, насколько успешно разнородные компоненты будут интегрированы в единую и монолитную структуру в процессе архитектурного проектирования, зависит кпд и возврат инвестиций от создаваемой архитектуры.

Но на нее оказывает влияние не только «внутренности» (компоненты и связи между ними), но и способы их применения и развития, а так же внешние события и атрибуты, используемые в бизнес «окружении» и «кросс» процессах конкретной компании.

Итоги

Данная статья получилась достаточно поверхностной. Так и планировалось .Мы не собирались отбирать хлеб у наших креативных собратьев разработчиков.

В конце скажем лишь о том, что в следующий раз мы поговорим о взаимовлиянии внешнего окружения и его составляющих и архитектуры программных продуктов.

До скорого!

Авторы статьи

Иван Никитин

Михаил Цулая