Главная Коллекция "Otherreferats" Программирование, компьютеры и кибернетика Разработка программных продуктов

Разработка программных продуктов

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 13.02.2016
Размер файла 809,6 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

Размещено на http://www.allbest.ru/

Содержание

  • Аннотация

Введение

1. Обзорно-аналитическая часть

  • 1.1 Обзор российского рынка плат сбора данных
    • 1.1.1 Введение
      • 1.1.2 ООО «L-Card»

1.1.3 ЗАО «Руднев-Шиляев»

1.1.4 ЗАО «Электронные технологии и метрологические системы»

1.1.5 НПГ R-Technology

1.1.6 Итоги

1.1.7 Вывод

  • 1.2 Обзор кроссплатформенных инструментариев разработчика для создания приложении? с графическим интерфеи?сом
    • 1.2.1 Введение
      • 1.2.2 Qt
      • 1.2.3 GTK+
      • 1.2.4 wxWidgets

1.2.5 Выводы

  • 1.3 Исследование архитектурных подходов к созданию инструментария разработчика
  • 2. Технологическая часть
    • 2.1 Выбор инструментов разработки
      • 2.1.1 Обоснование выбора языка разработки

2.1.2 Системы управления версиями

  • 2.1.2.1 Централизованные системы управления версиями

2.1.2.2 Распределенные системы управления версиями

  • 2.1.2.3 Subversion

2.1.2.4 Git

2.1.2.5 Mercurial

2.1.2.6 Сравнение Subversion, Git и Mercurial

2.1.2.7 Вывод

  • 2.1.3 Системы автоматической генерации документации
    • 2.2 Разработка программнои? архитектуры инструментария разработчика
      • 2.2.1 Введение

2.2.2 Модули разрабатываемого инструментария

  • 2.2.2.1 RSHSignalSaver

2.2.2.2 DPA

2.2.2.3 DM

2.2.2.4 DC

2.2.2.5 RSHPCI

2.2.2.6 RSHUSB

  • 2.2.2.7 RshDeviceBase
    • 2.2.3 Паттерны проектирования
      • 2.2.3.1 Паттерн «Фасад»

2.2.3.2 Паттерн «Абстрактная Фабрика»

  • 2.3 Проектирование программных интерфейсов (API) инструментария
    • 2.3.1 Введение
      • 2.3.2Требования и общие рекомендации к API

2.3.3 Типы данных и структуры

  • 2.3.3.1 Типы возвращаемых значений
    • 2.3.3.2 Базовый тип RshBaseType
      • 2.3.4 Внутреннее API
        • 2.3.4.1 Интерфейс IFactory
        • 2.3.4.2 Программный интерфейс IRSHDeviceBase
        • 2.3.4.3 Программный интерфейс IRSHUSB
        • 2.3.4.4 Программный интерфейс IRSHPCI
      • 2.3.5 Внешнее API
        • 2.3.5.1 Интерфейс IRSHDevice
        • 2.3.5.2 Программный интерфейс IDM
        • 2.3.5.3 Программный интефейс IDC
        • 2.3.5.4 Программный интерфейс IDPA
        • 2.3.5.5 Программный интерфейс IRSHSignalSaver
      • 2.3.6 Выводы
  • 3. Разработка
    • 3.1 Разработка платформонезависимого ядра и программных интерфейсов инструментария разработчика
      • 3.1.1 Введение

3.1.2 Разработка платформонезависимых модулей инструментария

  • 3.1.2.1 Модуль RshDllClient
    • 3.1.2.2 Модули DC и DM
      • 3.1.2.2 Модуль DPA
        • 3.1.2.3 Модуль RSHSignalSaver
        • 3.1.2.4 Библиотеки драйверов высокого уровня для устройств и интерфейс IRSHDevice
        • 3.1.2.5 Модуль RSHUSB
        • 3.1.2.6 RSHPCI
      • 3.1.3 Выводы
    • 3.2 Разработка USB-драйвера под ОС Linux
      • 3.2.1 Основные понятия USB
        • 3.2.1.1 Дескриптор устройства

3.2.1.2 Дескриптор конфигурации

3.2.1.3 Дескриптор интерфейса

3.2.1.4 Конечные точки

  • 3.2.1.5 Блоки запроса USB
    • 3.2.2 Разработка драйвера USB
      • 3.2.2.1 Инициализация устройства

3.2.2.2 Обмен данными с устройством

  • 3.2.3 Наименование файлов устройств

3.2.4 Заключение

  • 4. Экспериментальная часть
    • 4.1. Разработка методики испытания

4.2 Разработка тестового стенда

4.3 Проведение натурного эксперимента

  • 5. Охрана труда
    • 5.1 Выявление опасных и вредных факторов при эксплуатации ЭВМ и их влияния на пользователей
      • 5.1.1 Опасные и вредные факторы при работе с ВДТ и ПЭВМ
        • 5.1.1.1 Повышенные статические и динамические нагрузки

5.1.1.2 Повышенные нервно-психические нагрузки

5.1.1.3 Воздействие ВДТ на органы зрения

5.1.1.4 Воздействие электрического тока

5.1.1.5 Влияние статического электричества

