Даже при ОО подходе повторное использование программ связано с рядом ограничений. Разработчик, в частности, не желает разбираться во всех деталях поведения повторно используемых частей или настолько быть к ним привязанным, что впоследствии не сможет их заменить. Для систем высокой сложности иерархии наследования часто становятся огромными, трудно понимаемыми и нашпигованными отношениями, делающими невозможным их замену. Давление на разработчиков еще усиливается, если повторно используются части, созданные внешними производителями, так как они становятся еще более объемными и изощренными и доступными только в двоичном виде, а не в исходных кодах. Преодоление этих трудностей возможно лишь за счет четкого описания поведения частей и интерфейсов, а также реализации гибких механизмов связывания частей, обеспечивающего простоту добавления и замены частей.
Индустрия программирования в настоящее время обладает возможностью удобной реализации повторного использования программных частей большого объема. Это – результат появления стандартов и поддерживающих их технологий, которые позволяют определять функциональные элементы системы таким образом, чтобы интерфейс элемента отделялся от реализации. Такие интерфейсы могут запоминаться и разыскиваться, что упрощает взаимодействие частей системы даже в случае, когда они размещаются на разных машинах. Именно в этом и есть основное преимущество компонентно-базированного (КБ) подхода к разработке ПС. Заметим, что новые требования к разработке ПС – сборка из заготовленных ранее компонентов – не умаляют значимости и корректности ОО подхода. Наоборот, они основаны на этом подходе.
В КБ подходе спецификация (описание) того, что делает компонент, отделяется от того, как он реализуется. В результате в системе устанавливаются зависимости между спецификациями, что позволяет изменять реализацию без влияния на систему. Отделение спецификации компонента от реализации имеет много преимуществ. Главное – это механизм, позволяющий управлять внесением изменений при эволюции системы. Благодаря этому отделению реализация компонента может быть обновлена без влияния на его пользователей, поскольку услуги, предоставляемые компонентом, не изменяются. Таким образом, компонент может легко быть адаптирован к новым операционным требованиям, в нем могут быть реализованы новые алгоритмы, а также использованы преимущества новых платформ.
При КБ проектировании должна быть возможность строгого определения и ограничения влияния внутренних изменений в компоненте на другие компоненты. Это достигается за счет инкапсуляции, которая ограничивает доступ к функциональным элементам компонента и фиксирует набор операций, предоставляемых интерфейсом. Интерфейс определяет, как клиент должен взаимодействовать с компонентом, но скрывает детали реализации. Он содержит всю информацию, необходимую клиенту, обеспечивая разработчику клиента нечувствительность к реализации, языку программирования и в принципе независимость от того, есть реализация компонента или нет.
Через интерфейс пользователи компонента могут получить доступ к действиям, которые может выполнять компонент, независимо от того, как эти действия реализуются. Компонентная технология отодвигает на второй план выбор языка программирования. Более того, язык реализации определяется, исходя из организации разработок, опыта, доступности инструментальных средств и внутренней политики. В действительности большинство компонентов доступны только в двоичном исполняемом коде и язык программирования может быть неизвестен.
Компонент реализуется на конкретной платформе. Одна из проблем, характерная для многих организаций, состоит в том, как при изменении платформы сократить трудозатраты на повторную реализацию поведения компонента. Поэтому требуется абстрактное описание реализации (то есть, модель реализации), которая должна быть достаточно детальной для того, чтобы можно было сгенерировать код для многих различных платформ.
При разработке проектов в рамках одной организации накапливается опыт проектных решений для конкретной области деятельности, которые целесообразно реализовывать в виде компонент. Тогда этот опыт легко использовать в последующих проектах, что позволяет значительно сократить время разработки, поскольку компоненты не только запрограммированы, но и отлажены, а внешнее окружение использует только интерфейсы, но никак не может повлиять на реализацию компонента. Такие внутренние библиотеки компонент дополняются внешними, которые предоставляют стандартную реализацию общих приемов и механизмов программирования и предлагаются различными фирмами, производящими программное обеспечение.
В языке UML предусмотрена возможность показать логическую модель компонента, включая описание его интерфейсов, взаимодействие компонент в ПС и физическую реализацию компонент для каждого узла (компьютера) в многозвенной ПС.
Каждый компонент имеет интерфейс и реализуется одним или несколькими объектами, поэтому логику компонента удобно моделировать с помощью диаграмм классов (см. рис.1). Для этой цели на диаграммах классов UML предусмотрена возможность представления интерфейсов компонент. Интерфейс – это класс, которому присвоен стереотип . Интерфейс связывается с реализующими его классами отношением реализации. Интерфейс не может содержать атрибутов, он включает только сигнатуры операций.
На диаграмме показаны два интерфейса, имеющиеся у компонента. Для стереотипа <> возможно использование стандартного графического изображения. В этом случае отношение реализации показывается в виде линии. Оба интерфейса реализуются классом «Управление счетами», который имеет также внутренние (закрытые) операции проверки (CheckPassword и CheckPermission).
При моделировании взаимодействия удобно изображать компоненты в виде пакетов и показывать их интерфейсы (см. рис.2).
На диаграммах компонентов показывается физическое разбиение ПС на компоненты и другие программные блоки, а также отношения зависимости между ними. Можно, используя пакеты для обозначения узлов многозвенной ПС в одном пакете собрать компоненты, реализуемые на этом узле (см. рис.3).
