Web-приложение по ремонту компьютерной техники

Содержание
Введение………………………………………………………………………………………3
1. Постановка задачи……………………………………………………………………….4
1.1 Назначение системы……………………………………………………………………..4
1.2 Цели создания мобильного приложения……………………………………………….4
1.3 Анализ предметной области…………………………………………………………….5
2. Проектирование диаграммы вариантов использования……………………………….9
3. Проектирование схемы базы данных………………………………………………….12
4. Проектирование алгоритма работы программы……………………………………...15
Заключение………………………………………………………………………………….16
Список использованных источников……………………………………………………...17
Приложение А Диаграмма вариантов использования……………………………………18
Приложение Б Схема базы данных………………………………………………………..19 
Введение

Цель преддипломной практики – систематизация, обобщение, закрепление и углубление теоретических знаний и умений, приобретенных в процессе теоретического обучения, приобретение навыков практической работы, позволяющих по окончании колледжа квалифицированно выполнять должностные обязанности по использованию IT-технологий.
Задачами производственной практики являются:
- углубление профессиональных навыков работы и решения практических задач в области информационных технологий;
- совершенствование практического опыта работы в коллективе;
- сбор материалов для выполнения дипломного проектирования;
- углубление теоретических знаний в области применения информационных технологий в экономике;
- расширение и укрепление навыков проектной деятельности в области информационных технологий;
- изучение опыта создания и применения конкретных информационных технологий и систем для решения реальных задач организационной, управленческой или научной деятельности в условиях конкретных производств;
- приобретение навыков практического решения информационных задач на конкретном рабочем месте в качестве стажера.






 
1. Постановка задачи

1.1 Назначение системы

В ходе дипломного проекта будет разработано «Web-приложение по ремонту компьютерной техники»
Данное приложение будет сделано на базе Web-сайта с использованием.Приложение представляет собой Web-сайт с помощью которого вы можете вызвать мастера по ремонту компьютерной техники домой или же проконсультироваться с ним по телефону.
В WordPress интегрированы написанные мной пользовательские модификации, которые в свою очередь помогли мне адаптировать данный движок для своих нужд, в которые входит пользовательский виджет и улучшение работы сайта с БД.
Назначением данного приложения является автоматизированный и быстрый поиск места, в которым пользователь мог бы получить помощь по ремонту компьютерной техники.


1.2 Цели создания мобильного приложения
Изготовление сайтов как работающих целостных информационных ресурсов и систем — составной процесс, вовлекающий труд различных специалистов. Этот вид деятельности называется веб-разработка. Владельцы будущего сайта (частные лица или организации) разрабатывают сайты своими силами, либо обращаются к специализированным. Заказанная работа может представлять собой как полный комплекс создания сайта, вплоть до придумывания названия и регистрации домена, так и расширение сайта, техническую оптимизацию и редизайн. Всё больше разработка и сопровождение сайта (портала) становится мощным сегментом активов предприятий (организаций). Поэтому разработчиков предпочитают штатных или поручают проект вести одному из директоров аппарата управления (коммерческий директор, директор департамента по связям или непосредственно руководителю проекта с группой штатных специалистов и/или совместителей). Особую роль выполняют «тестеры» конечного продукта. Это ответственная роль в продвижении и оценке проекта, так как стадия разработки для динамического большого проекта никогда не прекращается. Если вы видите сайт невредимым 2-3 года без изменений, то он возможно никому не нужен, то ли пользуется спросом на базисную информацию. Но сопровождение проекта становится не менее ответственным делом.

1.3 Анализ предметной области
Предметной областью дипломного проекта является компьютерная техника.
Компьютерная техника — комплексное понятие, описывающее весь спектр компонентов компьютерных систем, от небольшого наладонника до сверхмощного суперкомпьютера. В последнее время часто этим понятием обобщают также офисное оборудование и компьютерные комплектующие. Тем не менее, чаще всего, говоря о компьютерной технике, подразумевают сами компьютеры или отдельно стоящее оборудование, которое работает совместно с компьютерами и обеспечивает некоторую дополнительную функциональность (например, печать или сканирование документов, доступ к cети Интернет, защиту от сбоев питания).
Понятие компьютерной техники включает в себя не только аппаратное, но также и программное обеспечение, устанавливаемое на компьютерах и обеспечивающее поддержку выполнения их базовых функций. Практически, сами устройства и работающие на них программы рассматриваются в рамках него, как составляющие единого аппаратно-программного комплекса.
Аппаратно-программный комплекс — совокупность технических и программных средств, позволяющая автоматизировать выполнение комплекса задач и обеспечивающая функционирование электронных информационных ресурсов и информационных систем.
















2. Проектирование диаграммы вариантов использования


Чтобы понять и правильно спроектировать будущую систему, нужно прежде всего определить, что она будет делать, то есть, необходимо создание проекции, называемой функциональной моделью. Первым шагом при описании функциональности системы является моделирование требований к ней.
Целями анализа и моделирования требований являются:
- достижение соглашения между разработчиками, заказчиками и пользователями о том, что должна делать ПС;
- достижение лучшего понимания разработчиками поведения ПС;
- ограничение системной функциональности;
- создание базиса для планирования разработки проекта;
- определение пользовательского интерфейса.
Для достижения этих целей используются диаграммы вариантов использования UML (Use case diagrams).
На диаграммах вариантов использования (ВИ) изображаются актеры и варианты использования, между которыми существуют отношения. Здесь можно показывать и другие элементы UML.
Актером будем называть внешнюю по отношению к ПС сущность, которая может взаимодействовать с системой. Актерами могут быть как люди, так и внешние системы или устройства. Следует всегда помнить, что актер – это не конкретный человек или устройство, а роль (должностная обязанность), в которой он выступает по отношению к программной системе. Например, в качестве актера «Бухгалтер» может выступать весь наличный штат бухгалтерии. В то же время один конкретный человек может играть несколько ролей по отношению к системе.
Нахождение актеров – один из первых шагов в определении использования любой системы (как реальной, так и программной). Каждый источник внешних событий, с которыми должна взаимодействовать система, представляется как актер. Актер должен иметь имя, которое должно отражать его роль. На диаграммах ВИ актер изображается в виде стилизованной человеческой фигурки, при этом можно использовать другие стереотипы для переопределения изображения.
При взаимодействии актера с системой последняя выполняет ряд работ, которые образуют вариант использования системы (use case). Каждый актер может использовать систему по разному, то есть инициировать выполнение разных ВИ. Таким образом, каждый ВИ, по существу, есть некоторое функциональное требование к системе (которое может быть разбито на несколько более мелких). ВИ не представляет собой конструкцию, напрямую реализуемую в программном коде. Все его поведение реализуется в виде классов и компонент.
ВИ описывает, что делает ПС, но не как она это делает. Каждый ВИ обычно предполагает наличие нескольких вариантов поведения системы (потоков событий), один из которых является основным, остальные – альтернативными. Основной поток событий определяет последовательность действий системы, направленную на выполнение главной целевой функции данного ВИ. Альтернативные потоки описывают поведение системы в исключительных ситуациях, например, при ошибках. Описание потоков событий может быть выполнено как в текстовой форме, так и с помощью диаграмм UML, которые будут рассматриваться в дальнейшем.
Каждый ВИ должен иметь название, отвечающее его назначению. Название должно отражать, что достигается при взаимодействии с актерами. На диаграммах ВИ изображается в виде овала.
Ассоциация – единственно возможная связь между актером и ВИ. Она показывает, что актер и ВИ общаются друг с другом, посылая и получая сообщения. Если ассоциация направленная, она показывает направление передачи сообщения. На рис.2а оператор инициирует начало выполнения ВИ открытия нового счета.
Если два или более ВИ имеют сходство в структуре и поведении, то целесообразно выделить общий фрагмент и построить новый, родительский ВИ. Исходные ВИ будут являться дочерними по отношению к родительскому. Дочерний ВИ наследует все поведение, описанное в родительском варианте. Отношение обобщения между двумя ВИ означает, что когда осуществляется дочерний ВИ, необходимо исполнение и родительского. В общем случае для того, чтобы создание родительского ВИ имело смысл, необходимо, чтобы у него было бы хотя бы два дочерних. Единственное исключение – это, когда имеются два ВИ и один из них является детализацией другого, но оба могут осуществляться независимо.
Отношение включения, помечаемое стереотипом <>, означает, что для полного осуществления основного (базового) ВИ необходимо выполнение и включаемого варианта. В общем случае выделение включаемых ВИ будет целесообразным в тех случаях, когда такой вариант включается в несколько базовых. Об отношении включения “знает” только базовый вариант использования, но не включаемый.
Если ВИ имеет фрагменты, которые по характеру являются необязательными или представляют собой исключения и при этом не способствуют лучшему пониманию основного назначения ВИ, вы можете вынести за скобки такие фрагменты, создав новый, расширяющий ВИ. Начальный вариант становится базовым, который связывается с новым вариантом отношением расширения.
Диаграммы ВИ применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к ПС при ее проектировании и разработке. Построение модели требований при необходимости дополняется их текстовым описанием. При этом иерархическая организация требований представляется с помощью пакетов use cases.
В Web-приложении в виде актера выступает пользователь. Вариантами использования являются:
- просмотр меню;
- работа с меню;
- просмотр категорий выполняемых работ;
Диаграмма вариантов использования для web-приложения находится в приложении А. 
3. Проектирование схемы базы данных

Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.
Основные задачи:
- обеспечение хранения в БД всей необходимой информации;
- обеспечение возможности получения данных по всем необходимым запросам;
- сокращение избыточности и дублирования данных;
- обеспечение целостности базы данных.
Основные этапы проектирования схемы базы данных:
- концептуальное (инфологическое) проектирование
концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.
Чаще всего концептуальная модель базы данных включает в себя:
- описание информационных объектов, или понятий предметной области и связей между ними;
- описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними;
- логическое (даталогическое) проектирование
Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД;
- физическое проектирование
Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.
При проектировании реляционных баз данных обычно выполняется так называемая нормализация.
Модель «сущность-связь» (англ. “Entity-Relationship model”), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма, либо с использованием других графических нотаций (Crows Foot, Information Engineering и др.).
Основные преимущества ER-моделей:
- наглядность;
- модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
- ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).
Основные элементы ER-моделей:
- объекты (сущности);
- атрибуты объектов;
- связи между объектами.
Сущность — объект предметной области, имеющий атрибуты.
Связь между сущностями характеризуется:
- типом связи (1:1, 1:N, N:М);
- классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности — обязательный, иначе — необязательный.
В Web-приложении база данных состоит из одной таблицы AppInfo, которая имеет следующие атрибуты:
- idTech (является ключевым полем);
- vidTehniki;
- vidPolomki;
- vidRabot;
- infoOplata;
- Master;
Схема базы данных мобильного приложения находится в приложении Б. 
4. Проектирование алгоритма работы программы

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









 
Заключение
В ходе преддипломной практики была поставлена задача для реализации дипломного проекта. Разработаны алгоритм реализации web-приложения, схема базы данных, а также составлена диаграмма вариантов использования web-приложения.
Была подготовлена основа для быстрой реализации приложения, что облегчает задачу и контролирует правильность алгоритма работы приложения.
Также были изучены шаблоны проектирования для более оптимизированного написания кода, изучен и разобран на практике движок WordPress, а также был более углубленно изучен язык программирования JavaScript, HTML 5 и CSS3. 
Список использованных источников
1. Цехнер, M. Программирование игр для Android. – Москва: Питер, 2013. – 688 с.
2. Хашими, С. Коматинени, С. Маклин, Д. Разработка приложений для Android. – Моска: Питер, 2011. - 735 с.
3. Майер, Р. Android 2. Программирование приложений. – Москва: Эксмо, 2010. – 669 с.
4. Варакин, М.В. Разработка мобильных приложений под Android. – Москва: Специалист, 2012. – 128 с.
5. Шилдт, Г. Полный справочник по Java SE6. – Москва: Вильямс, 2007. – 1034 с.
6. Блох, Дж. Java. Эффективное программирование. – Москва: Лори, 2010 – 220 с.
7. Файн Я. Программирование на Java для детей, родителей, дедушек и бабушек. – Москва: Питер, 2011. – 231 с.










 
Приложение А
(обязательно)
Диаграмма вариантов использования