Формальные модели компонентного программирования

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

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2003
Автор:	Грищенко, В.Н.
Формат:	Стаття
Мова:	Російська
Опубліковано:	Інститут програмних систем НАН України 2003
Теми:	Теоретические и методологические основы программирования
Онлайн доступ:	https://nasplib.isofts.kiev.ua/handle/123456789/1302
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Формальные модели компонентного программирования /В.Н. Грищенко// Проблеми програмування. — 2003. — N 2. — С. 42—57. — Бібліогр.: 18 назв. — рос

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

_version_	1859604784768614400
author	Грищенко, В.Н.
author_facet	Грищенко, В.Н.
citation_txt	Формальные модели компонентного программирования /В.Н. Грищенко// Проблеми програмування. — 2003. — N 2. — С. 42—57. — Бібліогр.: 18 назв. — рос
collection	DSpace DC
description	Предложен подход к построению формальных моделей компонентного программирования как основы создания компонентной теории. Рассмотрены модели компонентов, компонентных сред, определены внешняя и внутренняя компонентные алгебры. Проанализированы различные аспекты предложенных моделей и их связь с практикой программирования. Запропоновано підхід до побудови формальних моделей компонентного програмування як основи створення компонентної теорії. Розглянуті моделі компонентів і компонентних середовищ, визначені зовнішня та внутрішня компонентні алгебри. Проаналізовані різні аспекти запропонованих моделей і їх зв’язок з практикою програмування. The approach to construction of formal models of component programming, as bases of component theory creation, is offered. The models of components, component environments and external and internal component algebra are considered. The various aspects of these models and their relations with practice of programming are analysed.
first_indexed	2025-11-28T02:17:17Z
format	Article
fulltext	Теоретические и методологические основы программирования © В.Н. Грищенко, 2003 42 ISSN 1727-4907. Проблемы программирования. 2003. № 2 УДК 681.3 В.Н. Грищенко ФОРМАЛЬНЫЕ МОДЕЛИ КОМПОНЕНТНОГО ПРОГРАММИРОВАНИЯ Предложен подход к построению формальных моделей компонентного програм- мирования как основы создания компонентной теории. Рассмотрены модели компо- нентов, компонентных сред, определены внешняя и внутренняя компонентные алгеб- ры. Проанализированы различные аспекты предложенных моделей и их связь с практикой программирования. Введение В своем развитии, как отдельное направление в теории и практике про- граммирования, компонентное про- граммирование основывалось на раз- личных концептуальных взглядах, ме- тодических основах и подходах, фор- мальных моделях и методах. Такая си- туация достаточно часто встречается в различных отраслях науки и свиде- тельствует о том, что соответствующая область знаний находится в процессе формирования и постепенного повы- шения уровня формализации. И только в последние годы концептуальные ос- новы были достаточно четко сформу- лированы и сформировался необходи- мый базис для построения теории ком- понентного программирования. Приве- дем основные концепции. 1. Компонентное программиро- вание – это по своей сути композици- онное программирование, где в качест- ве базовых элементов композиции вы- ступают программные компоненты, об- ладающие определенными свойствами и характеристиками. Компоненты яв- ляются базовыми объектами, для кото- рых определяются методы агрегирова- ния в более сложные структуры и пра- вила взаимодействия при построении интегрированных сред и систем [1]. 2. При построении формальных основ компонентного программирова- ния одинаково важную роль играют как практические аспекты его приме- нения, так и результаты соответст- вующих теоретических исследований [2]. Игнорирование этой концепции часто приводило к разработке теорий и формальных моделей, которые либо не могли учитывать всех его особенно- стей, либо не обеспечивали достаточно гибкий базис дальнейшего развития теории, либо просто не были востребо- ваны теоретиками и практиками про- граммирования. 3. Компонентное программиро- вание – это самостоятельный стиль программирования, дополняющий и использующий результаты других дис- циплин и подходов программирования: модульного и сборочного программи- рования [3, 4], объектно-ориентирован- ного подхода [5], повторного использо- вания знаний и программных объектов [6,7] и т.д. Оно имеет свою концепту- альную базу, теоретическое обоснова- ние моделей и методов, соответствую- щие методологии и инструментальные средства. 4. Компонентное программиро- вание – один из подходов к созданию программных систем, и поэтому оно также характеризуется основными концептуальными понятиями про- граммной инженерии [7], присущими другим программным подходам. В част- ности, для него имеется свой жизнен- ный цикл с особенностями проектиро- вания на отдельных фазах и этапах [8], методология тестирования отдельных компонентов и компонентных конфи- гураций, методы обеспечения качества и повышения надежности и др. Эти концепции обеспечивают цельный взгляд на суть, особенности и роль компонентного программирова- ния в современной теории и практике программирования. Поэтому любая теория должна в той или иной мере учитывать приведенные выше аспекты Теоретические и методологические основы программирования 43 и основы. В настоящей статье предла- гается и описывается такой подход к разработке теоретического базиса ком- понентного программирования с уче- том его современного состояния, пер- спектив развития, актуальных задач теории и практики программирования. Определение базовых понятий и терминов Основываясь на приведенных выше концепциях, введем определение компонентного программирования. Под компонентным программи- рованием понимается метод создания программных систем, основанный на применении концепций композиции на всех этапах жизненного цикла, где ба- зовым элементом композиции есть специальная программная единица – компонент. Из этого определения следует, что суть данного метода определяется свойствами и характеристиками ком- понентов, а также операций с ними, конечная цель применения которых состоит в построении компонентной программы. Систематизируя и упоря- дочивая существующие теоретические и практические результаты [9], можно ввести следующее определение про- граммного компонента. Программный компонент или просто компонент – это независимый от языка программирования, самостоя- тельно реализованный программный объект, который обеспечивает выпол- нение определенного множества про- граммных сервисов и представлен как взаимозаменяемый контейнер, доступ к которому возможен только с помо- щью интерфейсов, определяющих его функциональные возможности и поря- док обращения к его операциям. В компонентном программирова- нии компонент является неделимой и инкапсулированной сущностью, удов- летворяющей определенным функцио- нальным требованиям, а также требо- ваниям архитектуры, структуры и ор- ганизации взаимодействия в компо- нентной программе. Поэтому совокуп- ность требований к конкретному ком- поненту на самом деле определяет классы компонентов, то есть все мно- жество компонентов разбивается на совокупность классов эквивалентности относительно требований для каждой создаваемой компонентной программы. Любые представители этих классов обеспечат построение данной про- граммы при условии, что для этого над ними выполняются допустимые опера- ции. Исходя из этих предпосылок, вве- дем определение компонентной про- граммы. Компонентная программа – со- вокупность компонентов (представите- лей из соответствующих классов экви- валентности), необходимых для обеспе- чения функциональных и других тре- бований, которая построена и функ- ционирует в соответствии с определен- ными правилами создания компонент- ных конфигураций и компонентного взаимодействия. Эти правила состав- ляют основу компонентной модели. Компонентная модель – это оп- ределенная совокупность архитектур- ных, структурных и поведенческих требований к компонентам, а также правила взаимодействия и построения компонентных конфигураций. Данное определение более сильное, чем соот- ветствующее понятие, встречающееся в практике программирования. Напри- мер, для CORBA [10] только сравни- тельно недавно была специфицирована компонентная модель, хотя история ее практического применения насчитыва- ет около 10 лет. Одной из первых сре- ди формализованных и специфициро- ванных моделей была Enterprise Java- Beans (EJB) [11], которая хорошо реализована для различных платформ. Для технологии COM [12] если и мож- но говорить о какой-то специфициро- ванной модели, то только в контексте двоичных реализаций компонентов для одной платформы WINDOWS. Компонентная модель является основой построения компонентных конфигураций. Введем соответствую- щее определение. Компонентная кон- фигурация – это архитектурно упоря- доченная относительно определенной Теоретические и методологические основы программирования 44 компонентной модели совокупность компонентов, построенная и взаимо- действующая согласно требованиям и правилам этой модели. Необходимо отметить следующие два следствия из этого определения. 1. Компонентная конфигурация определяется в рамках требований к конкретной компонентной программе. Не каждый набор компонентов будет определять конфигурацию. Необходи- мо (согласно определению), чтобы ме- жду ними существовали взаимодейст- вия, а для этого они должны иметь со- гласованные интерфейсы, что выпол- няется не для каждой пары компонен- тов. В свою очередь совокупность тре- буемых интерфейсов должна опреде- лять функциональные свойства компо- нентной программы. Этим и обуслов- ливается относительность компонент- ной конфигурации. 2. Количество компонентов в компонентной конфигурации может быть произвольным, но, согласно пре- дыдущему следствию, определяется от- носительно требований для конкретной компонентной программы. Минималь- ное значение равно единице, а макси- мальное – не больше числа классов эквивалентности для всего множества компонентов (как следует из дефини- ции компонентной программы). Приведенные выше определения являются базовыми для формализации компонентного программирования. Рас- смотрение вопросов конкретных архи- тектур моделей, аспектов практической Рис. 1. Модель семантической спецификации компонента * * * * * * * 2 * *1 * * * * 1 * 1 * 1 * * * 1 1 1 * 1 Входной интерфейс Выходной интерфейс Ограничение Компонент Состояние Интерфейс Инвариант Предусловие Метод Постусловие Входной параметр Параметр Выходной параметр Теоретические и методологические основы программирования 45 реализации требует дополнительных определений, которые будут вводиться по ходу статьи в соответствии с кон- текстом изложения. Относительно оп- ределения понятий, связанных с самим компонентом (интерфейсы, реализа- ции, методы и т.д.), то они достаточно хорошо изложены в существующей литературе, например в [9, 13]. Взаи- мосвязь большинства этих понятий ил- люстрирует рис. 1, где представлена модель семантической спецификации компонента. Обобщенная архитектура компонентной среды Современная архитектура ком- понентной среды является одним из Рис. 2. Обобщенное представление компонентной архитектуры Сервер компонентов 1 Компонент-контейнер 1 Экземпляр 1 Экземпляр N Экземпляр 2 Системные сервисы: наименования, транзакций, событий, безопасности и др. Управляющий (Home) интерфейс (Locate, Create, Delete) Функциональный интерфейс (методы) Клиент (Web- клиент, GUI и т.д.) Вызов методов Сервер компонентов 2 Системные сервисы Компонент 2 Компоненты сервера 2 Управляющий интерфейс Теоретические и методологические основы программирования 46 основных источников идей и подходов для построения теории компонентного программирования. Она была разра- ботана как расширение классической модели “клиент—сервер” с учетом специфики построения и функциони- рования программных компонентов, а также результатов практических реа- лизаций и их апробирования. По от- дельным вопросам и концепциям ар- хитектуры, построения и функциони- рования компонентной среды имеется достаточно обширная литература, на- пример [14—17]. В данной статье рассматривается представление обобщенной архитекту- ры как некоторой абстракции сущест- вующих моделей, сред, распределен- ных систем и их реализаций (рис. 2). Основой компонентной среды служит Разработчик сервера Сервер Разработчик контейнера Контейнер Разработчик функциональ- ности Реализации компонента Компонентное приложение Разработчик приложений Клиентские компоненты, GUI, Web-интерфейсы Разработчик клиентских объектов Компонентная инсталляция, компонентный каркас Разработчик компонентной среды Рис. 3. Роли и объекты в компонентном программировании Теоретические и методологические основы программирования 47 множество серверов компонентов (часто их называют серверы приложе- ний – application servers). Внутри сер- вера разворачиваются (устанавливают- ся) компоненты, представленные как контейнеры. Для каждого сервера мо- жет существовать произвольное коли- чество контейнеров. Контейнер представляет собой оболочку, внутри которой реализуется функциональность компонента. Взаи- мосвязь и взаимодействие контейнера с сервером строго регламентированы и осуществляются через стандартизован- ные интерфейсы. Контейнер управляет порождаемыми им экземплярами ком- понента, которые являются реализа- циями соответствующей функциональ- ности. В общем случае внутри него может существовать произвольное число экземпляров-реализаций, каждая из которых имеет уникальный иденти- фикатор. С каждым контейнером связаны два типа интерфейсов для взаимодей- ствия с другими компонентами и ин- терфейс системных сервисов, необхо- димых для функционирования самого контейнера и реализации специальных функций, например поддержка рас- пределенных транзакций, в которых участвуют несколько компонентов. Первый тип интерфейса (в некоторых архитектурах называется Home ин- терфейс) обеспечивает управление эк- земплярами компонента с обязатель- ными реализациями методов поиска, создания и удаления отдельных эк- земпляров. Ко второму типу относятся ин- терфейсы, обеспечивающие доступ к реализации функциональности компо- нента. Фактически с каждым экземп- ляром связан свой функциональный интерфейс. Экземпляры внутри контейнера могут взаимодействовать друг с дру- гом, связываться с помощью систем- ных сервисов с экземплярами, распо- ложенными в других компонентах. Са- ми компоненты могут размещаться как внутри одного сервера, так и в разных серверах для различных платформ. Та- кое взаимодействие обеспечивает уни- кальная идентификация компонентов и экземпляров, а также регламентиро- ванные методы взаимодействия по- средством интерфейсов и системных функций. Роли и жизненные циклы в компонентном программировании Анализируя архитектуру компо- нентной среды, можно отметить, что она состоит из различных типов про- граммных объектов. В их число входят: — серверы компонентов; — контейнеры компонентов; — реализации функционально- сти, представленные как экземпляры внутри контейнеров-компонентов; — компонентные среды, опре- деляемые компьютерными платформа- ми, реализациями компонентных моде- лей, объектами, обеспечивающими ус- тановку и конфигурирование отдель- ных компонентов; — клиентские компоненты, обе- спечивающие интерфейсы конечного пользователя, реализуемые в виде раз- личных типов клиентов (Web-клиенты, полноценные реализации графического интерфейса и т.д.); — законченное компонентное приложение, представленное как ком- понентная программа. Каждый тип объектов может реализоваться отдельно, так как для него существуют свои спецификации и требования, а также правила взаимо- действия с другими объектами компо- нентного программирования. Все типы объектов образуют цепочку, опреде- ляющую порядок реализации компо- нентного приложения. Каждый тип объектов может реализоваться отдель- ным разработчиком и в соответствии с этим определяется его роль в процессе создания компонентной программы. На рис. 3 представлена такая цепочка объектов компонентного программиро- вания с условным обозначением соот- ветствующей роли. Согласно разделению объектов компонентного программирования на типы и учитывая определенное место Теоретические и методологические основы программирования 48 каждого из них в процессе создания компонентного приложения, следует сделать вывод, что жизненный цикл компонентной программы значительно сложнее, чем жизненные циклы при других подходах программирования. Фактически речь идет о нескольких отдельных жизненных циклах для каж- дого типа объектов. Для обобщения этих данных все циклы с их краткими характеристиками сведены в таблицу. Более полное и подробное рассмотре- ние этих жизненных циклов выходит за рамки настоящей статьи. Таблица. Модели жизненного цикла в компонентном программировании Роль Объект компонентного программиро- вания Базовые концепции и спецификации Модель жизненного цикла объекта Разработчик сервера Сервер компо- нентов Спецификация сервера. Спецификация компо- нентной модели. Спецификация систем- ных сервисов Модель ЖЦ сервера Разработчик контейнера Контейнер Спецификация контей- нера. Спецификация компо- нентной модели. Спецификация систем- ных сервисов Модель ЖЦ контейнера Разработчик функциональ- ности компо- нента Реализации компонента Спецификации при- кладных интерфейсов. Спецификация компо- нентной модели Модель ЖЦ реализации компонента Разработчик компонентной среды, спе- циалист по инсталляции компонента Инсталляция и параметризация компонента в компонентной среде Спецификация разме- щения и настройки компонента. Спецификация компо- нентной модели. Спецификация систем- ных сервисов Модель раз- вертывания компонента. Модель построения каркаса Разработчик клиентских объектов Клиентские компоненты, GUI-объекты, Web- интерфейсы Спецификации клиент- ских интерфейсов. Спецификация компо- нентной модели Модель ЖЦ клиента Разработчик приложения Компонентное приложение Спецификация прило- жения. Спецификация разме- щения и настройки компонентов Модель ЖЦ компонентно- го приложе- ния Подход к определению формальной модели компонентного программирования Как было отмечено выше, подход к построению формальных моделей компонентного программирования обя- зан учитывать множество аспектов, в частности, базироваться на современ- ных концепциях компонентного про- граммирования, обеспечивать простой переход от теории к практике с ото- бражением и представлением сущест- Теоретические и методологические основы программирования 49 вующих архитектур и моделей (CORBA, COM, EJB), реализовать осно- ву для создания формальных методов построения компонентных программ и систем. Такие задачи одновременно не могут быть разрешены в рамках одной определенной модели. Поэтому необ- ходимо рассматривать семейство фор- мальных моделей и других абстракт- ных структур, объединенных единой понятийной, терминологической и ма- тематической базой. Такой подход предлагается в настоящей статье, где в качестве основных абстрактных струк- тур рассматриваются: – модель компонента; – модель компонентной среды; – внешняя компонентная алгебра. Выбор таких структур обуслов- лен следующими причинами. Во- первых, перечисленные модели отно- сятся к базовым моделям компонент- ного программирования. Это означает, что любая компонентная теория долж- на включать такие или аналогичные им модели. Во-вторых, они достаточно ти- повые и емкие, чтобы наметить даль- нейшие пути теоретических исследо- ваний. В-третьих, эти модели наглядно определяют связи теоретических и практических аспектов компонентного программирования, а также показыва- ют взаимосвязи с другими подходами. Рассмотренные замечания о требова- нии практической применимости мо- делей отражены в их отдельных эле- ментах и их связях. Определение модели компонента Модель компонента в общем случае представляется следующим об- разом: Comp = (CName, CInt, CFact, CImp, CServ), где CName – уникальное имя компонента; CInt = {CInti} – множество ин- терфейсов, связанных с компонентом; CFact – интерфейс управления экземплярами компонента; CImp = {CImpj} – множество реа- лизаций компонента; CServ = {CServr} – интерфейс, определяющий множество системных сервисов, необходимых для поддержки функционирования компонента. Имя компонента должно быть уникальным в любом пространстве имен для компонентной среды. Прак- тически это обеспечивается специаль- ными алгоритмами построения про- странств имен в виде иерархического дерева, где каждая вершина однознач- но определяется маршрутом (последо- вательностью вершин) от корня дерева. Множество CInt = CIntI ∪ CIntO состоит из интерфейсов двух типов. К первому (множество CIntI) относятся интерфейсы, которые реализуются в среде данного компонента, т.е. имеют соответствующие реализации методов. Ко второму (множество CIntO) относят- ся интерфейсы, реализуемые в других компонентах, но функциональность которых требуется для выполнения ме- тодов данного компонента. Каждый интерфейс компонента представлен следующим образом: CInti = ( IntNamei , IntFunci , IntSpeci ), где IntNamei – имя интерфейса; IntFunci – функциональность, реализуемая данным интерфейсом (со- вокупность методов); IntSpeci – спецификация интер- фейса (описания типов, констант, дру- гих элементов данных, сигнатур мето- дов и т.д.). Provide(CInti) обозначается реали- зация методов, определяемых интер- фейсом CInti и поставляемая некоторой компонентной реализацией. Интерфейс CFact определяет не- обходимые методы для управления эк- земплярами компонента. К ним отно- сятся: — поиск и определение нахож- дения требуемого экземпляра компо- нента Locate; — создание экземпляра компо- нента Create; — удаление экземпляра компо- нента Remove. Теоретические и методологические основы программирования 50 Таким образом, CFact = {Locate, Create, Remove}. Каждая реализация компонента описывается следующим образом: CImpj = ( ImpNamej , ImpFuncj , ImpSpecj ), где ImpNamej – идентификатор или имя реализации компонента; ImpFuncj – функциональность, выполняемая данной реализацией (со- вокупность реализаций методов); ImpSpecj – спецификация реали- зации (описание условий выполнения, описание параметров настройки реа- лизации и т.д.). Необходимым требованием пра- вильного представления компонента есть условие (∀CInti ∈CIntI) (∃CImpj ∈ ∈ CImp) Provide(CInti) ⊆ CImpj. Наличие знака включения в дан- ной формуле означает, что выбранная реализация может обеспечить под- держку не только требуемого интер- фейса, но и других. Практические тех- нологии и языки программирования (CORBA, Java, C++ и др.) содержат для этого необходимые средства. От- метим также, что для каждого из таких интерфейсов может существовать не- сколько реализаций, различающихся особенностями функционирования (на- пример, операционной средой, средст- вами хранения данных и т.д.). Определение связи компонентной модели с ОО-моделями Связь с объектно-ориентирован- ными моделями прослеживается на ос- нове следующего построения. В процессе своего функциониро- вания компонент посредством метода Create из интерфейса CFact порождает экземпляры CFact.Create: Comp -> {CInsk ij}, CInsk ij = (IInsk ij, IntFunci, ImpFuncj), где CInsk ij – экземпляр k компо- нента, предоставляющий свою функ- циональность посредством интерфейса IntFunci и обеспечивающий реализацию этого интерфейса посредством реали- зации ImpFuncj; IInsk ij – уникальный идентифи- катор экземпляра компонента. Пусть имеется некоторая объ- ектная система, представленная в виде диаграммы классов OSyst = (OClass, G), где OClass = {OClassi} – множест- во классов; G – объектный граф, отражаю- щий связи и отношения между класса- ми и экземплярами. Каждый класс представим в виде OClassi = (ClassNamei, Methodi, Fieldi}, где ClassNamei – имя класса; Methodi = {Methodj i} – множество методов; Fieldi = {Fieldn i} – множество пе- ременных, определяющих состояние экземпляров класса. Пусть PFieldi ⊂ Fieldi – множество внешних переменных (public), которые доступны извне. Каждому PFieldn i ∈ ∈ PFieldi поставим в соответствие мето- ды get<PFieldn i> и set<PFieldn i> для при- своения и выборки значений соответ- ствующей переменной, т.е. эти пере- менные становятся атрибутами в тер- минах современных компонентных мо- делей. Соответственно в других клас- сах вместо непосредственного обраще- ния к таким переменным будут ис- пользоваться указанные методы. Вве- дем новое множество методов IMethodi = Methodi ∪ {get<PFieldn i>} ∪ ∪ {set<PFieldn i>}, которому сопоставим интерфейс IFunci, состоящий из прототипов методов, входящих в IMethodi. Параллельно с OSyst рассмотрим систему ISyst = (IFunc, IG), где IFunc = {IFunci} – множество интерфейсов; IG – интерфейсный граф, иден- тичный графу G. Класс OClassi порождает свои эк- земпляры (объекты) Теоретические и методологические основы программирования 51 Objk i = {ObjNamek i, Methodi, Fieldi}, которым в системе ISyst будут соответство- вать интерфейсные элементы IObjk i = {INamek i, IFunci}. Для каждого такого элемента не определена реализация соответствую- щего интерфейса. Сопоставив некото- рому интерфейсу реализацию ImpFuncj (которая обеспечивает выполнение ме- тодов интерфейса), формируем элемент IObjk ij = {INamek i, IFunci, ImpFuncj }, который по своей сути эквивалентен экземпляру компонента CInsk ij = (IInsk ij, IntFunci, ImpFuncj). Основные различия определяют- ся следующими факторами. Во-первых, выбор подходящей реализации может происходить на этапе развертывания, а не на более ранних этапах, как это требуется для объектно-ориентирован- ного подхода. Во-вторых, экземпляр объектного класса порождается на ос- нове его описания и не может содер- жать элементов больше, чем есть в са- мом классе или в его суперклассах. В противоположность этому, реализация компонента может поддерживать не- сколько не связанных между собой ин- терфейсов. В остальном обе системы (объектная и интерфейсная) эквива- лентны. Таким образом, для построения компонентной программы могут при- меняться объектно-ориентированный подход и соответствующие инструмен- тальные средства. Для этого с исполь- зованием ОО-методов проектирования параллельно строятся объектная сис- тема и соответствующая ей интер- фейсная система без конкретизации реализации этих интерфейсов. Резуль- тат такого ОО-проектирования пред- ставляется как совокупность интер- фейсов, для которой рассматривается задача покрытия интерфейсов соответ- ствующими компонентными реализа- циями. На данном этапе жизненного цикла нет необходимости учитывать реализацию функциональности созда- ваемой программы. Эти реализации предоставляются компонентами на этапах интеграции и развертывания компонентного приложения. Определение основных типов отношений между компонентами Пусть выражение вида Compn = = (CNamen, CIntn, CFactn, CImpn, CServ) определяет конкретные компоненты. Рассмотрим основные типы компо- нентных отношений. Отношение наследования. Оди- ночное наследование. Компонент Comp1 наследует компонент Comp2, если ∀CInt1i ∈ ∈ Comp1.CIntI ∃Cint 2k ∈ Comp2.CintI такие, что интерфейс CInt1 i наследует интер- фейс CInt2 k (в смысле ОО-наследования интерфейсов). Множественное наследование. Компонент Comp1 наследует компоненты Comp2, Comp3, ..., CompN, если ∀CInt1i ∈ ∈ Comp1.CIntI (∃n ∈ {2, …, N}) & (∃CIntnk ∈ ∈ Compn.CintI) такие, что интерфейс CInt1 i наследует интерфейс CIntn k. Отношение наследования обла- дает свойствами рефлексивности, ан- тисимметричности и транзитивности. Отношение экземпляризации. Экземпляр CInsk ij = (IInsk ij, IntFunci, Imp- Funcj) есть экземпляр компонента Comp, если ∃CIntIm ∈ CInt и ∃CImpk ∈ CImp та- кие, что CIntIm.IntFuncm = IntFunci, CImpk .ImpFunck = ImpFuncj, Provide(CIntIm) ⊆ CImpk . Отношение контракта. Взаимо- действие между двумя компонентами описывается на основе модели кон- трактов. Если для функционирования одного компонента требуется функ- циональность, реализуемая в другом, то первый заключает контракт со вто- рым на предоставление требуемых ус- луг. Связь обеспечивается через соот- ветствующие интерфейсы. Пусть Comp1 и Comp2 – два ком- понента и CIntO1 i∈CInt1 – интерфейс, определяющий требуемую внешнюю Теоретические и методологические основы программирования 52 функциональность. Будем говорить, что между Comp1 и Comp2 возможно заклю- чение контракта, если для CIntO1 i (∃CIntI2 m∈CInt2) & (∃IMap12 im: CIntO1 i.IntFunc1 i -> CIntI2 m.IntFunc2 m) & & IMap12 im(CIntO1 i.IntFunc1 i) ⊆ ⊆ CIntI2 m.IntFunc2 m. Отображение IMap12 im реализует соответствие между методами, описан- ными в обоих интерфейсах, на уровне их сигнатур и типов данных для пере- даваемых параметров. Для интерфейса CIntI2 m на основе общих свойств ком- понента всегда будет существовать реализация в Comp2. Этим определяет- ся контракт между двумя компонента- ми, который записывается в виде Cont12 im = (CIntO1 i, CIntI2 m, IMap12 im). В общем случае компонент мо- жет заключать контракт сам с собой, если оба интерфейса, входящие в оп- ределение контракта, принадлежат ему. Отношение связывания. Отно- шение связывания определяется для двух экземпляров компонентов. Пусть Comp1 и Comp2 – два компонента и для них определен контракт Cont12 im. Для компонента Comp1 порожден экземпляр CIns1k ij, а для компонента Comp2 – CIns2p mq. Будем говорить, что в этом случае для экземпляров CIns1k ij и CIns2p mq существует отношение связы- вания в соответствии с контрактом Cont12 im, а сама связь будет обозначать- ся следующим образом: Bind (IIns1k ij, IIns2p mq) = = (IIns1k ij, IIns2p mq, Cont12 im). В общем случае отношение свя- зывания может существовать для двух экземпляров одного и того же компо- нента. Определение модели компонентной среды Определим компонентную среду как CE = (NameSpace, IntRep, ImpRep, CServ, CServImp), где NameSpace = {CNamem} – про- странство имен, представляющее мно- жество имен компонентов среды; IntRep = {IntRepi} – репозитарий интерфейсов, содержащий интерфей- сы компонентов среды; ImpRep = {ImpRepj} – репозита- рий реализаций, содержащий реализа- ции для компонентов среды; CServ = {CServr} – интерфейс, определяющий множество системных сервисов, необходимых для поддержки функционирования компонента; CServImp = {CServImpr} – множе- ство реализаций для системных серви- сов. Из определения этой модели следует, что она согласуется с обоб- щенной архитектурой компонентной среды, представленной на рис. 2. Элемент репозитария интерфей- сов определяется как пара IntRepi = (CInti, CNamem), где CInti – интерфейс для опре- деленного компонента; CNamem – имя компонента, ко- торый реализует этот интерфейс. Элемент репозитария реализа- ций определяется как пара ImpRep = (CImpj, CNamem), где CImpj – реализация для оп- ределенного компонента; CNamem – имя компонента, кото- рый содержит эту реализацию. Введем понятие нейтральной (нулевой) компонентной среды, кото- рая будет называться каркасом (frame- work): FW = (∅, ∅, ∅, CServ, CServImp), где пространство имен, репози- тарии интерфейсов и реализаций яв- ляются пустыми множествами. Элементы модели CServ и CServImp определяют конкретный тип компонентной среды. Совместимость компонентных сред различных типов определяется наличием отображения между соответствующими интерфей- сами системных сервисов. Теоретические и методологические основы программирования 53 Пусть FW1= (∅, ∅, ∅, CServ1, CServImp1), FW2 = (∅, ∅, ∅, CServ2, CServImp2) – два каркаса разных ти- пов. Отметим, что в соответствии с определением для каждого типа ком- понентной среды существует только один каркас. Если существует отобра- жение SMap: CServ1 -> CServ2 такое, что SMap(CServ1) ⊆ CServ2, то каркас FW1 со- вместим с каркасом FW2. Для совмес- тимости каркаса FW2 с каркасом FW1 необходимо существование обратного отображения с аналогичными свойст- вами. Ниже покажем (в соответствии с операциями внешней компонентной алгебры), что каждая компонентная среда определенного типа включает соответствующий каркас. Тогда со- вместимость каркасов будет опреде- лять и совместимость компонентных сред рассматриваемых типов. Практически совместимость кар- касов и компонентных сред означает следующее. Пусть для первой среды в состав CServ1 входит некоторый сервис, например сервис наименования. Тогда и в состав CServ2 тоже должен входить аналогичный сервис. И, кроме того, между этими сервисами должна суще- ствовать такая связь, что сервис пер- вой среды должен понимать наимено- вание объектов из второй и наоборот. Аналогичная ситуация должна быть и для остальных системных сервисов. Так как любая компонентная среда оп- ределенного типа использует одни и те же сервисы, то такие связи будут оп- ределять суть совместимости. В частности, взаимодействие компонентов, расположенных в разных серверах компонентов, поддерживает- ся сервисами этих серверов (этот факт отмечался при рассмотрении обобщен- ной архитектуры). Если совместимость между серверными сервисами сущест- вует, то такие компоненты могут вхо- дить в состав общего компонентного приложения. Основы внешней компонентной алгебры Алгебра называется внешней по- тому, что она определяет операции над компонентами и компонентными сре- дами как над цельными объектами. Обозначим CSet = {Compn} множество компонентов, а CESet = {CEn} множест- во компонентных сред. Все компонен- ты соответствуют условиям компо- нентной модели, а среды – условиям модели компонентной среды. Определим операцию инсталля- ции (развертки) компонента в компо- нентной среде CE2 = Comp ⊕ CE1 со следующей семантикой: CE2.NameSpace = {Comp.CName} ∪ ∪ CE1.NameSpace; CE2.IntRep = {Comp.(CInti, CName)} ∪ ∪ CE1.IntRep; CE2.ImpRep = {Comp.(CImpj, CName)} ∪ ∪ CE1.ImpRep. Определим операцию объедине- ния компонентных сред CE3 = CE1 ∪ CE2 с аналогичной семантикой: CE3.NameSpace = CE1.NameSpace ∪ ∪ CE2.NameSpace; CE3.IntRep = CE1.IntRep ∪ CE2.IntRep; CE3.ImpRep = CE1.ImpRep ∪ CE2.ImpRep. Операция ⊕ имеет более высо- кий приоритет, чем операция ∪. Этот факт легко объясним, так как прежде, чем работать с компонентными сре- дами, необходимо инсталлировать их компоненты. Отметим очевидные свойства операций: ∀CE CE ∪ FW = CE; ∀CE1, ∀CE2 CE1 ∪ CE2 = CE2 ∪ CE1; ∀CE1, ∀CE2, ∀CE3 (CE1 ∪ CE2) ∪ CE3 = = CE1 ∪ (CE2 ∪ CE3); ∀Comp, ∀CE1, ∀CE2 (Comp ⊕ CE1) ∪ ∪ CE2 = (Comp ⊕ CE2) ∪ CE1; ∀Comp1,∀Comp2,∀CE Comp1 ⊕ (Comp2 ⊕ ⊕ CE) = Comp2 ⊕ (Comp1 ⊕ CE). Теоретические и методологические основы программирования 54 Определим операцию удаления компонента из компонентной среды CE2 = CE1 \ Comp со следующей семантикой: ∃ CNamem ∈ NameSpace & (CNamem = = Comp.CName) ⇒ CE2.NameSpace = = CE1.NameSpace \ {Comp.CName} & & CE2. IntRep = CE1.IntRep \ {(∀I & & IntRepi.CName = Comp.CName) IntRepi} & & CE2. ImpRep = CE1.ImpRep \ {(∀j & & IntRepj.CName = Comp.CName) IntRepj}. Справедливо следующее равен- ство (доказывается на основе соответ- ствующих операций над множествами, входящими в определении компонента и среды): (Comp ⊕ CE) \ Comp = CE. При другом порядке скобок ра- венство не всегда выполняется. Это означает, что операция ⊕ имеем более высокий приоритет, чем операция \. Операцию замещения компонен- та Comp1 компонентом Comp2 можно выразить через операции ⊕ и \: CE2 = Comp2 ⊕ (CE1 \ Comp1). Пусть Ω обозначает множество операций: Ω = {⊕, \, ∪}, расположенных в порядке уменьшения приоритетов. Тогда Ψ = {CSet, CESet, Ω} определяет внешнюю компонентную алгебру, включающую множества ком- понентов, компонентных сред и опера- ции над их элементами. Другие модели компонентного программирования Среди других моделей, которые здесь подробно не рассматриваются, отметим такие. Внутренняя компонентная ал- гебра. Как было отмечено, во внешней компонентной алгебре компоненты представляют цельные объекты. Но со- гласно модели компонента он имеет собственную структуру. Поэтому целе- сообразно рассмотреть операции над отдельными элементами такой струк- туры, которые (по аналогии с соответ- ствующими операциями для других методов программирования, например объектно-ориентированного [18]) на- зываются операциями рефакторинга. Суть этих операций – изменения в именах, множествах интерфейсов, множествах реализаций, соотношениях и связях между этими множествами. Особый интерес представляет множе- ство таких операций рефакторинга, ко- торые сохраняют целостность понятия компонента, т.е. условия определения и существования компонента в результа- те рефакторинга не меняются. Приме- ром таких операций могут служить: — добавление новой реализации для существующего интерфейса; — добавление нового интерфей- са и новой реализации для него (этот пример характерен для программиро- вания в модели COM); — объединение существующих интерфейсов, и, если необходимо, объ- единение и их реализаций. Множество элементов модели компонента и множество указанных операций рефакторинга будут опреде- лять внутреннюю компонентную ал- гебру. Модель системных сервисов компонентной среды. Выше была от- мечена важность построения такой мо- дели (в частности, для определения со- вместимости компонентных сред). Эта модель детализирует CServ с указанием сервисов, которые необходимы для поддержки функционирования компо- нентов и компонентных сред в рамках задач компонентного программирова- ния, что обеспечивает формальное оп- ределение дополнительных статиче- ских и динамических свойств компо- нентных сред. Обобщенная компонентная ал- гебра. Эта алгебра на единой формаль- ной платформе объединяет внешнюю и внутреннюю компонентные алгебры, а также модель системных сервисов. Теоретические и методологические основы программирования 55 Помимо непосредственного объедине- ния возможностей указанных алгебр, она позволит формализовать дополни- тельные задачи: — для выбранного множества компонентов определить последова- тельность операций рефакторинга, ко- торые обеспечат построение компо- нентного приложения (или доказать, что для выбранного множества эта за- дача неразрешима); — указать необходимые условия, чтобы выбранная компонентная кон- фигурация обладала свойствами тран- закционности (или доказать отсутствие такого свойства); — обеспечить реализацию ком- бинированных операций, например переименования компонентов и/или их интерфейсов (которые по сути являют- ся рефакторингами), с образованием нового компонента, дополняющего су- ществующую компонентную среду. Формулировка основной задачи ком- понентного программирования Как отмечалось в начале статьи, основная задача компонентного про- граммирования состоит в построении компонентных программ и систем на основе компонентных моделей, мето- дов и средств. Переопределим и сфор- мулируем эту задачу в терминах, поня- тиях и моделях, рассмотренных выше. Выполним последовательно следующие шаги. Определение базовой компо- нентной среды. Пусть CSet – множе- ство имеющихся компонентов и Ψ = { CSet, CESet, Ω} – внешняя компо- нентная алгебра. Обозначим CEc ∈ CESet компонентную среду, в которой раз- вернуты все компоненты из CSet: CEc = CE1 ⊕ CE2 ⊕ . . . ⊕ FW. В дальнейшем компонентные среды типа CEc будем называть базо- выми для соответствующего множества CSet. Определение расширения базо- вой компонентной среды. Рассмотрим множество компонент CSet. В результа- те применения операций рефакторинга из внутренней компонентной алгебры и операций из обобщенной алгебры строим множество CSet, которое объ- единяет CSet и все допустимые резуль- таты применения этих операций над всеми элементами CSet. Будем гово- рить, что CSet является замыканием CSet относительно множеств операций из указанных алгебр. Для множества CSet* строим но- вую базовую компонентную среду CE*c, которая является расширением преды- дущей. Подобный процесс расширения может быть неоднократно повторен с получением новых компонентов и ба- зовых компонентных сред. Компонентное представление программы. Под компонентным пред- ставлением программы понимается та- кое абстрактное определение конст- руируемой программы, в котором его элементами являются представления, которым можно поставить в соответст- вие реальные компоненты, обеспечи- вающие реализацию функционально- сти задачи и выполнение других не- функциональных требований. Для од- ной и той же программы существует множество ее компонентных представ- лений в зависимости от концепций проектирования и используемого ком- понентного подхода. Рассмотрим обобщенный уровень такой модели. Основная задача проектирования компонентной программы состоит в представлении ее функциональности и других требований как совокупности контрактов между отдельными объек- тами – программными компонентами, из которых она будет состоять. Пусть {Ai} – множество контрактов для про- граммы, определяющих ее функцио- нальность. Каждому Ai можно поста- вить в соответствие интерфейс Ii, ко- торый описывает контракт как кли- ент—серверное взаимодействие с со- ответствующими методами и структу- рами данных. Согласно этому каждый интерфейс можно сопоставить с парой Ini и Outi, которые будем называть со- ответственно реализующим представ- лением для Ii и определяющим пред- Теоретические и методологические основы программирования 56 ставлением для Ii. Здесь используются эти термины вместо понятий входной и выходной интерфейс потому, что ре- ально они не являются такими интер- фейсами (для них могут не существо- вать соответствующие интерфейсы в существующих компонентах). В ре- зультате перепроектирования они мо- гут быть переопределены и изменены с целью адаптации их к реальным ин- терфейсам. Outi определяет условия и цель контракта со стороны клиента, а Ini задает аспект реализации контракта со стороны сервера. После того как все Ini и Outi оп- ределены, их можно группировать в различных сочетаниях. Рассмотрим произвольную совокупность Mv = {Ini} ∪ ∪ {Outj}. Назовем каждое Mv шаблоном компонента. Фактически каждый шаб- лон содержит некоторое множество определяющих и реализующих пред- ставлений интерфейсов. По этим пред- ставлениям в дальнейшем осуществля- ется сопоставление шаблонов и реаль- ных интерфейсов существующих ком- понентов. Если результаты сопоставления для всех Mv успешны, то в итоге по- добных операций группирования полу- чается множество CP = {Mv}, которое и будет называться компонентным пред- ставлением программы. Для одной и той же программы существует множе- ство представлений, которые опреде- ляются множествами контрактов (или интерфейсов) и способами построения шаблонов. Определение основной задачи компонентного программирования. Эта задача формулируется таким обра- зом. Дано множество компонентов CSet и указанные компонентные алгебры. Цель – построить компонентную про- грамму с заданными функциональными и нефункциональными требованиями на искомом множестве компонентов. Задача состоит в том, чтобы представить результаты проектирова- ния программы в виде компонентного представления CP = {Mv} таким обра- зом, чтобы для любого Mv существовал компонент из CSet или он мог быть получен из этого множества в резуль- тате конечного числа допустимых операций из соответствующих компо- нентных алгебр. На практике такие условия могут выполняться не всегда (например, раз- рабатывается программа с принципи- ально новой функциональностью). В этом случае реализуются дополнитель- ные компоненты и расширяется мно- жество CSet. Выводы В настоящей статье описан под- ход к построению теории компонент- ного программирования. Последова- тельно рассмотрены концепции по- строения такой теории, определения основных терминов, существующие теоретические и практические резуль- таты, влияющие на построение теории, а также описаны основные модели компонентного программирования. На базе рассмотренных моделей сформу- лирована основная задача компонент- ного программирования. Отличительной особенностью предлагаемого подхода является его целостность. Все концепции, аспекты, терминология, математические методы увязаны в единую схему со строгим определением причинно-следственных связей. Изложение показывает, что, несмотря на сложность и неоднознач- ность поставленной задачи, подход к построению единой теории возможен, а построенная теория может получить практическое применение. Дополнительной особенностью подхода является определение новых направлений исследования. Это отно- сится как к построению новых моде- лей и методов, так и к практическим аспектам применения полученных тео- ретических результатов. Построение теории компонент- ного программирования создаст необ- ходимый базис для формирования практических методик и методологий создания компонентных программ, разработки новых инструментальных средств и улучшения качества разраба- тываемых продуктов. Теоретические и методологические основы программирования 57 1. Грищенко В.Н., Лаврищева Е.М. Методы и средства компонентного программирования // Кибернетика и системный анализ. – 2003. – № 1. – C. 39—55. 2. Грищенко В.Н., Лаврищева Е.М. Компонент- но-орентированное программирование. Со- стояние, направления и перспективы раз- вития // Проблемы программирования. – 2002. – N 1—2. – С.80—90. 3. Лаврищева Е.М., Грищенко В.Н. Сборочное программирование. – Киев: Наук. думка, 1991. – 213 с. 4. Лаврищева Е.М. Сборочное программиро- вание. Некоторые итоги и перспективы // Проблемы программирования. – 1999. – № 2. – C. 20—31. 5. Буч Г. Объектно-ориентированный анализ и проектирование. – M.: Бином, 1998. – 560 с. 6. Rada R., Moore J. Standardizing Reuse // Communications of the ACM. – 1997. – 40, N 3. – P. 19—23. 7. Бабенко Л.П., Лаврищева К.М. Основи про- грамної інженерії. – К.: Знання, 2001. – 269 с. 8. Грищенко В.Н. Особливості компонентно- орієнтованої розробки програмного забез- печення // Проблемы программирования. – 2001. – N 3—4. – С. 75—92. 9. Грищенко В.Н. Систематизований підхід до визначення програмних компонентів // Там же. – С. 23—30. 10. Сигел Дж. CORBA 3. – М.: Малип, 2002. – 412 c. 11. Roman E., Ambler S., Jewell T. Mastering En- terprise JavaBeans. – New York: Wiley Comp. Publ., 2002. – 670 c. 12. Lowy J. COM and .NET Component Services. – O'Reilly, 2001. – 384 p. 13. Crnkovic I., Hnich B., Jonsson T., Kiziltan Z. Specification, Implementation and Deploy- ment of COMPONENTS // Comm. ACM. – 2002. – Oct. – P. 35—40. 14. Эммерих В. Конструирование распределен- ных объектов. Методы и средства про- граммирования интероперабельных объек- тов в архитектурах OMG/CORBA, Micro- soft/COM и Java/RMI. – М.: Мир, 2002. – 510 с. 15. Цимбал А.А, Аншина М.Л. Технологии соз- дания распределенных систем. Для профес- сионалов. – СПб.: Питер, 2003. – 576 с. 16. Андон Ф.И., Лаврищева Е.М. Методы ин- женерии распределенных компьютерных систем. – К.: Наук. думка, 1997. – 228 с. 17. Грищенко В.М. Парадигма перетворення да- них, що передаються в мережі // Проблемы программирования. – 2001. – N 1—2. – С. 84—94. 18. Фаулер М. Рефакторинг: улучшение соот- ветствующего кода. – СПб.: Символ-Плюс, 2003. – 432 с. Получено 26.05.03 Об авторе Грищенко Владимир Николаевич канд. физ.-мат. наук, докторант Место работы автора: Институт программных систем НАН Украины, просп. Академика Глушкова, 40, Киев-187, 03680, Украина Тел. (044) 266 3470
id	nasplib_isofts_kiev_ua-123456789-1302
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
issn	1727-4907
language	Russian
last_indexed	2025-11-28T02:17:17Z
publishDate	2003
publisher	Інститут програмних систем НАН України
record_format	dspace
spelling	Грищенко, В.Н. 2008-07-24T16:51:43Z 2008-07-24T16:51:43Z 2003 Формальные модели компонентного программирования /В.Н. Грищенко// Проблеми програмування. — 2003. — N 2. — С. 42—57. — Бібліогр.: 18 назв. — рос 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/1302 681.3 Предложен подход к построению формальных моделей компонентного программирования как основы создания компонентной теории. Рассмотрены модели компонентов, компонентных сред, определены внешняя и внутренняя компонентные алгебры. Проанализированы различные аспекты предложенных моделей и их связь с практикой программирования. Запропоновано підхід до побудови формальних моделей компонентного програмування як основи створення компонентної теорії. Розглянуті моделі компонентів і компонентних середовищ, визначені зовнішня та внутрішня компонентні алгебри. Проаналізовані різні аспекти запропонованих моделей і їх зв’язок з практикою програмування. The approach to construction of formal models of component programming, as bases of component theory creation, is offered. The models of components, component environments and external and internal component algebra are considered. The various aspects of these models and their relations with practice of programming are analysed. ru Інститут програмних систем НАН України Теоретические и методологические основы программирования Формальные модели компонентного программирования Формальні моделі компонентного програмування The Formal method of Component Basic Programming Article published earlier
spellingShingle	Формальные модели компонентного программирования Грищенко, В.Н. Теоретические и методологические основы программирования
title	Формальные модели компонентного программирования
title_alt	Формальні моделі компонентного програмування The Formal method of Component Basic Programming
title_full	Формальные модели компонентного программирования
title_fullStr	Формальные модели компонентного программирования
title_full_unstemmed	Формальные модели компонентного программирования
title_short	Формальные модели компонентного программирования
title_sort	формальные модели компонентного программирования
topic	Теоретические и методологические основы программирования
topic_facet	Теоретические и методологические основы программирования
url	https://nasplib.isofts.kiev.ua/handle/123456789/1302
work_keys_str_mv	AT griŝenkovn formalʹnyemodelikomponentnogoprogrammirovaniâ AT griŝenkovn formalʹnímodelíkomponentnogoprogramuvannâ AT griŝenkovn theformalmethodofcomponentbasicprogramming

Формальные модели компонентного программирования

Репозитарії

Схожі ресурси