5.1.1.6 Влияние электромагнитного излучения низких частот

  • 5.2 Методы и средства защиты пользователей от воздействия на них опасных и вредных факторов при эксплуатации ЭВМ
    • 5.2.1 Основные требования к видеодисплейным терминалам
      • 5.2.1.1 Цветовые параметры ВДТ

5.2.1.2 Основные требования к конструкции ВДТ

  • 5.2.2 Организация рабочего места пользователя ВДТ и ПЭВМ

5.2.3 Режим работы операторов ВДТ и ПЭВМ

5.2.4 Помещение для работы с ВДТ и ПЭВМ

5.2.5 Защитные меры электробезопасности

  • 5.2.5.1 Защитное заземление и зануление

5.2.5.3 Двойная изоляция

5.2.5.4 Разделяющие трансформаторы

5.2.5.5 Блокировки и быстроотключающие устройства

  • 5.2.6 Требование к освещению для работы с ВДТ и ПЭВМ
    • 5.2.6.1 Естественное освещение

5.2.6.2 Внутренне искусственное освещение

5.2.6.3 Особенности устройства освещения в помещениях для работы с ВДТ и ПЭВМ

  • 5.3 Выводы
  • Заключение
    • Итоги

Выводы

  • Список литературы

Введение

Актуальность. Разработка программных продуктов в рамках одного предприятия зачастую сводится к решению типовых задач. Для экономии времени на разработку целесообразно применить методологию повторного использования кода и реализовать часто требующийся функционал в виде программного инструментария. В таких сферах как разработка компьютерных игр или веб-сайтов существует множество готовых сторонних решений. Но сама специфика производимой предприятием ЗАО «Руднев-Шиляев» продукции (платы сбора данных) требует разработки индивидуального программного инструментария, учитывающего специфику конкретной аппаратной продукции.

Требование кросс-платформенности было мотивировано увеличением доли ОС Linux в Росcии среди потенциальных клиентов предприятия. Но, пожалуй, самым важным аргументов для включения этого пункта в список требований послужило сотрудничество между ЗАО «Руднев-Шиляев» и Военно-промышленным комплексом, в структурах которого используется МСВС - операционная система на базе Linux.

