CC BY
81
При первом запуске сценария происходит анализ и трансляция запросов с последующим кэшированием, чем и обусловлено несколько большее время работы. Кэш результатов запросов при тестировании не использовался. В плане производительности SQLMapper незначительно уступает специализированным ORM-библиотекам (главным образом, вследствие большей модульности и слабой связанности компонентов программного каркаса). Стоит заметить, что с использованием компонентов MapperStack можно реализовать и более производительное отображение (например, работая напрямую с драйвером СУБД, пропуская этап преобразования типов и т.д.).
Реализация модульного программного каркаса для интеграции различных систем хранения на уровне объектного отображения позволяет быстро разработать прототип приложения, используя стандартную функциональность, а затем при необходимости постепенно заменять их на более эффективные реализации исходя из решаемых задач. Интеграция различных систем хранения открывает новые возможности, позволяя использовать наиболее подходящие решения для работы с данными, сохраняя при этом целостную объектную модель приложения.
Литература
1. D. Merriman, «On Distributed Consistency», 2010.
(http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1)
2. R. Cattell, «Scalable SQL and NoSQL Data Stores», 2011.
(http://www.cattell.net/datastores/Datastores.pdf)
3. 451 Research, «NoSQL, NewSQL and Beyond: The drivers and use cases for database alternatives», 2011.
4. С. Д. Кузнецов, А. В. Посконин, «Распределенные горизонтально масштабируемые решения для управления данными», Труды Института системного программирования РАН, т. 24, стр. 327-358, 2013.
5. M. Stonebraker, U. Qetintemel, «"One Size Fits All": An Idea Whose Time Has Come and Gone», ICDE ’05: Proceedings of the 21st International Conference on Data Engineering, Washington, 2005.
6. Wikipedia: «Entity-Attribute-Value model».
(http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value model)
7. M. Fowler, «Polyglot Persistence», 2011.
(http://www.martinfowler.com/bliki/PolyglotPersistence.html)
8. С. Д. Кузнецов, А. В. Посконин, «Возможно ли сотрудничество SQL и NoSQL?», Открытые системы. СУБД, № 9, стр. 38-41, 2013.
9. S. Francia, J. Hileman, «Augmenting RDBMS with MongoDB for eCommerce».
(http://www.nosqldatabases.com/main/2011/4/11/augmenting-rdbms-with-mongodb-for-
ecommerce.html)
10. А. В. Посконин, «Web-приложения и данные: проблемы абстракции и масштабируемости», Труды Института системного программирования РАН, т. 23, стр. 159-171, 2012.
11. J. Miller, «Design Patterns for Data Persistence», 2009.
(http://msdn.microsoft.com/en-us/magazine/dd569757.aspx)
12. M. Fowler, «Patterns of Enterprise Application Architecture», Addison Wesley, 2002.
УДК 004.451.8
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ ОПЕРАЦИОННЫЕ СРЕДЫ
Штанюк Антон Александрович, к.т.н., доцент кафедры информационных технологий в предпринимательской деятельности, Нижегородский государственный университет им. Н.И. Лобачевского, Россия, Нижний Новгород, [email protected]
Введение
38
В прошлой статье [1] автором были затронуты вопросы относительно перспектив развития объектно-ориентированных операционных систем (ОООС). В таких системах сама архитектура предполагает использование объектной парадигмы, а все ресурсы представлены в виде концептуальных объектов. Операционные среды и оболочки являются тесно связанными, но отличными от операционной системы понятиями.
Операционная среда — комплекс программного обеспечения, предоставляющего средства разработки и выполнения прикладных программ.
Этим определением подчёркивается прикладной, пользовательский характер операционной среды, в то время как операционная система выступает лишь одним из её компонентов и концептуально располагается ближе к аппаратному обеспечению ЭВМ. К операционной среде можно добавить и понятие операционной оболочки, которая обеспечивает работу пользовательского интерфейса.
Почему до сих пор не появилось полноценной и массовой объектной операционной системы? Ответить на этот вопрос и легко, и сложно одновременно.
Легко, потому что операционные системы развиваются по законам рынка и конкуренции, они должны удовлетворять запросам пользователей и обладать набором взаимоисключающих показателей: быть быстрыми, но надёжными, стабильными, но переносимыми, компактными, но расширяемыми. Объектная парадигма позволяет создавать хорошие, продуманные архитектуры, но они не обязаны отвечать другим требованиям, особенно в плане скорости работы и компактности.
Сложно ответить потому, что сам характер управления сложными программными системами (а ОС относятся к их числу) предполагает использование объектных компонентов, в то время разработчики настойчиво предлагают архитектуры, далёкие от идеала и с трудом адаптирующиеся к изменчивым требованиям рынка. То есть приходится признавать, что корни проблемы уходят в далёкое прошлое, когда системы создавались без использования объектного подхода, и это наложило отпечаток на дальнейшее развитие. Это относится не только к системам, создававшимся в стенах крупных компаний, но и к тем, что развивались силами сообществ. Чем дальше разработчики уходят от первых шагов по проектированию архитектуры системы, тем меньше у них шансов изменить её в дальнейшем.
Операционная среда позволяет пользователю решать свои задачи с помощью вычислительной машины. Естественно, что при этом задействуются элементы интерфейса, составляющие пользовательское окружение (user environment). Классическое разделение пользовательских интерфейсов на графические (GUI) и командные (CLI) уже не отвечает требованиям времени. В большинстве систем имеются развитые средства поддержки и CLI, и GUI, и пользователю предоставляется право выбора между данными окружениями, а также использования данных средств параллельно. Для пользователя очень важен другой вопрос: а с чем он имеет дело, при использовании команд или графических элементов, что скрывается за «фасадом» окружения? Второй вопрос: насколько расширяемо пользовательское окружение, насколько легко в него добавить новые элементы? И третий вопрос: как соотносится пользовательское окружение и концепции прикладного программирования? И вот здесь нужно признать, что объектный характер операционной среды имеет большое значение и проистекает именно из-за восприятия её пользователем. Попробуем последовательно рассмотреть оба подхода к разработке пользовательского интерфейса, а также подходы к построению системного интерфейса с пользовательскими приложениями.
Командный пользовательский интерфейс
Взаимодействие с пользователем через CLI происходит благодаря командным оболочкам. В Windows это CMD, PowerShell, а в unix-системах - большое семейство shell: bash, csh, zsh.
Наиболее выраженный объектный характер имеет windows-оболочка PowerShell, построенная на классах .NET [2]. При построении файлов сценариев, пользователи и администраторы могут комбинировать классические команды и утилиты с методами классов
39
.NET. Это особенно ценно, если у пользователей уже накоплен опыт разработки приложений на различных языках программирования, входящих в набор разработчика .NET. Интерфейс с объектами COM, существующими в Windows много лет, также придаёт оболочке объектный характер. Отдельно хочется подчеркнуть возможность встраивания исполняемых компонентов оболочки в другие приложения.
Другие оболочки, зародившиеся много лет назад, не предполагают объектного подхода. Но есть практика использования скриптовых языков (особенно Python или Perl) для решения задач взаимодействия с системой. Python обладает развитыми средствами поддержки ООП и может выступать в качестве языка управления системой и её ресурсами [3]. Многие дистрибутивы Linux распространяются с большим количеством Python-пакетов, позволяющих решать задачи системного администрирования и программирования, а благодаря широкому использованию Python в прикладном программировании, -осуществлять взаимодействие прикладных и системных программ.
Существует несколько альтернативных проектов, мало известных широкой публике, например Pash (как свободная альтернатива PowerShell для многих систем), или Zoid, основанная на Perl. В Сети можно найти ряд материалов, посвящённых объектноориентированному программированию в bash.
Графический пользовательский интерфейс
Если перейти от командного интерфейса к графическому, то стоит рассмотреть два наиболее популярных пользовательских окружения unix-систем Gnome и KDE, для которых выпущены фреймворки (GTK+ и QT, соответственно), с помощью которых создаются приложения. Данные окружения сейчас чрезвычайно популярны и используются в большинстве unix-подобных систем. Имеются возможности их использования и в среде Windows, но здесь у них основное назначение состоит в поддержке запускаемых пользовательских приложений, в то время как в unix-системах они ещё и создают полноценную рабочую среду.
Элементы практически всех пользовательских интерфейсов состоят из объектов. Как правило, имеется несколько базовых классов, из которых методом наследования получается разнообразие элементов управления (от диалогов до кнопок и переключателей). Взаимодействие между объектами осуществляется обменом сообщениями, генерированием событий, исключений. При этом наиболее последовательной выступает библиотека QT, а вот в GTK+ практикуется смешение объектного и процедурного стилей.
В мире коммерческих unix-систем имелся положительный опыт разработки объектноориентированной операционной оболочки, основанной на библиотеке Motif. Речь идет о первых попытках стандартизации рабочего окружения на многочисленных операционных системах, то есть создание настоящей операционной среды - Common Desktop Environment (CDE) [4]. Эта среда, появившаяся в конце 90-х годов прошлого века, очень активно эксплуатировалась, но была «заморожена» из-за лицензионных ограничений. В настоящее время CDE распространяется с открытой лицензией, и опыт её разработки и эксплуатации мог бы пригодиться современным разработчикам.
Всё чаще для построения программ с GUI используют языки очень высокого уровня и скриптовые (Ruby, Python). Эти языки используют графические библиотеки GTK и QT «напрямую» благодаря специальным «обвязкам», благодаря чему к существующим консольным программам нетрудно разработать полноценный графический интерфейс, не дублируя основное содержание. Эти элементы пользовательского интерфейса также используют в качестве основных элементов объекты.
Интерфейс прикладного программирования
От интерфейса с пользователем обратимся теперь к интерфейсу с приложениями. Большинство операционных систем предоставляют приложениям программный интерфейс (API), который, в основном, представляет собой библиотеки системных функций. Эти
40
функции сгруппированы по категориям, к ним обычно прилагаются многочисленные структуры данных. Этот интерфейс очень далёк от объектной модели, часто бывает запутанным, нелогичным, избыточным, а также плохо документированным. Разработчики систем всегда оставляют недокументированные средства, благодаря которым могут достраивать систему или управлять её скрытыми настройками.
Своеобразным исключением можно считать безвременно забытую операционную систему BeOS, обладавшую API, реализованным на С++, и предлагавшей концепцию серверов для программных приложений. Идеи, заложенные в BeOS, надолго опередили своё время, и вот теперь их можно встретить в свободной реализации под названием Haiku [5].
Microsoft сделала ряд важных шагов в плане унификации API через прослойку .NET, которая фактически является системой классов и виртуальной машиной, преобразующей вызовы команд CLR в native-инструкции. Благодаря .NET удалось создать немало прикладных программ, имеющих объектный стиль взаимодействия с ресурсами системы. Несомненно, создание .NET было важным маркетинговым и техническим ходом компании, и его развитие было подготовлено предшествующей историей технологии COM.
Выводы
Подводя итоги, мы должны признать, что в операционных средах объектные технологии можно встретить чаще, чем в операционных системах, но и здесь нет общепринятого стандарта на их использование и развитие. Остаётся выразить надежду, что современные активные разработки пользовательских окружений будут учитывать положительный опыт прошлых проектов с использованием ООП, а разработчики системных API будут расширять объектные возможности своих ресурсов.
Литература
1. Штанюк А.А. Перспективы развития объектно-ориентированных операционных систем //
Объектные системы - 2013: Материалы VII Международной научно-практической
конференции (Ростов-на-Дону, 10-12 мая 2013) - ШИ(Ф) ЮГТУ, 2013, с. 35-39.
2. Коробко И. PowerShell как средство автоматического администрирования. М.: ДМК Пресс,
2014.
3. Гифт Н., Джонс Д. Python в системном администрировании Unix и Linux. М.: Символ-плюс,
2009.
4. CDE 2.1 Data Sheet [Электронный ресурс]. - Режим доступа
http://www.opengroup.org/desktop/cde/cde.data.sheet.htm (дата обращения 12.04.2014).
5. Haiku Book [Электронный ресурс]. - Режим доступа https://api.haiku-os.org/ (дата обращения
12.04.2014).
УДК 004.04
ПРЕДМЕТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ СТРУКТУРЫ БАЗЫ ДАННЫХ В ПОНЯТИЯХ МЕТАМОДЕЛИ ОБЪЕКТНОЙ СИСТЕМЫ
Олейник Павел Петрович, к.т.н., Системный архитектор программного обеспечения, ОАО «Астон»,
Россия, Ростов-на-Дону, [email protected]
Введение
В настоящее время широкую популярность получило предметно-ориентированное проектирование, предполагающее создание модели предметной области, основу которой составляет диаграмма классов, представленная в нотации UML [1-2]. Предполагается, что при реализации информационной системы впоследствии применяется объектноориентированный язык программирования, а для хранения информации в долговременной памяти - используется СУБД. При проектировании структуры БД можно выделить три основных этапа: концептуальное, логическое и физическое проектирование [3]. Последний
41
