Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

МГОУ имени В.С. Черномырдина. Одной из самых основных методик разработки ПО на сегодняшний день является

Жохова Л.А., к.п.н., доцент;Троицкий Д.В. студент 1 к. ГУиМ | Жохова Н.Н., ст. преподаватель; А.С.Тишков, студент 3 к. ГУиМ | СУБД - ОРИЕНТИРОВАННАЯ СИСТЕМА АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ ИНФОРМАЦИОННЫМИ ПРОЦЕССАМИ | МГОУ имени В.С. Черномырдина | МГОУ имени В.С. Черномырдина | Им. В.С. Черномырдина | МГОУ имени В.С. Черномырдина | МГОУ имени В.С. Черномырдина | Основные характеристики устройства | Анализ работоспособности модели |


Читайте также:
  1. I. Вопросительные местоимения-прилагательные
  2. I. Неопределенные местоимения-прилагательные
  3. I. Указательные местоимения-прилагательные
  4. II. Вопросительные местоимения-существительные
  5. II. Неопределенные местоимения-существительные
  6. II. Притяжательные местоимения-существительные
  7. II. Указательные местоимения-существительные

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

 

Естественной потребностью прикладных программ, разработанных с использованием объектно-ориентированного подхода, является сохранение состояния объектов из оперативной памяти во внешнее постоянное хранилище и обратная операция — восстановление состояний объектов. Эти операции носят название соответственно сериализации и де-сериализации объектов.

 

 

Одновременно с этим сложилась практика использования реляционных (табличных) СУБД в качестве универсальных хранилищ самых разнообразных данных. Плюсами реляционных СУБД являются:

ñ сравнительно простая математическая модель, лежащая в их основе — т. н. реляционная алгебра;

ñ наличие относительно стандартизированного способа взаимодействия с такими СУБД в виде языка SQL, который используется для выполнения запросов и других манипуляций с данными;

ñ наличие относительно стандартизированных прикладных программных интерфейсов (Application Programming Interface, API) для всевозможных языков программирования, с помощью которых программа может выполнять запросы к СУБД, используя выше упомянутый язык SQL;

ñ огромный выбор реализаций реляционных СУБД, удовлетворяющий большинству потребностей хранения данных;

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

 

В противовес реляционным существуют объектно-ориентированные базы данных, однако, по ряду причин, широкого распространения они до сих пор не получили. В качестве альтернативы объектным БД было предложено совмещение двух самых распространенных практик — объектно-ориентированного подхода и хранения данных в реляционных БД — это решение получило название объектно-реляционного преобразователя (Object-Relational Mapper, ORM). Основная задача инструментария ORM — отобразить классы, объекты и связи между ними на сущности БД — таблицы, строки, ограничения первичных и внешних ключей.

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

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

Нужно помнить, что между реляционной и объектной моделями существует значительное различие, они решают разные задачи. Поэтому, если в разрабатываемой системе основной упор делается на многокритериальный поиск и массированное извлечение информации (класс информационно-поисковых систем, OLAP, генерация отчетности), то использование объектов для доступа к данным может быть излишне. Никакого различия между табличным представлением информации в базе данных, внутри программы и на экране пользователя или в отчете нет, промежуточная обработка сводится к соединениям таблиц и простым пересчетам значений их полей. Напротив, если система осуществляет транзакционную обработку (OLTP, On-Line Transaction Processing), сложные расчеты, оповещения о событиях, диспетчеризацию, моделирует поведение — здесь преимущества использования инструментария ORM наибольшие.

На данный момент инструментарии ORM в среде программистов на C++ используются не так широко как среде программистов на таких языках, как Java или Python. Причиной может быть как несколько иная сложившаяся область применения языка С++, так и недостаточная развитость средств ORM, доступных программистам на языке C++.

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

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

При разработке должны быть использованы только общедоступные, а еще лучше стандартные компоненты. Однако, стандартная библиотека актуального стандарта ANSI С++ не содержит примитивов для работы с базами данных, данными в формате XML, типами данных для хранения дат и чисел с фиксированной точкой. Отчасти этот пробел восполняется такими библиотеками как Boost, являющимися стандартом де-факто.

 

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


 


Дата добавления: 2015-09-01; просмотров: 49 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
МГОУ имени В.С. Черномырдина| ТЕХНОЛОГИИ МОДЕЛИРОВАНИЯ СИСТЕМ ОПТИЧЕСКОЙ ОБРАБОТКИ ИНФОРМАЦИИ

mybiblioteka.su - 2015-2024 год. (0.007 сек.)