WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 | 4 |
ОБЪЕКТЫ В ПРОГРАММИРОВАНИИ: ТЕНДЕНЦИИ АППЛИКАТИВНОГО ПОДХОДА К ВЫЧИСЛЕНИЯМ В.Э. Вольфенгаген Институт актуального образования “ЮрИнфоР-МГУ” 119435, г. Москва, ул. М. Пироговская, д. 5, оф. 37 Тел.: +7 (499) 616-74-53; e-mail: vew@jmsuice.msk.ru Аннотация. Аналитический обзор посвящен проблеме развития представлений об объекте в аппликативных языках программирования, их использовании в более широкой области компьютинга (англ. computing), а также взаимосвязям различных представлений с ИТС. Интерес к технологиям работы с объектами возник более двадцати пяти лет назад. В частности, была выполнена одна из успешных попыток ее применения к реализации функциональных языков программирования с заранее нефиксированным набором инструкций. Это привело к разработке динамически генерируемых систем объектов-инструкций константного типа -- замкнутых и не зависящих от среды вычислений, -- а первые результаты были опубликованы в 1987 г.

[1]. В настоящее время актуальность подобных технологий только возросла, о чем свидетельствует рассматриваемый перечень приоритетных направлений исследований и разработок по ИКТ 7-ой Рамочной программы Европейского Союза, принятой на период 2007-2013 годов [2]. Эти направления являются внешними стимулирующими факторами развития аппликативных вычислительных технологий и сопутствующим им языков. Кроме этого имеются собственные факторы внутреннего развития компьютинга, резко ускоряющие поиск новых форм и моделей вычислений, которые проявили зависимость от исходно заложенного представления об объекте как информационной или вычислительной сущности. В настоящее время компьютинг переживает период бурного развития своих технологических оснований. Эти вопросы рассматриваются с позиций разработки научных основ и развития чисто объектного подхода к программированию, что важно для создания новых поколений ИКТ и ИТС.

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

Сам аппликативный подход к программированию превращается в заметную тенденцию, образуя самостоятельный и разветвленный раздел, с собственным кругом технологий, который может характеризоваться как аппликативный компьютинг [3].

Как оказалось, системы аппликативного компьютинга (англ.: applicative computing systems), или аппликативные вычислительные системы, явно выделенные Дж. Бэкусом [4], сопровождали программирование на всем пути его становления и развития – от теории до практических реализаций и технологий их использования.

2. Основные формы представления об объекте и объектах данных Как известно, имеется, по меньшей мере, два подхода к выработке представления об объекте. С позиций первого из них объект трактуется через выделяющие его свойства, то есть, по сути, принимается, что объект есть некоторая совокупность свойств, а еще лучше – некоторое отношение, установленное на свойствах [5]. Во втором в качестве объекта принимается некоторая правильно построенная абстрактная сущность.

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

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

2.1. Сервисные объекты Сервисные объекты данных, или СОД (Service Data Objects, SDO) [6], являются такой спецификацией модели программирования, которая позволяет унифицировать данные по типам источников данных, дает общую платформу для построения приложений. SDO предоставляет инструментарий и среду для работы с данными, облегчая их просмотр, связывание, модификацию и анализ.

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

Обеспечение доступа к данным при работе с неоднородными источниками данных.

Трудность заключается в том, что реальные приложения используют разнообразные источники данных, включая реляционные базы данных с доступом через JDBC [7], Entity EJB [8] или пользовательскими уровнями доступа на основе Webсервисов или XML, а также информационные системы масштаба предприятия и др. Их использование, как минимум, требует развития системы различных информационных адаптеров. Все это вместе взятое предъявляет повышенные требования к уровню знаний проектировщика приложений, которому нужно профессионально владеть многими и многими моделями программирования.



Унифицированная поддержка статических и динамических данных через интерфейсы API.

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

Например, Entity EJBs, JDO [9], Hibernate [10] и иные объектно-реляционные механизмы устойчивости (англ.: persistence mechanisms) дают удобные типизированные программные Java-интерфейсы, покрывая широкий спектр потребностей для работы с данными. Но ни статические, ни динамические интерфейсные средства все еще не являются достаточными, хотя они и успели стать необходимыми.

Поддержка инструментальных средств и сред.

Имеющиеся технологии программирования данных не достигли такого состояния развития, когда они могут претендовать на роль универсальных инструментальных средств и сред для известного многообразия типов источников данных. Для этого нужно будет обеспечить ряд ключевых возможностей:

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

Поддержка несвязанных моделей программирования.

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

На сегодня все еще не имеется технологии доступа к данным, которая бы осуществляла несвязанную модель при условии ее оснащенности указанными возможностями. В частности, хотя CachedRowSet in JSR-114, “RowSet Implementations” [11] и предоставляет несвязанную модель, но, тем не менее, не обеспечивает полноценный доступ к неоднородным данным и, кроме того, не обеспечивает легкости использования. Точно также многие из объектно-реляционных механизмов обеспечения устойчивости, хотя и поддерживают семантику одновременности, но не обеспечивают необходимых возможностей для универсального доступа к данным.

Поддержка пользовательских уровней доступа к данным, основанных на общих конструктивных принципах.

Многие приложения основаны на хорошо известных конструктивных принципах. Примерами могут служить Transfer Object [12], Transfer Object Assembler [13], Data Access Objects [14], и Domain Store [15], которые позволяют строить слои пользовательского доступа к данным. Эти системы используются, когда приложению надо получать данные непосредственно из физических источников данных.

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

Отделение кода приложения от кода доступа к данным.

Код приложения следует отделять от кода доступа к данным, если требуется добиться возможностей повторного использования и поддерживаемости. Технологии же доступа к данным должны быть приспособлены к подобными требованиям отделяемости.

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

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





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

3. Объекты в программировании Область, относящаяся к программированию, также нуждается в выработке продуктивного представления об объекте, пригодного для работы с данными и программами.

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

3.1. Объектно-ориентированный подход Как считается, применение объектов помогает сблизить представления об объекте в инженерии и объекты окружающего нас реального мира [5]. Можно провести следующую параллель. Получившие в новейшее время развития различные сообщества, которые возникают в информационной среде, лучше всего функционируют и развиваются, когда централизация управления ими сведена до минимума. В этот случае все интеллектуальные усилия, направленные на поддержание успешного развития сообщества, оказываются в высокой степени распределенными.

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

По своей организации большие объектно-ориентированные программы выглядят схожим образом. Основная идея состоит в том, чтобы большое программное обеспечение, возможно, содержащее миллионы строк кода, имело организации в виде некоторого сообщества объектов. К таким объектам предъявляется всего несколько требований:

-- объекты наделены способностью интерпретировать сообщения, полученные от других объектов, а затем реагировать на них, изменяя собственное поведение;

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

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

3.2. Объекты в распределенных системах Большинство из языков программирования, основанных на идее объекта, обладают своим распределенным расширением и наоборот, всякая вновь разрабатываемая распределенная архитектура основана на тех или иных представлениях об объекте. Наиболее значимыми примерами могут служить инициативы по стандартизации Открытая распределенная обработка (Open Distributed Processing, ODP) и Группа по управлению объектами (Object Management Group, OMG), которые распространяются на область неоднородного распределенного компьютинга.

Для них основным разрабатываемым понятие является именно представление об объекте [16]. Часто выделяют три подхода, в соответствии с которыми строятся вычислительные технологии работы с объектами.

1) При аппликативном подходе происходит заимствование объектноориентированного понятийного каркаса с целью структурирования распределенных систем в библиотеках и средах.

2) При интегративном подходе понятийный каркас распределенных систем унифицируется посредством использования объектно-ориентированного представления, что приводит к парадигмам активных объектов и асинхронного обращения к объектам.

3) При рефлективном подходе происходит интеграция библиотек протоколов в рамках языка программирования, основанного на идее объектов.

Pages:     || 2 | 3 | 4 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.