Разработку приложений можно вести в среде Android Studio, NetBeans, в среде Eclipse, используя при этом плагин Android Development Tools (ADT) или в IntelliJ IDEA. Версия JDK при этом должна быть 5.0 или выше.

8 декабря 2014 года Android Studio признана компанией Google официальной средой разработки под ОС Android.

Следующие успешные проекты реализованы с привлечением Java (J2EE) технологий: RuneScape, Amazon, eBay, LinkedIn, Yahoo!.

Следующие компании в основном фокусируются на Java (J2EE) технологиях: SAP, IBM, Oracle. В частности, СУБД Oracle Database включает JVM как свою составную часть, обеспечивающую возможность непосредственного программирования СУБД на языке Java, включая, например, хранимые процедуры.

Программы, написанные на Java, имеют репутацию более медленных и занимающих больше оперативной памяти, чем написанные на языке Си. Тем не менее, скорость выполнения программ, написанных на языке Java, была существенно улучшена с выпуском в 1997 - 1998 годах так называемого JIT-компилятора в версии 1.1 в дополнение к другим особенностям языка для поддержки лучшего анализа кода (такие, как внутренние классы, класс StringBuffer, упрощенные логические вычисления и т.д.). Кроме того, была произведена оптимизация виртуальной машины Java - с 2000 года для этого используется виртуальная машина HotSpot. По состоянию на февраль 2012 года, код Java 7 приблизительно лишь в 1.8 раза медленнее кода, написанного на языке Си.

Некоторые платформы предлагают аппаратную поддержку выполнения для Java. К примеру, микроконтроллеры, выполняющие код Java на аппаратном обеспечении вместо программной JVM, а также основанные на ARM процессоры, которые поддерживают выполнение байткода Java через опцию Jazelle.

Основные возможностиJava:

автоматическое управление памятью;

расширенные возможности обработки исключительных ситуаций;

богатый набор средств фильтрации ввода-вывода;

набор стандартных коллекций: массив, список, стек и т.п.;

наличие простых средств создания сетевых приложений (в том числе с использованием протокола RMI);

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

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

унифицированный доступ к базам данных:

на уровне отдельных SQL-запросов - на основе JDBC, SQLJ;

на уровне концепции объектов, обладающих способностью к хранению в базе данных - на основе Java Data Objects (англ.) и Java Persistence API;

поддержка обобщений (начиная с версии 1.5);

параллельное выполнение программ.

2.1.2 JavaScript

JavaScript (джаваскрипт) - прототипно-ориентированный сценарный язык программирования.

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

Основные архитектурные черты:

динамическая типизация;

слабая типизация;

автоматическое управление памятью;

прототипное программирование;

функции как объекты первого класса.

На JavaScript оказали влияние многие языки, при разработке была цель сделать язык похожим на Java, но при этом легким для использования непрограммистами. Языком JavaScript не владеет какая-либо компания или организация, что отличает его от ряда языков программирования, используемых в веб-разработки.

Название "JavaScript" является зарегистрированным товарным знаком компании Oracle Corporation.

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

Несмотря на схожий с Си синтаксис, JavaScript по сравнению с языком Си имеет коренные отличия:

объекты, с возможностью интроспекции;

функции как объекты первого класса;

автоматическое приведение типов;

автоматическая сборка мусора;

анонимные функции.

В языке отсутствуют такие полезные вещи, как:

модульная система: JavaScript не предоставляет возможности управлять зависимостями и изоляцией областей видимости;

стандартная библиотека: в частности, отсутствует интерфейс программирования приложений по работе с файловой системой, управлению потоками ввода-вывода, базовых типов для бинарных данных;

стандартные интерфейсы к веб-серверам и базам данных;

система управления пакетами, которая бы отслеживала зависимости и автоматически устанавливала их.

Синтаксис языка JavaScript во многом напоминает синтаксис Си и Java, семантически же язык гораздо ближе к Self, Smalltalk или даже Лиспу.

В JavaScript:

все идентификаторы регистрозависимы;

в названиях переменных можно использовать буквы, подчеркивание, символ доллара, арабские цифры;

названия переменных не могут начинаться с цифры;

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

Структурно JavaScript можно представить в виде объединения трех четко различимых друг от друга частей:

ядро (ECMAScript);

объектная модель браузера (Browser Object Model или BOM);

объектная модель документа (Document Object Model или DOM);

Если рассматривать JavaScript в отличных от браузера окружениях, то объектная модель браузера и объектная модель документа могут не поддерживаться.

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

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

