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

80

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

постановка задачи;

моделирование и инструментарий - выбор инструментов для разработки приложения и моделирование структуры базы данных и архитектуры приложения;

реализация программного обеспечения - описание структуры приложения;

руководство пользователя;

тестирование программного обеспечения - описание тестов, проводимых над приложением;

определение экономической эффективности разработки программного обеспечения;

охрана труда.

Дипломный проект выполнен с учётом указаний и требований к выполнению дипломного проекта.



1. ПРЕДМЕТ РАЗРАБОТКИ В КОНТЕКСТЕ AS-IS И TO-BE

1.1 Обзор состояния вопроса

На сегодняшний день почти каждое предприятие или фирма использует в своей работе всевозможные информационные системы или приложения для автоматизации рабочего процесса. Исследования показывают, что одна часть из них является универсальными готовыми системами, а другая - узкоспециализирована и привязана к конкретному предприятию, фирме. Эти системы отличаются между собой сферой применения, технологиями реализации, уровнем достижимости и открытости. Одними из лучших мобильных приложений в этой сфере являются «1С: Управление небольшой фирмой», «Учет товара» и другие.

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

Для управления учебным контентом и заданиями в состав Class Server входит клиентское программное обеспечение, которое устанавливается на android устройство и позволяет:

поступления товаров, продажа и инвентаризация;

печатная форма Расходная накладная;

отчеты по продаже и остаткам товаров;

архивирование данных;

удаление данных;

диаграмма по продажам.

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

создание и хранение товаров;

регистрация поставщика;

ведение статистики;

ведение учета клиентов;

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

Разрабатываемое мобильное приложение для учета и движения товаров на фирме позволит:

максимально облегчить и упростить процесс учета и движения товаров на фирме с помощью смартфона на базе Android;

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

сэкономить денег предприятию на учете и ведению статистики, все под рукой в смартфоне;

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

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

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

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

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

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

«Учет товара» - это система позволяющая вести учет товаров со стандартным функционалом и настройками. Система может применяться в небольших фирмах.

Функциональные возможности:

регистрация заказов;

учет новых поступлений;

назначение цен и скидок на товары;

учет клиентов.

Недостатки - приложение не развивается и содержит недоработки.

Таблица 1.1 - Анализ свободно распространяемых систем обучения

	1С: Управление небольшой фирмой	Учет товара	Контейнер: Торговля + Склад 1С
Лицензия	GNU/GPL	GNU/GPL	GNU/GPL
Количество скачиваний	100000	5000	5000
Многоязыковой интерфейс	Нет	Нет	Нет
Поддержка русского языка	Да	Да	Да
Поддержка SCORM	Да	Да	Да
Структура	ядро + набор модулей	монолитная	монолитная
Возможность расширения	да, за счет внешних модулей	зависит от разработчиков	зависит от разработчиков
Платформа	Android	Android	Android
Обновление приложения	Приложение развивается	Приложение не развивается	Приложение не развивается

1.2 Модель AS-IS

AS-IS - модель «как есть», модель существующего состояния организации. Данная модель позволяет систематизировать протекающие в данный момент процессы, а также используемые информационные объекты. На основе этого выявляются узкие места в организации и взаимодействии бизнес-процессов, определяется необходимость тех или иных изменения в существующей структуре.

На этапе построения модели AS-IS важным считается строить максимально приближенную к действительности модель, основанную на реальных потоках процессов, а не на их идеализированном представлении.

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

Рисунок 1.1 - Главная контекстная диаграмма (модель AS-IS)



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

регистрация поставщика;

зачисление и регистрация товаров;

регистрация заказа товаров.

Декомпозиция контекстной диаграммы представлена на рисунке 1.2.

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

Для детального понимания процесса «Регистрация поставщика» он разбивается на следующие три процесса:

проверка данных поставщиков;

регистрация поставщика;

вход в систему.

Декомпозиция процесса «Регистрация поставщика» приводится на рисунке 1.3.

Рисунок 1.2 - Декомпозиция контекстной диаграммы



Рисунок 1.3 - Декомпозиция процесса «Регистрация поставщика»

Для детального понимания процесса «Зачисление и регистрация товара» он разбивается на следующие два процесса:

проверка товара;

выгрузка товара на склад;

распределение товара по категориям;

хранение на складе.

