Диплом Малышев v9(Последняя инстанция) (1230560), страница 4

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

Текст из файла (страница 4)

В качестве СУБД будет использоваться SQLite, как стандартно используемая СУБД в ОС Android.

2.2.1.4 Визуализация данных

Для визуализации данных используются графики:

1. График зависимости значения крутящего момента от времени;

2. График зависимости глубины погружения сваи от времени;

3. График положения сваи;

4. График зависимости скорости вращения сваи от времени;

5. График зависимости значения крутящего момента от скорости вращения сваи.

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

2.2.1.5 Предупреждение пользователя об опасностях

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

2.2.1.6 Передача данных на web — сервер

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

Данные передаются через сеть Интернет, используя безопасное HTTPS соединение. На стороне мобильного приложения формируется JSON-пакет, включающий в себя всю информацию из базы данных приложения. Этот пакет отправляется на URL-адрес сервера, предварительно указанный в настройках приложения. Таким образом, при необходимости ПО может работать с различными серверами, при условии, что последние оборудованы соответствующим API. После отправки пакета на стороне сервера проходит верификация пользователя, отправившего данные, и если пользователь имеет соответствующие права, данные принимаются и обрабатываются.

2.3 Проектирование системы

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

Перечень необходимых модулей:

1. Модуль приёма данных датчиков (GetData);

2. Модуль первичной обработки принимаемых данных (PrepareData);

3. Модуль вторичной обработки принимаемых данных(MathData);

4. Модуль работы с базой данных (DBHelper);

5. Модуль визуализации данных (Visual);

6. Модуль оповещений пользователя (Notice);

7. Модуль отправки данных на сервер (SendServer);

8. Модуль приема данных с сервера (ReceiveServer);

9. Модуль интерфейса пользователя (Interface);

10. Вспомогательный модуль работы с JSON (JSONHelper).

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

А) Пользователь активирует процесс сбора данных с датчиков и отображения получаемых данных на экране (рисунок 2.1);

Б) Пользователь инициирует процесс сбора данных о проектах и сваях от сервера (рисунок 2.2);

В) Пользователь отправляет данные на сервер.

2.4 Проектирование классов

В данном разделе описана архитектура классов приложения.

2.4.1 Модуль Interface

2.4.1.1 Иерархия классов

Каждый класс модуля наследуется от класса Activity, представляющего собой базовое описание работы одного экрана приложения (рисунок 2.4).

2.4.1.2 Диаграмма классов модуля в порядке связи (переходов пользователя)

На рисунке 2.5 показаны интерфейсные классы в том порядке, в котором с ними может взаимодействовать пользователь. Например, открыть окно информации о свае пользователь может, только последовательно используя классы MainActivity, DetailProjectActivity, и, наконец, DetailPileActivity.

2.4.2 Модуль DBHelper

2.4.2.1 Модели данных, реализованных в приложении

На рисунке 2.6 представлены классы моделей данных для проектов, свай и типов свай. Модель Project (проект) имеет связь с моделью Pile (свая) типа один-ко-многим. Такую же связь с моделью Pile имеет модель TypePile (тип сваи).

2.4.2.2 Вспомогательные классы для выполнения CRUD-операций

CRUD — аббревиатура от create, read, update, delete (создание, чтение, обновление, удаление). Этот термин означает базовый набор операций, используемый для работы с базами данных [15]. На рисунке 2.7 представлены классы, реализующие CRUD для всех используемых моделей.

2.4.3 Модуль GetData

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

DrillingData — буферный класс, хранящий полученные данные в виде сериализуемого объекта.

DrillingBroadcastReceiver — класс для пересылки полученных данных о значении крутящего момента на модуль Interface.

На рисунке 2.8 показаны все вышеперечисленные классы, а также реализованные в них методы.

2.4.4 Модуль PrepareData

Модуль состоит из одного класса PreparingDrillingData, представленного на рисунке 2.9.

2.4.5 Модуль MathData

Модуль состоит из одного класса MathDrillingData, структура которого показана на рисунке 2.10.

2.4.6 Модуль Visual

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

2.4.7 Модуль Notice

Модуль уведомлений пользователя. Для каждого интерфейсного класса реализован свой класс уведомления. Их структура показана на рисунке 2.12.

2.4.8 Модуль SendServer

Данный модуль состоит из одного класса SendServer, методы которого представлены на рисунке 2.13.

2.4.9 Модуль ReceiveServer

Данный модуль состоит из одного класса ReceiveServer, методы которого представлены на рисунке 2.14.

2.4.10 Модуль JSONHelper

Данный модуль состоит из одного класса JSONHelper. Реализует методы преобразования получаемых и отправляемых данных в формат JSON. Его структура показана на рисунке 2.15.

2.5 Реализация

2.5.1 Этапы реализации проекта

1. Реализация первичного варианта интерфейса, а именно интерфейса классов MainActivity, ProjectActivity, PileActivity, SettingsActivity, ServerActivity;

2. Реализация серверной части комплекса: написание моделей, проектирование панели администрирование, подключение СУБД Postgresql 9.1, реализация интерфейса редактирования проекта и свайного поля проекта;

3. Реализация получения данных от сервера, класса JSONHelper;

4. Реализация работы с базой данных. Подключение ORM-системы, написание моделей и классов для выполнения CRUD-запросов к БД;

5. Реализация получения данных от датчиков. Подключение датчиков в WiFi модулю, организация передачи данных на WiFi модуль, реализация приема данных по беспроводному каналу и первичная обработка данных;

6. Реализация класса DrillingActivity;

7. Реализация модуля Visual, а именно графика положения сваи, а также графиков значения крутящего момента;

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

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

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

Рассмотрим подробнее некоторые этапы, и приведем примеры возникавших задач и пути их решения.

2.5.2 Реализация первичного варианта интерфейса

В процессе реализации классов, ответственных за реализацию интерфейса пользователя, возникла задача передачи данных между взаимодействующими объектами этих классов. Рассмотрим на примере: пользователь в данный момент находится на экране подробной информации о свае, т. е. PileActivity. Следующим его шагом будет запуск экрана бурения, т. е. DrillingActivity. Т.к. для сбора данных и записи их в базу данных необходимо знать, бурение какой именно сваи будет производиться, то нужно удостовериться, что DrillingActivity запущена именно для выбранной сваи. Нужно также помнить, что в Android-приложениях активности, т. е. объекты — наследники класса Activity (такие как DrillingActivity) по умолчанию независимы, и не связаны между собой. Таким образом, нужно решить задачу связываемости активностей, и передачи между ними некоторых минимально необходимых для функционирования приложения данных.

Решением данной задачи выступил механизм намерений (Intent-ов), заложенный в Android SDK. Этот механизм создан именно для трансляции сообщений, причем не только в рамках одного приложения, но по всей операционной системе, установленной на данном устройстве. Любое приложение способно зарегистрировать широковещательный приёмник и отслеживать эти намерения с возможностью на них реагировать. Это позволяет создавать приложения, использующие событийную модель, в основе которой лежат внутренние, системные или сторонние события, передаваемые внешними программами.

Характеристики

Список файлов ВКР