Разработка систем GPS-мониторинга

В jUnit для задания определенных стартовых условий могут пригодится т.н. фикстуры. Под этим термином следует понимать состояние среды тестирования, которое требуется для успешного выполнения тестового метода. Например, это может быть набор каких-либо объектов или состояние базы данных. Фикстуры помогают многократно использовать программный код за счет правила, которое гарантирует исполнение определенной логики до или после исполнения теста. В предшествующих версиях JUnit это правило неявно подразумевалось вне зависимости от реализации фикстур разработчиком. В версии JUnit 4 фикстуры указываются через аннотации: @Before, @After, @BeforeClass, @AfterClass.

@Before используется для выполнения множества предварительных условий перед выполнением теста. Например, если есть необходимость записать данные в БД или создать пользователя перед выполнением теста. Метод, помеченный @Before будет выполняться перед выполнением каждого теста в классе.

Метод, помеченный @After запускается после выполнения каждого теста. Например, если нужно очищать переменные после выполнения каждого теста, то этой аннотацией можно маркировать метод, имеющий необходимый код. Более того, можно маркировать одновременно несколько методов аннотациями @Before и @After. Однако, следует иметь в виду, что эти методы могут запускаться в различном порядке. Для задания многократных фикстур используются аннотации @Before и @After: его можно зааннотировать с помощью @Ignore.

Также есть такие аннотации, как @BeforeClass, @AfterClass (т.н. однократные фикстуры). Они необходимы, если нужно вызвать фикстуру всего один раз. Еще jUnit предоставляет функцию параметризированного тестирования.

3.4 Контейнер сервлетов Jetty

Jetty -- свободный контейнер сервлетов, написанный полностью на Java. Может использоваться как HTTP-сервер или в паре со специализированным HTTP-сервером (к примеру, с Apache HTTP Server). Первоначально распространялся под лицензией Apache 2.0 License, но после перехода в 2009 году в число приложений, разрабатываемых в рамках проекта Eclipse стал доступен и под Eclipse Public License (EPL).

Jetty начиная с версии 7 поддерживает спецификацию Servlet 2.5 API. Поддержка Servlet API 3.0 добавлена в Jetty 8.

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

В простейшем случае сервер во время старта просматривает директорию $JETTY_HOME/webapps в поисках веб-приложений, которые могут представлять собой:

ѕ Некоторый файл foo.war, коорый будет опублекован в контексте /foo

ѕ Директория foo/ будет опубликована в контексте /foo. Если директория имеет поддиректорию WEB-INF, то она будет считаться динамическим приложением, в противном случае будет обслуживаться только статическое содержание.

Веб-приложения на java обычно упаковываются в архивы строго определённой структуры - Web application archives. Эти архивы содержат:

ѕ Код, выполняемый на сервере - классы java

ѕ Статические файлы (HTML, изображения, звуки и т.д.).

ѕ Код, выполняемый на стороне клиента (например, апплеты).

Архив WAR имеет строго определённую структуру директорий. Директория верхнего уровня считается коневой директорияе веб-приложения. В ней хранятся файлы JSP, классы и архивы апплетов, статические части веб-страниц. Поддиректория WEB-INF в свою очередь содержит:

ѕ файл web.xml - конфигурация данного веб-приложения

ѕ Файлы - дескрипторы библиотек тегов

ѕ директория classes, в которой хранятся основные классы приложения: сервленты и вспомогательные классы, компоненты JavaBeans

ѕ директория lib, в которой хранятся архивы JAR с библиотечными классами.

Допускается создавать отдельный директории для каждого приложения (т.е. фактически пакеты java) или в корневой директории сервера или в директории WEB-INF/classes. Следует обратить внимание, что если добавляются классы java в архив WAR, то архиватор автоматически добавляет их именно в директорию WEB-INF/classes. Это правильно, если есть намерение использовать их на стороне сервера, но не подходит если нужно использовать классы на стороне клиента. Чтобы классы были доступны, например, апплетам, их файлы должны находится в корневой директории веб-документов. Для этого нужно просто переместить файлы классов внутри архива.

Обычно среда разработки уже содержит инструмент для создания таких архивов, но можно создать архив WAR и с помощью архиватора JAR из стандартной поставки JDK:

jar cvf archiveName.war

Чтобы запустить jetty, нужно перейти в директорию, в которую инсталлирован сервер и выполните команду:

java -jar start.jar etc/jetty.xml

После этого можно открыть в браузере веб-страницу демонстрационного приложения:

http://localhost:8080/test

Конфигурация Jetty:

Аргументы команды запуска - пути к файлам конфигурации. Файл etc/jetty.xml - это конфигурция по умолчанию, которая сожержит детальное описание настроек сервера. Можно просто раскомментировать фрагменты, чтобы задать необходимые параметры. Для удобства начальная конфигурация приказывает серверу запускать все приложения из директории webapps.

Остановка сервера jetty:

Можно остановить jetty с помощью клавиш ctrl+c или использовать для старта команду:

java -DSTOP.PORT=8079 -DSTOP.KEY=secret -jar start.jar

А для остановки - команду:

java -DSTOP.PORT=8079 -DSTOP.KEY=secret -jar start.jar --stop

Параметры STOP.PORT и STOP.KEY произвольны.

Embedded-сервер Jetty находится в классе org.eclipse.jetty.server.Server. И конструктор может содержать либо адрес сервера, либо номер порта:

Server jetty = new Server(8082);

Далее нужно добавить в jetty нужные handlerы и запустить его. Запускается и останавливается jetty методами без параметров start() и stop() соответственно. А handler надо написать свой, создав новый класс. Чтобы у был handler для обработки соединений по протоколу WebSocket, нужно его наследовать от org.eclipse.jetty.websocket.WebSocketHandler:

public class ChatWebSocketHandler extends WebSocketHandler {

}

У класса WebSocketHandler есть один абстрактный метод doWebSocketConnect(). Он и вызывается, когда браузер открывает новое соединение с jetty, и возвращает объект WebSocketа.

Класс WebSocket тоже следует определить свой, и наследовать его нужно от интерфейса org.eclipse.jetty.websocket.WebSocket.OnTextMessage -- этот интерфейс работает с данными, проходящими через протокол WebSocket, как с текстовыми данными. Интерфейс org.eclipse.jetty.websocket.WebSocket. OnTextMessage содержит три метода:

ѕ onOpen() - вызывается после открытия сокета;

ѕ onClose() - вызывается перед закрытием сокета;

ѕ onMessage() - вызывается когда приходит сообщение от клиента.

3.5 Библиотека Netty

Фреймворк Netty появился относительно недавно, но с каждым годом он только набирает популярность. В 2011 году проект |был удостоен награды Duke's Choice за инновации в сетевом программировании.

Cегодня его используют в своих разработках такие гиганты, как Apple, Twitter, Facebook, Google и Instagram. На базе Netty построены многие известные проекты с открытым кодом: Infinispan, HornetQ, Vert.x, Apache Cassandra и Elasticsearch.

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

Но сокеты можно настроить таким образом, чтобы сразу узнавать, есть там данные или нет, при чтении и не ждать передачи всех данных при записи. Это так называемые неблокирующие сокеты. Они позволяют одному потоку взаимодействовать с несколькими клиентами. В Java поддержка неблокирующих сокетов появилась только в версии 1.4 в виде Java NIO. Java NIO первоначально расшифровывалось как New 10, но теперь оно уже никакое не новое, поэтому и называется Non-blocking Ю.

Java NIO состоит из трех главных компонентов: каналов, буферов и селекторов.

Каналы похожи на потоки ввода/вывода (stream) с небольшими отличиями. Они обеспечивают двухстороннюю передачу данных, в один канал можно и писать, и читать. Чтение из канала и запись данных происходит асинхронно. Каналы всегда читают данные из буфера и пишут в буфер. Основные реализации каналов: FileChannel, DatagramChannel, SocketChannel, ServerSocketChannel.

Буфер представляет собой блок данных в памяти ограниченного размера и набор методов, облегчающих работу с ним. Буфер можно переключать в режим чтения и в режим записи. Один канал может работать с несколькими буферами, что позволяет не копировать данные на разных уровнях обработки. Если нужно, к примеру, добавить к данным заголовок, достаточно просто создать отдельный буфер для него, не копируя при этом сами данные. Основные классы буферов: ByteBuffer, MappedByteBuffer, CharBuffer, DoubleBuffer и другие.

Селектор -- это компонент, который работает с каналами. В одном селекторе можно зарегистрировать несколько каналов, указав, какие именно события нужно отслеживать. Бывает четыре вида событий: «соединение с сервером установлено», «входящее соединение принято», «можно читать данные», «можно писать данные». Метод select блокирует выполнение кода, пока хотя бы в одном из каналов не произойдет интересующее селектор событие. Есть также и неблокирующий аналог метода select.

В Java 7 появилось расширение NIO под названием NIO2. В нем архитектура взаимодействия с каналами была немного изменена. Теперь стало возможным получать и отправлять данные асинхронно. Больше не нужно постоянно проверять, не появилось ли новое событие канала. Достаточно запустить операцию и зарегистрировать слушателя, который узнает о ее выполнении. Либо можно воспользоваться классом Future. Объект Future моделирует выполняемую операцию. С его помощью можно проверить, выполнена ли операция или заблокировать выполнение потока, пока не будет получен результат.

Таким образом, в Java существует три способа работы с сетевыми клиентами. Netty умеет работать со всеми тремя. Кроме того, Netty успешно борется с некоторыми проблемами NIO и NIO2. Например, NIO может работать немного по-разному на разных платформах, так как NIO реализован на низком уровне. И если какие-то тесты работают в Linux, нет стопроцентной гарантии, что они будут работать в Windows. NIO2 поддерживается только с седьмой версии Java. Так что для пользователей шестой Java придется писать свою версию сервера. Netty же предоставляет единый интерфейс работы с NIO, NIO2 и даже блокирующими сокетами -- просто нужно указать, какой из фреймворков нужен.

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

Еще один недостаток может подстерегать пользователей Linux-систем. Согласно документации, селектор должен ожидать появления события, но из-за ошибки в системе уведомлений epoll может возникать ситуация, когда селектор выходит из блокировки, даже если событий канала нет. В результате он начинает проверять каналы в цикле и нагружает процессор на 100%. Netty справляется с этой и другими проблемами.

Netty также избавляет от сложностей асинхронного кода. Рассмотрим, к примеру, селектор. Метод select может вернуть разнообразные события (можно писать в канал, можно читать, «клиент присоединился»), чтобы разобраться, придется писать if-else конструкцию, поддерживать которую -- дорого по времени и ресурсам. Поэтому в Netty используется паттерн реактор. Каждому событию можно назначить свой обработчик. В Netty этот паттерн получил дальнейшее развитие. Каждому событию можно назначить цепочку обработчиков, выходное значение первого обработчика служит входным значением второго обработчика и так далее. Это облегчает последовательную обработку информации. К примеру, если клиент присылает сжатые зашифрованные данные, то первый обработчик разархивирует данные, второй расшифровывает, а третий уже непосредственно их обрабатывает. Если потребуется еще какая-то дополнительная обработка данных, то достаточно просто вставить новый обработчик в эту цепочку.

Приложение Netty начинается с классов Bootstrap и ServerBootstrap Bootstrap занимается инициализацией и конфигурацией инфраструктуры клиента, ServerBootstrap инициализирует сервер.

За обработку данных отвечают экземпляры ChannelHandler. Обработчики переводят объекты в бинарные данные и наоборот, а также предоставляют метод обработки ошибок, которые возникают в процессе. Таким образом, вся бизнес-логика происходит в обработчике. Обработчики разделяются на два типа: ChannellnboundHandler и ChannelOutboundHandler. Первый тип для работы с входящими данными, второй -- с исходящими.

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

Все операции ввода-вывода для канала выполняются в цикле событий EventLoop. Несколько циклов событий объединяются в группу EventLoopGroup. Bootstrap клиента создает один экземпляр EventLoopGroup. ServerBootstrap для сервера создает два экземпляра EventLoopGroup. Один экземпляр только принимает соединения от клиентов, второй обрабатывает остальные события: чтение/запись данных и так далее. Это помогает избежать тайм-аута при подключении к серверу новых клиентов.

Когда канал регистрируется, он привязывается к определенному циклу событий на все время своего существования. Цикл событий всегда выполняется в одном и том же потоке, поэтому не нужно заботиться о синхронизации операций ввода-вывода канала. Поскольку обычно один EventLoop работает с несколькими каналами, важно не выполнять никаких блокирующих операций в ChannelHandler. Но если это все же требуется, то Netty предоставляет возможность указать EventExecutorGroup при регистрации канала, EventExecutor которого будет выполнять все методы ChannelHandler в отдельном потоке, не нагружая EventLoop канала.

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

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

Netty позволяет передавать данные через TCP или UDP, поддерживает множество протоколов, таких как HTTP, FTP, SMTP, WebSockets, SSL/TLC, SPDY.

3.6 Проектирование и реализация решения

Предварительное проектирование структуры решения показано ниже на рис. 3.2. В процессе поиска подходящей архитектуры было принятое следующее решение: необходимую бизнес логику следует разделить на соответстствующие пакеты, реализующую определенный фукнционал. К примеру, классы для работы с GPS и геолокацией определить в отдельный пакет geolocation, классы для работы с БД - в database. Соответственно и прочие класса и интерфейсы будут разделены на пакеты.

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

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



Рис 3.2 - Диаграмма проекта

На рис.3.2 показаны классы и пакеты приложения без отображения между ними. Для наглядности отношения отображены на рис 3.3, но чтение диаграммы невозможно без увеличения, просмотр возможен на компьютере.

Рис. 3.3 - Диаграмма пакета c отношениями между классами

Пакет model содержит классы, реализующие работу с клиентом, обработку координат, работу с аккаунтами, и т.д.

Рис. 3.4 - Диаграмма пакета model



Пакет geolocation содержит классы, обрабатывающие информацию о местоположении объекта непосредственно от клиента.

Рис. 3.5 - Диаграмма пакета geolocation

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

Рис. 3.6 - Диаграмма пакета geocoder



Пакет api определяет интерфейс взаимодействия клиента с сервером.

Рис. 3.7 - Диаграмма пакета api

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

Рис. 3.8 - Диаграмма пакета reports

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

Следует отметить также и следующее. Как было сказано, разработка подчиняется некоторым стандартам Java, один из которых - Java Code Conventions. Стандарт определяет правила написания кода: отступы, количество строк в методах, переносы, а также правила именования методов, классов, полей. Подразумевается, что именование должно однозначно говорить, каккую логику реализует метод, для чего нужно поле, что представляет из себя класс. По этой причине отсутствует явная необходимость пояснять каждый метод и класс в отдельности, т.к. из названий становится понятно, какой класс за что отвечает, какими свойствами и поведением обладает: достаточно только привести диаграмму с имеющимися полями и методами.

Для обеспечения гарантии, что код будет написан в соответствии с конвенциями, был применен специальный плагин для системы сборки Maven: maven-checkstyle-plugin.

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

Из наиболее часто используемых и простых проверок:

ѕ Наличие комментариев

ѕ Размер класса не более N строк

ѕ В конструкции в try-catch, блок catch не пустой.

Подключить плагин довольно просто:

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-checkstyle-plugin</artifactId>

<version>2.7</version>

</plugin>

После этого можно запустить проверку кода: mvn checkstyle: check

Плагин проверит исходный код на наличие нарушений и сгенерирует файл checkstyle-result.xml. Чекстайл удобно использовать совместно с непрерывной интеграцией. Автоматическая проверка кода сильно экономит время. Самое важное - относиться к checkstyle ошибкам также, как и ошибкам компиляции - при их возникновении сразу исправлять, т.к. когда ошибок накапливается сотни, их исправление обходится еще дороже. Если checkstyle ошибки исправляются, как только они появятся- весь код будет чисто написан и комментирован, и можно быть больше уверенным в его качестве.

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

Внутри jar плагина есть примеры конфигурационных файлов:

ѕ config/sun_checks.xml - от Sun Microsystems. Используются по умолчанию.

ѕ config/maven_checks.xml - от Maven.

ѕ config/turbine_checks.xml -от Turbine.

ѕ config/avalon_checks.xml - от Avalon.

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

Итак, в результате указанные выше пакеты и классы были реализованы в соответствии с теми требованиями которые были предъявлены. Нецелесообразно приводить все классы и методы в них, рассмотрим с небольшими пояснениями лишь некоторые.

Отметим, что для ознакомления с полным перечнем классов, пакетов и методов был сгенерирован Javadoc по всему проекту.

Ниже на рис.3.9 - 3.20 приведены UML-диаграммы классов с реализованными методами.

Класс Config реализует логику по настройке сервера из прилагаемого файла конфигурации.



Рис 3.9 - Диаграмма класса Config.

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

Рис 3.10 - Диаграмма класса Protocol



Класс контекст также служит настройкой сервера, его назначение было описано выше при обзоре контейнера сервлетов Jetty. Методы реализованы в соответствии с проектом.

Рис 3.11 - Диаграмма класса Context

Класс TrackerServer частично реализует логику сервера, содержит методы для его настройки (порты, адрес), методы запуска и остановки и др.



Рис 3.12 - Диаграмма класса TrackerServer

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

Рис 3.13 - Диаграмма классов для шифрования



Рис 3.14 - Диаграмма классов дешифрования сообщений

Класс FilterHandler создан для фильтрации поступающих сообщений.

Рис 3.15 - Диаграмма класса FilterHandler



Класс Adress создан для хранения адреса объекта в пакете geocoder

Рис 3.16 - Диаграмма класса

Класс ReportUtils содержится в пакете reports и служит вспомогательным классом для генерации отчетов.

Рис 3.17 - Диаграмма класса



Класс Position служит представлением позиции объекта на карте.

Рис 3.18 - Диаграмма класса Position

На этом рассмотрение классов и пакетов, описание разработки и инструментов завершено.

В результате разработки был получен рабочий прототип системы GPS/ГЛОНАСС мониторинга объектов. Система построена в виде веб-приложения с трехзвенной архитектурой, имеет веб-интерфейс и была протестирована с помощью Unit-тестов. Скриншот интерфейса запущенного веб-приложения приведен на рис 3.19,20.



Рис 3.19 - Скриншот главного окна приложения

Рис 3.20 - Скриншот окна добавления устройства



Заключение

В рамках бакалаврской работы было разработано приложение на Java, представляющее собой систему GPS-мониторинга. Приложение удовлетяворяет поставленным требованиям и реализует заданный функционал - осуществляет мониторинг объектов с помощью клиентского приложения с использованием навигационных систем GPS и ГЛОНАСС.

Были выполнены описанные требования:

ѕ Спроектировать архитектуру приложения;

ѕ Выбрать инструменты и методы реализации на языке Java;

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

ѕ Приложение не должно обладать другими избыточными функциями;

ѕ Приложение должно быть легко масштабируемо и дополняемо;

ѕ Код должен быть снабжен документацией и комментариями;

ѕ Архитектура приложения должна быть понятной, логичной и обоснованной;

ѕ Приложение должно быть кроссплатформенным;

ѕ Реализовать веб-интерфейс приложения

ѕ Реализовать приложение в формате трехзвенной архитектуры

ѕ Работу клиента и сервера производить через специальный протокол

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

ѕ Хранение объектов в БД

ѕ Загрузка объектов из БД при запуске приложения

ѕ Графический интерфейс на Swing

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

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

Написанное приложение соответствует поставленным требованиям, выполнено в соответствии со стандартами разработки на языке Java, с соблюдением правил написания кода и стандартов именования объектов.

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

В текущем варианте решения полученные результаты являются удовлетворительными, приложение может использоваться по своему назначению при решнии задач GPS/ГЛОНАСС мониторинга, трекинга объектов.

программный автоматизированный информация библиотека



Список использованных источников

1. Эккель, Б. Философия Java. Библиотека программиста [Текст]/Б. Эккель - 4-е изд. - СПб.: Питер, 2009. - 640 с.

2. Шилдт, Г. Java. Полное руководство [Текст]/Г. Шилдт - 8-е изд.: пер. с англ. - М.: ООО «И.Д. Вильямс», 2012. - 1104 с.

3. Спецификация языка Java [Электронный ресурс]/2017

4. Спецификация виртуальной машины Java [Электронный ресурс]/2017

5. Спецификация java.util.Concurrency [Электронный ресурс]/2017

6. Многопоточность в среде Java [Электронный ресурс]/2017.

7 Вирт, Н. Алгоритмы и структуры данных. Пер. с англ. [Текст]/ Н.Вирт. - СПб: Невский Диалект, 2008 г. - 352 с.

8 Лафоре, Р. Объектно-ориентированное программирование в С++. Пер. с англ. [Текст]/ Р. Лафоре - СПб: Питер, 2004. - 920 с.

9 Шахгельдян, К.И. Объектно-ориентированное программирование. [Текст]/ К.И. Шахгельдян: Влад., ВГУЭС, 2000 - 320с.

10 Балд, Т. Объектно-ориентированное программирование в действии. [Текст]/. Т.Бадд: Питер. 1997 - 430 с.

11 Буч, Г. Объектно-ориентированный анализ и проектирование. Addison-Wesley [Текст]/ Г. Буч. 1998.

12 Заварыкин, В.М. Основы информатики и вычислительной техники. [Текст] /В.М Заварыкин Житомирский В.Г., Лапчик М.П. -- М.: Просвещение, 2010 - 310 с.

13 Тассел, Д. Стиль, разработка, эффективность, отладка и испытание программ[Текст] / Д. Ван Тассел -- М.: Мир, 2011 - 530с.

14 Бондарев, В.М., Основы программирования. [Текст] / В.М Бондарев., В.И. Рублинецкий, Е. Г. Качко --Харьков: Фолио, Ростов н/Д: Феникс, 2007 - 710 с.

15 Элиенс, А. Принципы объектно-ориентированной разработки программ [Текст] / А. Элиенс. - 2-е издание. --М.: Издательский дом «Вильямс», 2002, 550 с.

16 Волкова, И. А. Системы программирования [Текст] / И. А. Волкова, И. Г. Головин, Л. Е. Карпов. -- М.: Издательский отдел факультета ВМиК МГУ, 2009, 260 с.

17 Канер, Дж. Тестирование программного обеспечения. [Текст] / Дж. Канер -- М.: «DiaSoft», 2001, 370 с.

18 Одинцов, И. О. Профессиональное программирование. Системный подход. [Текст] / И. О. Одинцов -- СПб.: БХВПетербург, 2002, 610 с.

19 Миков, А. И. Информатика. Введение в компьютерные науки. [Текст] / А. И. Милков -- Пермь: Изд-во ПГУ, 2008, 320 с.

20. API переводчика [Электронный ресурс]/2017

Размещено на Allbest.ru

...