Декомпозиция процесса «Зачисление и регистрация товара» приводится на рисунке 1.4.

Рисунок 1.4 - Декомпозиция процесса «Зачисление и регистрация товара»

1.3 Модель TO-BE

Модель TO-BE («как должно быть») создается на основе AS-IS, с устранением недостатков в существующей организации бизнес-процессов, а так же с их совершенствованием и оптимизацией путём устранения выявленных на базе анализа AS-IS узких мест.

В соответствии с моделью TO-BE целью предмета разработки является упрощение организации учета и движения товаров на фирме. При этом предмет разработки должен обеспечить:

формирование базы данных, информацию о товарах клиентах и поставщиках;

средства доступа к этой базе для редактирования, добавления, удаления данных;

сортировку и фильтрацию данных, содержащихся в базе;

средства поиска нужной информации в базе данных;

удобный просмотр запрошенной информации.

На основе анализа созданной выше AS-IS модели процессов проблемной области была создана TO-BE модель, контекстная диаграмма которой приводится на рисунке 1.5.

Рисунок 1.5 - Главная контекстная диаграмма (модель TO-BE)

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

регистрация и поддержка пользователей;

работа с товарами;

работа с заказами товаров.

Декомпозиция контекстной диаграммы представлена на рисунке 1.6.

Рисунок 1.6 - Декомпозиция контекстной диаграммы

Процесс «Регистрация и поддержка пользователей» для детального рассмотрения разбивается на четыре процесса:

регистрация студентов и преподавателей;

изменение личных и секретных данных регистрации;

восстановление пароля;

удаление пользователя.

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

Рисунок 1.7 - Декомпозиция процесса «Регистрация и поддержка пользователей»

Процесс «Работа с новыми поставками товаров» был разбит на следующие три процесса:

добавление данных о товаре;

изменение данных о товаре;

удаление данных о товаре.

В качестве объектов, которыми оперируют процессы, выступают данные о товарах. Все процессы в результате своей деятельности обмениваются информацией с базой данных «Mysql»: добавляют, модифицируют и удаляют данные, причём вводимые данные должны удовлетворять требованиям, предъявляемые базой данных. Данные действия может выполнять «Администратор». Декомпозиция процесса «Работа с данными о товарах» приводится на рисунке 1.8.

Рисунок 1.8 - Декомпозиция процесса «Работа с данными по дисциплине»

Процесс «Работа с новыми заказами» был декомпозирован на следующие три процесса:

добавление нового заказа;

изменение нового заказа;

удаление нового заказа.

Все процессы в результате своей деятельности обмениваются информацией с базой данных «Mysql»: добавляют, модифицируют и удаляют данные, причём вводимые данные должны удовлетворять требованиям, предъявляемые базой данных. Данные действия может выполнять только «Администратор».

Декомпозиция процесса «Работа с данными» приводится на рисунке 1.9.

Рисунок 1.9 - Декомпозиция процесса «Работа с соответствующими данными»



2. ЦЕЛЬ И ЗАДАЧИ ПРОЕКТА

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

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

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

В общем случае система для всех пользователей должна предоставлять следующие возможности:

просмотр существующих товаров;

фильтрация и поиск товаров по различным критериям;

регистрация клиентов фирмы;

возможность изменения данных поставщика;

возможность удаления поставщика;

возможность изменения клиента фирмы;

возможность удаления клиента фирмы;

добавление категории товаров;

изменение категории товаров;

удаление категории товаров;

удобный, интуитивно понятный интерфейс с всевозможными подсказками.

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

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

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

В качестве уровня доступа к данным необходимо использовать СУБД MySql, которая обеспечивает централизованное структурированное хранение всех данных системы, гарантируя их целостность и непротиворечивость, а также предоставляя множество сервисов низкого уровня для: чтения данных из хранилища, сохранения данных, изменения их структуры и прочее. На этом уровне должна быть создана база данных, которая будет хранить все данные системы. Реализация команд выборки данных, контроль целостности и непротиворечивости данных должна осуществляться с помощью соответствующих хранимых процедур, триггеров и других объектов, предоставляемых сервером.

Уровень бизнес-логики будет разворачиваться на сервере приложений и представлять собой ядро системы. На этом уровне должна быть сосредоточена большая часть бизнес-логики системы:

алгоритмы авторизации пользователя системы, система проверки прав доступа;

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