Анализ кроссплатформенных инструментариев для построения пользовательского интерфейса, поддерживающих в том числе мобильные платформы iOS и Android позволит оценить перспективы добавления кроссплатформенности в клиентское программное обеспечение. Наличие такого программного обеспечения даст возможность ЗАО “Руднев-Шиляев” занять пустующую в настоящее время на российском рынке нишу плат сбора данных для мобильных устройств (планшетных компьютеров и смартфонов) и создать аналоги таких западных продуктов как OsciPrime (http://www.osciprime.com/) и iMSO-104 (http://www.oscium.com/products/mixed-signal-oscilloscope-imso-104).

Целью даннои? работы является разработка кроссплатформенного программного инструментария и адаптации под него пользовательского приложения осциллографа-спектроанализатора.

Задачи, которые были решены в этои? работе:

· Анализ современных технологий и подходов используемых при разработке ПО.

· Анализ типовых сценариев использования (use-case'ов) продукции и выявление на основе полученной информации требований к разрабатываемому ПО.

· Проектирование и разработка программного инструментария, адаптация под него программы осциллографа-спектроанализатора.

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

· Тестирование и внедрение разработанного ПО на предприятии.

Практическая значимость даннои? работы подтверждена успешным внедрением разработанного программного инструментария в работу организации ЗАО «Руднев-Шиляев».

Апробация работы

Программный инструментарий успешно протестирован и функционирует на предприятии ЗАО «Руднев-Шиляев».

1. Обзорно-аналитическая часть

1.1 Обзор российского рынка плат сбора данных

1.1.1 Введение

Современные технологии позволяют получить как мобильную и компактную, так и стационарную систему измерения из готовых, серийно выпускаемых компонентов в кратчайшие сроки. Основой любой системы компьютерных измерений является АЦП. Как микросхема, АЦП мало пригоден для быстрого построения системы, поэтому рассмотрим его как составную часть устройств сбора данных. Кроме АЦП на большинстве плат имеются цифровые входы и выходы, опционально -- пара каналов ЦАП. Каждый производитель в комплект поставки включает программное обеспечение, как минимум с функцией осциллографирования. Помимо штатного ПО фирм, существует стороннее - самые известные это ACTest и PowerGraph, поддерживающие ОС Windows.

В данном обзоре анализируются крайние точки спектра выпускаемой на российском рынке продукции плат сбора данных с интерфейсами PCI и USB: высокоточные низкочастотные и высокочастотные. Будут рассмотрены 14 плат от 4-х отечественных производителей. Платы могут быть выполнены как специальное устройство, с цифровыми входами и выходами и опционально ЦАП, так и в виде модуля только с аналоговыми входными каналами для масштабируемой системы.

1.1.2 ООО «L-Card»

Сайт: http://www.lcard.ru/

Фирма предлагает два варианта подходящих под заданные требования USB-плат: E20-10 (14 бит, 10 МГц на 4 канала) и LTR114 (24 бита, 4 кГц суммарно для всех опрашиваемых каналов). Наличие у E20-10 цифрового сигнального процессора и возможность загрузки прикладных программ позволяют реализовать различные функциональные алгоритмы и специализированные режимы работы модуля. Есть опция установки двухканального ЦАП на плату. Недостатком LTR114 является отсутствие цифровых портов входа/выхода, большие габариты и необходимость внешнего питания. Из плат с PCI-интерфейсом были рассмотрены два продукта: L-780M (14 бит, 400 кГц, 32 канала) и L-783M (12 бит, 3 МГц, 32 канала). Главное преимущество L-Card -- масштабируемые модульные системы.

Продукция фирмы поддерживается собственным штатным бесплатным ПО LGraph2, а также сторонними ACTest и PowerGraph. Есть ПО для разработчика и драйвера под Linux.

1.1.3 ЗАО «Руднев-Шиляев»

Сайт: http://www.rudshel.ru/

У данной фирмы были рассмотрены следующие продукты: высокоточная плата с разрядностью АЦП 24 бита и частотой 800 Гц и не имеющая близких аналогов среди продукции других рассматриваемых фирм плата «Сириус» с частотой 5 ГГц. Это касается плат с интерфейсом USB. Рассмотренные две PCI-платы имеют такие характеристики: Леонардо-II с частотой 104,4 кГц и 24 разрядами точности и ЛАн10-12PCI-у, двухканальная с 12-разрядным АЦП и 100 МГц на канал.

Продукция поддерживается собственным штатным бесплатным ПО ADCLab с функуциями самописца, осциллографа-спектроанализатора, программы для просмотра собранных данных и конвертации их в форматы .txt и .cvs, а также совместима со сторонними ACTest и PowerGraph. Софт поддерживает только ОС Windows. Фирма предоставляет возможность модификации своего оборудования или создания на его основе измерительных комплексов по техническим заданиям заказчиков.

1.1.4 ЗАО «Электронные технологии и метрологические системы»

Сайт: http://www.zetms.ru/

Фирма предлагает в рассматриваемом диапазоне 24-битную плату ZET 220 с суммарной частотой преобразования 8 кГц на 16 каналов и двухканальный осциллограф ZET 302 с 50-мегагерцовым 8-разрядным АЦП. PCI-платы имеют неоправданно высокую стоимость для своих характеристик, даже несмотря на то, что в них встроен генератор сигнала: 24-битная 2-канальная плата с частотой дискретизации 1 кГц и одноканальная с частотой 10 МГц и разрядностью 14 бит. Цена аналогичного комплекта (АЦП-ЦАП) с такими же характеристиками у других рассматриваемых фирм в среднем в два раза меньше.

В качестве программного обеспечения используется только своё бесплатное и набор дополнительного платного программного обеспечения также собственной разработки. Все ПО поддерживает только ОС Windows. Фирма предлагает широкий набор ПО по трем направлениям: ZETView -- среда графического программирования (наподобие LabVIEW) для построения сложных измерительных систем, ZETLab Studio -- SDK для работы с продукцией фирмы и ZETLab -- набор виртуальных приборов и средств для работы с ними.

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

Из особенностей стоит выделить набор любопытных опций: передача данных по Bluetooth, Ethernet и Wi-Fi или запись их на карту памяти SD в автономном режиме, что существенно расширяет круг решаемых задач.

1.1.5 НПГ R-Technology

Сайт: http://www.r-technology.ru/

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

Поддержка ПО: В комплект поставки продукции фирмы входит программный пакет QMLab с функциями самописца, осциллографа, спекроанализатора и математической обработки собранных данных. Программа поддерживает только семейство ОС Windows. Ее большим минусом является неудобный графический интерфейс, отсутствие встроенной справки или хотя бы всплывающих подсказок к элементам управления. На сайте фирмы выложен пакет SDK под ОС Windows и примеры программирования. Продукция фирмы поддерживается сторонними пакетами ПО: PowerGraph и ACTest.

Из интересующей нас продукции фирмой представлены два устройства: USB3000 -- высокочастотный 8-канальный 14-битный АЦП, с частотой 3 МГц на канал и самая высокочувствительная плата из выпускаемых этой фирмой -- QMBox15-16 со следующими характеристиками: 500 кГц, 32 канала, 16 разрядов.

1.1.6 Итоги

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

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

Таблица 1

Сравнение плат сбора данных представленных на российском рынке

Продукты

Частота

Разрядность

Цена, руб.

L-Card

LTR114 (USB)

4 кГц

24

18696

E20-10 (USB)

10 МГц

14

16892

L-780M (PCI)

400 кГц

14

11152

L-783M (PCI)

3 МГц

12

14104

ЗАО «Руднев-Шиляев»

ЛА-И24USB

800 Гц

24

14000

Сириус (USB)

5 ГГц

8

150000

Леонардо-II (PCI)

102,4 кГц

24

34800

ЛАн10-12PCI-у

100 МГц

12

42000

ЗАО «Электронные технологии и метрологические системы»

ZET 220 (USB)

8 кГц

24

27890

ZET 302 (USB)

50 МГц

8

12000

АЦП ЦАП 24/4 (PCI)

1 кГц

24

60960

АЦП ЦАП 14/2 (PCI)

10 МГц

14

72960

R-Technology

QMBox15-16 (USB)

500 кГц

16

19730

USB3000

3 МГц

14

18780

1.1.7 Вывод

Из проведенного обзора был сделан вывод, что ЗАО «Руднев-Шиляев» производит конкурентноспособную аппаратную продукцию. Для дальнейшего развития фирмы целесообразным является обеспечение своей продукции хорошей программной поддержкой в виде пользовательских приложений и SDK, предоставляющих отсутствующие у конкурентов возможности: поддержка Linux и мобильных платформ.

1.2 Обзор кроссплатформенных инструментариев разработчика для создания приложении? с графическим интерфеи?сом

1.2.1 Введение

В данной работе требуется провести анализ кроссплатформенных программных инструментариев для создания пользовательских приложений с графическим интерфейсом и выбрать из них наиболее подходящий для портирования на него клиентского программного обеспечения ЗАО «Руднев-Шиляев». Для данных задач используется такой класс сторонних продуктов как фреймворки и библиотеки виджетов.

В рамках данной работы были сформулированы следующие требования к фреймворку:

· Кросс-платформенность;

· Написан на C/C++;

· Поддержка мобильных платформ (iOS, Android);

· Наличие встроенной или сторонней библиотеки для отрисовки графиков;

· Элементы интерфейса должны выглядеть нативными (native) для каждой из поддерживаемых операционных систем;

· Лицензия распространения, совместимая с проприетарной лицензией;

· Совместимость снизу вверх (forward-compatibility);

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

Разработка графического пользовательского интерфейса для приложения является очень трудной задачей, поскольку в большинстве случаев только front-end часть видна конечному пользователю. Не важно насколько продуманный, «красивый» и оптимизированный код используется в back-end части приложения -- если оно не будет выглядеть удобным и привлекательным для клиента, ничто не заставит его им пользоваться. Это является проблемой многих хороших с программной точки зрения продуктов свободного программного обеспечения, не получивших широкой популярности из-за того, что разработчики не уделили достаточного внимания созданию удобного, продуманного интерфейса. Особенно остро стоит проблема создания графического интерфейса пользователя для кроссплатформенного приложения. Графическое окружение каждой ОС имеет свой набор правил по созданию интерфейсов: Windows User Experience Interaction Guideline, KDE User Interface Guideline, Gnome HID. Каждое из этих руководств содержит рекомендации по построению пользовательских интерфейсов для конкретного окружения. Кроссплатформенные фреймворки для построения ГИП решают эту проблему разными способами. Самым очевидным из них является отрисовка элементов интерфейса через обращение к соответствующим функциям API конкретной ОС. Минусом такого подхода является то, что некоторые элементы интерфейса, присутствующие на одной платформе, могут не иметь аналогов на другой или вести себя по-разному. Другим вариантом является реализация элементов интерфейса, которые отрисовываются с помощью графических примитивов функциями самого фреймворка, а не ОС (примером подобного решения является интерфейс программы Adobe Photoshop -- он имеет одинаковый интерфейс на всех ОС и одновременно не выглядит нативным ни для одной из них).

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

Рассмотрим подробнее наиболее распространенные современные лицензии программных продуктов:

GPL (General Public License) - обязывает публиковать весь код проекта под GPL (из-за чего эта лицензия получила неофициальное название «вирусной» лицензии). Тем не менеее использование ПО под данной лицензией в проектах с закрытым исходным кодом возможно, если связь между открытыми и закрытыми компонентами программы происходит не путём загрузки в адресное пространство, а, например, через запуск GPL-программы как отдельного процесса и общения с ней через пайпы. Также эта лицензия запрещает поставлять программу в одном пакете (установщике) вместе с проприетарным ПО.

LGPL (Lesser GPL) - является менее строгой модификацией GPL-лицензии. Позволяет не раскрывать исходные коды модулей, написанных без использования LGPL-кода, и требует динамического связывания (dynamic linking) с LGPL - библиотеками.

Требование совместимости снизу вверх (forward-compatibility) является важным при нынешнем стремительном развитии технологий. Многие технологии очень быстро устаревают и заменяются новыми. Особенно это следует учитывать при проектировании мульти-платформенного приложения, одной из целевых платформ которого является ОС Linux. Эта платформа активно развивается в последнее время, ее дистрибутивы обновляются по модели роллинг-релизов (rolling-release).

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

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

После анализа различных ресурсов для разработчиков программного обеспечения, были выявлены следующие наиболее популярные и часто упоминаемые кросс-платформенные фреймфорки для создания пользовательских приложений: Qt, GTK+, wxWidgets. Ниже приведен детальный обзор всех их по каждому из пунктов списка выявленных требований.

1.2.2 Qt

Последние версии этого фреймворка используют нативное графическое API каждой поддерживаемой платформы для отрисовки элементов пользовательского интерфейса [1].

В комплект поставки Qt входит WYSIWYG-редактор -- Qt Creator для генерации кода пользовательского интерфейса приложения на языках С++ и QML. QML является декларативным языком программирования, по синтаксису схожим с JavaScript, на котором, начиная с версии Qt 4.7, описываются все элементы а также простая логика пользовательской (front-end) части приложения. Более того, функционал элементов, описанных на QML, может быть расширен путем подключения файлов на JavaScript. Виджеты загружаются из .qml-файла при запуске приложения. В Qt реализована поддержка графического сервера Wayland. Фреймворк поддерживает мобильные платформы Android и iOS. Существует сторонняя библиотека Qwt (http://qwt.sourceforge.net/) для отрисовки графиков и добавляющая дополнительные элементы управления (контролы).

Qt значительно расширяет базовый функционал C++ за счет введения концепции слотов и сигналов для обработки пользовательских событий.

В качестве преимуществ Qt стоит также упомянуть наличие подробной документации, примеров программирования и обучающих статей на официальном сайте, а исходные коды фреймворка снабжены подробными комментариями. На официальном сайте проекта есть активный форум для разработчиков. Проект поддерживается большим количеством как коммерческих, так и некоммерческих организаций -- Trolltech, Nokia, Digia, KDE, Qt Project.

Конечному пользователю Qt поставляется в виде открытых исходных кодов, под лицензий LGPL.

1.2.3 GTK+

В первую очередь надо отметить, что изначально GTK+ разрабатывался не как универсальный графический фреймворк, а как инструментарий исключительно для графического редактора GIMP и был написан на языке Си для Unix-систем, а мульти-платформенность и официальная привязка к C++ -- gtkmm, были добавлены позже. В нем отсутствуют платформонезависимые реализации функций, обычно требуемых при создании пользовательского приложения -- многопоточность, работа с динамическими библиотеками, работа с файловой системой. Но, несмотря на такие изначальные дефекты дизайна и очевидные недостатки в плане функционала, он удовлетворяет выдвинутым выше требованиям и подходит для решения задачи создания приложения с ГИП.

Для отрисовки всех виджетов в GTK+ используется сторонняя кросс-платформенная графическая библиотека cairo, поддерживающая аппаратное ускорение. Пользовательский интерфейс приложения может быть описан как на C++, так и на языке XML в отдельном файле, из которого виджеты будут загружены при запуске программы по мере необходимости. Существует официальный графический редактор Glade для конструирования пользовательских интерфейсов. Минусом использования языка разметки XML является его избыточность и сложность восприятия человеком (по сравнению с существующими альтернативами XML).

Единственным разработчиком проекта является некомерческая организация GNOME Foundation. Отсутствует поддержка мобильных платформ. Графический сервер Wayland поддерживается. Отрисовываемые им виджеты не выглядят нативными для поддерживаемых платформ. Есть множество библиотек для отрисовки графиков и диаграмм.

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

1.2.4 wxWidgets

Является полноценным кроссплатформенным фреймворком на языке C/C++, а не только лишь инструментарием для построения ГИП. Кроссплатформенная реализация множества функций, таких как: потоки и многопоточность, работа с файлами и т. д.

Фреймворк использует нативные элементы графического интерфейса. Разработчиками было заявлено о работе над внедрением поддержки мобильных платформ -- iOS в 2011, а в 2012 -- Android, однако к 2013 году поддержка обеих платформ по-прежнему отсутствует. Также нет какой-либо информации о работе по внедрению поддержки графического сервера Wayland. Для данного фреймворка отсутствует возможность вынести описание элементов интерфейса в отдельный файл, тем самым увеличивая количество кода, не связанного непосредственно с логикой разрабатываемого приложения.

Разработка осуществляется командой энтузиастов, насчитывающей 20 человек (http://wxwidgets.org/about/whowhat.htm). На сайте проектов присутствует подробная документация по всем компонентам фремворка, есть примеры программирования.

WxWidgets является бесплатным программным обеспечением с открытым исходным кодом, распространяемым под модифицированным лицензионным соглашением LGPL - wxWindows License, позволяющим разработчикам ПО не раскрывать исходные коды своего приложения.

1.2.5 Выводы

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

Таблица 2

Сравнение графических фреймворков

Кросс-платформенность

Язык C/C++

Библиотека отрисовки графиков

“Нативные” виджеты

Лицензия

Совместимость снизу вверх

Qt

Да - полная, поддержка iOS и Android

Да

Да

Да

Да

Да

GTK+

Частичная - поддерка только Linux и Windows

Да

Да

Нет

Да

Да

wxWidgets

Частичная - поддержка только Linux и Windows

Да

Да

Да

Да

Не

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

1.3 Исследование архитектурных подходов к созданию инструментария разработчика

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

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

· Model Driven Architecture - в основе этого подхода лежит идея о полном разделении этапов общего проектирования (моделирования) и последующей реализации приложения на конкретной программной платформе. Сначала при помощи специальных средств проектирования создается общая и независимая от способов реализации модель приложения, а затем осуществляется реализация программы на каком-либо языке программирования . При этом процесс разработки полностью основан на модели, которая должна содержать всю необходимую для программирования информацию.

· Event Driven Architecture - это архитектурный подход, основанный на понятиях события и его обработке. Система, построенная по EDA, представляет собой совокупность слабосвязанных компонентов, обменивающихся сообщениями. Действие в системе выполняется как реакция на такое сообщение. Отправитель сообщения может не знать о том, какой компонент системы будет его обрабатывать.

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

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

Для проектирования инструментария разработчика в соответствии с выявленными требованиями модульной структуры с высокой связанностью модулей, наиболее рациональным является выбор Model Driven Architecture.

2. Технологическая часть

2.1 Выбор инструментов разработки

2.1.1 Обоснование выбора языка разработки

При разработке кроссплатформенного программного продукта, когда встает вопрос о выборе языка программирования, обычно рассматривают такие наиболее популярные языки как Java и C/C++. В Java кросс-платформенность заложена в самом дизайне языка. Этот язык обладает большим количеством как встроенных в него (AWT, Swing), так и сторонних (SWT) библиотек для создания графического интерфейса. К тому же Java является основным языком для разработки приложений под мобильную платформу Android. А в рамках данной работы совместимость с Android является одним из требований к разрабатываемому ПО. Но несмотря на все вышеуказанные плюсы Java, согласно данным, опубликованным Google, в тестах производительности Java проигрывает по времени исполнения программного кода в 6 раз по сравнению с C/C++ [10]. Время исполнения программного кода является наиболее приоритетным показателем при выборе языка разработки прикладного ПО [20]. Учитывая это, а также то, что в команде разработчиков подавляющее большинство имели значительно больший опыт разработки ПО на C/C++ чем на Java, выбор был сделан в пользу C/C++.

2.1.2 Системы управления версиями

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

Специально для командной работы над проектом были разработаны системы управления версиями - класс ПО для работы с изменяющейся информацией. Существует две принципиально разные модели систем управления версиями: централизованная и распределенная.

2.1.2.1 Централизованные системы управления версиями

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

Рисунок 1. - Устройство централизованных систем управления версиями

2.1.2.2 Распределенные системы управления версиями

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

Рисунок 2. - Устройство распределенных систем управления версиями.

На данныи? момент самыми популярными системами контроля версий являются Subversion, Git и Mercurial. Далее будут рассмотрены ключевые возможности этих систем, достоинства, недостатки и примеры команд для взаимодеи?ствия с ними.

2.1.2.3 Subversion

Subversion (SVN) -- свободная централизованная система управления версиями, выпущенная компаниеи? CollabNet Inc. в 2004 году.

В настоящее время Subversion довольно популярна среди разработчиков открытого программного обеспечения. Вот лишь некоторые известные проекты, разработчики которых используют данную систему: Apache, GCC, Python, Ruby, FreeBSD, Boost. Subversion также широко используется в закрытых проектах и корпоративнои? сфере.

Возможности:

· Копирование объектов с разветвлением истории -- при копировании в хранилище появляются два отдельных объекта с общеи? историеи?.

· Поддержка ветвления:

· Создания ветвеи? (копированием директории?) и работы с ними.

· Слияние ветвеи? (переносом изменении?).

· История изменении? и копии объектов (в том числе ветви и метки) хранятся в виде связанных разностных копии? -- не требующих больших временных и дисковых ресурсов при создании и хранении.

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

· Фиксации изменении? в хранилище (в том числе многообъектные) организуются в виде атомарных транзакции?.

· Сетевои? обмен между сервером и клиентом предусматривает передачу только различии? между рабочеи? копиеи? и хранилищем.

· Обеспечивается одинаково эффективная работа как с текстовыми, так и с двоичными фаи?лами.

· Различные варианты доступа к хранилищу, в том числе:

· Непосредственныи? доступ на локальнои? фаи?ловои? системе.

· По собственному сетевому протоколу.

· Через веб-сервер по протоколу WebDAV/DeltaV.

· Два возможных внутренних формата хранилища: база данных или набор обычных фаи?лов.

Примеры команд:

1. Checkout - создание локальнои? копии хранилища.

2. Update - обновление состояния локальнои? копии хранилища до последнеи? зафиксированнои? в удаленном хранилище ревизии.

3. Add - добавление нового ресурса в хранилище.

4. Commit - фиксирование изменении? локальнои? копии в хранилище, то есть создание новои? ревизии.

2.1.2.4 Git

Git - распределе?нная система управления версиями фаи?лов. Проект был создан Линусом Торвальдсом для управления разработкои? ядра Linux, первая версия выпущена 7 апреля 2005 года. Проекты, использующие систему: ядро Linux, Drupal, Cairo, GNU Core Utilities, Wine, Chromium, Compiz Fusion, jQuery, PHP.

Возможности:

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

· Поддержка множества протоколов. А именно HTTP, FTP, rsync или же собственныи? протокол.

· Эффективен при работе над большими проектами. Проект может становиться больше и тяжелее, но Git будет все? так же быстр, в отличии от других систем.

· Наде?жная история изменении?. В Git невозможно вносить изменения в старые версии фаи?лов, без создания нового состояния.

· Git спроектирован как набор программ, специально разработанных с уче?том их использования в скриптах.

· Гибкии? функционал для объединения предлагает пользователю системы несколько способов автоматического объединения конфликтных фаи?лов.

· Очистка от мусора. В процессе работы с системои? в неи? может накапливаться мусор - некорректные версии фаи?лов, которые появились в результате откатов на предыдущие версии. Git может отследить и удалить подобныи? мусор.

Примеры команд:

· Clone - создание локальнои? копии хранилища.

· Pull - обновление состояния локальнои? копии хранилища до последнеи? зафиксированнои? в удаленном хранилище ревизии.

· Add - добавление нового ресурса в хранилище.

· Commit - фиксирование изменении?, проделанных с локальнои? копиеи?.

· Push - отправка изменении? из локальнои? копии хранилища в удаленное хранилище.

2.1.2.5 Mercurial

Mercurial -- распределенная система контроля версий, выпущенная в 2005 году. Основной функционал реализован на языке Python, а требующие высокой производительности части (например, своя реализация diff) написаны на Си. Проекты использующие эту систему: Vim, Xen, OpenSolaris, NetBeans, OpenJDK, OpenOffice.org.

Возможности:

· Простота освоения. У Git больше команд и опций. Документация Mercurial выглядит более законченной и простой.

· Полностью кроссплатформенная, лучше и полнее поддержка Windows.

· Большое количество графических клиентов, интегрирующихся в графическую оболочку системы.

· В отличии от Git не требуется операция по техническому обслуживанию репозитория (Git требует частых ручных переупаковок своих метаданных, иначе падает производительность и увеличивается занимаемое репозиторием дисковое пространство).

Примеры команд:

1. Clone -- создание копии репозитория.

2. Add -- добавляет существующий файл в следующий коммит.

3. Commit -- фиксирование набора изменений.

4. Push -- получение измененией из удаленного репозитория.

5. Pull -- отправка изменений в удаленный репозиторий.

2.1.2.6 Сравнение Subversion, Git и Mercurial

Преимущества Subversion:

· Это централизованная система контроля версии?, что позволяет иметь небольшую рабочую копию.

· Совместима c Windows, не имеет проблем с кириллицеи? (у GIT проблемы с кириллицеи? под Windows).

· Позволяет держать в рабочеи? копии часть репозитория.

· Subversion имеет удобную нумерацию ревизии?.

Преимущества Git:

· Это распределенная система контроля версии?. В случае сбоя можно взять локальныи? репозитории? без потери истории изменении? (При этом локальная копия меньше по размеру, в сравнении с Mercurial).

· Быстрее, чем Subversion. При сравнении разница была очень заметна (до 20 раз быстрее).

· Позволяет делать локальные коммиты без доступа к центральному серверу.

Преимущества Mercurial:

· Распределенная система контроля версий.

· Поддержка Windows (В отличии от Git который имеет для Windows только MinGW-порт).

· Большее количество графических клиентов.

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

2.1.2.7 Вывод

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

2.1.3 Системы автоматической генерации документации

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

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

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

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

· Поддержка синтаксиса языка C/C++

· Кроссплатформенность (система работает на всех платформах на которых ведется разработка: Linux, Windows)

· Бесплатность

Всем этим требованиям отвечает Doxygen - одна из старейших (разрабатывается с 1997 года, изначально была частью проекта Qt) бесплатных кроссплатформенных систем документирования исходных кодов с консольным интерфейсом. Имеет встроенную поддержку генерации документации в форматах HTML, CHM, PDF, man. Для документации в виде html-файла, размещаемого на веб-серверах, существует удобный способ организации поиска с помощью автоматически сгенерированнного Doxygen'ом PHP-модуля. Есть возможность добавлять математические выражения любой сложности, используя синтаксис языка разметки LaTeX. Doxygen применяется в таких известных проектами как KDE, Mozilla, Drupal.

2.2 Разработка программнои? архитектуры инструментария разработчика

2.2.1 Введение

Была поставлена задача спроектировать и разработать программный инструментарий для работы с платами сбора данных с интерфейсами PCI и USB. Перед проектированием программного инструментария был проведен анализ типовых use-case'ов для продукции ЗАО «Руднев-Шиляев». Диаграмма сценариев использования приведена на рисунке 3.

Рисунок 3. - Диаграмма сценариев использования

На основании этого анализа были выявлены следующие функции, которые должны быть реализованы в разрабатываемом программном инструментарии:

· Непрерывный сбор данных с плат

· Покадровый режим сбора данных

· Запись собранных данных в файл, снабженный требуемой пользователю мета-информацией

· Применение следующих математических алгоритмов как к собираемым данным в режиме реального времени, так и к уже собранным данным:

· поиск разрывов в сигнале

· поиск фронта сигнала

· расчет среднеквадратичного отклонения

· быстрое преобразование Фурье.

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

2.2.2 Модули разрабатываемого инструментария

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

2.2.2.1 RSHSignalSaver

Программный модуль для работы с данными, полученными при аналогово-цифровом преобразовании. Также позволяет осуществлять работу с метаданными -- любой требуемой пользователю информацией о записанных в файле данных, предоставляя функции для их записи в файл, чтения из файла и внесения в них изменений. Модуль поддерживает файловый формат HDF5 (подробнее см. пункт 3.1.2.3.), с которым могут работать многие популярные математические пакеты. Этот формат данных не ограничивает пользователя применением только клиентского ПО ЗАО «Руднев-Шиляев».

2.2.2.2 DPA

Data Processing Algorithms -- модуль для математической обработки данных в реальном времени или уже собранных данных. В этом модуле реализованы следующие математические алгоритмы:

· Нахождение переднего и заднего фронта в сигнале;

· Поиск разрывов в сигнале;

· Быстрое преобразование Фурье;

· Расчет основной погрешности и коэффициента согласия ряда измеренных значений. Об этом подробнее см. [6];

2.2.2.3 DM

Device Manager -- модуль, управляющий всеми находящимися в системе устройствами ЗАО. Производит подключение к устройствам по VID и PID, а также по их названиям, загружая соответствующую динамическую библиотеку, создавая экземпляр класса и предоставляя указатель на интерфейс IRSHDevice.

2.2.2.4 DC

Device Controller -- реализует упрощенный высокоуровневый интерфейс для сбора, обработки и сохранения данных. Скрывает от пользователя детали работы с классами DPA, RSHSignalSaver и интерфейсом устройства IRSHDevice.

2.2.2.5 RSHPCI

Все платы производства ЗАО «Руднев-Шиляев» с интерфейсом PCI выполнены на базе чипов PLX9050/PLX9054, для которых от производителя есть официальные драйвера под Windows и Linux, а также кроссплатформенное API с низкоуровневыми функциями для работы с драйвером. RSHPCI представляет собой класс-обертку над функциями этого API.

2.2.2.6 RSHUSB

Класс для низкоуровневой работы со всеми платами с интерфейсом USB. Содержит функции записи, чтения и контроля ввода-вывода (ioctl) для отправки команд и получения данных от платы, реализацию кольцевого буфера для непрерывного сбора данных и потоки сбора данных для двух режимов: непрерывного и покадрового. Работа с файлом устройства осуществляется через кроссплатформенные функции-обертки над функциями Windows API и системными вызовами Linux.

2.2.2.7 RshDeviceBase

Базовый класс для всех устройств. Содержит функции загрузки низкоуровневых библиотек в зависимости от интерфейса платы (RSHPCI, RSHUSB) и получения экземпляров соответствующих классов. Также в нем содержатся функции получения информации об устройстве: количество каналов, минимальная и максимальная частота, коэффициенты усиления. Соответствующие поля этого базового класса заполняются после подключения к устройству и получения его ревизии.

Спроектированная структура программного инструментария представлена на рисунке 4.

Рисунко 4. - Компонентная диаграмма инструментария

2.2.3 Паттерны проектирования

Архитектура программного продукта, а в особенности программного инструментария должна быть универсальной и легко расширяемой. Это достигается благодаря паттернам проектирования.

В сфере разработки ПО паттерном (или шаблоном) проектирования называется описание некоторой типовой, часто встречающейся проблемы проектирования архитектуры ПО и оптимальный способ ее решения [17].

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

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

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

2.2.3.1 Паттерн «Фасад»

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

Подробнее о реализации паттерна проектирования «Фасад» в данной работе см. пункт 3.1.2.2.

2.2.3.2 Паттерн «Абстрактная Фабрика»

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

Страница:


Подобные документы

  • Разработка обучающего игрового приложения на платформе Android

    Анализ целевой аудитории. Функциональные характеристики пользовательского приложения. Разработка алгоритмов и интерфейса программного продукта, функций рабочей области. Написание скриптов на языке C#. Тестирование программы методом чёрного ящика.

    дипломная работа [1,5 M], добавлен 09.11.2016

  • Разработка мобильного приложения

    Обзор мобильной ОС Android. Выбор инструментов и технологий. Проектирование прототипа графического интерфейса. Характеристика и описание пользовательского интерфейса. Проектирование и разработка базы данных. Определение списка необходимых разрешений.

    курсовая работа [376,6 K], добавлен 13.09.2017

  • Разработка приложения для смартфонов под управлением операционной системы Android

    Разработка программного обеспечения для платформы Android версии 2.3: информационное приложения для поклонников футбольной команды, с возможностью просмотра событий, статистики и иной информации о команде и ее успехах. Листинг JsonDataManager.java.

    дипломная работа [4,1 M], добавлен 24.04.2013

  • Разработка программных средств формирования групповой спецификации в среде Creo

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

    дипломная работа [2,6 M], добавлен 25.09.2014

  • Автоматизированная система построения лабиринта и поиска выхода из него

    Описание алгоритмов поиска пути. Диаграмма объектов предметной области. Разработка структурной схемы. Проектирование интерфейса пользователя. Выбор и обоснование комплекса программных средств. Разработка пользовательского меню. Диаграмма компонентов.

    курсовая работа [3,5 M], добавлен 10.04.2015

  • Разработка развивающей игры для смартфонов под управлением операционной системы Android

    Средства разработки развивающих и обучающих игр и используемой программы. Среда выполнения и Dalvik. Разработка приложения для платформы Android. Графический интерфейс и обработка касаний экрана. Разработка экранов приложения и их взаимодействия.

    дипломная работа [2,1 M], добавлен 18.01.2016

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

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

    отчет по практике [159,3 K], добавлен 11.04.2016

  • Разработка Android-приложения на тему "Исторический справочник Volkswagen"

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

    курсовая работа [167,8 K], добавлен 18.01.2017

  • Разработка игрового приложения для платформы Android

    Знакомство с особенностями и этапами разработки приложения для платформы Android. Рассмотрение функций персонажа: бег, прыжок, взаимодействие с объектами. Анализ блок-схемы алгоритма генерации платформ. Способы настройки функционала рабочей области.

    дипломная работа [3,4 M], добавлен 19.01.2017

  • Мобильная версия приложения учета и движения товаров на фирме на базе платформы Android

    Анализ свободно распространяемых систем обучения. Главная контекстная диаграмма (модель AS-IS). Декомпозиция процесса "Регистрация, поддержка пользователей". Выбор методологий моделирования и инструментария. Руководство по установке приложения на Android.

    дипломная работа [2,1 M], добавлен 29.07.2016

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены