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

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

В основе проекта заложено применение сети независимых устройств с рабочим названием «DalaZond» (Dala (тюрк.нареч.) – «поле»). Они представляют собой набор разнородных датчиков для оперативного сбора информации о текущих характеристиках почвы (кислотности, влажности, температуры), состояния воздуха (температуры, влажности, наличия дождя). Само устройство предполагается управлять контроллером Arduino и передавать полученные от датчиков характеристики в центр сбора и анализа данных. Все данные будут собираться в единый (возможен вариант локального или частного) сервер центра мониторинга, где будет проводиться автоматический анализ экологического состояния территории.

Данный проект характеризуется следующими проблемами:

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

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

Рис.1. Обобщенная схема проекта «DalaZond»

Так же данный проект может быть локализован в качестве «Умной фермы», с возможностью использования данного зонда как элемента управления эко-системой, а именно:

• Автоматическая система полива
• Автоматическая система затенения (для некоторых культур боящихся прямого солнечного света, например лимон)
• Автоматическая система проветривания (особо важно в парниках и закрытых садах)
• Автоматическая система увлажнения воздуха
• Автоматическая система поддержки температуры (как почвы так и воздуха)
• Автоматическая система управления освещением (при наличии светодиодных ламп или систем рефлекторов солнечного излучения)
• Автоматическая система оповещения

Рис 2. Схема организации сети

Область применения данных зондов:  Фермерские хозяйства, парки, лесопосадки и парники.

В перспективе проект поможет оптимизировать мониторинг удаленных территорий и/или подконтрольных фермерских хозяйств на предмет достаточно комфортных для выращивания различных культур условий.

Стандарт OpenGL (Open Graphics Library – открытая графическая библиотека) был создан и утвержден в 1992 году ведущими фирмами в области разработки программного обеспечения как эффективный аппаратно-независимый интерфейс, пригодный для реализации на различных платформах. Основой стандарта стала библиотека IRIS GL, изначально разработанная фирмой Silicon Graphics Inc (SGI). Развитие стандарта OpenGL осуществляется специальной бюрократической структурой, известной как Architectural Review Board (ARB) – Комитет по пересмотру архитектуры. Комитет состоит из представителей основных компаний, заинтересованных в развитии и использовании библиотеки. В их числе 3D Labs, SGI, Apple, NVIDIA, ATI, Intel, id Software и, конечно, Microsoft. Кстати, Microsoft поставляет реализацию OpenGL вместе со своими операционными системами. Она соответствует одной из ранних версий OpenGL и не использует возможности аппаратного ускорения. Этот недостаток восполняют драйверы видеокарт, которые предоставляют быстрые реализации OpenGL. C начала 90-х годов прошлого века OpenGL используется в различных областях индустрии и науки. Архитектура библиотеки получилась настолько удачной, что уже на протяжении более десяти лет она остается стабильной и предсказуемой. OpenGL де-факто является стандартом в области программирования графики. Но в этом скрыт и ее недостаток. ARB работает довольно медленно – любое изменение стандарта требует множества согласований, документов и так далее. В силу этого OpenGL развивается очень вяло. Правда, до последнего времени с этим не было проблем, поскольку изначально библиотека предназначалась для быстрых рабочих станций профессионального уровня, которые обновляют не так уж часто. Однако сейчас даже дешевые видеокарты за $100 превзошли уровень профессиональных монстров пятилетней давности стоимостью в тысячи долларов. И при этом обновление их возможностей происходит в среднем раз в год. Фактически OpenGL не поспевает за индустрией, поэтому игровые разработчики вынуждены использовать так называемый механизм расширений (extensions), чтобы получить доступ к новейшим функциям видеокарт. На данный момент OpenGL прошла путь от версии 1.0 до версии 1.4 (и это за десять лет!). Версия 2.0, обещающая революционные изменения, находится в процессе стандартизации.