класс для подключения к базе данных и выполнения транзакций;

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

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

Система разработана под операционную систему Android в интегрированной среде разработки Android Studio и выше с использованием базовой технологии разработки современных Android приложений и языка программирования Java.



3. ЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ

3.1 Выбор методологий моделирования и инструментария

Для визуального моделирования проблемной области было отдано предпочтение Rasional Rose компании Rational Software. Данное средство является простым и полностью интегрированным решением для разработки ПО, включая Интернет-решения. Rational Rose является стандартом дефакто среди инструментов проектирования приложений. Ни одно другое CASE-средство не предлагает такую широту и глубину решений как платформа Rational. С помощью Rational Rose можно визуализировать, изменять и тестировать модель.

Одно из неоспоримых преимуществ Rational Rose - обратное проектирование, поскольку разработчику и проектировщику важно увидеть перед изменениями уже работающую систему в нормальном графическом представлении. Как правило визуально-графический ряд оказывает куда большее воздействие нежели пролистывание технических заданий и программных текстов. Тем более что, проект, подвергшийся обратному проектированию может быть доработан и вновь сгенерирован (а впоследствии и скомпилирован). Rational Rose предоставляет для этого все необходимые средства.

Rational Rose является лидирующим инструментом визуального моделирования, поскольку он имеет все необходимые возможности - поддержку UML, многоязыковую поддержку итерационной разработки, полную поддержку командной разработки, компонентно-базированную разработку с поддержкой ведущих архитектур и таких компонентных моделей, как WinDNA и J2EE/SE/ME, легкость применения, оптимизированную интеграцию и многое другое.

Для проектирования и моделирования данных был использован инструментарий AllFusion ERwin Data Modeler (ERwin) компании Computer Associates. ERwin позволяет проектировать, документировать и сопровождать базы данных, хранилища данных и витрины данных (data marts). Основные аргументы и факты для разработчиков ПО в пользу использования данного инструментария:

поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД;

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

ERwin является стандартом де-факто;

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

позволяет переносить структуру БД из СУБД одного типа в СУБД другой;

позволяет документировать структуру БД;

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

позволяет получить точную и наглядную информацию, где хранятся данные и как получить к ним доступ;

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

3.2 Разработка диаграмм вариантов использования

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

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

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

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) называется любая сущность, взаимодействующая с системой извне. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру, т.е. каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

3.2.1 Действующие лица

При анализе работы системы были выделены следующие действующие лица:

Менеджер;

3.2.2 Варианты использования

Были выделены следующие варианты использования:

просмотр соответствующей информации по каждому каталогу (включает в себя: товары, контрагенты, покупатели);

работа с данными (включает в себя: добавление, обновление и удаление товаров, а так же вывод статистики);

обновление и поддержка БД (включает в себя добавление, обновление и удаление соответствующих данных);

3.2.3 Диаграмма вариантов использования

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

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

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



Рисунок 3.1 - Диаграмма вариантов использования

3.2.4 Описание вариантов использования

Вариант использования «Работа с данными по соответствующей категории»:

назначение: служит для добавления, удаления и обновления информации по соответствующей категории;

основной поток событий: выполняется, когда «Пользователь» начинает работу с системой:

система запрашивает требуемое действие (добавить, удалить, обновить информацию по соответствующей категории);

после того как «Пользователь» выбирает действие, начинает выполняться один из подчиненных потоков: добавление, обновление и удаление данных по категории.

Добавление данных по категории:

система запрашивает соответствующий раздел для добавления данных (товар, контрагент, покупатель);

«Пользователь» выбирает соответствующий раздел;

система запрашивает соответствующие данные для ввода;

«Пользователь» вводит данные;

система проверяет корректность введенных данных;

система сохраняет данные по соответствующему разделу в базу данных.

Обновление данных по дисциплине:

система запрашивает соответствующий раздел для обновления данных (товар, контрагент, покупатель);

«Пользователь» выбирает соответствующий раздел;

система запрашивает соответствующие данные для обновления;

«Пользователь» указывает соответствующие данные;

система выводит соответствующие данные для обновления;

«Пользователь» обновляет данные;

система проверяет корректность введённых данных и сохраняет их в базе данных;

Удаление данных по категории:

система запрашивает соответствующий раздел для удаления данных (товар, контрагент, покупатель);

