Системы с открытой архитектурой

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

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

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

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

Часто говорят, что системы, обладающие перечисленными свойствами, имеют открытую архитектуру. Ее упрощенная схема представлена на рис. 1.

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

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

Рассмотрим основные свойства и приемы разработки систем с открытой архитектурой.

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

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

3. Особую роль в системах с открытой архитектурой играет инфраструктура или каркас. Именно она в большой мере обеспечивает гибкость системы. Для этого инфраструктура должна обладать достаточными резервами пропускной способности и не накладывать на систему лишних ограничений. Особой гибкостью обладают те системы, в которых обеспечивается связь между любыми ее компонентами. Наиболее эффективны инфраструктуры, основанные на общепринятых стандартах взаимосвязей между компонентами. Во-первых, стандарты впитывают в себя значительный опыт разработчиков подобных систем, более того, стандартную инфраструктуру можно приобрести либо целиком, либо частично. Во-вторых, под стандартную инфраструктуру можно найти готовые компоненты, а у компонент, разрабатываемых заново, появляется шанс быть использованными не только в данной системе, но и в других системах, основанных на таком же интерфейсе (расширение рынка сбыта – дополнительный стимул).

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

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

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

7. Важную роль в смысле гибкости системы играют не только стандартные правила взаимодействия компонент через инфраструктуру, но и фактическое наполнение передаваемой/принимаемой компонентами информации, другими словами интерфейс компонент (на рис. 1 интерфейс условно показан в виде разъемов, посадочных мест). В ряде случаев удается так обобщить интерфейс компонента, что значительные переделки внутреннего содержания последнего никак не отражаются на его интерфейсе, а значит, и на других компонентах, на всей системе в целом. Компонент воспринимается системой, как черный ящик. Он виден только через свой интерфейс, а его внутреннее исполнение скрыто (т.н. прием инкапсуляции). Если интерфейс не поменялся, то неважно поменялось ли содержимое компонента. Подобные интерфейсы компонент принято называть стабильными.

9. Взаимодействие между компонентами следует всячески ослаблять. Чем меньше предположений и увязок будет между компонентами, тем легче их удалять/заменять/добавлять. Другими словами легче конфигурировать систему.

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

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

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