Объектная модель браузера - браузер-специфичная часть языка, являющаяся прослойкой между ядром и объектной моделью документа. Основное предназначение объектной модели браузера - управление окнами браузера и обеспечение их взаимодействия. Каждое из окон браузера представляется объектом "window", центральным объектом DOM. Объектная модель браузера на данный момент не стандартизирована, однако спецификация находится в разработке WHATWGи W3C.

Помимо управления окнами, в рамках объектной модели браузера, браузерами обычно обеспечивается поддержка следующих сущностей:

управление фреймами;

поддержка задержки в исполнении кода и зацикливания с задержкой;

системные диалоги;

управление адресом открытой страницы;

управление информацией о браузере;

управление информацией о параметрах монитора;

ограниченное управление историей просмотра страниц;

поддержка работы с HTTP cookie.

Объектная модель документа - интерфейс программирования приложений для HTML и XML-документов. Согласно DOM, документ (например, веб-страница) может быть представлен в виде дерева объектов, обладающих рядом свойств, которые позволяют производить с ним различные манипуляции:

– генерация и добавление узлов;

– получение узлов;

– изменение узлов;

– изменение связей между узлами;

– удаление узлов.

Встраивание в веб-страницы

– расположение внутри страницы;

– расположение внутри тега;

– вынесение в отдельный файл.

Область применения:

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

AJAX. JavaScript используется в AJAX, популярном подходе к построению интерактивных пользовательских интерфейсов веб-приложений, заключающемся в "фоновом" асинхронном обмене данными браузера с веб-сервером. В результате, при обновлении данных веб-страница не перезагружается полностью и интерфейс веб-приложения становится быстрее, чем это происходит при традиционном подходе (без применения AJAX).

Comet.comet - широкое понятие, описывающее механизм работы веб-приложений, использующих постоянные HTTP-соединения, что позволяет веб-серверу отправлять данные браузеру без дополнительного запроса со стороны браузера. Для таких приложений используются технологии, непосредственно поддерживаемые браузерами. В частности, в них широко используется JavaScript.

Браузерные операционные системы. JavaScript широко используется в браузерных операционных системах. Так, например, исходный код IndraDesktop WebOS на 75 % состоит из JavaScript, код браузерной операционной системы IntOS - на 70 %. Доля JavaScript в исходном коде eyeOS - 5 %, однако и в рамках этой операционной системы JavaScript играет важную роль, участвуя в визуализации на клиенте и являясь необходимым механизмом для коммуницирования клиента и сервера.

Серверные приложения. Приложения, написанные на JavaScript, могут исполняться на серверах, использующих Java 6 и более поздних версий. Это обстоятельство используется для построения серверных приложений, позволяющих обрабатывать JavaScript на стороне сервера. Помимо Java 6, существует ряд платформ, использующих существующие движки (интерпретаторы) JavaScript для исполнения серверных приложений. (Как правило, речь идет о повторном использовании движков, ранее созданных для исполнения кода JavaScript в браузерах WWW.)

Для обеспечения высокого уровня абстракции и достижения приемлемой степени кросс-браузерности при разработке веб-приложений используются библиотеки JavaScript. Они представляют собой набор многократно используемых объектов и функций.

Среди известных JavaScript библиотек можно отметить Adobe life, Dojo Toolkit, Extjs, jQuery, Mootools, Prototype, Qooxdoo, Underscore.

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

По состоянию на ноябрь 2009 года, Internet Explorer, Opera, Firefox, Safari, и Google Chrome имеют отладчики сценариев.

Internet Explorer имеет три отладчика: Microsoft Visual Studio - самый полный из них, за ним следует Microsoft Script Editor (компонент Microsoft Office), и, наконец, свободный Microsoft Script Debugger, гораздо более простой, чем два других. Бесплатный Microsoft Visual Web Developer Express предоставляет ограниченную версию с отладочной функцией JavaScript в Microsoft Visual Studio. В восьмой версии в IE вместе с инструментами для разработчиков появился встроенный отладчик.

В Opera также имеется собственный отладчик - Opera Dragonfly.

Разрабатываемые веб-приложения в Firefox можно отлаживать при помощи расширений Firebug, Venkman.

В Safari входитотладчик JavaScript WebKit Web Inspector. Этот же отладчик доступен и в других браузерах, использующих WebKit: Google Chrome, Arora, Rekonq, Midori и др.

