Разработка программных продуктов
Анализ инструментариев для построения пользовательского интерфейса, поддерживающих платформы iOS и Android. разработка кроссплатформенного программного инструментария и адаптация под него пользовательского приложения осциллографа-спектроанализатора.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 13.02.2016 |
| Размер файла | 809,6 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Подробнее о реализации данного паттерна проектирования см пункт 3.1.2.1.
2.3 Проектирование программных интерфейсов (API) инструментария
2.3.1 Введение
Одна из главных целей разработки SDK - создать удобный инструмент, который в дальнейшем позволит сэкономить время на разработку прикладного прогаммного обеспечения на его основе. Обычно SDK состоит из нескольких модулей, выполняющих определенные функции. При использовании этих модудей для написания ПО подробности того как они функционируют не существенны, имеет значение только что эти модули делают. Для взаимодействия модулей SDK с внешними программными продуктами используется API (Application Programming Interface) - интерфейс программирования приложений.
API позволяет реализовать ключевую для программирвоания концепцию “черного ящика”, когда внутреннее устройство функционального модуля (динамической или статической библиотеки, сервиса и т.д.) неизвестно пользователю. API является средством для взаимодействия пользователся с функциональным модулем, описывая какие действия этот модуль может выполнить, какие ему труебуются данные от пользователся и в каком виде пользователь получит результат выполненных действий. Это позволит пользователю применить модуль при разработке собственных приложений. Можно сказать что API (Application Programming Interface) схож с GUI (Graphical User Interface) в том что оба обеспечивают посредничество между пользователем и некоторым программным функциональным блоком, с разницей в том что API это “текстовый интерфейс” рассчитаный на пользователя-программиста.
Проектируя API для SDK следует сделать его таким, чтобы сторонний разработчик его использующий мог сконцетрироваться на том какие ему нужны функции, не вникая как они реализованы. В идеале API должен отражать только лишь логику предметной области.
С одной стороны API должен быть простым и удобным для пользователя, но и не слишком упрощенным - не сводиться к минимальному количеству высокопараметризованных, “универсальных” функций.
Также следует учитывать что любой успешный программный продукт будет постоянно улучшаться. При разработке API должна быть предусмотрена возможность улучшения и развития программного продукта. Если это не будет учтено, то изменение одного компонента, а затем и API для него, потребует изменений реализации других компонентов и их API. А если продукт используется сторонним пользователем, то при таких изменениях, все его программы, использующее API, также потребуют модификации.
2.3.2 Требования и общие рекомендации к API
Существует ряд рекомендаций, которых стоит придерживаться при проектировании API [8, 14, 16]. Хороший API должен:
1) Содержать как можно меньше открытых методов на класс и как можно меньше классов. Это позволит пользователю API быстро его освоить, а разработчику - поддерживать и изменять его.
2) Покрывать всю функциональность требуемую в рамках предметной области, при этом не конфликтуя с первым требованием.
3) Быть понятным и легкозапоминающимся. Названия классов, методов и их параметров должны быть краткими и в тоже время информативными, делая обращения к документации минимальными, а код - читаемым.
4) Минимизировать возможность ошибок при написании кода. Хорошо спроектированный API в самом своем дизайне минимизирует риск неправильного использования, ошибок времени компиляции (compile-time errors) и времени исполнения программы (run-time errors).
Распространненой ошибкой при написании программного продукта является следующая последовательность этапов проектирования и разработки: реализация функционала, проектирование API и релиз продукта. Спроектированное таким образом API будет отражать то какие функции реализованны в компоненте, а не то какой функционал хотел бы получить пользователь API от этого компонента. Требования к функционалу модулей должны быть получениы из анализа сценариев использования(use-case'ов) модуля - реализация должна подстраиваться под пользователя, а не наоборот.
Еще одно немаловажное требование: лучшее API - это то которое не требует от пользователя написания большого количества кода. Не стоит использовать высокопараметризованные конструкторы класса, или создавать класс, требующий перед его использованием в программе вызова множества методов. Не стоит использовать методы с множетсвом параметров - лучше чтобы они предоставляли более общий функциционал. API всегда может быть расширено в дальнейшем если это необходимо.
2.3.3 Типы данных и структуры
В разарабатываемом программном инструментарии были приняты определнные соглашения о типах и структурах используемых в методах классов.
2.3.3.1 Типы возвращаемых значений
В разработанном программном инструментарии было принято решение не используются исключения. Любой публичный метод класса возвращает беззнаковое 32-битное число с кодом ошибки, при этом 4 младшие тетрады остаются зарезервированными под системные коды ошибок, получаемые через вызовы GetLastError() (Windows) и errno() (Linux).
2.3.3.2 Базовый тип RshBaseType
В API разрабатываемого инструментария у многих классов есть многофункциональные геттеры(getter - получатель) и сеттеры(setter - установщик) - методы, служащие для получения или изменения данных, доступ к которой напрямую ограничен. Многофункциональность этого метода означает что в него передаются переменные различных типов, в зависисмости от получаемых или изменяемых данных. Если тип данных передается в другом параметре, использование указателя на void-тип делает риск ошибки очень высоким и нарушает четвертую из перечисленных выше рекомендаций к хорошему API. К тому же это идет вразрез с сильной типизацией в C++.
Для решения этой проблемы был создан базовый класс RshBaseType. Класс имеет приватное поле перечислимого типа (enumeration) enum RshDataTypes, в котором перечисленны типы данных, используемые в инструментарии. В конструкторе типа данных наследованного от RshBaseType это поле заполняется соответствующим значением из RshDataTypes. Передача такого типа данных в сеттер- или геттер-метод, вместе с кодом, определяющим тип запроса (что пользователь хочет получить от класса или какие данные отправить), по указателю на RshBaseType позволит определить, соответствует ли переданый тип коду запроса.
Интерфейсами компонентов программного инструментария являются чистые виртуальные классы (pure virtual class).
2.3.4 Внутреннее API
Эти программные интерфейсы служат для взамодействия компонентов SDK между собой и недоступны пользователю.
2.3.4.1 Интерфейс IFactory
class IFactory {
public:
virtual U32 CreateInstance(const char* IFaceName, void**)=0;
virtual U32 Release(void**)=0;
virtual U32 Free()=0;
virtual U32 Get(U32 code, RshBaseType*)=0;
};
Интерфейс для класса-фабрики. Предоставляет пользователю методы для создания экземпляра класса (CreateInstance()), освобождения всех ресурсов, занимаемых созданным фабрикой объектом(Release()), удаления всех созданных фабрикой объектов(Free()) и получения информации(названия, версии, описания, пути к файлу и т.д.) о библиотеке из которой загружена фабрика (Get()).
2.3.4.2 Программный интерфейс IRSHDeviceBase
интерфейс осциллограф кроссплатформенный программный
class IRSHDeviceBase {
public:
virtual U32 Connect(U16 VID, U16 PID, U8 DeviceNumber)=0;
virtual U32 Connect(const char* deviceName, U8 DeviceNumber)=0;
virtual U32 CloseConnection()=0;
virtual U32 Get(U32 mode, RshBaseType*)=0
};
Интерфейс для подключения к драйверу устройства. Наследуется интерфейсами библиотек IRSHUSB и IRSHPCI для низкоуровневой работы с устройствами. Содержит методы для подключения к устройству по его VID и PID, а также по его имени (Connect(U16 VID, U16 PID, U8 DeviceNumber) и Connect(const char* deviceName, U8 DeviceNumber)), освобождения занятых ресурсов (CloseConnection()) и геттер-метода для получения версии библиотеки, статусной информации об устройстве и т.д.
2.3.4.3 Программный интерфейс IRSHUSB
class IRSHUSB : public IRSHDeviceBase {
public:
virtual U32 ReadData(void* Buffer, U64 Size)=0;
virtual U32 WriteData(const void* Buffer, U64 Size)=0;
virtual U32 Dio(S32 CtrlCode,
void* InBuffer, U64 InBufferSize,
void* OutBuffer, U64 OutBufferSize)=0;
virtual U32 StopGathering()=0;
virtual U32 InitSingleGathering(RshGatheringParameters*)=0;
virtual U32 GetSingleBuffer()=0;
virtual U32 InitPersistentGathering(RshGatheringParameters*)=0;
virtual U32 StartPersistentGathering()=0;
};
Программный интерфейс для библиотеки низкоуровневой работы с USB-устройствами. Предоставляет методы для обмена данными с устройством (ReadData()/WriteData()), контроля ввода-вывода (Dio()), инициализации параметров сбора данных, выделения памяти и старта потока сбора данных для покадрового режима (InitSingleGathering() и GetSingleBuffer()) и непрерывного (InitPersistentGathering() и StartPersistentGathering()), остановки процесса сбора и освобождения памяти (StopGathering()).
2.3.4.4 Программный интерфейс IRSHPCI
class IRSHPCI : public IRSHDeviceBase {
public:
virtual U32 WritePLXreg(U32 offset, U32 value)=0;
virtual U32 ReadPLXreg(U32 offset, U32* value)=0;
virtual U32 WriteBOARDreg(U32 offset, U32 value)=0;
virtual U32 ReadBOARDreg(U32 offset, U32* value)=0;
virtual U32 StopGathering()=0;
virtual U32 InitSingleGathering(RshGatheringParameters*)=0;
virtual U32 GetSingleBuffer(RshRegister startReg)=0;
virtual U32 InitPersistentGathering(RshGatheringParameters*)=0;
virtual U32 StartPersistentGathering(RshRegister startReg)=0;
};
По аналогии с IRSHUSB - IRSHPCI является программным интерфейсом для библиотеки низкоуровневой работы с PCI-платами. В реализации самой библиотеки используется в основном PLX API, а библиотека лишь служит оберткой для его унификации с API разрабатываемого инструментария. Предоставляет методы для работы с регистрами контроллера шины PCI от фирмы PLX (WritePLXreg()/ReadPLXreg()), регистрами самой платы (WriteBOARDreg()/ReadBOARDreg()), инициализации параметров сбора данных, выделения памяти и старта потока сбора данных для покадрового режима (InitSingleGathering() и GetSingleBuffer()) и непрерывного (InitPersistentGathering() и StartPersistentGathering()), остановки процесса сбора и освобождения памяти (StopGathering()).
2.3.5 Внешнее API
Это API через которое пользователь обращается к комонентам SDK из своего приложения.
2.3.5.1 Интерфейс IRSHDevice
class IRSHDevice {
public:
virtual U32 Connect(U8 index)=0;
virtual U32 Init(RshInitBaseType*, U32 mode)=0;
virtual U32 Start()=0;
virtual U32 Stop()=0;
virtual U32 GetData(RshBufferBaseType*, U32 flag)=0;
virtual U32 Get(U32 mode, RshBaseType*)=0;
};
Описывает единый интерфейс для программного взаимодействия с любым устройством ЗАО «Руднев-Шиляев». Реализован в библиотеках для каждой конкретной платы. Метод Connect() позволяет пользователю “подключиться” к опредленному устройству в системе через хэндл соотвествующего файла устройства.
Метод Init() дает пользователю возможность установить параметры (частоту дискретизации, дифференциальный режим АЦП, количество активных каналов АЦП, коэффициенты усиления и множество других) сбора данных.
Start() запускает АЦП на плате, метод Stop() останавливает его.
GetData() предоставляет пользователю возможность получить оцифрованную информацию в разных форматах (МЗР с приведением к разным типам данных, вещественные числа с разной точностью).
Get() - многофункциональный метод, предоставляющий пользователю различную информацию о плате и её текущем состоянии (название, ревизия, серийный номер, текущий режим работы и т.д.).
2.3.5.2 Программный интерфейс IDM
class IDM {
U32 Get(U32 code, RshBaseType*)=0;
U32 GetDevice(RshDeviceKey*, IRSHDevice* device)=0;
};
Интерфейс библиотеки DM - Device Manager. В сответсвии со своим названием является менеджером всех находящихся в системе устройств ЗАО «Руднев-Шиляев», предоставляя пользователю о них информацию (характеристики, ревизию, версию библиотек), список находящихся в системе устройств(всех или только соотвествующих какому то параметру) (Get()). GetDevice() позволяет получить интерфейсный IRSHDevice для выбранного пользователем устройства.
2.3.5.3 Программный интефейс IDC
class IDC {
public:
virtual U32 InitGathering(RshDCGatheringParameters*)=0;
virtual U32 CollectData()=0;
virtual U32 StopDevice()=0;
virtual U32 Get(U32 mode, RhsBaseType*)=0;
};
IDC - интерфейсный класс библиотеки DC. Библиотека Device Controller предоставляет пользователю возможность более общего, менее детального подхода к сбору данных, их анализу и сохранению, избавляя его от взаимодействия с большим числом компонентов напрямую.
InitGathering() предоставляет метод для инициализации всех параметров сбора, настройки платы, алгоритмов для обработки собранных данных и их сохранения.
CollectData() - запускает отдельный поток, в котором идет процесс сбора данных.
StopDevice() - останавливает процесс сбора данных.
Get() - получить информацию о состоянии сбора данных (сколько собранно, ожидание события о завершении) и стандартное применение для этого метода - получение информации о библиотеке (версия, путь к файлу и т.д.).
2.3.5.4 Программный интерфейс IDPA
class IDPA {
public:
virtual U32 Process(RshDPABaseType*)=0;
virtual U32 Get(U32 mode, RshBaseType*)=0;
};
Интерфейс для работы с алгоритмической библиотекой DPA. Предоставляет унифицированный интерфейс для обработки данных с помощью различных алгоритмов.
Метод Process() производит обработку переданных данных. В зависимости от алгоритма в метод передаются разные структуры с параметрами для этого алгоритма, наследованные от RshDpaBaseType.
Get() позволяет получить информацию о библиотеке (версия, реализованные алгоритмы и т.д.).
2.3.5.5 Программный интерфейс IRSHSignalSaver
class IRSHSignalSaver {
virtual U32 OpenFile(const char* fileName) = 0;
virtual U32 CreateFile(const char* fileName) = 0;
virtual U32 CloseFile() = 0;
vitual U32 ReadMetadata(RshSignalMetadata*, U32) = 0;
virtual U32 WriteMetadata(RshSignalMetadata*, U32) = 0;
virtual U32 WriteData(RshBufferBaseType* data, U32) = 0;
virtual U32 ReadData(RshBufferBaseType* data, U32) = 0;
virtual U32 Get(U32, RshBaseType*) = 0;
virtual U32 Release() = 0;
}
Интерфейс библиотеки для работы с файлом собранных с плат данных и сопровождающей их метаинформации.
Методы CreateFile(), OpenFile(), CloseFile() предоставляют пользователю функции для создания файла с данными, открытия существуюшего и закрытия файла с которым библиотека работает в данный момент.
ReadMetadata() и WriteMetadata() вычитывают и записывают метаинформацию.
Методы WriteData() и ReadData() записывают в файл полученные с АЦП данные.
Get() получает информацию о самой библиотеке (версия, путь к файлу), Release() выгружает ее из памяти.
2.3.6 Выводы
На основании анализа сценариев использования, рассмотренных п. 2.2.1., и требований к функционалу модулей, описанных в п. 2.2.2., а также учитывая общие рекомендации и требования к проектированию программных интерфейсов, рассмотренные в 2.3.2., было спроектировано простое и одноверменно гибкое API для разрабатываемого инструментария, предоставляющее весь требуемый функционал.
3. Разработка
3.1 Разработка платформонезависимого ядра и программных интерфейсов инструментария разработчика
3.1.1 Введение
После проектирования программных интерфейсов были разработаны реализующие их платформонезависимые модули. Для обеспечения платформонезависимости модулей в основном были использованны сторонние решения. Наиболее известным из них является библиотека boost, позволяющая решить большинство проблем связанных с написанием платформонезависимых программных продуктов на языке С++.
3.1.2 Разработка платформонезависимых модулей инструментария
3.1.2.1 Модуль RshDllClient
Основной класс для работы с описываемым программным инструментарием. Через него пользователь загружает остальные бибилиотеки инструментария и получает интерфейсы для работы с ними. Класс описан в заголовочном файле предоставляемом конечному пользователю.
Модули программного инструментария представлены в виде динамических библиотек, содержащих единственный экспортируемый объект -- класс фабрики.
При установке программного инструментария директория установки записывается в реестр (ОС Windows) или в системную переменную среды (Linux).
Загрузка модуля, требуемого пользователю, и инстанциирование его класса реализовано с помощью паттерна «Абстрактная Фабрика»: RshDllClient определяет директорию установки компонентов инструментария и загружает из требуемой пользователю библиотеки класс-фабрику, которая реализует общий для всех фабрик интерфейс IFactory. Через вызов метода класса-фабрики RshDllClient передает пользователю экземпляр нужного ему класса, как указатель на его интерфейс. Схема реализации шаблона проектирования «Абстрактная Фабрика» в рассматриваемой работе показана на рисунке 5.
Рисунок 5. - Реализация шаблона проектирования «Абстрактная Фабрика»
3.1.2.2 Модули DC и DM
Два основных модуля разработанного программного инструментария, агрегирующие в себе работу со всеми остальными модулями инструментария.
DM управляет всеми подключенными к компьютеру платами ЗАО «Руднев-Шиляев». Поддерживает горячее подключение (hot-plug) USB-плат с помощью функций libusb (http://www.libusb.org/) -- кроссплатформенной сторонней библиотеки [8]. Для получения информации о PCI-платах используется функционал PlxSDK.
DC реализует интерфейс IDC, предоставляет пользователю возможность сбора данных с платы, их анализа и записи в файл.
Тем не менее программный инструментарий не навязывает пользователю использование лишь класса DC как основного. С помощью модуля DllClient пользователь может самостоятельно взаимодействовать с другими модулями программного инструментария.
DC в данной работе является примером реализации шаблона проектирования «Фасад», упрощающим сбор, обработку и запись данных в файл, скрывая от пользователя детали работы с классом DPA, классами устройств через их интерфейс IRSHDevice и классом RSHSignalSaver. Детали реализации показаны на рисунке 6.
Рисунок 6. - Реализация шаблона проектирования «Фасад»
3.1.2.2 Модуль DPA
Библиотека, содержащая в себе различные алгоритмы обработки и анализа собранных данных. Включает в себя неколько классов, каждый из которых реализует определенные алгоритмы. Конструктор класса параметризован так, чтобы каждый экземпляр класса предоставлял обработку данных только одним алгоритмом.
Алгоритмы и реализующие их классы:
· DPAApplyWindow - алгоритм наложения оконной функции;
· DPACalculateError - рассчет основной погрешности и коэффициента согласия ряда измеренных значений;
· DPAFFT - реализует алгоритм быстрого преобразования Фурье (прямого и обратного). Использована кроссплатформенная бибилотека на Си - FFTW (http://www.fftw.org);
· DPAFindInterestPoint - функция нахождения определенных точек в сигнале. Реализован поиск разрывов в непрерывноим сигнале и поиск фронта импульса;
Каждый из этих классов наследует общий интерфейсный класс IDPA.
3.1.2.3 Модуль RSHSignalSaver
Модуль RSHSignalSaver предоставляет возможности сохранять в один файл и читать из него данные, собранные с плат в непрерывном и покадровом режиме; добавлять и изменять пользовательские данные, такие как timestamp, модель платы, с которой собраны данные и любая текстовая информация, требуемая пользователю.
Для реализации требуемого функционала нужен формат данных, позволяющий создать файл-контейнер, который мог бы хранить как собранные данные в удобном для человека виде (например в вольтах, МЗРах), так и пользовательскую информацию о характере этих данных (какой эксперимент проводился, дата и время, когда была собрана информация, тип платы и т.д.). Также формат этого файла с данными должен поддерживаться популярными математическими пакетами.
Этим требованиям удовлетворяет HDF (Hierarchical Data Format, иерархический формат данных) - формат данных для хранения численной информации, успешно применяемый в NASA. Сайт проекта: http://www.hdfgroup.org.
Внутренняя структура такого файла похожа на структуру файловой системы в Unix-подобных ОС: наборы данных (datasets) хранят однородную информацию (аналог файла), группы (groups) являются контейнерами для других групп и наборов данных (аналог директорий), при этом сам файл с его содержимым является своего рода корневой директорией. Для доступа к требуемому массиву данных применяются пути с POSIX-синтаксисом. Такая древовидная структура неограниченной разветвленности и вложенности позволяет хранить в одном файле много разной информации. Такая структура файла решает проблему с хранением данных, полученных с высокочастотных плат, работающих в покадровом режиме, сохраняя каждый собранный с платы буфер в одной группе.
Библиотека для работы с данным форматом имеет официальное API для C/C++ и является кроссплатформенной. HDF является основным форматом для файлов в математических пакетах Scilab и MATLAB. Сжатие данных происходит по алгоритму szip. Это решение идеально отвечает всем требованиям для модуля сохранения данных. Функционал данного модуля основан на библиотеке HDF5.
3.1.2.4 Библиотеки драйверов высокого уровня для устройств и интерфейс IRSHDevice
IRSHDevice - интерфейсный класс для всех плат сбора данных. Все классы для работы с платами ЗАО «Руднев-Шиляев» наследуются от IRSHDevice, реализуя данный интерфейс. Он описывает функции, которые должны быть реализованы в классах устройств (высокоуровневых драйверах), не специфицируя реализацию этих функций. Были разработаны библиотеки высокоуровневых драйверов для каждой из плат ЗАО «Руднев-Шиляев» с интерфейсами PCI и USB, учитывающие аппаратные особенности каждой платы. Всего было разработанно 16 модулей.
3.1.2.5 Модуль RSHUSB
Библиотека для работы с драйверо м (о разработке которого написано в пункте 3.2.). Осуществляет всю низкоуровневую работу, не зависящую от конкретного устройства: подключение к драйверу через файл устройства, отправка команд, выделение памяти для буфера и чтение данных, управление потоками сбора данных, получение списка подключенных к системе поддерживаемых USB-устройств.
Платформнонезависимость работы с потоками и событиями обеспечивается библиотекой Boost.Thread и Boost.Signals. Работа с файлами устройства осуществляется через кроссплатформеннаую обертку над функциями ОС для работы с файлами: open()/close(), read()/write() для Linux и CreateFile()/CloseFile(), WriteFile()/ReadFile() для Windows.
3.1.2.6 RSHPCI
Библиотека для работы с PCI-платами. Фирма PLX, контроллеры которой используются на всех изделиях ЗАО «Руднев-Шиляев» с PCI-интерфейсом, предоставляет для своей продукции кроссплатформенный программный инструментарий и драйверы как для ОС Linux, так и для Windows. Эта библиотека предоставляет функционал подобный библиотеке RSHUSB, используя в основном программные интерфейсы (API) инструментария PLX. Через эти программные интерфейсы осуществляется работа с регистрами платы, управление DMA. Для организации единой с библиотекой RSHUSB логики сбора данных также используются библиотеки Boost.Thread и Boost.Signals.
3.1.3 Выводы
Были разработаны модули, реализующие весь фукционал, требуемый от программного инструментария. Для реализации платформо-зависимого функционала были использованы готовые кроссплатформенные сторонние решения, в основном библиотека Boost.
3.2 Разработка USB-драйвера под ОС Linux
Universal Serial Bus (USB, универсальная последовательная шина) служит для соединения компьютера и периферийных устройств. Важной особенностью USB является то, что в какую бы сторону ни передавалась информация, запрос на передачу всегда приходит от контроллера USB хоста, и только тогда периферийное устройство, отвечая на этот запрос, начинает передавать или принимать информацию.
USB-устройство -- очень сложная вещь, но для упрощения работы с ним в ядре Linux есть подсистема USB core. Далее будут рассмотрены базовые понятия, связанные с устройством USB: конфигурация, интерфейс, конечная точка, а также функции USB core, с помощью которых драйвер обращается к устройству.
Рисунок 7. - Схема взаимодействия пользовательского приложения с USB-устройством
3.2.1 Основные понятия USB
Все устройства USB имеют иерархию дескрипторов, которые содержат различную информацию об устройстве для хоста. Подробнее рассмотрим эту иерархию дескрипторов и информацию, которую они содержат.
3.2.1.1 Дескриптор устройства
Устройство USB может иметь только один дескриптор устройства. В нем содержатся его VID и PID (для определения драйвера соответствующего этому устройству), поддерживаемая ревизия USB и количество конфигураций устройства. В ядре Linux он представлен структурой usb_device. Некоторым функциям USB core требуется доступ к полям этой структуры. Обычно для этого используется функция interface_to_usbdev() чтобы конвертировать переданную функции структуру интерфейса в структуру struct usb_device.
3.2.1.2 Дескриптор конфигурации
Показывает величину потребляемой устройством мощности, питается ли устройство от шины, либо от собственного источника питания и количество интерфейсов, которые есть у этой конфигурации. Например, у устройства может быть две конфигурации -- одна с высоким потреблением мощности от шины, другая с собственным источником питания. Если устройство подключено к стационарному компьютеру, драйвер может выбрать конфигурацию с питанием от шины, а в случае подключения к ноутбуку -- конфигурацию с собственным источником питания. Также конфигурация позволяет иметь несколько интерфейсов устройства с разными наборами конечных точек. Хотя спецификация USB предоставляет такую возможность, очень немногие устройства имеют более одной конфигурации.
3.2.1.3 Дескриптор интерфейса
Каждый интерфейс устройства определяет некоторую его функцию. Например, многофункциональное устройство факс/сканер/принтер имеет три интерфейса для каждого из режимов работы. В отличии от конфигурации, устройство не имеет ограничений на количество одновременно предоставляемых интерфейсов, но каждый интерфейс требует отдельного драйвера. В ядре Linux интерфейсы представлены структурой struct usb_interface. Эта структура передается драйверу от USB core и через нее драйвер взаимодействует с устройством.
3.2.1.4 Конечные точки
Обмен данных с устройством USB происходит с помощью так называемых endpoints («конечных точек»). Endpoint передает данные только в одном направлении -- либо от компьютера к устройству (OUT endpoint), либо от устройства к компьютеру (IN endpoint). Можно сравнить endpoints с однонаправленными пайпами.
Endpoint может быть одного из следующих типов:
· CONTROL -- Управляющая конечная точка. Используется для конфигурации устройства, получения информации о нем и получения статусной информации от устройства. У каждого устройства есть управляющая конечная точка «endpoint 0», которая используется USB core для получения информации об устройстве, его конфигурациях, интерфейсах и конечных точках.
· INTERRUPT -- Конечная точка прерываний. Передает небольшие объемы данных с фиксированной частотой. Отличие от аппаратных прерываний в том, что требуется постоянный опрос от хоста.
· BULK -- Эти конечные точки передают большие объемы данных. Передача через такую конечную точку гарантирует что данные будут переданы без потерь, но не гарантирует завершения передачи в определенный интервал времени.
· ISOCHRONOUS -- Изохронные конечные точки. Служат для передачи больших объемов данных. Гарантируют время доставки данных, но не их целостность.
Конечные точки USB описаны в ядре Linux структурой struct usb_endpoint_descriptor, содержащей следующее поля:
· bEndpointAddress -- однобайтовый адрес конечной точки. 7-й двоичный разряд определяет направление конечной точки.
· bmAttributes -- тип конечной точки (bulk, isochronous, interrupt, control).
· wMaxPacketSize -- максимальный размер в байтах, которые эта конечная точка может передать за один раз. Драйвер может передать или получить объем данных больше этого значения, но при фактической передаче данные будут разделены на куски размером по wMaxPacketSize.
· bInterval -- Для конечной точки типа Interrupt, интервал в миллисекундах между запросами прерываний.
Суммируя все сказанное в разделе 4.2.1. структуру USB-устройства можно представить как иерархию дескрипторов, что наглядно представлено на Рисунке 5.
Рисунок 8. - Структура USB-устройства
3.2.1.5 Блоки запроса USB
USB-драйвер обменивается данными с USB-устройством с помощью механизма называемого urb (USB request block, блок запроса USB). Urb осуществляет асинхронный обмен данных с устройством через одну из его конечных точек. Можно провести аналогию между urb и пакетом в сетевой передаче данных. Каждая конечная точка имеет очередь из urb, что позволяеет отправить устройству одновременно множество запросов.
Urb описывается структурой struct urb:
· struct usb_device *dev - устройство которому послан urb.
· unsigned int pipe - пайп для передачи данных. Этот параметр хранит в себе: тип передачи данных (bulk, control и т.д.), направление и номер конечной точки. Для инициализации этого поля существует набор макросов для каждого типа конечной точки:
unsigned int usb_[snd/rcv][ctrl/bulk/int/isoc]pipe(
struct usb_device *dev,
unsigned int endpoint).
· void *transfer_buffer - указатель на буфер который будет использоваться для обмена данными с устройством.
· int transfer_buffer_length - размер буфера на который указывает переменная transfer_buffer.
· usb_compete_t complete - указатель на функцию, вызываемую USB core после завершения передачи urb или при возникновении ошибки.
· void *context - указатель на blob (Binary Large Object), который может быть использован в обработчике завершения передачи.
После определения основных понятий перейдем непосредственно к описанию разработки USB-драйвера.
3.2.2 Разработка драйвера USB
3.2.2.1 Инициализация устройства
Прежде всего нужно указать, работу с какими устройствами будет поддерживать разрабатываемый драйвер.
static const struct usb_device_id lausb_table[] = {
{ USB_DEVICE(RSH_VID, LA2USB_PID) },
{ USB_DEVICE(RSH_VID, LAN10_12USB_PID},
//...
{}
};
MODULE_DEVICE_TABLE(usb, lausb_table);
Значения VIP и PID устройств объявлены в заголовочном файле драйвера. Макрос USB_DEVICE(VID, PID) создает структуры с соответствующими VID и PID для поддержки драйвером только устройств ЗАО «Руднев-Шиляев». Макрос MODULE_DEVICE_TABLE() позволяет сообщить USB core о том, какие устройства поддерживает данный драйвер.
static struct usb_driver lausb_driver = {
.name = «lausb»,
.probe = lausb_probe,
.disconnect = lausb_disconnect,
.id_table = lausb_table,
};
Эта структура описывает драйвер UBS-устройсва: его название, с какими устройствами он работает и callback'и вызываемые USB core при подключении (поле .probe) и отключении (поле .disconnect) устройств, поддерживаемых драйвером.
Также требуются callback'и вызываемые при загрузке и выгрузке модуля USB-драйвера:
static int __init lausb_init(void) {
int result = usb_register(&lausb_driver);
//...
}
static int __exit lausb_exit(void) {
usb_deregister(&lausb_driver);
}
module_init(lausb_init);
module_exit(lausb_exit);
Функции usb_register и usb_deregister используются для регистрации и удаления драйвера из USB core. Макросы module_init() и module_exit() объявляют эти функции как точки входа при загрузке и выгрузке данного модуля.
static struct usb_class_driver lausb_class = {
.name = «lausb%d»,
.fops = &lausb_fops,
.minor_base = LAUSB_MINOR_BASE,
};
Поле .name служит в качестве имени файла устройсва, %d - значит что к имени файла будет добавлен порядковый номер устройства. В поле .fops передается указатель на структуру, содержащую адреса функций, вызываемых при выполнении операции с файлом устройства.
static const struct file_operations lausb_fops = {
.read = lausb_read,
.write = lausb_write,
.unlocked_ioctl = lausb_ioctl,
.open = lausb_open,
.release = lausb_release,
};
Зачастую возникает необходимость хранить связанные с устройством данные и передавать их в функции драйвера. Для этого создана специальная структура, содержащая кроме всего прочего следующие поля:
struct lausb {
struct usb_device *udev;
struct usb_interface *interface;
struct urb *in_urb;
struct urb *out_urb;
unsigned char *bulk_in_buffer;
unsigned int buffer_size;
//...
};
Описание функции probe:
static int lausb_probe(struct usb_interface *interface,
const struct usb_device_id *id)
{
struct lausb *dev = kzallock(sizeof(*dev), GFP_KERNEL);
dev->udev = interface_to_usbdev(interface);
dev->interface = interface;
dev->in_urb = usb_alloc_urb(0, GFP_KERNEL);
dev->out_urb = usb_alloc_urb(0, GFP_KERNEL);
dev->bulk_in_buffer = NULL;
dev->buffer_size = 0;
//...
usb_set_intfdata(interface, dev);
retval = usb_register_dev(interface, &lausb_class);
//...
}
В этой функции выделяется память под структуру lausb, соответствующие поля этой структуры заполняются указателями на структуры struct usb_device и struct usb_interface. Инициализируются две структуры struct urb -- для записи и чтения данных. Функция usb_set_intfdata() позволяет сохранить данные для конкретного устройства в поле структуры struct usb_interface, которая в дальнейшем будет передаваться в остальные функции драйвера. Функция usb_register_dev() регистрирует символьное устройство, не связанное ни с одной из подсистем обработки пользовательского взаимодействия (таких как: input, tty, video и т. д.). После вызова этой функции будет зарегистрировано символьное устройство с major-номером USB и выделен наименьший свободный minor-номер начиная с указанного в поле .minor_base. В sysfs будут созданы все необходимые файлы, затем демон udev создает файл устройства в директории /dev/.
static void lausb_disconnect(struct usb_interface *iface)
{
struct lausb *dev = usb_get_intfdata(iface);
usb_set_intfdata(iface, NULL);
usb_deregister_dev(iface, &lausb_class);
//...
usb_free_urb(dev->in_urb);
usb_free_urb(dev->out_urb);
usb_put_dev(dev->udev);
kfree(dev);
//...
}
Функция lausb_disconnect() выполняет действия, обратные действиям функции lausb_probe(): получает из struct usb_interface структуру struct lausb с информацией об отключенном устройстве и освобождает выделенную под нее память, удаляет структуры urb и struct usb_device. usb_deregister_dev() возвращает занятый minor-номер, удаляя файл устройства.
3.2.2.2 Обмен данными с устройством
По завершении регистрации устройства в подсистеме USB core, обращение к нему происходит через файл устройства. После системного вызова, такого как, например, read(), write(), open(), close() или ioctl() из пользовательского приложения драйвер вызывает соответсвующую процедуру, указатель на которую харанится в struct file_operations.
static int lausb_open(struct inode *inode, struct file *file) {
int subminor = iminor(inode);
struct usb_interface *iface;
iface = usb_find_interface(&lausb_driver, subminor);
//...
struct lausb *dev = usb_get_intfdata(iface);
//...
file->private_data = dev;
//...
}
При открытии файла будет вызвана вышеописанная функция в которую в качестве параметров передаются структуры inode и file. C помощью struct file в Linux описывается любой открытый файл (в т.ч. и файл устройства), а в struct inode содержится информация об этом открытом файле. С помощью функции iminor() будет получен minor-номер файла устройства который был открыт из user-space'а. С помощью usb_find_interface() происходит доступ к соответствующему интерфейсу устройства, из которого извлекается дескриптор struct lausb. Далее дескриптор устройства связывается со структурой открытого файла записывая указатель на struct lausb в поле .private_data структуры file, чтобы иметь к ней доступ из функций в lausb_fops.
static int lausb_release (struct inode *inode, struct file *file) {
//...
struct lausb *dev = file->private_data;
//...
usb_autopm_put_interface(dev->interface);
//...
kref_put(&dev->kref);
//...
}
При закрытии файла устройства, функция lausb_release() уменьшает количество ссылок на struct usb_interface и struct lausb.
static ssize_t lausb_write(struct file *file, const char *user_buffer, size_t count, loff_t *offp) {
//...
struct lausb *dev = file->private_data;
//...
char buf;
buf = usb_alloc_coherent(dev->udev, count, GFP_KERNEL,
&dev->out_urb->transfer_dma);
//...
copy_from_user(buf, user_buffer, count);
//...
usb_fill_bulk_urb(dev->out_urb, dev->udev,
usb_sndbulkpipe(dev->udev, LAUSB_CMD_EP),
buf, count, lausb_write_bulk_callback, dev);
urb->transfer_flag |= URB_NO_TRANSFER_DMA_MAP;
//...
usb_submit_urb(dev->out_urb);
}
Функция lausb_write() позволяет отправлять данные (в данном конкретном случае -- пакеты команд) устройству. Она принимает в качестве аргументов дескриптор файла устройства file, буфер с пользовательскими данными user_buffer, которые нужно отправить в устройство, размер этого буфера count и offset для записи offp (в данной реализации драйвера не используется).
Из поля .private_data структуры file извлекается указатель на структуру lausb. Функция usb_alloc_coherent() выделяет буфер buf под размер переданных в драйвер данных. Функция copy_from_user() копирует данные из буфера в user-space'е в буффер buf в kernel-space'е. usb_fill_bulk_urb() заполняет структуру struct urb и отправляет urb-запрос подсистеме USB core (подробнее см. 4.2.1.5.).
Callback-функция lausb_write_bulk_callback() будет вызвана асинхронно при успешном или ошибочном завершении запроса. В ней проводится проверка статуса, с которым завершился запрос, и освобождение выделенной памяти занятой буфером, который был отправлен устройству.
static ssize_t lausb_read(struct file *file, chat *buffer, size_t count, loff_t *ppos) {
//...
struct lausb *dev = file->private_data;
lausb_do_read(dev, count);
copy_to_user(buffer, dev->bulk_in_buffer, count)
//...
}
static int lausb_do_read(struct lausb *dev, size_t count) {
//...
usb_fill_bulk_urb(dev->in_urb, dev->udev,
usb_rcvbulkpipe(dev->udev, LAUSB_DATA_EP),
dev->bulk_in_buffer, count,
lausb_read_bulk_callback, dev);
//...
usb_submit_urb(dev->in_urb, GFP_KERNEL);
//...
}
В функции чтения происходит обычная последовательность действий: из struct file извлекается указатель на struct lausb. В функции lausb_do_read() происходит сам процесс чтения. Поскольку выделения памяти стоит избегать в time-critical задачах (чтение в большинстве случае означает что АЦП на плате уже запущен и начал преобразования) то функция lausb_do_read() делает проверку на размер выделенной памяти в dev->bulk_in_buffer, высвобождает и заново выделяет память только если размер буфера изменился. Затем выполняется заполнение структуры struct urb и отправка запроса на получение данных к USB core. lausb_read_bulk_callback() асинхронно вызывается при успешном или неудачном завершении запроса. Полученные от USB-устройства данные копируются в пользовательский буфер buffer из dev->bulk_in_buffer с помощью функции copy_to_user(buffer, dev->bulk_in_buffer, count).
3.2.3 Наименование файлов устройств
Разработанный драйвер поддерживает все USB-устройства ЗАО «Руднев-Шиляев». У этой универсальности есть два недостатка. Первый из них - файлы устройств будут иметь одинаковые названия (за исключением номера), независимо от того какие устройства подключены к системе. Это сильно затрудняет пользовательскому приложению подключение к определенному устройству. Второй недостаток -- файлы устройств, созданные драйвером, будут доступны только суперпользователю (root), и при запуске приложений работающих с устройствами, потребуется ввод его пароля. Для устранения этих проблем было решено воспользоваться возможностями предоставляемыми udev -- менеджером устройств Linux. Udev отслеживает события связанные с добавлением и отключением устройств из системы. У udev есть механизм правил (udev rules) позволяющий связать подключение определенного устройства с конкретным действием. Так при подключении устройства udev может запустить приложение, передать ему аргумент, а вывод приложения использовать для создания символьной ссылки (symlink) на файл устройства. Пример:
KERNEL==«lausb*», ATTRS{idVendor}==«534b» ATTRS{idProduct}==«c373», PROGRAM=«/usr/local/bin/device_namer c373», SYMLINK=«RSH/%c», GROUP= «users», MODE=«0666»
В этом правиле при подключении устройства его PID передается программе device_name в качестве аргумента. Программа device_namer -- утилита, написанная на Си, которая по PID'у определяет название подключенного устройства, считает количество уже существующих в директории /dev/RSH ссылок с таким же названием. Вывод программы состоит из строки с названием устройства и его порядкового номера в системе. Эта строка будет использована для символьной ссылки на файл устройства в /dev. При этом символьная ссылка будет иметь права доступа для обычного пользователя.
3.2.4 Заключение
Разработанный драйвер предоставляется конечному пользователю в ввиде исходных кодов самого драйвера, программы для именования файлов устройств, файла правил udev и установочного скрипта. Для работы драйвера требуется ОС Linux с ядром версии 2.6.35 и выше с установленным udev.
4. Экспериментальная часть
4.1 Разработка методики испытания
Для тестирования модулей программного инструментария были разработаны функциональные тесты. Была протестирована работоспособность программного инструментария со всей аппаратной продукцией ЗАО «Руднев-Шиляев».
Испытание работоспособности драйвера проводилось со всеми платами сбора данных производства ЗАО «Руднев-Шиляев» с интерфейсом USB. Поданный на входы платы сигнал записывался в файл и анализировался на предмет разрывов с помощью модулей разработанного программного инструментария.
4.2 Разработка тестового стенда
Для тестирования работоспособности разработанного программного инструментария был использован персональный компьютер с установленными ОС Windows и Linux.
Для тестирования работоспособности драйвера использовались генераторы сигналов -- Г3-118 и Г4-158.
4.3 Проведение натурного эксперимента
К персональному компьютеру с ОС Linux была подключена плата, на аналоговые входы которой с помощью генератора сигналов подавался синусоидальный сигнал заданной частоты. На персональном компьютере была запущенна программа, использующая модули разработанного программного инструментария, ведущая сбор данных с платы и анализ сигнала на предмет наличия в нем разрывов. В ходе испытаний была подтверждена работоспособность драйвера и компонентов программного инструментария.
5. Охрана труда
5.1 Выявление опасных и вредных факторов при эксплуатации ЭВМ и их влияния на пользователей
Компьютеры начали активно внедряться в жизнь людей с конца 80-х годов. Сейчас их в мире уже работает сотни миллионов. Почти сразу же стало ясно что ВДТ и ПВЭМ следует отнести к источникам вредного воздействия на человека. В некоторых странах Европы работа за дисплеем входит в список 40 наиболее вредных и опасных профессий.
Поскольку комплекс монитор-системный блок-сканер-принтер и другие устройства с которыми приходится работать оператору или программисту питается от сети переменного тока с напряжением 220 В / 380 В то он рискует подвергнуться поражающему воздействию электрического тока.
В 90-е годы Всемирная Организация Здравоохранения (ВОЗ) выявили специфические заболевания, связанные с работой на компьютере -- это синдром стресса оператора дисплея (VODS) и синдром запястного канала (CTS). По данным ВОЗ этими заболеваниями в той или иной степени страдает около половины всех операторов. В этих условиях очень важно знать все возможные риски, которым подвергается человек, работающий с ВДТ и ПВМ и меры безопасности, которые необходимо соблюдать при работе с ними.
Поэтому сразу с началом «компьютерного бума» в нашей стране были разработаны и утверждены требования к организации рабочих мест с использованием ВДТ и ПВЭМ. Эти требования изложены в следующих документах:
1. Санитарные правила и нормы (СанПиН 2.2.2/2.4. 1340-03) «Гигиенические требования к видеодисплейным терминалам и персональным электронно-вычислительным машинам. Организация работы.»
2. ГОСТ Р50948-96 «Средства отображения информации индивидуального использования. Общие эргономические требования и требования безопасности»
5.1.1 Опасные и вредные факторы при работе с ВДТ и ПЭВМ
5.1.1.1 Повышенные статические и динамические нагрузки
Большую часть времени оператор сидит за столом почти неподвижно. Это приводит к тому, что у него часто возникает чувство онемения и боли в спине, плечах и шее (особенно если рабочее место устроено неудобно). Из всех недомоганий, которые встречаются у операторов ЭВМ чаще распространены те, которые связаны с работой на клавиатуре и с мышью. За сутки работник делает до 60000 мелких движений кистями и пальцами рук. Каждое нажатие на клавишу связано с напряжением мышц и сухожилий. Это может приводить к болезненным воспалительным процессам (тенденитам). Недомогания, связанные с долгой малоподвижной работой получили название «синдром длительных статических нагрузок (СДСН)». Однообразные движения рук при работе с мышью и клавиатурой приводят к развитию синдрома запястного канала (по международной классификации CTS). Непрерывное сидение за компьютером ведет к гиподинамии, ослаблению мышц всего тела. Мышцы теряют свою упругость -- это ведет к нарушениям осанки (сколиозу, сутулости), а в сочетании с постоянными «перекусами» - к ожирению.
5.1.1.2 Повышенные нервно-психические нагрузки
Нервно-эмоцинальное напряжение при работе на ПК возникает из-за большого объема перерабатываемой информации, из-за дефицита времени, особенностей диалогового режима общения с ПК, из-за большой ответственности за возможные информационные ошибки. Все это приводит к повышенной раздражительности, нарушениям сна, хроническим головным болям, снижению концентрации внимания и работоспособности и даже к депрессиям.
Кроме того при повышенных нервных нагрузках происходит «выброс» из организма витаминов и минеральных веществ (особенно селена, железа, магния). Их недостаток ведет к ослаблению организма и обостряет восприимчивость ко всем вредным воздействиям.
5.1.1.3 Воздействие ВДТ на органы зрения
Общеизвестно, что 90% всей информации мы получаем через органы зрения, следовательно, глаза надо беречь «как зеницу ока». Работа оператора (пользователя) ВДТ и ПЭВМ требует огромного перенапряжения зрения.
Нагрузка на зрение оператора ЭВМ имеет свои особенности:
1. Многократный перевод глаз с бумаги, лежащей на столе (горизонтальная плоскость) на экран монитора (вертикальная плоскость)
2. Недостаточная четкость изображения на экране
3. Постоянные мелькания, блики и отражения светового потока
4. При считывании с экрана глаза смотрят непосредственно на источник света
Зрительное утомление проявляется в жалобах на затуманенное зрение, на трудности при переводе взгляда с ближних на дальние предметы, двоение предметов, чувство жжения или «песка» в глазах, покраснение глаз вследствие перенапряжения сосудов. Работа на компьютере ведет к снижению зрения, чаще всего к близорукости.
5.1.1.4 Воздействие электрического тока
Питание всего комплекса устройств с которыми работает оператор (системный блок, монитор, принтер, сканер и т.д.) производится от сети переменного тока напряжением 380 В / 220 В и частотой 50 Гц, а безопасным для человека является напряжение не выше 40 В и частота не более 20 Гц. Следовательно, самым опасным фактором при работе оператора является поражение электрическим током.
Поражение электрическим током приводит к различным травмам. Это могут быть:
1. Общие травмы (судорожные сокращения мышц, потеря сознания, нарушение дыхания и кровообращения и даже клиническая смерть)
2. Местные травмы (электрические ожоги, электрические знакия, электроофтальмия)
3. Более глубокие разрушения (термический нагрев тканей и крови, электролитическое разложение крови и плазмы)
Тяжесть поражения электрическим током зависит от:
1) величины тока
2) времени протекания, рода и частоты тока
3) индивидуальных особенностей человека
4) состояния окружающей среды (температура, влажность)
5.1.1.5 Влияние статического электричества
Во время работы ЭВМ могут возникать разрядные токи статического электричества. Вследствие этого происходит электризация пыли и других мелких частиц и их притягивание к экрану дисплея. Собравшаяся на экране пыль ухудшает видимость изображения. А если в помещении повышается подвижность воздуха, то наэлектризованная пыль попадает в глаза и дыхательные пути человека. При повышении напряженности поля E > 15 кВ/м статическое электричество может привести к сбою в работе ПЭВМ вплоть до исчезновения информации с ячеек памяти. Особенно электростатически эффект велик в помещениях с синтетическим покрытием полов и пониженной влажность воздуха.
5.1.1.6 Влияние электромагнитного излучения низких частот
При работе с ЭВМ за счет кадровой и строчной разверток образуется электромагнитное излучение низких частот. Электромагнитные поля с частотой 60 Гц и выше могут приводить к изменениям в клеточном строении живых существ вплоть до изменения синтеза ДНК. Электромагнитные поля с частотой 60 Гц вовлекают в аналогичные колебания молекулы любого типа. Результатом действия низкочастотных колебаний становится снижение активности ферментов и иммунитета. Это, в свою очередь, может приводить к таким опасным заболеваниям как катаракта, меланомный рак и др.
Подобные документы
Анализ целевой аудитории. Функциональные характеристики пользовательского приложения. Разработка алгоритмов и интерфейса программного продукта, функций рабочей области. Написание скриптов на языке C#. Тестирование программы методом чёрного ящика.
дипломная работа [1,5 M], добавлен 09.11.2016Обзор мобильной ОС Android. Выбор инструментов и технологий. Проектирование прототипа графического интерфейса. Характеристика и описание пользовательского интерфейса. Проектирование и разработка базы данных. Определение списка необходимых разрешений.
курсовая работа [376,6 K], добавлен 13.09.2017Разработка программного обеспечения для платформы Android версии 2.3: информационное приложения для поклонников футбольной команды, с возможностью просмотра событий, статистики и иной информации о команде и ее успехах. Листинг JsonDataManager.java.
дипломная работа [4,1 M], добавлен 24.04.2013Разработка программного продукта для экспорта спецификации из приложения PartList. Выбор метода передачи информации в файл, формата для представления. Разработка конвертера, реализация пользовательского интерфейса. Обоснование актуальности разработки.
дипломная работа [2,6 M], добавлен 25.09.2014Описание алгоритмов поиска пути. Диаграмма объектов предметной области. Разработка структурной схемы. Проектирование интерфейса пользователя. Выбор и обоснование комплекса программных средств. Разработка пользовательского меню. Диаграмма компонентов.
курсовая работа [3,5 M], добавлен 10.04.2015Средства разработки развивающих и обучающих игр и используемой программы. Среда выполнения и Dalvik. Разработка приложения для платформы Android. Графический интерфейс и обработка касаний экрана. Разработка экранов приложения и их взаимодействия.
дипломная работа [2,1 M], добавлен 18.01.2016Общие сведения об исследуемой организации, направления ее хозяйственной деятельности, характеристика используемой вычислительной техники и программного обеспечения. Разработка пользовательского интерфейса, шаблонов, отладка и тестирование программы.
отчет по практике [159,3 K], добавлен 11.04.2016Архитектура и история создания операционной системы Android. Язык программирования Java. Выбор средства для реализации Android приложения. Программная реализация Android приложения. Проведение тестирования разработанного программного обеспечения.
курсовая работа [167,8 K], добавлен 18.01.2017Знакомство с особенностями и этапами разработки приложения для платформы Android. Рассмотрение функций персонажа: бег, прыжок, взаимодействие с объектами. Анализ блок-схемы алгоритма генерации платформ. Способы настройки функционала рабочей области.
дипломная работа [3,4 M], добавлен 19.01.2017Анализ свободно распространяемых систем обучения. Главная контекстная диаграмма (модель AS-IS). Декомпозиция процесса "Регистрация, поддержка пользователей". Выбор методологий моделирования и инструментария. Руководство по установке приложения на Android.
дипломная работа [2,1 M], добавлен 29.07.2016