«Пользователь» выбирает соответствующий раздел;

система запрашивает соответствующие данные для удаления;

«Пользователь» указывает соответствующие данные;

система удаляет данные.

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

добавление данных по категории: если данные для добавления некорректны, то система выводит предупреждающее сообщение о некорректности данных;

добавление данных отменено: если во время выполнения подчиненных потоков «Добавление данных по категории» «Пользователь» решил его отменить, то добавление отменяется, и основной поток начинается сначала;

обновление данных по категории: если данные для обновления некорректны, то система выводит предупреждающее сообщение о некорректности данных;

обновление данных отменено: если во время выполнения подчиненных потоков «Обновление данных по категории» «Пользователь» решил его отменить, то обновление отменяется, и основной поток начинается сначала;

предусловия: перед началом выполнения данного варианта использования «Пользователь» должен войти в систему;

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

Вариант использования «Просмотр соответствующей информации»:

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

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

«Пользователь» выбирает соответствующую категорию для работы;

система выводит соответствующие разделы выбранной категории;

«Пользователь» выбирает соответствующий раздел для просмотра;

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

«Пользователь» выбирает соответствующую ссылку интересующей его информации;

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

альтернативный поток: в том случае, когда системе не удалось найти соответствующей информации по запросу «Пользователь» в базе данных, система выводит соответствующее сообщение (при этом выполнение варианта использования продолжается);

предисловия: перед началом выполнения данного варианта использования «Пользователь» должен войти в систему;

постусловия: если вариант использования выполнен успешно, «Пользователю» предоставляется для просмотра вся информация заданного раздела по выбранной дисциплине.

Вариант использования «Обновление и поддержка БД»:

назначение: служит для добавления, удаления и обновления информации, которая необходима для функционирования системы;

основной поток событий: выполняется, когда «Пользователь» начинает работу с системой:

система запрашивает требуемое действие (добавить, удалить, обновить информацию по соответствующей категории);

после того как «Пользователь» выбирает действие, начинает выполняться один из подчиненных потоков: добавление, обновление и удаление данных.

Добавление данных:

система запрашивает соответствующий раздел для добавления данных (товар, контрагент, покупатель);

«Пользователь» выбирает соответствующий раздел;

система запрашивает соответствующие данные для ввода;

«Пользователь» вводит данные;

система проверяет корректность введенных данных;

система сохраняет данные по соответствующему разделу в базу данных.

Обновление данных:

система запрашивает соответствующий раздел для обновления данных (товар, контрагент, покупатель);

«Пользователь» выбирает соответствующий раздел;

система запрашивает соответствующие данные для обновления;

«Пользователь» указывает соответствующие данные;

система выводит соответствующие данные для обновления;

«Пользователь» обновляет данные;

система проверяет корректность данных и сохраняет их в базе данных;

Удаление данных:

система запрашивает соответствующий раздел, для удаления данных (товар, контрагент, покупатель)

«Пользователь» выбирает соответствующий раздел;

система запрашивает соответствующие данные для удаления;

«Пользователь» указывает соответствующие данные;

система удаляет данные.

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

добавление данных: если данные для добавления некорректны, то система выводит предупреждающее сообщение о некорректности данных;

добавление данных отменено: если во время выполнения подчиненных потоков «Добавление данных по категории», «Пользователь» решил его отменить, то добавление отменяется, и основной поток начинается сначала;

обновление данных: если данные для обновления некорректны, то система выводит предупреждающее сообщение о некорректности данных;

обновление данных отменено: если во время выполнения подчиненных потоков «Обновление данных по дисциплине», «Пользователь» решил его отменить, то обновление отменяется, и основной поток начинается сначала;

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

предусловия: перед началом выполнения данного варианта использования «Пользователь» должен войти в систему;

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

android система декомпозиция пользователь

3.3 Идентификация классов анализа

3.3.1 Способы идентификации классов анализа

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

Для идентификации классов и объектов используются:

классические подходы (опираются на классическую категоризацию и согласуются с требованиями предметной области);

анализ поведения (сосредотачивается на динамическом поведении как на первопричине объектов и классов);

анализ предметной области (выделение объектов операций и связи, которые эксперты предметной области считают важными);

анализ вариантов (образцов использования, сценариев, начинающихся с того, что пользователь системы имитирует операцию или последовательность операций);

CRC-карточки (компонента-ответственность-участники: на карточке ищут название компоненты снизу в левой половине - за что отвечает, а в правой - с кем сотрудничает);

неформальное описание (описывает задачу на простом английском языке, а затем существительные причисляют кандидатами в классы, а глаголы в имена операций);

структурный анализ (выполняет самый верхний уровень структурного анализа, а затем переключается на выполнение классификации).

3.4 Поведение предмета разработки

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

Трактуя предмет разработки как класс, поведение объекта системы может быть представлено в виде диаграммы деятельности, приведённой на рисунке 3.2.

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

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

Рисунок 3.2 - Диаграмма деятельности системы

3.5 Взаимодействие объектов и экранные формы

3.5.1 Вариант использования «Аутентификация»

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

Макет экранной формы «Аутентификации», который приводится на рисунке 3.5, имеет довольно абстрактный вид. В процессе реализации системы, безусловно, реальные формы будут в значительной степени отличаться от проектируемых, прежде всего с точки зрения интерфейса пользователя.

На диаграмме последовательности «Аутентификации», которая приводится на рисунке 3.3, изображена последовательность действий пользователя при осуществлении входа в систему.

Рисунок 3.3 - Диаграмма последовательности «Аутентификации»

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

Макет экранной формы «Аутентификации», который приводится на рисунке 3.5, имеет довольно абстрактный вид. В процессе реализации системы, безусловно, реальные формы будут в значительной степени отличаться от проектируемых, прежде всего с точки зрения интерфейса пользователя.

Рисунок 3.4 - Диаграмма кооперации «Аутентификации»

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

На диаграмме последовательности «Просмотр соответствующей информации по категории», которая приводится на рисунке 3.6, изображена последовательность действий пользователя при осуществлении входа в систему.

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

Рисунок 3.5 - Диаграмма последовательности «Просмотр соответствующей информации по категории»

Рисунок 3.6 - Диаграмма кооперации «Просмотра информации»

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

3.5.2 Вариант использования «Работа с данными категорий товаров»

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

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

Рисунок 3.7 - Диаграмма последовательности «Работа с данными по соответствующей категории»

Рисунок 3.8 - Диаграмма кооперации «Работа с данными по соответствующей категории»

Макет экранной формы «Работа с данными по соответствующей категории», который приводится на рисунке 3.9, имеет довольно абстрактный вид. В процессе реализации системы, безусловно, реальные формы будет в значительной степени отличаться от проектируемых, прежде всего с точки зрения интерфейса пользователя.

Рисунок 3.9 - Макет экранной формы «Работа с данными по соответствующей категории»

3.5.3 Вариант использования «Обновление и поддержка БД»

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

На диаграмме последовательности «Обновление и поддержка БД», которая приводится на рисунке 3.10, изображена последовательность действий администратора при осуществлении операций добавления, обновления и удаления соответствующих данных.

Рисунок 3.10 - Диаграмма последовательности «Обновление и поддержка БД»

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

Макет интерфейса экранной формы «Обновление и поддержка БД», который приводится на рисунке 3.12, является прообразом будущего интерфейса, который будет в значительной степени отличаться от проектируемого.

Рисунок 3.11 - Диаграмма кооперации «Обновление и поддержка БД»

3.6 Логическая модель данных

3.6.1 Определение основных типов сущностей

В результате анализа предметной области и диаграммы модели TO-BE, а также после выполнения необходимой нормализации выделенных ранее сущностей (до 3 нормальной формы), удаления из них нежелательных элементов и преобразование полученных моделей в локальные логические модели данных (удаление связей типа M:N, сложных связей, рекурсивных связей, множественных атрибутов, связей с атрибутами и избыточных связей, перепроверка связей типа 1-1), были окончательно определены типы сущностей, которые представлены в таблице 3.2, а определение и описание атрибутов сущностей приведено в «ПРИЛОЖЕНИИ А».

Таблица 3.2 - Определение основных типов сущностей и их атрибутов