Большинство фреймворков автоматизированного тестирования JavaScript-кода предполагают запуск тестов в браузере. Это осуществляется при помощи HTML-страницы, являющейся контекстом тестирования, которая, в свою очередь загружает все необходимое для осуществления тестирования. Первыми такими фреймворками были JsUnit (создан в 2001 году), Selenium (создан в 2004 году). Альтернатива - запуск тестов из командной строки. В этом случае используются окружения, отличные от браузера, например, Rhino. Одним из первых инструментов такого рода является Crosscheck, позволяющий тестировать код, эмулируя поведение Internet Explorer 6 и Firefox версий 1.0 и 1.5 Другой пример фреймворка автоматизированного тестирования JavaScript-кода, не использующего браузер для запуска тестов - библиотека env. js, созданная Джоном Резигом. Она использует Rhino и при этом содержит эмуляцию окружения браузера и DOM.

Blue Ridge, плагин к фреймворку веб-приложений Ruby on Rails, позволяет осуществлять модульное тестирование JavaScript-кода как в браузере, так и вне его. Это достигается за счет использования фреймворка автоматизированного тестирования Screw. Unit и Rhino с env. js.

Главная проблема систем тестирования, не использующих браузеры, в том, что они используют эмуляции, а не реальные окружения, в которых выполняется код. Это приводит к тому, что успешное прохождение тестов не гарантирует того, что код корректно отработает в браузере. Проблемой систем тестирования, использующих браузер, является сложность работы с ними, необходимость осуществления рутинных неавтоматизированных действий. Для решения этого JsTestDriver, фреймворк автоматизированного тестирования, разрабатываемый Google, использует сервер, взаимодействующий с браузерами для осуществления тестирования. Сходным образом ведет себя Selenium Remote Control, входящий во фреймворк автоматизированного тестирования Selenium: он включает в себя сервер, запускающий и завершающий браузеры и действующий как HTTP-прокси для запросов к ним. Кроме того, в Selenium содержится Selenium Grid, позволяющий осуществлять одновременное тестирование JavaScript-кода на разных компьютерах с разными окружениями, уменьшая время выполнения тестов. Testswarm, имеющее поддержку фреймворков автоматизированного тестирования JavaScript-кода QUnit (библиотека jQuery), UnitTestJS (библиотека Prototype), JSSpec (библиотека MooTools), JsUnit, Selenium и Dojo Objective Harness, представляет собой распределенное средство поддержки непрерывной интеграции.

Негативное свойство, которым может обладать фреймворк автоматизированного тестирования JavaScript-кода - наличие зависимостей. Это создает риск отказа в работе тестируемого кода, успешно проходящего тесты, в среде с отсутствием этих зависимостей. Например, исходная версия JsUnitTest, фреймворка, созданного и использовавшегося для тестирования библиотеки Prototype, зависела от самой Prototype, изменяющего свойства объектов в глобальной области видимости. Включение в библиотеку JavaScript инструмента тестирования - распространенная практика. Так YUI Test 3 является частью Yahoo! UI Library и может быть безопасно использован для тестирования произвольного JavaScript-кода. QUnit - фреймворк автоматизированного тестирования, созданный разработчиками jQuery.

2.2 SpringMVC

Spring имеет собственную MVC-платформу веб-приложений, которая не была первоначально запланирована. Обеспечивает разделение между слоями представления и обработки запросов, а также между слоем обработки запросов и моделью.

Класс DispatcherServlet является основным контроллером фрэймворка и отвечает за делегирование управления различным интерфейсам, на всех этапах выполнения HTTP - запроса. Об этих интерфейсах следует сказать более подробно.

Spring MVC является фреймворком, ориентированным на запросы. В нем опредены стратегические интерфейсы для всех функций современной запросно-ориентированной системы. Цель каждого интерфейса ? быть простым и ясным, чтобы пользователям было легко его заново имплементировать, если они того пожелают. MVC прокладывает путь к более чистому front - end - коду. Все интерфейсы тесно связаны с Servlet API.

Сервлет является классом Java, реализация которого расширяет функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством принципа запрос-ответ.

Эта связь рассматривается некоторыми как неспособность разработчиков Spring предложить для веб - приложений абстракцию более высокого уровня. Однако эта связь оставляет особенности Servlet API доступными для разработчиков, облегчая все же работу с ним. Наиболее важные интерфейсы, определенные Spring MVC, перечислены ниже:

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

HandlerAdapter: вызов и выполнение выбранного метода обработки входящего запроса;

Controller: включен между Моделью (Model) и Представлением (View). Управляет процессом преобразования входящих запросов в адекватные ответы. Действует как ворота, направляющие всю поступающую информацию. Переключает поток информации из модели в представление и обратно;

View: ответственно за возвращение ответа клиенту в виде текстов и изображений. Некоторые запросы могут идти прямо во View, не заходя в Model; другие проходят через все три слоя;

