Книги, научные публикации
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ КОМПОНЕНТНАЯ АРХИТЕКТУРА С ОПРЕДЕЛЕНИЕМ ТИПОВ ВО ВРЕМЯ ИСПОЛНЕНИЯ Е.М. Гринкруг, кандидат технических наук, доцент кафедры Управления разработкой
программного обеспечения Национального исследовательского университета Высшая школа экономики, e-mail: egrinkrug
А.Р. Шакуров, аспирант кафедры Управления разработкой программного обеспечения Национального исследовательского университета Высшая школа экономики, e-mail: amir-shak@yandex.ru.
Адрес: г. Москва, ул. Кирпичная, д. 33/5.
В работе рассматриваются вопросы компонентного подхода к разработке программного обеспечения. На основе анализа основных идей данного подхода, их реализации в существую щих на сегодняшний день технологиях, присущих им ограничений и перспективных направлений их развития предлагается новая компонентная архитектура, расширяющая функциональ ные возможности существующих компонентных моделей. Описываются основные принципы построения данной архитектуры.
Ключевые слова: компонент, компонентная разработка, интерфейс, реализация.
1. Введение Наиболее распространёнными примерами по вторного использования кода являются программ азработка программного обеспечения Ч тру ные библиотеки, паттерны проектирования [5] и доёмкий процесс, и неудивительно, что по каркасы приложений. Объектно-ориентированное Р вторному использованию кода [8] придаётся и обобщённое программирование [4] также содер большое значение. Многократное использование жат в своей основе данную идею. Однако наиболее реализованной функциональности снижает трудо многообещающей её формой нам представляется затраты при разработке больших программных си стем, сокращает количество ошибок в коде и упро- компонентный подход к созданию программного щает его сопровождение. обеспечения [9].
БИЗНЕС-ИНФОРМАТИКА №1(15)Ц2011 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ Под программным компонентом в общем случае использование конечным приложением (runtime).
понимают некоторую сущность, содержащую дан- Необходимость такого разделения признана и до ные и реализующую функциональность, скрытые некоторой степени реализована (см., напр., [13]), за чётко определёнными интерфейсами (ср. [10] и однако, на наш взгляд, в этой области возможно [11]). Взаимодействие с подобным чёрным ящи- достичь большего.
ком осуществляется исключительно через интер Приведём пример. Пусть, проектируя приложе фейс. Более точное определение компонента при ние с графическим интерфейсом, мы должны изме ведено в разделе 4.
нить надпись на компоненте кнопка. Изменение Само понятие линтерфейса трактуется по- окончательно: после запуска программы надпись разному в различных технологиях. Это может быть меняться не будет. Реализации данного процесса совокупность свойств (латрибутов, членов и (запись в соответствующее свойство необходимой т.п.) [13] или самостоятельная неделимая сущность строки) в различных технологиях обладают общим [2]. Возможны и другие варианты. Ниже мы пред недостатком: переменное свойство остаётся из ложим оптимальный, на наш взгляд, подход и при меняемым и после запуска приложения. Т.о., хотя ведём ряд аргументов в его пользу.
заранее известно, что надпись на кнопке во время В рамках компонентной идеологии соедине- исполнения должна быть константой, реализовать ние компонентов в работоспособную систему по- это существующими средствами невозможно.
лагается сравнительно простой операцией (см., На данную проблему можно взглянуть иначе.
напр., [3]). Но манипулирование структурой ком Сложность глубокой подстройки компонента под понентной системы осуществляется в разных тех контекст использования (разделение designtime Ч нологиях различными способами. Наша задача Ч runtime Ч лишь частный пример) связана с тем, найти оптимальный вариант организации взаи что фактически речь идёт об определении нового модействия компонентов, представляющий собой типа данных. И т.к. любые манипуляции с компо сбалансированное между гибкостью и простотой нентом предполагают использование его функцио использования решение.
нальности и, следовательно, его запуска, определе ние нового типа должно осуществляться во время 2. Ограничения существующих исполнения (и без перекомпиляции).
компонентных моделей Существуют обходные пути: генерация кода (так поступает большая часть инструментов визуально Несмотря на очевидные преимущества компонент го проектирования GUI (напр., [1])) и вызов ком ного подхода, его реализации в тех или иных техно пилятора, непосредственная генерация байт-кода логиях на сегодняшний день имеют ряд существен и т.п. Однако компилятор доступен далеко не во ных ограничений.
всякой среде исполнения;
данное ограничение, в Основная сложность, по-видимому, заключается частности, свойственно встраиваемым системам.
в том, что сторонний код всегда либо недостаточно По этой причине представляются интересными универсален, либо содержит избыточную функци системы, не прибегающие к помощи компилято ональность. Последнее характерно для программ ров и т.п. обходных путей и способные создавать из ных библиотек, т.к. универсальность Ч критически компонентов, настроенных по усмотрению поль важное для них свойство. Но избыточность приво зователя, новые типы, оставаясь при этом в рамках дит к неоправданному раздуванию итоговой си собственной компонентной модели.
стемы, усложнению процесса разработки и т.п.
Компонент может быть сделан более специали 3. Структуризация данных зированным, т.к. он структурно меньше, чем целая и управление потоком исполнения библиотека. Но и компромисс между универсаль ностью и специализированностью здесь более ва Рассмотрим основные аспекты распространён жен: если иногда есть возможность использовать ных сегодня языков программирования и компо лишь часть библиотеки, то часть компонента ис нентных технологий с целью выявить общие идеи, пользовать не удастся, не нарушив инкапсуляции.
лежащие в их основе, и найти наиболее подходя Одним из способов достижения указанного ком- щие реализации каждой из них. Анализ определит промисса является разделение работы с компонен- основные черты предлагаемой модели, описание том на проектирование и разработку (designtime) и которой приведено в следующем разделе.
БИЗНЕС-ИНФОРМАТИКА №1(15)Ц2011 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ Детальное рассмотрение конкретных языков и мальна в силу ограниченного количества характе технологий и их отличительных особенностей вы- ристик понятия свойство и операций над ним.
ходит за рамки данной работы (подобный обзор Однако свойства, как они реализованы, напр., в можно найти в [12]). Мы отталкиваемся от анализа C#, не могут конкурировать с методами в части объектно-ориентированной концепции в целом, предоставляемых разработчику возможностей. Так, приводя частные примеры и привлекая технологии, если свойство предоставляет лишь доступ для чте выходящие за рамки объектно-ориентированной ния/записи, реализация широко известного меха парадигмы, когда это необходимо, т.к. требование низма обратных вызовов затруднительна. Т.о., мы возможности определения новых типов во время приходим к необходимости добавления операции исполнения приводит к необходимости построе- связывания.
ния компонентной технологии, где время разра Итак, мы указали на два ключевых принципа Ч ботки и время исполнения не имеют строгого раз иерархическую организацию компонентов и их граничения.
взаимодействие, основанное на свойствах, Ч сле Всякая среда разработки/исполнения может быть дование которым, на наш взгляд, необходимо для рассмотрена с точки зрения предлагаемых ею прин создания компонентной технологии, удобной в ципов и механизмов 1) организации данных и 2) практическом применении. Наряду с требованием управления потоком исполнения. С точки зрения возможности определения новых типов компонен первого аспекта для объектно-ориентированной тов во время исполнения, эти принципы легли в программы отметим возможность иерархической основу предлагаемого решения, к описанию кото организации данных. Это проверенное средство рого мы сейчас переходим.
борьбы с нарастающей сложностью программных систем, поэтому предлагаемая компонентная мо 4. Предлагаемое решение дель предполагает возможность объединения ком Охарактеризуем компонентную модель, реализа понентов во взаимодействующие группы, представ ция которой позволит сохранить преимущества су ляющие собой новые компоненты, и т.д. (строго ществующих технологий и моделей, устранив пере говоря, в группы объединяются типы компонентов, численные выше ограничения.
после чего создаются сами составные компоненты, см. раздел 4).
К числу основных категорий, которыми опериру ет модель, относятся: компонент, тип компонента В части управления потоком исполнения, как и редактор типа компонента. Формальные опреде нам кажется, объектно-ориентированный подход не столь удачен. Взаимодействие объектов осу- ления приведены ниже, но, забегая вперёд, отме тим, что под компонентом понимается сущность, ществляется посредством методов, но концепция метода чересчур гибка, что приводит к усложнению представляющая собой основной строительный структуры программ, использующих её. Метод мо- блок программной системы и инкапсулирую жет возвращать значение, а может не возвращать щая данные и поведение. Тип компонента Ч это его. Возвращаемое значение может быть ссылкой сущность, описывающая тип данных, хранимых в на внутреннее поле объекта, но может являться и компонентах данного типа, и содержащая другую его защитной копией. Он может иметь произволь- метаинформацию. Редактор типа Ч это средство ное количество параметров произвольных типов, определения новых типов компонентов на основе а может не иметь их вовсе. Список можно продол- существующих.
жить. Понятие метода не предоставляет возмож ности достаточной формализации взаимодействия 4.1. Компонент объектов.
Идея компонентной разработки программного Концепция свойства, присутствующая в некото обеспечения в первую очередь предполагает разгра рых технологиях (C#, JavaBeans), более удачна. Она ничение линтерфейс Ч реализация, что позволяет сочетает в себе как признаки поля объекта (типизи осуществлять разработку и использование компо рованность, строго заданный набор операций: чте нента независимо.
ние, запись), так и признаки метода (за операциями может скрываться определённая программистом Под компонентом будем понимать чёрный функциональность). Модель взаимодействия ком- ящик, функциональность и данные, скрытые за понентов, основанная на свойствах, проста и фор- интерфейсом. Компонент, т.о., характеризуется БИЗНЕС-ИНФОРМАТИКА №1(15)Ц2011 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ интерфейсом и реализацией, а также состоянием, Реализация т.е. данными, содержащимися в нём и изменяющи Придерживаясь идеи организации компонентов мися в течение жизни.
в иерархические структуры, мы различаем три вида Интерфейс компонента определяется набором его компонентов: примитивные, скомпилированные и свойств Ч именованных атрибутов, для которых составные.
определён тип значения и права доступа.
Реализация определяет поведение компонента, его функциональность и отличается у примитив A1 B1 C1 D1 E1 F1 G ных, составных и скомпилированных компонентов.
Интерфейс A4 B4 C Элементарной ячейкой интерфейсной части ком понента является его свойство. Свойством мы на зываем имеющую строго определённый тип име нованную сущность, представляющую некоторый аспект или атрибут компонента, к которой, воз можно, применимы некоторые из трёх операций A2 B2 C2 A3 B3 C (см. рис. 1):
чтение Ч получение текущего значения данно- го свойства;
запись Ч установка текущего значения;
связывание Ч операция подключения слуша- Рис. 2. Реализация: компонент содержит в себе три подкомпонента, связанных друг с другом и со свойствами надкомпонента.
теля события изменения свойства.
Пунктирные линии показывают установленные событийные связи, Применимость данных операций определяется штрихпунктирные соединяют между собой разделяемые свойства.
правами доступа (устанавливаемыми типом компо нента, см. раздел 4.2).
Примитивные компоненты аналогичны прими тивным типам в языках программирования. Они чтение инкапсулируют данные наиболее распространён запись ного вида: целые и дробные числа, логические зна связывание чения, символы, строки символов и ряд других. С точки зрения модели, примитивные компоненты A B C D неделимы, т.е. не состоят из других компонентов, и интерфейс не обладают свойствами.
Примитивные компоненты Ч типичный пример реализация лобъектов-значений, значение которых задаётся при создании и не может быть изменено. Важней шей характеристикой примитивного компонента Рис. 1. Интерфейс компонента, состоящий из свойств A, B, C является индивидуальность его значения.
и D с различными режимами доступа.
Составные компоненты представляют собой (с Значение свойства, если оно доступно для чте- точки зрения реализации) наборы других компо ния, определяется внутренним состоянием компо- нентов, сочленённых посредством двух механиз нента, на которое, в свою очередь, влияют опера- мов: событий и разделяемых свойств. В подобных ции записи свойств. случаях мы будем говорить об объемлющем компо ненте (надкомпоненте) и вложенных компонентах Операция связывания свойства A со свойством B (подкомпонентах).
(A и B могут принадлежать различным компонен там) позволяет компоненту-владельцу свойства B Событийная связь предполагает, что над свой получать уведомления о каждом изменении зна- ствами двух подкомпонентов была произведена чения свойства A в виде записи нового значения в описанная выше операция связывания некоторых свойство B. из их свойств.
БИЗНЕС-ИНФОРМАТИКА №1(15)Ц2011 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ Связь посредством разделения подразумевает сле- Перейдём теперь к описанию типов компонентов дующее. Компонент, создаваемый внутри другого и механизмов их создания.
компонента, в процессе создания получает ссылку на свойство своего надкомпонента. Это вынуждает 4.2. Тип компонента его не создавать новое свойство (что делается при создании компонента вовне других компонен Тип компонента представляет собой именован тов), а использовать существующее свойство объ ную сущность, специфицирующую, каким обра емлющего компонента для последующих операций зом должен создаваться компонент данного типа. взаимодействия с внешним миром (чтение/запись/ Т.о., понятие типа аналогично понятию класса в связывание). Реализация данного механизма опи объектно-ориентированных языках.
сана в разделе 4.2. Одно свойство надкомпонента Типы содержат в себе описание интерфейса, реа может быть разделено несколькими свойствами лизации и их взаимосвязи для компонентов дан подкомпонентов, что позволяет достаточно гибко ного типа. Интерфейсная часть типа содержит организовывать взаимодействие в системе.
перечень дескрипторов свойств, каждый из которых Заметим, что способ прикрепления свойства задаёт имя (либо индекс или любой другой ладрес) компонента к его реализации (определения, каким свойства будущего компонента, его тип, права до образом операции над свойством взаимодействуют ступа и, возможно, значение по умолчанию.
с реализацией) в принципе может иметь достаточно Реализационная часть типа различна для при сложный характер. Одна крайность - это описание митивных, скомпилированных и составных типов взаимодействия на некотором языке программиро (однозначно соответствующих трём рассмотрен вания, другая - это тривиальная реализация, когда ным категориям компонентов). Для примитивных свойство лишь предоставляет доступ к внутренней типов она сводится к хранению текущего значения переменной компонента. Вышеописанный подход - компонента. Для скомпилированных типов Ч это компромисс, не перегруженный сложностью и не указание способа получения реализации создавае лишённый гибкости.
мого компонента и связывания его с интерфейсом.
Подкомпоненты некоторого компонента могут Так, для создания компонента, реализация которо сами являться составными компонентами. Подоб го основана на технологии JavaBeans, достаточно ная иерархия может иметь рекурсивную вложен указания имени соответствующего java-класса Ч ность произвольной глубины (ограниченную лишь дальнейшие действия осуществляются с помощью доступными аппаратными средствами), будучи на механизма отражений Java [6].
нижнем уровне представлена примитивными ком Наибольший интерес представляет составной понентами.
тип. В части реализации он включает в себя список Скомпилированные компоненты Ч это компо дескрипторов подкомпонентов, каждый из которых ненты, реализованные средствами, отличными от задаёт тип соответствующего подкомпонента в бу описанных выше средств реализации составных дущем компоненте и, возможно, его начальное зна компонентов. Их поддержка необходима для инте чение.
грации со сторонними технологиями (такими как JavaBeans). Эта информация дополняется данными о связях:
для каждого свойства каждого подкомпонента Анализ реализации скомпилированного компо указывается, какое свойство надкомпонента оно нента моделью не производится. Этим скомпили разделяет (если разделение имеет место);
рованные компоненты схожи с примитивными. Два перечисляются событийные связи для тех основных различия: 1) последние не имеют свойств свойств (подкомпонентов и надкомпонента), для и являются (неизменяемыми) компонентами которых это необходимо.
значениями;
2) скомпилированные компоненты, Прежде чем переходить к описанию процесса ин как и составные, имеют состояние по умолчанию станциирования (создания экземпляра) типа, вве и могут быть сконструированы вне какого-либо внешнего контекста, тогда как создание прими- дём понятие поля компонента. Поля являются сред тивных компонентов без указания как минимум их ством реализации механизма разделения свойств.
значения лишено смысла. Если компонент создаётся вне другого компонента, Всякий компонент в момент создания получает и сохраняет ссылку на собственный тип, тем самым однозначно ассоциируя себя с ним.
БИЗНЕС-ИНФОРМАТИКА №1(15)Ц2011 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ он создаёт лячейку, соответствующую этому свой- Перечисленное выше содержимое типа (переч ству, с которой взаимодействует его внутренняя ни дескрипторов свойств, событийных связей, де реализация. Но если компонент в момент инициа- скрипторов подкомпонентов) Ч это три свойства лизации получает ссылку на некоторое свойство типа тип.
надкомпонента, он должен использовать её везде, Специфика понятия тип накладывает важное где в обычном случае использовал бы упомянутую ограничение на манипулирование типами как ком лячейку. Т.о., эта лячейка должна иметь ссылоч понентами: тип по своей сути является сущностью ный тип, исполняя роль посредника во взаимодей неизменяемой, т.к. содержит в себе метаинформа ствии реализации компонента с его свойствами, цию о других сущностях. Необходимость определе а адрес ссылки должен определяться контекстом ния новых типов во время исполнения, о которой инициализации компонента. Подобную ячейку шла речь выше, не требует, тем не менее, модифи ссылку мы и называем полем. кации существующих типов: достаточно иметь воз Опишем теперь процесс конструирования ком- можность создания нового типа, являющегося мо понента. Он подразумевает следующую последова- дифицированной версией прежнего.
тельность шагов.
1. Создаются и инициализируются (в зависимо 4.3. Определение типов сти от контекста) поля компонента (по одному на во время исполнения каждый дескриптор свойства составного типа или описание свойства скопилированного типа). Рассмотрим вопрос определения новых типов во 2. Создаётся реализация компонента. В случае со- время исполнения. Предлагаемая модель предо ставного типа создаются подкомпоненты (по одно- ставляет возможность следующей логики действий.
му на дескриптор подкомпонента);
если свойство 1. Пользователь, выбрав тип компонента из библи Ai некоторого подкомпонента i должно быть раз отеки типов (включающей в себя предопределён делено со свойством A0 надкомпонента, в момент ные примитивные типы, а также составные типы, инициализации компоненту i передаётся ссылка на определённые ранее), создаёт редактор типа Ч A0. В случае примитивного типа в компоненте со специальную сущность, в которую заключена храняется его значение, заданное пользователем. В функциональность определения новых типов на случае скомпилированного типа создание реализа основе существующих. Она принимает на вход су ционной части компонента зависит от нижележа ществующий тип и позволяет совершать операции, щей технологии.
перечисленные ниже.
3. Интерфейс прикрепляется к реализации.
2. Пользователь имеет возможность настроить Для составного компонента это означает установ полученную структуру.
ку необходимых событийных связей между его Он может изменить дескрипторы свойств:
свойствами и свойствами подкомпонентов. Для имя, значение по умолчанию, права доступа.
скомпилированного компонента данный шаг, как Важно, что компонент глубоко подстраивает и предыдущий, зависит от технологии, на основе ся под контекст. Так, если пользователь указал, которой он реализован.
что свойство, прежде доступное для чтения, за После инстанциирования типа результирующий писи и связывания, будет доступно только для компонент обладает соответствующими свойства- чтения, реализация свойства как переменной ми и реализацией. Все ограничения, отслеживаемые должна измениться на реализацию в виде кон компонентами в процессе функционирования, - станты (в смысле языка программирования).
контроль типов, доступа и др. - основываются на Пользователь может редактировать мета метаинформации, заложенной в их типах. данные реализации: добавлять и удалять под компоненты, устанавливать и удалять собы Заметим, что, стремясь минимизировать коли тийные связи между ними, добавлять и удалять чество независимых категорий, которыми опе отношения разделения свойств.
рирует модель, мы считаем типы компонентами.
Т.о., существует тип тип, экземплярами кото- 3. Когда необходимые модификации произве рого являются все типы (в т.ч. и сам этот тип). дены, созданный составной тип можно добавить в Описанное понятие сходно с концепцией поля в языке VRML [7].
БИЗНЕС-ИНФОРМАТИКА №1(15)Ц2011 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ библиотеку типов и в дальнейшем использовать его этапе, когда в библиотеке имеются только прими наравне с другими типами. тивные типы.
5. Заключение Редактор типа, т.о., предоставляет доступ к вну тренним данным типа и позволяет модифицировать Мы рассмотрели основные положения новой их копию, с тем чтобы иметь возможность создавать компонентной архитектуры, расширяющей воз видоизменённые варианты типов, экземпляры ко можности существующих компонентных моделей.
торых существуют в системе. Реализация редактора Мы полагаем (и постарались аргументировать эту типа, благодаря такому подходу, становится доста точку зрения), что принципы, заложенные в ней, точно простой;
мы не станем останавливаться на обусловливают высокую гибкость и универсаль ней в данной работе.
ность. Возможность порождения новых типов по В заключение заметим также, что редактор типа зволит системам, реализованным на базе данной позволяет помещать произвольную редактируемую архитектуры, развиваться значительно более ин им структуру в составной компонент. Это необходи- тенсивно, чем это доступно традиционному про мо для полноты модели, в частности, на начальном граммному обеспечению.
Литература 1. Boudreau T., Glick J., Greene S. NetBeans: The Definitive Guide. Ч OТReilly Media, 2002. Ч 672 с.
2. Bruneton E., Coupaye T., Stefani J.B. The Fractal Component Model specification. Version 2.0-3. Ч The ObjectWeb Consortium, 2004. Ч 52 с.
3. Costa Seco J., Silva R., Piriquito M. ComponentJ: A Component-Based Programming Language with Dynamic Reconfiguration. // Computer Science and Information System. Ч2008. Ч Vol. 5, No. 2. Ч С. 63-86.
4. Dos Reis G., J rvi J. What is Generic Programming? // Library-Centric Software Design. Ч2005. Ч С. 1-11.
5. Gamma E., Helm R., Johnson R. Design Patterns: Elements of Reusable Object-Oriented Software. Ч Addison Wesley, 1994. Ч 416 с.
6. Gosling J., Joy B., Steele G. The JavaЩ Language Specification. Ч 3-е изд. ЧAddison Wesley, 2005. Ч 688 с.
7. International Standard ISO/IEC 14772-1:1997. The Virtual Reality Modeling Language. URL: web3d.org/x3d/specifications/vrml/ISO-IEC-14772-VRML97/ (дата обращения: 20.05.2010) 8. Krueger C.W. Software reuse. // ACM Comput. Surv. Ч Vol. 2. Ч New York: ACM. Ч 1992. Ч С. 131-183.
9. McIlroy M.D. Mass produced software components. // Naur P., Randell B., Software Engineering, Report on a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968. Ч Brussels: Scientific Affairs Division, NATO. Ч 1969. Ч С. 138-155.
10. Object Management Group. The Common Object Request Broker: Architecture and Specification. Version 3.1.
Part 3 - Components. Ч OMG document formal/2008-01-08. Ч 2008. Ч 192 с.
11. Redmond F.E. DCOM: Microsoft Distributed Component Object Model. Ч Foster City: IDG Books Worldwide, Inc. Ч 1997. Ч 384 с.
12. Stiemerling O. Component-Based Tailorability. Ч Bonn: Bonn University. Ч 2000. Ч 180 с.
13. Sun Microsystems Inc. The JavaBeansЩ API specification. Version 1.01-A. Ч Sun Microsystems Inc. Ч 1997.
Ч 114 с.
БИЗНЕС-ИНФОРМАТИКА №1(15)Ц2011 г.