DirectX к моменту выхода Windows 95 большинство игр по-прежнему делалось под MS-DOS. Windows в те времена не предоставляла возможностей для программирования игр. Многочисленные уровни абстракции (введенные в целях совместимости и универсальности) делали доступ к звуковому и видеооборудованию весьма медленным и неприменимым для игровых приложений. Поэтому было решено разработать библиотеку, предоставляющую возможность прямого доступа к аппаратуре. Это позволило бы играм работать на приемлемой скорости (и увеличило бы продажи Windows 95). Вместо создания собственного API Microsoft использовала разработку небольшой компании RenderMorphic. Первой более или менее жизнеспособной версией была DirectX 3.0. Позже последовали версии 5, 6 и 7 (четвертой не было). Седьмая версия была воспринята разработчиками с интересом: она хорошо работала, ее интерфейсы были достаточно удобны в использовании. Восьмая версия не заставила себя ждать и принесла интересные нововведения – вершинные и пиксельные шейдеры (специальные, обычно короткие программы, предназначенные для выполнения на графическом процессоре; используются для расчета освещения, создания тех или иных спецэффектов и так далее). Недавно вышедший DirectX 9 также развивает эти перспективные направления. Длительное время DirectX рассматривался как неудачная альтернатива OpenGL. Однако последние улучшения в API сделали эту библиотеку весьма мощной и стабильной. Поскольку она разрабатывается авторами ОС, можно быть уверенным, что скорость ее работы с графикой оптимальна. Многие считают, что именно DirectX, а не OpenGL, становится стандартом для программирования графики. Microsoft постоянно работает в тесном контакте с разработчиками “железа”, обеспечивая поддержку новых возможностей аппаратуры. Более того, DirectX иногда предлагает различные возможности раньше, чем на рынке появляются видеокарты с их аппаратной реализацией. Мы рассматриваем только графическую часть DirectX, но кроме графики DirectX также предлагает интерфейсы для работы со звуком, источникам ввода, мультимедиа и так далее. У OpenGL таких функций нет – это чисто графическая библиотека. Ядро OpenGL контролирует процесс обработки примитивов (то есть треугольников). Для передачи данных используется процедурная модель, фактически – вызовы функций. В каждый момент времени состояние OpenGL определяется через набор переменных, задающих параметры обработки (например, накладывать текстуру или не накладывать). Каждый новый переданный треугольник проходит обработку в соответствии с текущим состоянием. Такой механизм весьма эффективен, а код обычно короток и прост. Хотя ядро OpenGL процедурное, в использовании OpenGL совместно с объектно-ориентированными технологиями сложностей обычно не возникает: все зависит от выбора программиста. Структура DirectX очень сильно отличается от OpenGL. DirectX основан на модели COM (Component Object Model).

DirectX обычно не является идеалом легко читаемого и понимаемого. Поэтому даже рисование простого треугольника требует огромного объема кода. Разработчики Microsoft, конечно, понимают это, поэтому для упрощения программирования ими создана отдельная библиотека DirectX Common Files, которая скрывает часто используемый код. Производительность Вопрос производительности настолько же важен, насколько запутан и неясен. Дебаты на тему “Что быстрее – OpenGL или DirectX?” не утихают. При этом, как ни парадоксально, cкорость обоих библиотек одинакова. Иначе и быть не может, потому что сейчас большинство функций реализованы напрямую через аппаратные ускорители. Естественно, производительность может различаться в зависимости от степени оптимизации программного кода и используемой для тестирования аппаратной платформы.. Это не очень-то хорошо как для производителя, так и для пользователя (возрастает стоимость разработки игр, появляются ошибки и т.п.), но таковы реалии современного рынка видеоигр. Пример: считается, что драйверы от фирмы ATI для серии видеокарт ATI Radeon хорошо оптимизированы под DirectX и значительно слабее поддерживают OpenGL. Однако специально написанные тесты не выявили значительной разницы в скорости работы программ. Сравнение в чем же, если не в производительности, различие между библиотеками? Прежде всего – в удобстве интерфейса, функциях, гибкости, перспективах развития и области применения. Начнем с функций. Неоднократно приходилось слышать заявления типа: “DirectX 9 поддерживает пиксельные шейдеры, а OpenGL не поддерживает, поэтому все игры должны быть написаны под DirectX!” При этом ARB остается весьма неповоротливым, и надеяться на оперативное включение новых опций не позволяет. Для решения этой проблемы в OpenGL существует механизм расширений, с помощью которого можно использовать различные функции, не входящие в базовую спецификацию, а поддерживаемые только реализацией OpenGL для конкретной видеокарты. Этот процесс выглядит следующим образом: как только производитель выпускает видеокарту с поддержкой определенной полезной функции, он включает ее в свою реализацию OpenGL (которая обычно входит в поставку драйвера). Для программиста эта возможность становится доступной, если он специальным образом запросит данное расширение. OpenGL идеален для визуализации результатов научных исследований. Изменения в OpenGL предлагаются, обсуждаются и утверждаются представителями различных компаний. Что касается DirectX, то здесь ситуация прямо противоположная. Только Microsoft может вносить какие-либо изменения в библиотеку. Иначе говоря, именно Microsoft в конечном итоге определяет все пути развития библиотеки, и если путь был выбран неверно, это может быть исправлено только в новой версии. Итак, достоинства библиотек становятся наиболее очевидны при их использовании в разных (но в то же время пересекающихся) прикладных областях. DirectX идеален для профессиональной разработки игр и мультимедийных приложений на платформе Windows. OpenGL используется на высокопроизводительных рабочих станциях, в научной сфере, в образовании, а также в любых проектах, где требуется переносимость приложений на различные программные или аппаратные платформы. И в дальнейшем развитие DirectX наверняка будет связано с постепенным улучшением гибкости и удобства использования.