ViewResolver: выбор, какое именно View должно быть показано клиенту;

HandlerInterceptor: перехват входящих запросов. Сопоставим, но не эквивалентен сервлет - фильтрам (использование не является обязательным и не контролируется DispatcherServlet-ом);

LocaleResolver: получение и, возможно, сохранение локальных настроек (язык, страна, часовой пояс) пользователя;

MultipartResolver: обеспечивает Upload - загрузку на сервер локальных файлов клиента;

Spring MVC предоставляет разработчику следующие возможности:

ясное и прозрачное разделение между слоями в MVC и запросах;

стратегия интерфейсов - каждый интерфейс делает только свою часть работы;

интерфейс всегда может быть заменен альтернативной реализацией;

интерфейсы тесно связаны с Servlet API;

высокий уровень абстракции для веб-приложений.

2.3 JSP

JSP (JavaServer Pages) - технология, позволяющая веб-разработчикам создавать содержимое, которое имеет как статические, так и динамические компоненты. Страница JSP содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов HTML, SVG, WML, или XML, и JSP - элементы, которые конструируют динамическое содержимое. Кроме этого могут использоваться библиотеки JSP-тегов, а также EL (Expression Language), для внедрения Java-кода в статичное содержимое JSP-страниц.

Код JSP-страницы транслируется в Java-код сервлета с помощью компилятора JSP-страниц Jasper, и затем компилируется в байт-код виртуальной машины java (JVM). Контейнеры сервлетов, способные исполнять JSP-страницы, написаны на платформонезависимом языке Java. JSP-страницы загружаются на сервере и управляются из структуры специального Java server packet, который называется Java EE Web Application. Обычно страницы упакованы в файловые архивы. war и. ear.

JSP является платформонезависимой, переносимой и легко расширяемой технологией для разработки веб-приложений.

2.4 PostgreSQL

Свободная объектно-реляционная система управления базами данных (СУБД). PostgreSQL является самым профессиональным СУБД. Она свободно распространяемая и максимально соответствует стандартам SQL.

От других СУБД PostgreSQL отличается поддержкой востребованного объектно-ориентированного и/или реляционного подхода к базам данных. Например, полная поддержка надежных транзакций, т.е. атомарность, последовательность, изоляционность, прочность. Благодаря мощным технологиям Postgre очень производительна. Параллельность достигнута не за счет блокировки операций чтения, а благодаря реализации управления многовариантным параллелизмом (MVCC). PostgreSQL очень легко расширять своими процедурами, которые называются хранимые процедуры. Эти функции упрощают использование постоянно повторяемых операций.

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

Достоинства PostgreSQL:

открытое ПО соответствующее стандарту SQL. PostgreSQL - бесплатное ПО с открытым исходным кодом. Эта СУБД является очень мощной системой;

большое сообщество, существует довольно большое сообщество в котором вы запросто найдете ответы на свои вопросы;

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

расширения - существует возможность расширения функционала за счет сохранения своих процедур;

объектность - PostrgreSQL это не только реляционная СУБД, но также и объектно-ориентированная с поддержкой наследования и много другого.

Когда использовать PostgreSQL:

целостность данных, когда надежность и целостность данных - ваши требования, PostgreSQL будет, пожалуй, лучшим выбором;

сложные пользовательские процедуры, если вам необходимо использовать пользовательские процедуры, то PostgreSQL имеет встроенную поддержку для них;

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

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

2.5 Hibernate

Hibernate ? библиотека для языка программирования Java, предназначенная для решения задач объектно-реляционного отображения (ORM). Она представляет собой свободное программное обеспечение с открытым исходным кодом (open source). Данная библиотека предоставляет легкий в использовании каркас (фреймворк) для отображения объектно-ориентированной модели данных в традиционные реляционные базы данных.

Целью Hibernate является освобождение разработчика от значительного объема сравнительно низкоуровневого программирования по обеспечению хранения объектов в реляционной базе данных. Разработчик может использовать Hibernate как в процессе проектирования системы классов и таблиц "с нуля", так и для работы с уже существующей базой данных.

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

Hibernate обеспечивает прозрачную поддержку сохранности данных.

3. Практическая часть

3.1 Концептуальная модель базы данных

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

В чем же преимущество базы данных перед хранением информации в множестве однородных файлов?

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

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

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

Этот подход практически не обладает недостатками. Единственно, следует отметить, что возрастут затраты на создание, сопровождение программное обеспечения, которое будет отвечать за миграцию данных и необходимость администрировать базу данных.

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

В исследуемой системе существуют шесть тяговых подстанций, на каждой из которых установлено по 9-10 счетчиков, по одному на каждый фидер или выпрямитель. Каждый счетчик снимает показания тока и напряжения с частотой 20 раз в минуту. Программное обеспечение счетчика генерирует csv файл, куда вносит все произведенные измерения за сутки, и отправляет на сервер.

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

В предметной области можно выделить следующие три объекта:

тяговая подстанция;

счетчик тяговой подстанции;

измерение счетчика в один момент времени.

Создадим сущности концептуальной модели на основе этих объектов предметной области.

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

Вторая сущность должна характеризовать важные для системы свойства счетчика. Перечислим эти свойства:

порядковый номер счетчика;

идентификатор подстанции, которой принадлежит данный счетчик;

счетчик, с которым данный соединен контактной сетью;

символьное имя счетчика;

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

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

На рисунке 3.1 представлена диаграмма концептуальной модели базы данных.

Рисунок 3.1 - Концептуальная модель проектируемой базы данных

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

3.2 Логическая модель базы данных

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

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

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

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

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

Определившись с видом логической модели, спроектируем ее на основе сущностей концептуальной модели.

Первой сущностью является тяговая подстанция. На основе атрибутов сущности концептуальной модели разработаем атрибуты сущности модели логической. Результат отображен на ER-диаграмме, представленной на рисунке 3.2.

Рисунок 3.2 - ER-диаграмма сущности тяговой подстанции

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

В таблице ниже приведены все атрибуты отношения, краткое описание и тип данных.

Таблица 3.1 - Описание атрибутов отношения

Наименование атрибута в схеме отношения	Описание	Тип данных
ts_id	Первичный ключ	Целое
ts_name	Название тяговой подстанции	Строка
ts_comment	Пользовательский комментарий для служебной информации	Строка

Следующей сущностью будет Счетчик. На ее основе создадим отношение TS_METER. В данном отношении один атрибут (tsm_id) будет служить суррогатным первичным ключом, два атрибута (ts_id и tsm_nearby) - внешними ключами, которые ссылаются на номер тяговой подстанции и на номер счетчика соответственно. Во втором случае, следует отметить, что отношение будет ссылаться на самого себя.

Подводя итог, сущность TS_METER будет иметь изображенный на рисунке 3.3.

Рисунок 3.3 - ER-диаграмма сущности счетчика

В таблице 3.2 показано соотношение атрибутов сущности со свойствами счетчика.

Таблица 3.2 - Описание атрибутов модели

Наименование атрибута в модели	Характеристика объекта предметной области
tsm_id	Суррогатный первичный ключ. Несмотря на тот факт, что номер счетчика и номер подстанции будут кандидатом в первичные ключи, суррогатный выгоден тем, что позволяет упростить структуру базы данных
tsm_num	Порядковый номер внутри тяговой подстанции.
ts_id	Уникальный идентификатор тяговой подстанции, в составе которой находится счетчик. Внешний ключ
tsm_nearby	Уникальный идентификатор счетчика, соединенного с данным посредством контактной сети. Внешний ключ
tsm_name	Символьное имя счетчика, предназначенное для пользователя
tsm_comment	Пользовательский комментарий

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

У этого отношения первичный ключ тоже будет суррогатным, несмотря на наличие потенциального природного первичного ключа (дата, время измерения и номер счетчика).

Выбор пал на суррогатный ключ, поточу что составной первичный ключ менее удобен, особенно, если он состоит из трех атрибутов. На рисунке 3.4 изображена ER-диаграмма сущности, описывающей одно измерение.

Рисунок 3.4 - ER-диаграмма сущности, описывающей одно измерение

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

Таблица 3.3 - Описание атрибутов модели

Наименование атрибута в модели	Характеристика объекта предметной области
ts_rec_id	Суррогатный первичный ключ
ts_meter_id	Уникальный идентификатор счетчика
ts_date_mensuration	Дата измерения
ts_time_mensuration	Время измерения
ts_voltage	Напряжение на фидере
ts_the_current	Ток фидера
ts_power	Мощность
ts_given_energy	Отданная энергия
ts_accepted_energy	Полученная энергия

Далее необходимо определить кардинальность всех связей между отношениями.

Отношение TS_MENSURATION (ts_meter_id) связано с отношениемTS_METER (tsm_id) с кардинальностью много-к-одному, так много измерений, могут принадлежать одному счетчику, а у каждого измерения может быть только один счетчик.

Отношение TS_METER (ts_id) имеет связь с отношением TS (ts_id) с кардинальностью много-к-одному, потому что на подстанции находятся несколько счетчиков (около десяти), а каждый счетчик может иметь только одну подстанцию. Этот факт следует из предметной области. Отношение TS_METER также связано с самим собой: атрибут tsm_nearby связан с атрибутом tsm_id с кардинальностью один-к-одному.