Имя сущности	Описание	Псевдонимы	Особенности использования
Контрагент	Физическое или юридическое лицо, являющееся стороной в гражданско-правовых отношениях, при заключении договора	клиент, покупатель	Используется в качестве клиента, который покупает товар.
Склад	Место где хранятся наши товары.	Хранилище	Нужен для хранения товара, а также добавления его от поставщика и продажи товара клиенту.
Товар	Продукт труда, имеющий стоимость и распределяющийся в обществе путём обмена, купли- продажи	продукция
Категория	Товары связанные теми или иными общими признаками	группа, класс	Связывает товара по признакам.
Поставщик	Физическое или юридическое лицо.	импортер	Лицо, у которого будет закупаться товар.

На основании проведённого анализа сущностей и их атрибутов при помощи инструментального средства ERwin была построена логическая модель данных, которая представлена ниже на различных уровнях в нотации IDEF1X (Integration DEFinition for Information Modeling):

на рисунке 3.12 приводится модель данных на уровне сущностей (без раскрытия их внутренней структуры);

на рисунке 3.13- модель данных на уровне первичных ключей;

на рисунке 3.14 - модель данных на уровне атрибутов (с раскрытием внутренней структуры сущности и отношениями между ними).

Рисунок 3.12 - Логическая модель данных на уровне сущностей

Рисунок 3.13 - Логическая модель данных на уровне первичных ключей

Рисунок 3.14 - Логическая модель данных на уровне атрибутов

3.7 Статическая модель предмета разработки

3.7.1 Статическая модель архитектуры приложения

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

Рисунок 3.15 - Диаграмма классов базы данных



4. ФИЗИЧЕСКОЕ МОДЕЛИРОВАНИЕ

4.1 Выбор среды разработки, языка программирования и инструментальных средств разработки

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

В качестве среды для разработки базы данных была выбрана СУБД MySQL сервер.

MySQL Server - это законченное предложение в области баз данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных. Оно позволяет значительно сократить время выхода этих решений на рынок, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям. В сервер включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки. Также СУБД предоставляет удобный доступ к базе данных через Web по протоколу HTTP, быстродействующий встроенный полнотекстовый поиск в данных, хранящихся в БД и в документах.

4.1 Физическая модель данных

4.1.1 Проектирование и создание таблиц базы данных

На основании логической модели базы данных на рисунке 4.1 приводится физическая модель спроектированной базы данных «FIRM», отображаемая на уровне первичных и внешних ключей, а в «ПРИЛОЖЕНИИ Б» представлена физическая структура таблиц и их связей базы данных «FIRM», реализованная с помощью Mysql Workbench.

Рисунок 4.1 - Физическая модель данных на уровне атрибутов

4.1.2 Разработка хранимых процедур

Под понятие физической и логической независимости данных следует понимать то, что все ограничения целостности должны задаваться не логикой работы приложения, а определяться на уровне базы данных. Следуя этой технологии, для реализации логики эффективной работы базы данных и компенсации недостающих функций, на сервере были разработаны соответствующие хранимые процедуры, которые приведены в таблице 4.1, а в «ПРИЛОЖЕНИИ В» приведены листинги некоторых из них.

Таблица 4.1 - Список разработанных хранимых процедур

№	Название хранимой процедуры	Назначение
	DeleteProduct	Удаляет товар
	DeleteStore	Удаляет склад
	DeleteProvider	Удаляет поставщика
	DeleteContragent	Удаляет клиента
	DeleteCategory	Удаляет категорию
	GetProductList	Возвращает список товаров
	GetProductListByCategory	Возвращает список товаров определенной категории
	GetStore	Возвращает склад с товарами
	GetProvidersList	Возвращает список поставщиков
	InsertCategory	Используется для добавления новой категории
	InsertProduct	Используется для добавления нового товара
	InsertProvider	Используется для добавления нового поставщика
	InsertContragent	Используется для добавления нового клиента
	InsertStore	Используется для добавления нового склада
	UpdateCategory	Используется для обновления существующей категории
	UpdateStore	Используется для обновления существующего склада
	UpdateProduct	Используется для обновления существующего товара
	UpdateProvider	Используется для обновления существующего поставщика
	UpdateContragent	Используется для обновления существующего клиента
	GetProviderById	Возвращает поставщика по идентификатору
	GetContagentList	Возвращает список клиентов
	GetContagentById	Возвращает клиента по идентификатору
	GetCategoriesList	Возвращает список категорий
	GetCategoryById	Возвращает категорию по идентификатору
	GetProductById	Возвращает продукт по идентификатору

