на главную поиск по сайту карта сайта
+7 (495) 646-0612info@informicus.ru

Оформить заказ

Оказываем полный спектр услуг в сфере информационных технологий. Разработка, внедрение и сопровождение программного обеспечения. Анализ, оценка эффективности и консультирование в сфере использования информационных систем. А также собственные программные решения для оптимизации вашего бизнеса.
Разработка программ, разработка ПО на заказ, торговые роботы    
ГЛАВНАЯ О КОМПАНИИ РЕШЕНИЯ УСЛУГИ СТАТЬИ

СТАТЬИ

СТАТЬИ

К оглавлению.

Компонентно-базированная разработка

Принципы компонентно-базированного подхода к разработке ПС

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

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

КБ подход базируется на трех основных принципах:

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

Отделение спецификации от реализации

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

Инкапсуляция данных и процессов

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

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

Абстракция и автоматизация

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

Чем компонент отличается от класса?

Компоненты во многих отношениях подобны классам но имеют и существенные отличия от последних.

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

Библиотеки компонентов

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

В языке UML предусмотрена возможность показать логическую модель компонента, включая описание его интерфейсов, взаимодействие компонент в ПС и физическую реализацию компонент для каждого узла (компьютера) в многозвенной ПС.

Логическое моделирование компонентов

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


Рис.1. Логическая модель компонента.
На диаграмме показаны два интерфейса, имеющиеся у компонента. Для стереотипа <> возможно использование стандартного графического изображения. В этом случае отношение реализации показывается в виде линии. Оба интерфейса реализуются классом «Управление счетами», который имеет также внутренние (закрытые) операции проверки (CheckPassword и CheckPermission).

Моделирование взаимодействия компонентов

При моделировании взаимодействия удобно изображать компоненты в виде пакетов и показывать их интерфейсы (см. рис.2).


Рис.2. Диаграмма классов, показывающая взаимодействие компонент

Диаграммы компонентов

На диаграммах компонентов показывается физическое разбиение ПС на компоненты и другие программные блоки, а также отношения зависимости между ними. Можно, используя пакеты для обозначения узлов многозвенной ПС в одном пакете собрать компоненты, реализуемые на этом узле (см. рис.3).


Рис. 3. Диаграмма компонентов
««НазадДалее»»

90
Проектное управление
Проектное управление
Подробнее
89
Аспекты проектного управления
Аспекты проектного управления
Подробнее
82
Что такое Rational Unified Process (RUP)
Что такое Rational Unified Process (RUP)
Подробнее
73
Цикл статей по моделированию программных систем
Цикл статей по моделированию программных систем
Подробнее
1234

телефон/факс: +7 (495) 646-0612/687-9964

105120, г. Москва, ул. Нижняя Сыромятническая,д. 5/7

info@informicus.ru

COPYRIGHT INFORMICUS, 2006 - 2020

Главная | О компании | Решения |
Услуги | Статьи | Карта сайта