После проектирования отношений и установления между ними связей строится общая ER-диаграмма базы данных, она представлена на рисунке 3.5.

Рисунок 3.5 - ER-диаграмма сущностей

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

3.3 Физическая модель базы данных

Физическая модель базы данных будет разрабатываться для СУБД PostgreSQL 9.4

Таблицы в базе данных будут создаваться операторами DDL языка SQL, стандарта SQL-92, поддержка которого осуществляется СУБД.

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

Таблица 3.4 - Соответствие типов логической и физической моделей

Тип атрибута в логической модели	Тип атрибута в физической модели	Описание типа
Целое число (для суррогатных первичных ключей)	serial	Четырехбайтное целое число с автоинкрементом
Целое число	integer	Знаковое четырехбайтовое целое
Дробное число с плавающей точкой	double	Число с плавающей точкой двойной точности (8 байт)
Строка	varchar [ (n)]	Строка с переменной длиной
Дата	date	Календарная дата (год, месяц, день)
Время	time [without time zone]	Время дня (без часового пояса)

После того, как были определены типы данных, создадим таблицы, на основе отношений, описанных в логической модели. Для этого воспользуемся встроенной утилитой СУБД для написания SQL запросов. Создадим таблицу TS:

create table TS (
ts_id	serial	NOT NULL PRIMARY_KEY
,ts_name	varchar (30)	NOT NULL
,ts_comment	varchar (255)
);

Листинг 3.1 - SQL запрос для создания таблицы TS

Выполнив данный запрос, СУБД помимо создания таблицы TS создаст дополнительно четыре вспомогательных объекта:

объект типа "последовательность" ("sequence"). Этот объект содержит в себе автогенерируемую последовательность целых чисел (следует отметить, что объекты данного типа могу содержать данные любых типов). Эта последовательность необходима для того, что реализовать автоинкремент суррогатного первичного ключа таблицы. Такой объект будет создан один, так как таблица содержит только один атрибут типа serial;

объекты типа "ограничение" ("constraint"). Объекты данного типа необходимы для обеспечения целостности данных: они ограничивают ввод каких-либо данных в ячейку таблицы или позволяют определять первичные либо внешние ключи. В данном запросе будет создано три объекта-ограничения, первые два из которых - на атрибут ts_id. Ограничение "NOT NULL" запрещает все значения null в ячейке, ограничение " PRIMARY KEY" определяет столбец как первичный ключ. Последний объект запретит пользователю давать имена станций типа null.

Создав таблицу TS, необходимо создать и другие таблицы. Для этого воспользуемся тем же инструментом и выполним SQL запрос, показанный на листинге 3.2

create table TS_METER (
tsm_id	serial	NOT NULL PRIMARY KEY
,tsm_num	integer	NOT NULL
,ts_id	integer	NOT NULL
,tsm_nearby	integer	NOT NULL
,tsm_name	varchar (10)
,tsm_comment	varchar (255)
FOREIGN KEY (ts_id) REFERENCES TS (ts_id)
FOREIGN KEY (tsm_nearby) REFERENCES TS_METER (tsm_id)
);
create table TS_MENSURATION (
ts_rec_id	serial	NOT NULL PRIMARY KEY
,ts_meter_id	integer	NOT NULL
,ts_date_mensuration	date
,ts_time_mensuration	time without timezone NOT NULL
,ts_voltage	double
,ts_the_current	double
,ts_power	double
,ts_given_energy	double
,ts_accepted_energy	double
FOREIGN KEY (ts_meter_id) REFERENCES TS_METER (tsm_id)
);

Листинг 3.2 - Создание таблиц TS_METER и TS_MENSURATION

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

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

Секционирование (англ. partitioning) - разделение хранимых объектов баз данных (в нашем случае таблиц) на отдельные части с раздельными параметрами физического хранения. Метод секционирования выбран не только для повышения производительности, но и в целях повышения управляемости и доступности для базы данных.

Секционировать таблицу TS_MENSURATION будем горизонтально, то есть по строкам. Секционирование будет производиться по первичному ключу.

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

create table TS_MENS_ARHIVE (
CHECK (rec_id<= (select MAX (rec_id) from TS_MENSURATION) - 172800)
)
INHERITS (TS_MENSURATION);
create table TS_MENS_ARHIVE (
CHECK (rec_id> (select MAX (rec_id) from TS_MENSURATION) - 172800)
)
INHERITS (TS_MENSURATION);

Листинг 3.3 - Запрос на разбиение таблицы на архивную и актуальную части

Актуальная таблица будет содержать измерения счетчиков шести подстанций за одни сутки (20•60•24•6 = 172 800).

Но если чтение из таблицы будет происходить автоматически, например, при запросе записи с rec_id = 182 321 (максимальный порядковый номер записи будет 200 000), то при записи данных потребуется написать функцию. Код функции показан на листинге 3.4

CREATE OR REPLACE FUNCTION FUNC_ACTUAL_REC_WRITER ()
RETURNS TRIGGER AS $$
DECLARE
tab CONSTANT TEXT: = 'TS_MENSURATION';
BEGIN
- ГдеNEW переменная с переданными значениями
- Функция делит rec_id на 172800 и в актуальную таблицу записывает нужный элемент
EXECUTE ('INSERT INTO '||tab||'VALUES ('||NEW. rec_id|| ',' || quote_literal (NEW. name) ||') ');
RETURN NULL; END;
LANGUAGE plpgsql;
Листинг 3.4 - Функция записи данных в актуальную таблицу

Необходимо, после создании функции, написать триггер, который будет запускать функцию FUNC_ACTUAL_REC_WRITER () на выполнение при срабатывании метода INSERT.

CREATE TRIGGER TRIGGER_TO_ACTUAL
BEFORE INSERT ON TS_MENSURATION
FOR EACH ROW EXECUTEPROCEDUREFUNC_ACTUAL_REC_WRITER ();

Листинг 3.5 - Триггер для запуска функции

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

Так же для удобства работы пользователя с базой данных будут созданы представления (View) для таблицы TS_MENSURATION.

Типы таблиц, которыми создавались ранее, назывались - базовыми таблицами. Базовые таблицы - это таблицы, которые содержат данные. Однако имеется другой вид таблиц: - представления. Представления - это таблицы чье содержание выбирается или получается из других таблиц. Они работают в запросах и операторах DML точно также как и основные таблицы, но не содержат никаких собственных данных. Представления - подобны окнам, через которые вы просматриваете информацию (как она есть, или в другой форме, которая задается при создании). Эта информация фактически хранится в базовой таблице. Представление представляет собой запрос, который выполняется всякий раз, когда представление становится темой команды. Вывод запроса при этом в каждый момент становится содержанием представления. Каждое представление будет показывать измерения только для одной подстанции.

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

create view ts1_view
as select msn. *
fromTS_MENSURATION msn
inner join TS_METER mtr
on msn. meter = mtr. tsm_id
where mtr. ts_id = 1;

Листинг 3.6 - Создание представления для таблицы измерений

По аналогии cозданы представления для остальных тяговых подстанций.

3.4 Описание программного комплекса

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

Первая программа под названием "MigrationCsvInDB" (далее Программа 1) полностью автоматизирует процесс миграции данных. От пользователя лишь необходимо указать адрес и логин/пароль от базы данных и местонахождение csv файлов. Программа является многопоточной, что существенно повышает ее скорость работы.

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

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

3.4.1 Алгоритмическое обеспечение программного комплекса

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

Для Программы 1 основным алгоритмом будет служить алгоритм обработки файла и передача информации в базу данных. Так как для каждого файла создается свой собственный поток, который выполняет эти задачи, то создадим логику его работы.

Графическая схема алгоритма приведена на рисунке 3.6.

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

Программа 2 работает на полноценном паттерне MVC, который был реализован на фреймворке SpringMVC. На рисунке 3.3 изображена функциональная диаграмма программы.

Теперь опишем логику работы программы поэтапно. Клиент в браузере переходит по ссылке, которая указывает на наше веб-приложение. Запрос клиента приходит к Dispatcher (главный сервлет). Dispatcher перенаправляет запрос тому контроллеру, к которому он предназначен. Контроллер посылает запрос к слою сервиса, чтобы получить данные, который запрашивает пользователь.

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

Рисунок 3.6 - ГСА алгоритма потока

Рисунок 3.7 - Функциональная схема программы "WebViewer"

Этот процесс во времени показан ниже на рисунке.3.8.

Рисунок 3.8 - UML диаграмма последовательности

3.4.2 Основные требования к программному обеспечению

Программный комплекс состоит из двух программ: "MigrationCsvInDB" и "WebViewer".

Общие требования для данного программного обеспечения таковы:

надежность работы;

расширяемость;

простота в поддержке и сопровождении;

удобство использования, отсутствие специальных навыков у персонала;

платформонезависимость.

Процесс создания данного программного комплекса основан на гибкой методологии Agile и следующих принципах:

принцип модульности. Программа 1 не должна зависить от выбора платформы, СУБД, ORM;

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

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

3.4.3 Описание программы "MigrationCsvInDB"

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

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

невозможен качественный анализ данных стандартными средствами;

низкая скорость доступа к данным;

низкая надежность хранения и переноса данных;

не читаемость данных, требуется импорт файлов в табличные процессоры (например, MSExcel), либо в СУБД (например, MSAccess);

файлы хранятся в иерархической структуре, которая для больших объемом данных неудобна;

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

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

Программа "MigrationCsvInDB" (далее Программа 1) разрабатывалась для осуществления переноса данных о показаниях счетчиков тяговых подстанций из csv файлов в базу данных под управлением СУБД PostgreSQL.

Структура Программы 1 представляет собой урезанный паттерн MVC (подробнее о паттерне в следующем разделе), а именно слой модели и слой контроллера. Промежуточным слоем является слой сервиса, задачей которого отделить слой модели от ORM и снизить ответственность классов модели. Структура представлена ниже на рисунке 3.9.

Преимущество данной структуры состоит в том, что она поддерживает принципы, описанные в пункте 3.3.1.

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

Слой контроллера отвечает за основной функционал Программы 1. Другими словами классы на этом слое несут ответственность за управление процессом миграции.

Теперь рассмотрим структуру программы подробно.

Рисунок 3.9 - Функциональная схема программы "MigrationCsvInDB"

Рисунок 3.10 - Обобщенная диаграмма классов

В иерархии классов (рисунок 3.10) на самом нижнем уровне, слое DAO (dataaccessobject) расположились классы сущностей.

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

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

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

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

Аннотация @Column сообщает ORM фреймворку, что поля являются колонками таблицы, имя которой указано в свойстве name аннотации @Table. Это свойство также присутствует в аннотации @Column и содержит имя атрибута, который это поле олицетворяет.

@Entity @Table (name = "data_ts1") public class DataTS1 extends AbstractDataTS { @Id @Column (name = "rec_id") @SequenceGenerator (name = "data_ts1_seq"

,sequenceName = "data_ts1_seq"

,allocationSize = 1) @GeneratedValue (strategy = GenerationType. SEQUENCE

,generator = "data_ts1_seq") @NotNull private Integer rec_id;

@Column (name = "time_mensuration") @NotNull private Date timeMensuration;

@Column (name = "date_mensuration") @NotNull private Date dateMensuration;

@Column (name = "meter_id") @NotNull private Integer meter_id;

@Column (name = "voltage") private Double voltage;

@Column (name = "the_current") private Double the_current;

@Column (name = "power") private Double power;

@Column (name = "given_energy")

Листинг 3.7 - Модель данных, лист 1

privateDouble given_energy;

@Column (name = "accepted_energy") private Double accepted_energy;

public void setRec_id (Integer rec_id) {

this. rec_id = rec_id; }

publicInteger getRec_id () {return rec_id; }

}

Листинг 3.7, лист 2

Выше классов моделей в иерархии находится слой DAO (DataAccessObject). В программном обеспечении DataAccessObject (DAO) - это объект, который предоставляет абстрактный интерфейс к какому-либо типу базы данных или механизму хранения. Определенные возможности предоставляются независимо от того, какой механизм хранения используется и без необходимости специальным образом соответствовать этому механизму хранения. Традиционно этот шаблон связывают с приложениями на платформе JavaEnterpriseEdition, взаимодействующими с реляционными базами данных через интерфейс JDBC, потому что он появился в рекомендациях от фирмы SunMicrosystems.

Интерфейс DAO реализует класс DataDAOImpl, код которого представлен в листинге ниже:

importnet. eutkin. main. entity. AbstractDataTS;

import org. springframework. orm. hibernate3. support. HibernateDaoSupport;

public class DataDAOImpl extends HibernateDaoSupport implements IDataDAO { @Override public void save (AbstractDataTS obj) { getHibernateTemplate (). save (obj);

} }

Листинг 3.8 - Код класса, реализующего интерфейс DAO

Класс HibernateDaoSupport, который входит в состав фрейморка Spring, отвечает за доступ к базе данных. Этот класс позволяет получить сессию, необходимую, чтобы создавать SQL или HQL запросы программно. В данном классе метод save использует метод getHibernateTemplate () класса HibernateDaoSupport для доступа к шаблонным действиям, например, сохранению объекта (экземпляр модели) в базу данных. Класс HibernateDaoSupport существенно облегчает реализацию паттерна DAO, программное обеспечение становится более простым в поддержке и сопровождении.

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