4.2 Компоненты предмета разработки

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

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

спецификации исполнимого варианта программной системы;

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

Разрабатываемая система на уровне пользователя состоит из трёх частей: администраторской, преподавательской и студенческой, а на физическом уровне - из базы данных (размещается на сервере информационного ресурса и является одним из компонентов СУБД) и Android приложения (клиентского приложения в виде отображаемых activity на смартфоне).

Диаграмма компонентов клиентской части приложения приводится на рисунке 4.2.

Рисунок 4.2 - Диаграмма компонентов клиентской части приложения

Диаграмма компонентов серверной части приложения приводится на рисунке 4.3.

Рисунок 4.3 - Диаграмма компонентов серверной части приложения

4.3 Развертывание предмета разработки

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

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

Перечислим цели, которые преследовались при разработке диаграммы:

определить распределение компонентов системы по ее физическим узлам;

показать физические связи между всеми узлами системы на этапе ее исполнения;

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

Рисунок 4.4 - Диаграмма развёртывания системы

Сервер Web-приложения реализует с помощью php-страниц, которые в свою очередь базируются (основаны) на разработанных классах (хранятся в файлах *.php) и master-страницах, предоставляющих однотипный интерфейс страницы.

База данных, которая храниться на серверной станции и является компонентом СУБД, состоит из файлов данных *.mdf и *.ndf, а также файла-журнала транзакций *.ldf.

В конце данного раздела на рисунке 4.7 приводится общая структура будущего физического (аппаратного) развёртывания программно-методического комплекса.

Рисунок 4.5 - Структура аппаратного развёртывания приложения



5. РЕАЛИЗАЦИЯ И ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.1 Назначение и описание компонентов программного обеспечения

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

Ниже приводятся описание разработанных классов для подключения, доступа, отображения и выполнения транзакций с данными, хранящимися в базе данных, а также классов непосредственно данных (код критических классов приводится в «ПРИЛОЖЕНИИ Г»):

ActivityPrice - базовый класс который отвечает за работу с ценами;

DocPriceAdapter - базовый класс, для вывода цены;

ActivityByuer - базовый класс который отвечает за работу с покупателями;

DocBuyerAdapter - базовый класс, для вывода информации о покупателе;

ActivityRealiz - базовый класс, отвечает за реализацию всех процессов в приложении;

ExtDbHelper - базовый класс для создания подключения и выполнения основных транзакций (операций) к базе данных;

WarehouseList - класс скалада;

OrganizationList - класс организации;

EntranceTovarList - класс входящих товаров;

DocSupplierList - класс поставщика;

DocReceiptList - класс прихода товаров;

На рисунке 5.1 приводится UML-диаграмма иерархии классов самих данных, а на рисунке 5.2 - UML-диаграмма иерархии классов для непосредственной работы с данными.

Рисунок 5.1 - UML-диаграмма иерархии классов данных

Рисунок 5.2 - UML-диаграмма иерархии классов для работы с данными



Структура файла AndroidManifest.xml

Элемент <manifest> является корневым элементом файла.

<manifest package="com.example.mogilevtrans2"

android:versionCode="1"

android:versionName="1.0" xmlns:android="http://schemas.android.com/apk/res/android">

Элемент <uses-sdk> позволяет объявлять совместимость приложения с указанной версией (или более новыми версиями API) платформы Android. Уровень api, объявленный приложением, сравнивается с уровнем API системы мобильного устройства, на который инсталлируется данное приложение.

<uses-sdk android:minsdkversion="11" />

11 версия sdk означает, что приложение будет откомпилировано с использованием библиотек android 3.0.

Элемент <uses-permission> запрашивает разрешения, которые приложению должны быть предоставлены системой для его нормального функционирования.

Использование доступа к интернету:

<uses-permission android:name="android.permission.internet" />

Разрешение приложению доступа к данным о местоположении, предоставляемым сетью wi-fi или сотовой сетью, которые получаются через класс geolocation:

<uses-permission android:name="android.permission.access_coarse_location" />

Разрешает приложению доступ к данным gps через класс geolocation.

<uses-permission android:name="android.permission.access_fine_location" />

Элемент <application> - это элемент манифеста, содержащий описание компонентов приложения, доступных в пакете. Этот элемент содержит дочерние элементы, которые объявляют каждый из компонентов, входящих в состав приложения.