С технической точки зрения желательно создавать приложения для конкретных популярных мобильных платформ, таких как: Windows, iOS, Android. Очень важно при разработке соблюдать гайд-лайны (guidelines (англ.) – стили) каждой операционной системы (ОС), иначе приложение может не пройти модернизацию в магазине приложений.

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

LinearLayout — тип верстки при котором область верстки делится на строки и в каждую строку помещается один элемент. Внутри верстки возможно комбинировать вертикальную и горизонтальную разбивки, а кроме того, возможна комбинация нескольких разных типов верстки например использование LinearLayout внутри FrameLayout.

ListView  – ListView берет содержимое для отображения через адаптер. Адаптер расширяется классом BaseAdapter и отвечает за модель данных для списка и за расположение этих данных в его элементах. Отображение большого количества данных на мобильном устройстве должно быть реализовано максимально эффективно. Поэтому ListView создает виды (виджеты) по необходимости и подкрепляет их к иерархии видов. Стандартный Адаптер ListView удаляет виды, например, если элемент больше не отображается, он будет стерт и только его содержимое поменяется. Если вы используете свой адаптер, то вы должны так же предусмотреть это, чтобы избежать проблем с производительностью.

Адаптер обычно создаётся при помощи конструкции new ArrayAdapter(Context context, int textViewResourceId, String[] objects).

• context - текущий контекст
• textViewResourceId - идентификатор ресурса с разметкой для каждой строки. Можно использовать системную разметку с идентификатором android.R.layout.simple_list_item_1 или создать собственную разметку
• objects - массив строк

Метод setAdapter(ListAdapter) связывает подготовленный список с адаптером. Переходим к java-коду. Сначала мы получаем экземпляр элемента ListView в методе onCreate(). Далее мы определяем массив типа String. И, наконец, используем адаптер данных, чтобы сопоставить данные с шаблоном разметки. Выбор адаптера зависит от типа используемых данных. В нашем случае мы использовали класс ArrayAdapter

Кнопка(Button) – один из самых распространенных элементов управления в программировании. Наследуется от TextView и является базовым классом для класса СompoundButton. От класса CompoundButton в свою очередь наследуются такие элементы какCheckBox, ToggleButton и RadioButton

ImageView – Компонент ImageView предназначен для отображения изображений. Находится в разделе Widgets.  Для загрузки изображения в XML-файле используется атрибут android:src. ImageView является базовым элементом-контейнером для использования графики. Можно загружать изображения из разных источников, например, из ресурсов программы, контент-провайдеров.

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

В результате использования этих простых компонентов разработки программного обеспечения  было создано приложение BusStop.

