67
На рисунке №12 схематично показаны этапы эволюции технологии
аутентификации к записям.
С середины 1980х годов существовала проблема концепции независимости
ввиду конкретной базы данных. Проблема состоит в том, как данные должны
поступать из самых разных источников, любой из которых обладает своей
спецификой. Однако внедрение приложений существенно упростилась бы, если бы
удалось создать унифицированный механизм взаимодействия с самыми разными
источниками данных.
Это мог бы быть универсальный программный интерфейс API, который
позволил бы программистам разрабатывать приложения, одинаковым образом
взаимодействующие с различными источниками данных.
За истекшее время различными компаниями было предложено множество
решений в этой области. Наиболее значительными являются MS ODBC (Open
Database Connectivity)
В середине 1990х годов, с развитием, распространением технологии COM
(Component Object Model), компания MS объявила о постепенном переходе ввиду
ODBC к использованию новой технологии OLE DB. Однако OLE DB, по причине
мнению самой компании MS, является интерфейсом системного уровня, этот
интерфейс должен использоваться системными программистами. Технология OLE
DB является тяжеловесной, трудной, очень чувствительной к ошибкам. Она
требует ввиду программиста слишком многого. Работать с OLE DB очень трудно.
Чтобы облегчить работу с OLE DB, был создан дополнительный прикладной
уровень, который получил название ADO (ActiveX Data Objects). Работать с ADO
существенно проще, чем с OLE DB. Технология ADO предназначена в угоду
прикладных программистов.
Стандарт COM был разработан в 1993 году корпорацией Майкрософт как
основа в угоду развития технологии OLE. Технология OLE 1.0 уже позволяла
создавать т. н. «составные документы» (англ. compound documents): например, в
пакете MS Office эта технология позволяла включать диаграммы MS Excel в
документы MS Word. Стандарт же COM должен был унифицировать процесс
создания, включения, связывания таких внедряемых объектов, а в свою очередь
стандартизировать разработку приложений, использующих внедряемые объекты.
68
COM (англ. Component Object Model — Объектная Модель Компонентов;
произносится как [ком]) — это технологический стандарт ввиду компании MS,
предназначенный в угоду разработки программного обеспечения на базе
взаимодействующих распределённых компонентов, любой из которых может
использоваться во многих программах одновременно. Технология воплощает в
себе идеи полиморфизма, инкапсуляции объектно-ориентированного
программирования. Технология COM могла бы быть универсальной,
платформонезависимой, но закрепилась в основном на операционных системах
семейства MS Windows. В современных версиях Windows COM используется очень
широко.
OLE (англ. Object Linking and Embedding) — технология связывания,
включения объектов в протокол, разработанная корпорацией Майкрософт.
OLE позволяет передавать часть работы ввиду одной программы
редактирования к другой, возвращать результаты назад. Например, установленная
на персональном компьютере издательская система может послать некий текст на
обработку в текстовой редактор, либо некоторое изображение в редактор
изображений с поддержкой OLE технологии.
Основное преимущество использования OLE (кроме уменьшения размера
файла) в том, как она позволяет создать главный файл, картотеку функций, к
которой обращается программа. Этот файл может оперировать записями из
исходной программы, которые впоследствии обработки возвращаются в исходный
документ.
OLE используется в обработке составных документов (англ. compound
documents), может быть использована в передаче данных промеж различными
несвязанными промеж собой системами посредством интерфейса переноса (англ.
draganddrop), а в свою очередь в выполнении операций с буфером обмена. Идея
включения широко используется в работе с мульмедийным содержанием на
вебстраницах (пример — ВебТВ), где используется передача изображение звука,
видео, анимации в страницах HTML (язык гипертекстовой разметки) либо в других
файлах, в свою очередь использующих текстовую разметку (например, XML,
SGML). Однако технология OLE использует архитектуру «толстого клиента», то
есть сетевой ПК с избыточными вычислительными ресурсами. Это означает, как
69
тип файла либо программа, которую пытаются внедрить, обязана присутствовать
на машине клиента. Например, если OLE оперирует таблицами MS Excel, то
программа Excel обязана быть инсталлирована на машине пользователя.
OLE 1.0 был выпущен в 1990 году на базе технологии DDE (Dynamic Data
Exchange), использовавшейся в ранних версиях операционной системы MS
Windows. В то время как технология DDE была сильно ограничена в количестве,
методах передачи данных промеж двумя работающими программами, OLE имел
возможность оперировать активными соединениями промеж двумя документами
либо даже внедрить документ одного типа в документ другого типа.
OLE сервера, клиенты взаимодействуют с системными библиотеками в
помощи таблиц виртуальных функций (англ. virtual function tables, VTBL). Эти
таблицы содержат указатели на функции, которые системная библиотека может
использовать в угоду взаимодействия с сервером или же клиентом. Библиотеки
OLESVR.DLL (на сервере), OLECLI.DLL (на клиенте) первоначально были
разработаны в угоду
взаимодействия промеж собой с поддержкой сообщения WM_DDE_EXECUTE,
разработанного операционной системой.
OLE 1.1 позднее объединился с архитектурой COM (component object model)
в угоду работы с компонентами программного обеспечения. Позднее архитектура
COM была преобразована, стала называться DCOM.
Когда объект OLE помещен в буфер обмена информацией, он сохраняется в
оригинальных форматах Windows (таких как bitmap или же metafile), а в свою
очередь сохраняется в своём собственном формате. Собственный формат позволяет
поддерживающей OLE программе внедрить порцию другого документа,
скопированного в буфер,, сохранить её в документе пользователя.
OLE DB представляет собой отбор специализированных объектов СОМ,
инкапсулирующих стандартные функции обработки данных,, специализированные
функции конкретных источников данных, интерфейсов, обеспечивающих передачу
данных промеж объектами.
Интерфейс ADO
ADO это объектно-ориентированный интерфейс фирмы Мicrosoft в угоду
работы с data base, другими аналогичными источниками данных объектам данных
70
АctiveХ (АctiveХ Data Оbject АDО). АDО содержит представление объектов,
которые возможно использовать в угоду работы с записями многих всевозможных
типов приложений. АDО опирается на интерфейс Соmmоn Оbjесt Моdel (СОМ),
содержащий объекты, доступные в угоду широкого спектра языков
программирования, включая Visual С++, Visual Basic, Visual Basic for Applications
(VВА), VBScript, JavaScript. АDО в свою очередь возможно использовать в
серверных или же приложениях промежуточного типа, особенно в работе с Active
Server Page компании Мicrosoft.
Типы данных NoSQL
Хранилище на основе упорядоченных столбцов. Решение Bigtable компании
Google предлагает модель хранения данных на основе столбцов. Это решение
противоположно решению, применяемому в реляционных решениях, на основе
строк. Хранилище столбцов более эффективно хранит данные. Подобный формат
сокращает расходы при хранении пустых значений (NULL-значение или
типизированных пустых значений). Каждый элемент данных хранится как набор
пар ключ – значение, причем каждый элемент однозначно идентифицируется
ключевым атрибутом, также называемым первичным ключом. В Bigtable и его
клонах такой идентификатор получил название строковый ключ. Дополнительно,
как видно из названия формата, элементы данных хранятся в упорядоченном виде;
элементы отсортированы и упорядочены по значению строкового ключа. Для
лучшего понимания данного формата рассмотрим пример. Пусть дана простая
таблица данных, содержащая информацию о людях.
Подобная таблица содержит следующие столбцы:
irst_name (имя),
last_name (фамилия),
occupation (адрес),
zip_code (индекс),
and gender (пол).
Информация об отдельном человеке в такой таблице имеет вид:
irst_name: John
last_name: Doe
zip_code:10001
71
gender: male
Другой элемент данных может иметь иной вид: irst_name: Jane zip_code:
94303 Строковый ключ первого элемента может быть равен 1, а второго 2. Тогда
эти данные будут храниться таким образом, что элемент с ключом 1 будет
размещен перед элементом с ключом 2. Также оба элемента будут выравнены
относительно друг друга. Далее, только пары «ключ – значения» с корректными
значениями будут храниться в системе. Таким образом, возможное семейство
столбцов для данного примера может быть названо как name и содержать столбцы
irst_name и last_name, которые принадлежат данному семейству. Другое семейство
может быть location со столбцом zip_code. Третье семейство столбцов может быть
названо как proile. Семейства столбцов обычно конфигурируются на этапе запуска.
Сами столбцы не нуждаются в предварительном объявлении. Столбцы могут
хранить данные любого типа, включая массивы байт. Таким образом, логическое
представление полученного хранилища для данного примера состоит из семейств
столбцов: name, location и proile. Внутри каждого семейства хранятся только
корректные значения. Семейство столбцов name хранит следующие значения: For
row-key: 1 irst_name: John last_name: Doe For row-key: 2 irst_name: Jane Семество
столбцов location будет хранить: For row-key: 1 zip_code: 10001 For row-key: 2
zip_code: 94303 Семейство столбцов proile будет хранить значения только для
элемента с ключом 1: For row-key: 1 gender: male
В практических реализациях хранилищ, семейства столбцов не изолированы
в рамках одной строки. Все данные, относящиеся к одному строковому ключу,
хранятся совместно. Семейство столбцов выступает как ключ для столбцов,
которые заключены в данном семействе, а строковый ключ выступает в качестве
ключевого поля для всего набора данных. Данный в Bigtable и его клонах хранятся
в последовательной форме. По мере того как растет объем данных на отдельном
узле, может возникнуть необходимости разделения узла на два. Данные
сортируются и упорядочиваются не только в пределах одного узла, но и в рамках
группы узлов, обеспечивающих функционирование укрупненного набора
последовательных данных. Данные хранятся в отказоустойчивой форме, при
которой поддерживаются три копии каждого набора. Большинство клонов Bigtable
также используют распределенное файловое хранилище, что позволяет
72
распределять данные по узлам кластера. Сортированная упорядоченная структура
позволяет эффективно реализовать поиск данных. HBase – это распространенное,
свободно распространяемое решение на базе семейства столбцов, которое
спроектировано на основе идей, лежащих в основе Bigtable от Google. Данный в
HBase обрабатываются в рамках парадигмы MapReduce. MapReduce-инструменты
Hadoop могут использовать HBase как источник и/или приемника данных. Вот
некоторые open-source клоны Bigtable: – HBase; – Hypertable; – Cloudata.
Хранилища на основе семейства столбцов в настоящее время широко
распространены и формируют популярное NoSQL-направление. Тем не менее,
NoSQL-подход заключает в себе различные варианты хранилищ типа «ключ –
значение» и документоориентированных хранилищ.
Хранилища «ключ – значение».
Структура данных HashMap, или ассоциированный массив, способна
хранить набор элементов, каждый из которых представляет собой пару ключ –
значение. Данная структура данных очень популярна благодаря эффективной
реализации (в среднем О(1)) процедуры доступа к данным. Ключи в парах ключ –
значение являются уникальными в пределах всего набора данных, благодаря чему
просто обеспечивается поиск данных. Пары ключ – значение могут быть
различного типа: некоторые предполагают хранение данных в ОЗУ, другие
обеспечивают хранение на диске. Пары ключ – значение могут быть распределены
по узлам кластера. Простое и производительное хранилище типа ключ – значение –
Berkeley DB от Oracle. B erkeley DB – это только движок хранилища данных, в
котором и ключи и значения – байтовые массивы. Движок Berkeley DB не
предполагает, что у данных могут быть смысловые значения. Berkeley DB
оперирует массивами батов и возвращает их по запросу клиентов. Данные
кэшируются в ОЗУ и «сбрасываются» на диск п мере роста их объема. В Berkeley
DB существует также механизм индексирования, обеспечивающий ускорение
операций поиска. Данная база данных существует с середины 1990 года.
Изначально, Berkeley DB создавалась чтобы заменить NDBM от AT&T. Другой
распространенный способ организации хранилищ типа ключ – значение – к эширов
ание. Кэширование обеспечивает снимок в памяти для тех данных, которые
наиболее часто используются приложением. Основная цель подхода –
73
минимизировать количество обращений к диску. Кэширование – это стратегия,
которая реализуется на различных уровнях программного стека для увеличения
производительности. Кэширование используется в операционных системах, базах
данных, различных компонентах и приложениях. Существуют надежные open-
source распределенные системы кэширования наподобие EHCache
(http://ehcache.org/), которая широко распространена при разработке Java-
приложений. EHCache также может рассматриваться как решение NoSQL. Другая
известная система кэширования – Memcached (http://memcached.org/), которая
представляет собой open-source высокопроизводительную систему кэширования
объектов. Memcached была создана Брадом Фитцпатриком для LiveJournal в 2003
году. Memcached позволяет эффективно управлять памятью ЭВМ, создавая
виртуальный пул и выполняя при необходимости распределение общего адресного
пространства между узлами. Это предотвращает появление ситуаций, когда один
узел имеет избыток памяти, а другой испытывает недостаток в ней. Так как
NoSQL-технологии продолжают развиваться, то появляются различные хранилища
типа ключ – значение. Некоторые из них строятся на основе Memcached API,
другие используют Berkeley DB как низлежащее хранилище, третьи – реализуют
альтернативные подходы на новых принципах
Многие из систем, основанных на парах ключ – значение, обладают
собственным API, позволяющим более просто развернуть распределенную
систему. Несколько из них, такие как Redis (http://redis.io/), обеспечивают более
производительные API и более высокий уровень абстракции. Redis – это сервер
структур данных, так как он предоставляет различные структуры данных в виде
строк (последовательности символов), списков, множеств, а также карт
отображения. Redis также предоставляет программисту богатый набор операций
над этими структурами данных. Некоторые хранилища на основе пар ключ –
значение: – Membase; – Kyoto Cabinet; – Redis. Все три вышеуказанные системы
являются эффективными хранилищами типа ключ – значение, обеспечивающие
хранение данных для систем реального времени, часто используемых данных или
просто для долговременного хранения данных. Системы на основе пар ключ –
значение рассматриваемые до сих пор обеспечивают надежную модель
согласованности данных, которые они хранит. Однако, некоторые другие системы
74
типа ключ – значение делают акцент на доступности вместо согласованности.
Многие из них разработаны на основе Dynamo от Amazon, системы, которая также
основана на парах ключ – значение. Dynamo от Amazon обеспечивает высокую
доступность и масштабируемость и составляет основу отказоустойчивых систем
Amazon. Амазонки вина и высокой доступности системы. Apache Cassandra, Basho
Riak, и Voldemort являются open-source-проектами, в основе которых положены
идеи Amazon Dynamo. Amazon Dynamo выносит на первый план идеи высокой
доступности. Наиболее важная из концепций – временная согласованность.
Временная (условная, частичная) согласованность подразумевает, что там могут
присутствовать небольшие интервалы несоответствия реплицированных узлов, в то
время как происходит обновление данных между узлами peer-to-peer. Временная
согласованность не означает, что данные не согласованы. Это лишь слабая форма
согласованности, чем та, которая определяется в принципах ACID для РСУБД.
Существуют клоны Dynamo: – Cassandra;
Документоориентированные базы данных.
Документоориентированные базы данных не являются системами
автоматизации документооборота. Многие начинающие разработчики путают
систему NoSQL на основе документоориентированной базы данных и систему
управления контентом на основе документов. Слово документ в сфере баз данных
подразумевает слабо структурированные наборы пар ключ – значение для
описания документа в формате JSON (нотация объектов JavaScript); это не
документы или электронные таблицы (хотя они также могут быть сохранены в
подобных системах). Документоориентированные базы данных рассматривают
документ в целом, не разбивая его на составные пары имя/значение. Это позволяет
оперировать коллекциями документов. Документоориентированные базы данных
поддерживают индексирование не только на основе первичного ключа, но и с
использованием различных свойств документа. На сегодняшний день доступны
несколько СУБД данного типа, но наиболее популярными являются MongoDB и
CouchDB.
Графовые базы данных.
В предыдущих подразделах были рассмотрены основные направления
развития продуктов NoSQL. Некоторые решения, например, основанные на
75
графовых базах данных и XML, также могут быть отнесены к базам данных
NoSQL. В данном пособии они рассматриваться не будут. Сегодня наибольшую
популярность приобрели графовые базы данных: Neo4j и FlockDB. Neo4J
полностью удовлетворяет требованиям ACID. Такие СУБД облегчают обработку
графов.
76
2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Каскадная модель
Деятельность по причине созданию программного продукта описывается в
виде модели жизненного цикла как последовательности процессов, работ, задач,
обеспечивающих разработку, эксплуатацию, сопровождение программного
продукта, отражающей эволюцию изменения продукта, начиная ввиду
формулировки требований к ней до прекращения ее использования. Такая
последовательность может быть а то и не быть линейной, поскольку фазы должны
следовать друг за другом, повторяться а то и происходить одновременно (рисунок
№13). В литературе приводятся описания следующих моделей жизненного цикла
разработки ПП: каскадной, V-образной, прототипирования, быстрой разработки
приложений, инкрементной, спиральной [11, 12]. Одной из первых, применяемых
на практике моделей была каскадная модель, а то и «водопад», в которой каждая
работа выполняется один раз, лишь в определенной последовательности. В этом
делается допущение, как каждая работа будет выполнена настолько тщательно,
как впоследствии ее завершения, перехода к следующей работе возвращения к
предыдущей не потребуется (рисунок №14). Отличительным свойством каскадной
модели возможно назвать то, как она представляет собой формальный метод,
разновидность разработки «сверху вниз», состоит из независимых фаз,
выполняемых последовательно. Каскадную модель возможно рассматривать как
модель ЖЦ, пригодную в угоду разработки первой версии ПП, в условии если:
условия к ПП максимально четко определены, понятны, не изменяются;
разрабатывается новая версия уже существующего продукта, вносимые изменения
четко определены, управляемы; осуществляется разработка ПП типовых бизнес-
процессов, содержание которых закреплено законодательно.