После того, как программа загрузилась пользователь видит список остановок как показано на рисунке 1.  Список состоит из названий остановок, ориентиров, и их пиктограмм.

Рисунок 1. Список остановок

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

Рисунок 2. Список автобусов

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

 Рисунок 3. Подробности о маршруте автобуса

В самой нижней части экрана пользователь может видеть траекторию маршрута, то есть карту как показана рисунке 4.

Рисунок 4. Карта маршрута 

Карта помещена в программу как картинка и благодаря этому программное обеспечение «BUSSTOP» работает не подключаясь в интернет (offline). Карта удобна тем, что пользователь может видеть на ней название зданий которые расположены вдоль маршрута по которому проезжает автобус.

Разработанное программное обеспечение полностью соответствует поставленной цели – реализации приложения справочной системы автобусного транспорта для мобильной платформы Android. Разработанное приложение позволяет пользоваться общественным транспортом города Ургенча более комфортно.

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

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

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

Рис.1. Business Use Case диаграмма процесса требующего автоматизации

На рисунке 1 серым цветом выделены действия, которые можно полностью автоматизировать программно, * – помечены действия которые можно автоматизировать лишь частично.

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

Рис. 2. Схема реляционной модели данных текущего дипломного проекта

Реализация  ПО

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

Рис. 3. Общий вид ПО

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

Рис. 4. Добавление позиций в список комплектующих

Для внесения изменения в текущих результатах запроса, например, при выборе устанавливаемой или продаваемой части автомобиля, его комплектующих или зап. частей, на основной рабочей зоне в категории результата доступны кнопки меню «Снять позицию» (Рис. 5) или «Добавить позицию» (Рис. 4). Это позволяет пользователю списывать со склада проданную или установленную зап. часть автомобиля или его комплектующую с указанием количества единиц подлежащих списанию. А так же позволяет добавить необходимый элемент или количество в текущий список в «Активную карту» потенциального покупателя.

Рис. 5. Подтверждение действия меню «Снять позицию»

Рис. 6. Меню «Активная карта»

Данное меню (Рис. 6) позволяет пользователю использовать и просматривать свою «корзинку покупок» для мониторинга требуемых сумм оплаты, количества заказываемых зап. частей и комплектующих, в так же ошибочных «закупок». Меню «Активная карта» организовано в форме таблицы с 2 основными типами активных кнопок: 1) отмена операции 2) подтверждение операции и закрытие текущего счета.

Все ранее выполненные операции сохраняются в базе данных и могут быть перепроверены с указанием точной даты выполнения сделки в меню «История сделок» (Рис. 7). Так же в этом же меню есть возможность сформировать в формате PDF и/или отправить на печать отчет о произведенных сделках (Рис. 8).

Рис. 7. Меню «История сделок»

Рис. 8. Формирование отчетов по сделкам

При необходимости формирования сводного отчета по всем операциям, пополнениям базы данных склада, фильтрацией по требуемым позициям и датам, существует гибкий настраиваемый «Генератор отчетов» (Рис. 9). Отчет формируется в формате .XLS.

Рис. 9. Формирование отчетов по условию

Добавление товаров на склад вручную можно осуществить в меню «Добавить товар». Данный пункт содержит основные поля и категории для занесения нового товара в базу данных склада. Поля отмеченные * – символом являются критичными для занесения в базу, и должны обязательно быть заполненными.

Рис. 10. Форма добавления товара

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

Рис. 11. Оповещение – Товар не найден или на складе его нет

Приведем пример: по текущему запросу требуемые комплектующие или зап. части не были обнаружены или же их количество на складе равняется нулю. В таком случае появляется сообщение «Обратитесь к поставщикам» (Рис.11).

Рис. 12. Оповещение отправки официального письма с заказом поставщику

В таком случае используя инструменты панели поиска в левой части ПО пользователь может указать наименование требуемого комплектующего, его количество, и выбрав одно или нескольких, внесенных заранее, поставщиков отправить им официальный запрос на поставку (Рис. 12). Эта функция доступна при подключении к сети Интернет. В противном случае сообщение не будет отправлено (Рис. 13).

Рис. 13. Подтверждение отправки официального письма с заказом поставщику

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

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