МИНОБРНАУКИ РОССИИ
Федеральное государственное автономное образовательное учреждение высшего образования
«Национальный исследовательский университет
«Московский институт электронной техники»
Факультет микроприборов и технической кибернетики
Кафедра информатики и программного обеспечения вычислительных систем
Николаев Николай Александрович
Бакалаврская работа
по направлению 09.03.04 «Программная инженерия»
«Разработка программного модуля геоинформационной системы контроля и учета
энергетических ресурсов в многоквартирных зданиях»
(Шифр ПМ КУЭР)
Студент
Николаев Н. А.
Научный руководитель,
профессор каф. ИПОВС, д.т.н.
Портнов Е. М.
Москва 2017
СОДЕРЖАНИЕ
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ4
ВВЕДЕНИЕ5
1 ИССЛЕДОВАТЕЛЬСКИЙ РАЗДЕЛ7
1.1 Предметная область разработки ПО 7
1.2
1.4
Анализ существующих программных решений9
1.3 Постановка целей и задач2
Функциональные требования, предъявляемые к ПМ КУЭР3
1.5 Концептуальная модель3
1.6 Структура входных и выходных данных
1.7 Программная архитектура и алгоритм работы
1.7.1 Алгоритм работы ПМ КУЭР
1.7.2 Программная архитектура ПМ КУЭР
1.7.3 Требования к надежности
1.8 Требования к информационной и программной совместимости
Выводы по разделу...............................................................................................22
2
2.1
3
КОНСТРУКТОРСКИЙ РАЗДЕЛ23
Выбор языка программирования23
2.2 Выбор среды разработки5
2.3 Программная реализация7
2.4 Работа с базами данных6
2.4.1 Требования к размерности БД 38
2.4.2 Требования к поддерживаемым типам данных 38
2.5 Разработка пользовательского интерфейса 9
Выводы по разделу...............................................................................................41
ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ............................................................................42
3.1 Средства и методы отладки ПМ КУЭР42
3.2 Проведение тестирования6
3.2.1 Анализ методов и средств тестирования46
3.2.2 Процесс составления тест-кейсов для проведения тестирования
ПМ КУЭР51
3.3 Процесс и результаты тестирования.........................................................53
3.3.1 Процесс тестирования53
3.3.2 Результаты тестирования54
Выводы по разделу...............................................................................................56
ЗАКЛЮЧЕНИЕ .............................................................................................................57
СПИСОК ИСТОЧНИКОВ............................................................................................58
ПРИЛОЖЕНИЕ 1. Техническое задание..............................................................1 - 6
2
ПРИЛОЖЕНИЕ 2.
ПРИЛОЖЕНИЕ 3.
Руководство оператора ........................................................1 - 15
Текст программы....................................................................1 - 1
3
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ
ПМ КУЭР
-
программный модуль геоинформационной системы контроля и
ПО
БД
СУБД
ПМИ
РС
ОС
-
учета энергетических ресурсов
программное обеспечение
база данных
система управления базами данных
программа и методика испытаний
рабочая станция (персональный компьютер)
операционная система
4
ВВЕДЕНИЕ
В современном мире одной из важнейших проблем промышленности является
проблема энергосбережения. Трудно представить себе, что в больших городах остались
дома, в квартирах которых люди не пользуются электроэнергией, газопроводом.
Керосиновые лампы, газовые баллоны, всё это уже давно ушло в прошлое. В настоящее
время в многоквартирных домах используются газовые, а то и электрические, плиты, свет в
помещениях дает электроэнергия. За всем этим следят – ЖКХ [14] и Газпром межрегионгаз
[16]. Они ставят специальные счетчики для измерения потребления электроэнергии, газа, с
которых в последствии считывают показания и обнуляют [15]. И так продолжается из года в
год. Но нередко доводилось слышать и видеть, как потребители бывали часто недовольны
тем, какие счета за использование приходили им от сотрудников ЖКХ. Особо недовольные
подают жалобы и протесты на эти квитанции. Для того, чтобы доказывать свою правоту, им
приходится тратить много времени, а главное нервов. Невозможно обеспечить высокий
уровень жизни общества без реализации энергетической безопасности. А безопасность,
прежде всего, заключается в том, чтобы общество было уверено в правдивости показаний.
Для решения этой задачи предлагается программный модуль (ПМ) контроля и учета
энергетических ресурсов в многоквартирных домах.
Необходимо отметить, что рассматриваемый комплекс обеспечения энергетической
безопасности требует применения различных методов и алгоритмов для формирования
управляющих решений. Существенную помощь в таких исследованиях могут оказать
геоинформационные системы, которые помогают визуализировать информацию о работе
сложных пространственно-распределенных систем.
Целью данной ВКР является контроль и учет потребления энергетических ресурсов
жилого
дома
с
возможностью
интеллектуального
анализа
данных
на
основе
геоинформационных технологий [17], в котором предстоят исследования и разработка
алгоритмов функционирования систем контроля и учета энергоресурсов.
При выполнении работы требуется решить следующие задачи:
исследование предметной области;
сравнительный анализ существующих программных решений;
выбор языка и среды программирования;
разработка структурной схемы, схемы данных и схемы алгоритмов ПМ КУЭР;
5
разработка удобного пользовательского интерфейса;
программная реализация;
отладка и тестирование;
разработка руководства оператора.
Программный
модуль
контроля
и
учета
энергетических
ресурсов
должен
обеспечивать следующие возможности:
получение данных с приборов для учета потребления, с помощью которых
производится дальнейший анализ;
анализ полученных данных;
отправка данных в БД;
автоматическое обновление базы данных потребителей;
повышение
производительности
и
надежности
полученного
программного
продукта;
Пояснительная записка состоит из введения, 3 разделов, заключения, списка
литературы и приложений.
Раздел 1 является исследовательским разделом и содержит анализ проведенных
предварительных научно-исследовательских работ, описание постановки целей и задач,
описание входных и выходных данных для разрабатываемого программного модуля,
детальные схемы основных алгоритмов работы ПМ КУЭР, перечисление требований к ПМ
КУЭР;
Раздел 2 является конструкторским разделом и посвящен разработке алгоритмов и
реализации решения поставленной задачи, анализу существующих языков, средств и
технологий разработки, разработке моделей и алгоритмов, применительно к выбранным
технологиям разработки и описанию разработки пользовательского интерфейса.
Раздел 3 является технологическим разделом и содержит сведения о приемах
тестирования и отладки разрабатываемого программного модуля. Посвящен анализу
выбранных средств и методик тестирования.
Приложение 1 представляет собой техническое задание.
Приложение 2 представляет руководство оператора.
Приложение 3 содержит в себе фрагменты исходного кода программного модуля.
Объем пояснительной записки 62 листа.
6
Результаты работы апробированы на 4-ой Международной научно-технической
конференции «Энергосбережение и эффективность в технических системах».
7
1 ИССЛЕДОВАТЕЛЬСКИЙ РАЗДЕЛ
1.1 Предметная область разработки ПО
В России немало крупных компаний, которые работают в сфере энергосбережения и
энергетической безопасности. Известное маркетинговое агентство РБК.reserch, которое
проводит исследование во всех крупных отраслях бизнеса [18], не так давно на своем сайте
опубликовало рейтинг компаний, которые предоставляют услуги в энергетике и
энергосбережении. Основополагающими для составления рейтинга были следующие
критерии:
проведение
мероприятий,
направленных
на
улучшение
энергосбережения
и
энергетической эффективности;
энергосервисная деятельность;
разработка программ энергосбережения;
энергоаудиторская деятельность;
создание интеллектуальных систем в сфере энергосбережения.
Всего было отобрано более 50 компаний, которые, по мнению агентства РБК.reserch,
были наиболее конкурентно-способными, на фоне остальных. Рейтинг, который в итоге
получился, можно увидеть ниже:
Результаты рейтинга представлены в Таблице 1.1 Рейтинг компаний в сфере
энергосбережения и энергетической безопасности.
Таблица 1.1 – Рейтинг компаний в сфере энергосбережения и энергобезопасности
Позиция
1
2
3
4
5
6
7
8
9
10
Название компании/предприятия
ООО "ИНТЕР РАО ЕЭС"
Холдинг "ТЕПЛОКОМ"
ЗАО ИТФ "Системы и технологии"
ООО НПП "ВНИКО"
ЗАО "Энергокомплекс-Инжиниринг"
ООО "Компания "Интегратор"
ЗАО "Шнейдер Электрик"
ООО "Технологический институт "ВЕМО"
ООО "КЭР-Инжиниринг"
ООО "ПромЭнергоАудит"
8
Город
Кол-во баллов
г. Москва
г. C.-Петербург
г. Владимир
г. Новочеркасск
г. Москва
г. Ярославль
г. Москва
г. Москва
г. Казань
г. Иваново
из 117
73,35
71,01
64,95
56,52
55,22
53,46
48,68
46,38
45,83
43,18
Позиции в рейтинге указывают как на количественные, так и на качественные
результаты деятельности компаний [13]. Исходя из рейтинга, можно сделать вывод, что
больше трети компаний, которые активно занимаются вопросами энергетических ресурсов и
энергосбережением, находятся в Москве. Что не может не указывать на то, где следует
предлагать готовые решения или реальные идеи, для решения данных проблем:
Соотношение компаний в городах, активно ведущих работу в сфере энергетики
Москва
Ярославль
Санкт-Петербург
Иваново
Казань
Новочеркасск
Владимир
Рисунок 1.1 - Города, где больше всего компаний, занятых в энергетической отрасли
Каждая из этих компаний решает свои, не менее важные задачи. Но ни одна из них не
ведет контроль и учет потребления энергетических ресурсов в жилых домах [12]. Большим
плюсом как для общества, так и для сферы энергетики, была бы разработка ПО, к которому
предъявлялись бы следующие требования:
простота в использовании;
экономичность;
возможность быстрого доступа;
надежность.
наличие единой системы обмена данными.
9
1.2 Анализ существующих программных решений
На данный момент существует немного сервисов, которые решают проблему
контроля и учета потребления энергоресурсов. Есть такие программные решения, которые
либо частично затрагивают рассматриваемую область, либо охватывают ее не полностью.
Рассмотрим некоторые из них ниже.
Plugmee — предоставляет комплекс для решения повседневных задач в доме. Из
всех существующих аналогов предоставляет наиболее широкий функционал, в который
входит учет и контроль потребления энергетических ресурсов, а также возможность
снижения использования энергии в конкретном доме или квартире. Данный сервис
функционирует и успешно продвигается уже 10 лет и, как говорят официальные
представители, останавливаться на достигнутом не собираются. Основным направлением
видится безопасность дома в целом, что сказывается на цене продукта. Полный пакет
услуг за один год использования потенциальному потребителю обойдется примерно в
500$ (30 000руб), что делает ее использование для среднестатистических семей финансово
нецелесообразным. По словам генерального директора компании, которая занимается
разработкой данного продукта, цена пакетов услуг, куда включены не все опции, будет
отличаться незначительно.
ЯЭнергетик - представляет собой комплекс по сбору показаний с электросчетчиков
в любой момент времени по запросу и по расписанию. Данный сервис отличается от
вышеупомянутого своим простым и понятным пользователю интерфейсом, что является
несомненным плюсом. Имеется несколько интересных функций, которые нельзя не
отметить:
опрос показаний счетчиков прямо на сайте;
наличие тепловой карты (наличие или отсутствие показаний в определенные
дни);
телефонный робот для сбора показаний;
несколько ценовых категорий для расчета.
Также имеется демонстрационная версия, подписка на которую дается на 7 дней,
после чего предлагается приобрести полную версию.
АСТУЭ – расшифровывается как автоматизированная система технического учета
10
электроэнергии. Работает по стандартному принципу установки приборов учета с
заданными характеристиками, которые оглашает на этапе реализации заказчик. Система
учета
электроэнергии
представляет
информационно-измерительную
систему
собой
с
территориально
многоуровневой
распределенную
организацией
и
иерархической системой обработки информации.
Уровни системы:
нижний уровень (измерение, вычисление и хранение данных о потреблении
электроэнергии;
средний уровень (сбор, хранение и передача данных на верхний уровень);
верхний уровень (ведение базы данных, визуализация данных, формирование
отчетов);
В задачи АСТУЭ входит:
точное измерение количества потребленной электроэнергии;
сбор
данных
об
объемах
потребления
электроэнергии
с
заданным
интервалом;
анализ полученных данных в соответствие с требованиями заказчика;
хранение необходимых данных за заданный период в соответствие с
требованиями заказчика.
Результаты сравнения программных решений представлены в Таблице 1.2
Существующие программные решения.
11
Таблица 1.2 – Существующие программные решения
Продукт
Plugmee1
ЯЭнергетик2
Стоимость
490$ / год
Бесплатно
Основное
направление
работы
АСТУЭ3
Зависит от
ПМ КУЭР
Бесплатно
Снижение
пакетов услуг
Аудит и контроль
Контроль и учет
Безопасность
тарифов на
потребления
ГИС
дома
электроэнерги
электроэнергии
энергетических
ю
ресурсов
Онлайн оплата
за потребление
электроэнерги
-
-
-
+
+
-
+
+
+
+
+
+
и и газа
Возможность
размещения на
собственных
серверных
мощностях
Аналитически
е инструменты
Источники информации:
[1]http://plugmee.com/ru/home
Условные обозначения:
+ - указанная возможность
[2]https://yaenergetik.ru/
[3]http://www.telesystems.info
присутствует;
- - указанная возможность
отсутствует.
Из приведенной выше таблицы видно, что ни одно их существующих решений не
обеспечивает в полной мере тем функционалом, который нужен для общества. В наше
нестабильное, с точки зрения экономики, время, остро стоит вопрос о цене за
предоставляемые услуги. Часто, пользователи закрывают глаза на бренд, на безопасность,
стараясь найти предложение выгоднее. Стоимость представленных в таблице 1.2 сервисов
достаточно велика для среднестатистических семей. В связи с чем, логичным развитием
проекта выглядит уменьшение цены и более узкий, но необходимый, функционал.
12
К тому же «ЯЭнергетик» рассчитан на использование предприятиями, офисами,
торговыми центрами и им подобным объектам. Предоставляемый в данной работе ПМ будет
находиться в свободном доступе. К нему лишь предлагается
купить модем, по которому
будет идти передача данных о потреблении энергетических ресурсов в сервер БД. А для
подключения необходимо подключение к сети интернет и авторизация.
1.3 Постановка целей и задач
Существующие
программные
продукты,
осуществляющие
контроль
и
учет
потребления энергетических ресурсов, требуют значительных трат средств, что делает их
применение невыгодным, или же не имеют достаточного и нужного количества
функционала. Из-за этого разработка собственного программного модуля контроля и учета
потребления энергетических ресурсов, является актуальным.
Целью разработки является контроль и учет потребления энергетических ресурсов в
многоквартирных зданиях с возможностью интеллектуального анализа данных на основе
геоинформационных технологий.
Основными задачами являются:
исследование предметной области;
сравнительный анализ существующих аналогичных решений;
определение набора входных и выходных данных;
выбор инструментальных средств и среды разработки;
разработка схемы данных ПМ КУЭР;
разработка схем алгоритмов ПМ КУЭР;
разработка пользовательских интерфейсов;
программная реализация;
отладка и тестирование;
разработка руководства оператора.
1.4 Функциональные требования, предъявляемые к ПМ КУЭР
13
Разрабатываемый программный модуль должен обеспечивать выполнение
следующих функций:
работа в режиме реального времени;
авторизация в качестве администратора или потребителя;
обработку начальных условий на основе входных данных, полученных с сервера;
получение списка домов с квартирами для последующей обработки данных;
совместимость с APIЯндекс.Карт;
отправка данных в заданном формате;
прямая и обратная связь с платежными системами наподобиеApplePay, WebMoney,
ЯндексДеньги;
вывод информации о статусе операций в файл логирования;
немедленный выход из программы в случае отказа системы.
1.5 Концептуальная модель
Одной из первых этапов проектирования системы БД является построение
семантической модели предметной области. Он строится на анализе свойств и
характеристик объектов той сферы, которую мы затрагиваем. Также в ней учитываются
предпочтения будущих пользователей данной разрабатываемой системы. Данную стадию
принято называть концептуальным проектированием системы, результатом которого будет
концептуальная модель [19]. В концептуальной модели объектом моделирования будет
предметная область разрабатываемой системы.
Для описания концептуальной модели ПМ КУЭР используются следующие
инструменты:
ER – диаграмма;
подробное описание сущностей, связей и свойств;
диаграмма
прецедентов
для
иллюстрации
взаимодействия
пользователя
с
разрабатываемой системой;
словесное описание ограничений на значения свойств и число сущностей.
Каждый пункт, описанный выше, несет в себе свои важные задачи. Обоснуем выбор
данных инструментов.
14
В процессе описания концептуальной модели необходимо описать сущности, свойства
и связи между ними. ER- диаграмма с диаграммой прецедентов [21] как нельзя лучше
описывает модель разрабатываемого модуля и наиболее детально иллюстрирует связь между
сущностями. Глядя на рисунок 1.2 и рисунок 1.3, программисту легко будет определиться с
теми классами и объектами, которые ему необходимо реализовать. А благодаря
информативным связям между сущностями, легко перемещаться и искать нужные области в
файлах разработки.
Рисунок 1.2 — ER-диаграмма «сущность-связь»
К диаграмме «сущность-связь» приведем словесное описание каждой из сущностей:
1) Пользователь. Является главной сущностью разрабатываемого модуля. Именно
пользователь задает входные данные и он определяет, каким будет дальнейший
функционал сервиса. Связан с сущностью «Потребляемость» как «один ко
многим». Имеется ввиду, что у Пользователя может быть несколько источников
потребления. С сущностью «Платежи» связан аналогичным образом. Могут быть 2
типа
пользователя:
администратор
и
потребитель.
Главным
отличием
администратора от потребителя является его возможность менять данные в
15
таблице потребления и просмотр данных потребления всего дома, а не только
конкретной квартиры.
2) Потребляемость. Сущность, которая отвечает за генерацию и постоянное
обновление таблицы с потреблением. Необходима для того, чтобы Пользователь
мог считывать данные с этой таблицы.
3) Платежи. Сущность, которая отвечает за генерацию и постоянное обновление
таблицы с платежами за потребление. Необходима для того, чтобы Пользователь
мог в режиме онлайн оплатить услуги. Связан с сущностями «Квитанции»,
«Электронные деньги», «Банковская карта» как «один ко многим», так как
предполагается, что по любому из 3-х видов платежей могут быть несколько
операций платежа.
4) Квитанции. Одна из разновидностей платежа.
5) Электронные деньги. Одна из разновидностей платежа.
6) Банковская карта. Одна из разновидностей платежа.
16
Рисунок 1.3 — Диаграмма прецедентов
Для того, чтобы наглядно можно было увидеть, какие функции доступны при
взаимодействии клиента с системой, была построена диаграмма прецедентов, которую мы
видим выше.
Диаграмму прецедентов также называют диаграммой вариантов использования. На
рисунке 1.3 «Актеры» изображены в виде человечков с надписью, «Прецеденты»
изображены в виде овалов, которые соединены связями с «Актерами». Данную диаграмму
можно считать хорошим дополнением к ER-диаграмме, так как именно здесь мы видим, где
используются сущности и для чего они нужны.
17
1.6 Структура входных и выходных данных
В качестве входных данных должен использоваться запрос на получение данных с
информацией о потреблении энергетических ресурсов в конкретной квартире, если была
произведена авторизация под учетной записью потребителя, или конкретного дома, если
была произведена авторизация под учетной записью администратора, кем может являться
сотрудник ЖКХ или Газпрома.
Входная информация вводится при помощи внешних устройств ввода – клавиатуры и
мыши, путем редактирования базы данных, в которой содержится список квартир и домов.
В качестве выходных данных для ПМ ГИС КУЭР выступает таблица с информацией о
данных авторизованного пользователя (идентификационный номер пользователя, ФИО),
количестве потребленной энергии, которое измеряется в кВт*ч, цене за потребление.
Входные и выходные данные разрабатываемого ПМ ГИС КУЭР должны быть
организованы согласно заданной структуре, изображенной на рисунке 1.4.
Рисунок 1.4 – Схема данных ПМ ГИС КУЭР ГОСТ 19.701-90
1.7 Программная архитектура и алгоритм работы
18
1.7.1 Алгоритм работы ПМ КУЭР
Рассмотрим алгоритм работы [22] программного модуля по учету и контролю
энергетических ресурсов в многоквартирных домах. Работа в ПМ начинается с авторизации.
Есть два способа авторизации: администратор, потребитель. Рассмотрим вариант с
администратором.
На рисунке 1.5 показана схема алгоритма работы ПМ КУЭР при авторизации
администратора.
Рис.1.5 - Схема алгоритма работы ПМ КУЭР (администратор)
В случае успешной аутентификации происходит авторизация пользователя. Откроется
главное окно, в котором администратору предстоит выбрать режим работы. Режимов работы
несколько: регистрация, редактирование, поиск, отчет.
Регистрация предназначена для ввода данных о новом потребителе. В эти данные
входят адрес дома нового участника, его фамилия, имя, отчество, виды оказываемых услуг,
дата заполнения в реестр данных. Администратор может воспользоваться поиском по
данным, где предполагается поиск по ФИО, дате регистрации. Также ему доступна функция
формирования отчета и ее печать.
19
Рассмотрим вариант с авторизацией потребителя. Ниже на рисунке 1.6 показана схема
алгоритма работы ПМ КУЭР при авторизации потребителя.
Рис.1.6 - Схема алгоритма работы ПМ КУЭР (потребитель)
В случае успешной аутентификации происходит авторизация пользователя. Откроется
главное окно, в котором потребителю предстоит выбрать режим работы. Режимов работы
несколько: просмотр, оплата, поиск, отчет.
Просмотр предназначен для наблюдения и отчетности по данным о потреблениях. В
эти данные входят виды оказываемых услуг, период оказания услуг, стоимость. Находясь на
той же странице, можно оплатить услуги, выбрав соответствующую кнопку в строке с
потреблением.
Потребитель
может
воспользоваться
поиском
по
данным,
где
предполагается поиск по виду услуги и дате регистрации. Также ему доступна функция
формирования отчета и ее печать.
Далее предполагается внесение измененных данных в базу данных, сохранение и
выход из сервиса. Либо можно вернуться на этап выбора режима работы и продолжить
пользование.
20
1.7.2 Программная архитектура
ПМ КУЭР
Архитектурой программной системы является ее организационная структура, которая
показывает модули, которые включены в данную систему, а также их связи между собой.
Архитектура разрабатываемого программного модуля должна быть построена согласно
рисунку 1.7. Предполагается, что будет реализован модуль, который будет связывать
пользовательский интерфейс и СУБД MySQLпри помощи паттерна MVC (model-viewcontroller).
Рисунок 1.7 Структурная схема ПМ КУЭР
1.7.3 Требования к надежности
Разрабатываемый ПМ для контроля и учета потребления энергетических ресурсов.
Данные, полученные и проанализированные модулем, попадают в базу данных MySQL. В
связи с этим возникает потребность написания требований к надежности передачи,
хранения, извлечения из СУБДMySQL.
21
Для обеспечения надежности в работе программы должно быть предусмотрено
следующее:
разрабатываемое ПО должно поддерживать возможность отладки, изменения
функциональности и реконфигурации без остановки его работы;
модули
разрабатываемого
ПО
должны
быть
снабжены
наборами
автоматизированных тестов, обеспечивающих полное покрытие исходного кода
самих компонентов, а также проверку необходимой функциональности
используемого стороннего ПО;
возможность повторного ввода входных данных при неправильном вводе на
этапе авторизации;
при
обрыве
сети,
вывести на экран
соответствующее
сообщение
и
заблокировать окно;
при неудачной попытке подключиться к базе данных, пытаться подключиться
заново;
1.8
при сбое в системе элетроснабжения, делать откат к изначальному состоянию.
Требования к информационной и программной совместимости
Информационное и программное взаимодействие между программным модулем
контроля
и
учета
энергетических
ресурсов
и
пользовательским
интерфейсом
осуществляется через базу данных. Для обеспечения информационной совместимости
должны быть разработаны модели, в которых описаны классы. Для правильной работы
модулей, должны быть описаны контроллеры, в которых хранятся методы.
Программный модуль должен работать под управлением операционных систем
Windows 7 и выше, Ubuntu 14 и выше. Обязательно наличие подключения к сети Ethernet.
Пользовательский интерфейс должен быть интуитивно понятным и простым. Должен
содержать всплывающие подсказки.
Среда разработки - JetBrainsPhpStorm 2016.2.1(64).
Среда интеграционного тестирования - SeleniumWebDriver.
22
Выводы по разделу
В исследовательском разделе был проведен анализ предметной области. Были
изучены аналоги разрабатываемого программного модуля, выявлены их лучшие стороны и
худшие. Был проведен сравнительный анализ. Также были поставлены цели и задачи,
построена концептуальная модель модуля. Были разработаны схема алгоритма работы и
схема данных, используемых в ПМ КУЭР. Поставлены требования к надежности, к
информационной и программной совместимости.
23
2 КОНСТРУКТОРСКИЙ РАЗДЕЛ
2.1
Выбор языка программирования
Для выбора языка программирования [23] было проведено исследование, которое
показало, какой язык более точно подходит по требованиям для реализации ПМ КУЭР.
Критериями выбора были:
подход объектно-ориентированного программирования;
автоматическое управление памятью;
динамическая типизация;
интегрирование с различными СУБД.
распространенность языка
По результатам исследования были отобраны языки программирования, которые
представлены в таблице 2.1.
Таблица 2.1 – Сравнительный анализ языков программирования для решения задачи
Критерий
C++ [1]
Java [2]
управление
-
+
памятью
Поддержка
-
C#
Ruby(RoR)
PHP [4]
Python [5]
+
+
+
+
-
-
+
+
+
+
+
+
+
-
+
приятного
-
-
-
+
+
+
интерфейса
Поддержка
+
+
+
-
+
+
1 года
2 года
Нет
1 год
1 год
2 года
[3]
[6]
Автоматическое
браузерами
Популярность
Разработка
многопоточности
Опыт работы
24
Источники информации:
Условные обозначения:
[1] https://ru.wikipedia.org/wiki/C++
[1] https://msdn.microsoft.com/ru-ru/library/hh875062.aspx
[2] http://www.oracle.com/technetwork/java/index.html
[2] https://ru.wikipedia.org/wiki/Java
[3] http://msdn.microsoft.com/ru-ru/vcsharp/default.aspx
[3] https://ru.wikipedia.org/wiki/C_sharp
+ - указанная возможность
присутствует;
- - указанная возможность
отсутствует;
± - указанная возможность
присутствует не полностью.
[4] https://ru.wikipedia.org/wiki/PHP
[5] https://habrahabr.ru/post/149420/
[6] http://railstutorial.ru/chapters/
Рассмотрев детально таблицу 2.1, можно сделать вывод, что наиболее подходящими
языками являются: Ruby и PHP. Rubyимеет следующие преимущества по сравнению с
приведенными выше языками, такие как:
открытая разработка;
работает на многих платформах;
может внедряться в HTML-разметку;
относится к языкам программирования сверхвысокого уровня (VHLL), то есть
обладает высоким уровнем абстракции и предметным подходом в реализации
алгоритмов;
реализует концептуально чистую объектно-ориентированную парадигму;
предоставляет продвинутые методы манипуляции строками и текстом;
легко интегрирует в свои программы высокопроизводительные серверы баз данных
(DB2, MySQL, Oracle и Sybase);
благодаря VHLL программы на Ruby хорошо масштабируются и легко
сопровождаются;
25
простой и чистый синтаксис значительно облегчает программистам первые шаги в
обучении этому языку;
имеется простой программный интерфейс для создания многопоточных приложений;
имеет продвинутые средства для работы с массивами;
возможности языка можно расширить при помощи библиотек, написанных
на C или Ruby;
зарезервированные слова могут являться идентификаторами, если это не создаёт
неоднозначности для парсера;
дополнительные возможности для обеспечения безопасности;
встроенный отладчик.
2.2
Выбор среды разработки
Существует несколько сред разработки для языка Ruby. Среди которых: JetBrains
PhpStorm [25], IntelliJ IDEA Community Edition [26], Sublime Text [27], Rubymine [28].
Главными критериями выбора среды разработки должны быть:
отладка и диагностика;
средства тестирования;
интегрированная среда разработки;
удобный и простой интерфейс, к которому быстро и легко привыкнуть.
Результаты
сравнения
JetBrains
PhpStorm
с
другими
средами
разработки,
представлены в таблице 2.2. Сравнительный анализ сред разработки для решения задачи.
По сравнению с конкурентами JetBrains PhpStorm выделяется следующими
характеристиками:
система управления версиями, позволяет быстро и легко выкладывать свой код в
систему контроля версий, что делает разработку намного быстрее;
встроенный фреймворк для тестирования PHPUnit;
26
Таблица 2.2 – Сравнительный анализ сред разработки для решения задачи
IntelliJ IDEA
Критерий
JetBrainsPhpStorm[1]
Стоимость
Бесплатно
Бесплатно
Бесплатно
Подсветка кода
+
+
+
+
-
-
+
+
-
-
-
+
+
+
+
Встроенное
подключение к Git
Community Edition [2]
SublimeText [3]
Управление
процессами
разработки
Простота в
разворачивании
проекта
Обзор инструментов
рефакторинга
Источники информации:
Условные обозначения:
[1] https://www.jetbrains.com/phpstorm/
+ - указанная возможность
[2] https://www.jetbrains.com/idea/
присутствует;
[3] https://www.sublimetext.com/3
- - указанная возможность
отсутствует;
2.3
Программная реализация
28
При разработке ПМ КУЭР использовался объектно-ориентированный подход.
Объектно-ориентированное программирование (ООП) – методика разработки программ,
использующая в качестве основы понятие объекта как некоторой структуры, позволяющей
описать его как объект реального мира и его поведение. Программа представляется в виде
совокупности объектов и связей между ними.
Действие
в
объектно-ориентированном
программировании
инициируется
посредством передачи сообщений объекту, ответственному за действие. Сообщение
содержит
запрос
на
осуществление
действия
и
сопровождается
дополнительной
информацией (аргументами), необходимой для его выполнения. Получатель — это объект,
которому посылается сообщение. Если он принимает сообщение, то на него автоматически
возлагается ответственность за выполнение указанного действия. В качестве реакции на
сообщение получатель запустит некоторый метод (функцию), чтобы удовлетворить
принятый запрос.
Класс
Объект
События
Свойства
Методы
Рисунок 2.2 – Концепция ООП
Совокупность объектов,
обладающих
одинаковыми
методами
и
свойствами,
объединяют в класс. Все объекты являются представителями, или экземплярами, классов.
Метод, вызываемый объектом в ответ на сообщение, определяется классом, к которому
принадлежит получатель сообщения. Все объекты одного класса используют одни и те же
методы в ответ на одинаковые сообщения.
29
Объекты при их работе могут генерировать и обрабатывать события. События важны
тем, что позволяют выполнять определенные действия в других частях кода. С помощью
событий можно создавать управляемые событиями приложения, которые гораздо более
полезны, чем может показаться поначалу. Достаточно вспомнить, что, например, все Webприложения полностью зависят от событий. Каждый щелчок пользователя на кнопке или
перетаскивание ползунка на полосе прокрутки выполняется с помощью обработки событий,
генерируемых мышью или клавиатурой.
В основе ООП лежат три главных принципа:
Инкапсуляция – защита данных от неправильного использования. Представляет
собой разработку класса, чтобы скрыть от конечного пользователя внутреннее содержание
класса (методы и свойства).
Абстракция – представление объекта в виде некоторой урезанной до предметной
области модели.
Полиморфизм – использование единого интерфейса для решения целого класса
задач. Достаточно спроектировать базовый класс, реализовать методы для него, и эти
методы будут применимы к классам-потомкам.
Наследование – использование дочерним классом методов и свойств родителя.
Можно создать новый класс, использующий в качестве основы существующий. В новом
классе могут быть переопределены старые методы или созданы новые. Этот принцип
позволяет создавать иерархию классов.
Преимущества ООП:
Многоразовое использование одного и того же программного кода. Такой код
содержит гораздо меньше ошибок, чем вновь написанный.
Следование принципам ООП позволяет строить из простых объектов более
сложные, что обеспечивает высокую масштабируемость.
Данные локализованы внутри классов, что позволяет независимо разрабатывать
отдельные модули (объекты) программы.
Объектно-ориентированное проектирование – это методология проектирования,
соединяющая в себе процесс объектной декомпозиции и приемы представления логической
и физической моделей. Определение включает в себя две ключевые части: объектно30
ориентированное проектирование, во-первых, основывается на объектно-ориентированной
декомпозиции и, во-вторых, использует многообразие приемов представления моделей,
отражающих логическую (классы и объекты) и физическую (модули и процессы) структуру
системы, а также ее статические и динамические аспекты.
Рисунок 2.3 – Представление основных модулей в виде классов
Объектно-ориентированное проектирование итеративный процесс, состоящий из
циклического выполнения 4 основных шагов:
определение объектов и классов на определенном уровне абстракции;
определение состава и назначения методов класса;
идентификация связей между объектами и классами;
реализация классов;
На каждой итерации уточняются описания классов и перерабатываются проектные
документы.
UML— это "язык для определения, визуализации и конструирования артефактов
программных систем". Это система обозначений (включая семантику), предназначенная для
моделирования систем на основе объектно-ориентированного подхода.
Диаграмма UML — это графическое представление набора элементов, изображаемое
чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями).
31
Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма в
некотором смысле одна из проекций системы. Как правило, за исключением наиболее
тривиальных случаев, диаграммы дают свернутое представление элементов, из которых
составлена система. В UML выделяют девять основных типов диаграмм:
диаграмма классов предназначена для отображения классов разрабатываемого
приложения и их взаимосвязей;
диаграмма объектов предназначена для представления объектов и отношений
между ними;
диаграмма
проектируемой
прецедентов
системы
с
предназначена
любыми
внешними
для
или
описания
взаимодействия
внутренними
объектами
-
пользователями, другими системами и т.п.;
диаграмма
последовательности
последовательностей
действий
в
служит
процессе
основным
выполнения
способом
того
или
расшифровки
иного
варианта
использования;
диаграмма
кооперации позволяет показать взаимодействие и подчеркнуть
структурную организацию объектов, посылающих и принимающих сообщения;
диаграмма состояний применяется для иллюстрации того, как какой-либо один
элемент переходит между различными своими состояниями;
диаграмма
действий иллюстрирует переходы потока управления от одной
деятельности к другой внутри системы;
диаграмма компонентов показывают, как выглядит модель на физическом уровне;
диаграмма
развертывания
предназначена
для
представления
конфигурации
обрабатывающих узлов системы и размещенных в них компонентов.
Одним из наиболее важных приемов объектно-ориентированного проектирования
является использование паттернов. Паттерн – независимая от выбора языка стратегия
решения
проблем
при
разработке
средствами
программирования.
32
объектно-ориентированного
Паттерны проектирования [33] позволяют разными способами решать многие задачи
проектирования, с которыми приходится постоянно сталкиваться проектировщикам
объектно-ориентированных систем.
По назначению выделяют три группы паттернов:
Порождающие. Во-первых, эти паттерны инкапсулируют знания о конкретных
классах, которые применяются в системе. Во-вторых, скрывают детали того, как эти классы
создаются и стыкуются. Единственная информация об объектах, известная системе, - это их
интерфейсы, определенные с помощью абстрактных классов. Следовательно, порождающие
паттерны обеспечивают большую гибкость при решении вопроса о том, что создается, кто
это создает, как и когда.
Структурные. В структурных паттернах рассматривается вопрос о том, как из
классов и объектов образуются более крупные структуры. Структурные паттерны уровня
класса используют наследование для составления композиций из интерфейсов и реализаций.
Вместо композиции интерфейсов или реализаций структурные паттерны уровня объекта
компонуют объекты для получения новой функциональности.
Поведенческие. Паттерны поведения связаны с алгоритмами и распределением
обязанностей между объектами. Речь в них идет не только о самих объектах и классах, но и
о типичных способах взаимодействия. Паттерны поведения характеризуют сложный поток
управления, который трудно проследить во время выполнения программы. Внимание
акцентировано не на потоке управления как таковом, а на связях между объектами.
33
ПаттернMVС
Первые упоминания о паттерне MVC (model-view-controller) [29] появились примерно
в 80-х годах. Он задумывался как способ организации приложений графического
пользовательского интерфейса проекта Smalltalkв компании Xerox. С тех пор MVC играет
важную роль в построении пользовательских интерфейсов.
Этот
паттерн
разделяет
работу
программного
модуля
на
три
основные
функциональные части: модель данных (model), пользовательский интерфейс (view) и
контроллер (controller). Таким образом можно сказать, что, внося изменения в одну из
составляющих паттерна, меняем частично другие части. На рисунке 2.4 подробно показан
алгоритм работы паттерна MVC.
Рисунок 2.4 – Реализация паттерна MVVM
34
Рассмотрим более подробно каждую из этих составляющих частей:
Модель данных (model)
ActiveRecord – это модель в RoR. Модель хранит данные и предоставляет базу для
работы с данными. Кроме этого ActiveRecord также является ORM фрэймворком. ORM
значит
Object-relationalmapping
(Объектно-реляционная
проекция).
Функционал
ActiveRecord выглядит следующим образом:
1) Проекция таблицы на класс. Каждая таблица проецируется на один или несколько
классов по принципу convention over configuration (соглашение выше конфигурации). Одно
из таких соглашений – имя таблицы должно быть во множественном числе, а название
класса – в единственном. Атрибуты таблицы налету проецируются в атрибуты экземпляра
Ruby. После того, как все проекции сделаны, каждый объект ORM класса представляет
определенную строку таблицы, с которой класс был спроецирован.
2) Соединение
с БД. Можно подключиться к базе данных, используя API,
предоставляемый ActiveRecord, который создает необходимый запрос непосредственно в
движок БД при помощи адаптеров. У Active Record есть адаптеры для MySQL, Postgres, MS
SQLServer, DB2, и SQLite. Необходимо лишь записать параметры доступа к БД в файле
database.yml.
3) Операции CRUD. Это операции create (создание), retrieve (получение), update
(обновление) и delete (удаление) над таблицей. Так как ActiveRecord – это ORM фрэймворк,
работать приходится всегда с объектами. Чтобы создать новую строку таблицы, необходимо
создать новый объект класса и заполнить его переменные экземпляра значениями. Стоит
заметить, что все это ActiveRecord делает автоматически.
4) Проверка данных. Проверка данных перед помещением их в таблицу – это первый
шаг в безопасности проекта. ActiveRecord предоставляет проверку модели. Данные могут
быть проверены автоматически с помощью множества готовых методов, которые, в случае
необходимости, можно переписать.
Представления (view)
ActionView - включает в себя логику, необходимую для вывода данных модели. Роль
представления в RoR играет ActionView. Наиболее часто используемые функции
ActionView:
35
1) Шаблоны (templates).
Шаблоны
–
это
файлы,
содержащие
заполнители
(placeholders), которые буду заменены на контент. Шаблоны могут содержать HTML-код и
код Ruby, встраиваемый в HTML с использованием синтакса встроенного (embedded) Ruby
(ERb).
2) Помощники (helper) форм
и форматирования.
Помощники
форм
позволяют
создавать такие элементы страниц, как чекбоксы, списки, используя готовые методы. В свою
очередь помощники форматирования позволяют форматировать данные необходимым
способом, методы существуют для дат, валют и строк.
3) Макет. Макеты (layouts) определяют, как контент будет расположен на странице.
Динамически создаваемая страница может содержать вложение из нескольких страниц, даже
без использования таблиц и фрэймов, используя API Макета.
Контроллеры (controller)
ActionController. В веб-приложении Контроллер регулирует поток логики приложения.
Он находится на границе программы, перехватывая все запросы, на основе которых он
изменяет какой-то объект модели и вызывает представление, чтобы отобразить обновленные
данные. В RoR ActionController выполняет следующие функции:
1) Поддержка сессий. Сессия – это период времени, проведенный пользователем на
сайте. Его можно отследить с помощью cookie или объекта сессии. Cookie – небольшой
файл, он не может содержать объекты, в отличие от объекта сессии.
2) Фильтрация. Бывают ситуации, когда необходимо вызвать определенный код, перед
тем как исполнять логику контроллера или после него, например, аутентификация
пользователей, логирование событий, предоставление персонального ответа. Помогают в
таких случаях фильтры, предоставляемые ActionController. Существуют три основных
фильтра: before, after и around.
3) Кэширование. Кэширование – это процесс, при котором наиболее запрашиваемый
контент сохраняется в кэше, чтобы не было необходимости запрашивать его вновь и вновь.
RoR поощряет использование отдельных сред для каждого из этапов цикла жизни
приложения: разработка (development), тестирование (testing) и эксплуатация (production),
для каждого из которых создается отдельная БД. Рассмотрим каждую среду.
36
1) Development. В среде разработки ставка делается на немедленное отображение
нового варианта при изменении кода – достаточно обновить страницу в браузере. Скорость в
этой среде не важна. Когда случается ошибка, она выводится на экран.
2) Test. При тестировании каждый раз наполняется БД каким-нибудь текстом, для того
чтобы убедиться, что нормальное поведение не зависит от содержания БД. Процедуры
юнит-тестинга и теста функциональности в RoR автоматизированы и производятся через
консоль. Тестовая среда предоставляет отдельное пространство, в которых оперируют эти
процедуры.
3) Production. В конце концов приложение выходит к финальной черте, пройдя тесты
и избавившись от багов. Теперь обновления кода будут происходить редко и можно
сконцентрироваться на производительности, включить кэширование. Нет необходимости
писать огромные логи ошибок и пугать пользователей сообщениями об этих ошибках в
браузере. Для этого существует среда production.
Преимущества MVС
Ниже приведены преимущества использования данного паттерна:
Тестируемость MVС-приложений. Приложения, разработанные с использованием
MVС, обладают очень хорошим основанием для проведения модульного тестирования
с целью проверки работы отдельных классов и методов.
1) Меньшее
количество
кода.
Объем
кода,
необходимого
для
управления
представлением немного снижается при использовании MVС, а это означает, что снижается
риск допустить ошибки и уменьшается код для написания модульных тестов.
2) Улучшенное проектирование приложений. Разработчики и дизайнеры могут
самостоятельно работать над разными частями приложения. Как вы видели на примере,
представление генерируется в XAML - разметке и использует базовый синтаксис привязок и
команд, для взаимодействия с модель-представлением. Вы можете создать модельпредставление, которое предоставляет необходимые точки входа для связывания с
представлением (например, общедоступные свойства), которые в конечном представлении
можно будет легко привязать. Это позволяет дизайнерам работать над внешним видом
приложения, а программистам над бизнес-логикой приложения.
3) Легкость
понимания логики представления. MVС предусматривает хорошо
организованную и легкую для понимания конструкцию построения графического
интерфейса за счет использования механизмов привязок, команд и шаблонов данных.
37
2.4 Работа с базами данных
Для создания практически любой системы, модуля или приложения, где применяется
хранение данных, используются базы данных. Управление ложится на различные СУБД,
среди которых можно выделить самые популярные: MsSQL, Oracle, MySQL, PostgreSQL.
Что же из себя представляет база данных? База данных – это специальное хранилище для
разных типов данных. Она может быть реляционной, документно-ориентированной [31].
Мы рассмотрим реляционную систему управления базами данных PostgreSQL. Именно его
мы будем использовать в ПМ КУЭР для взаимодействия с базой данных [32]. Связь
программного модуля с БД, к которому идет обращение, происходит при помощи
специальных запросов.
PostgreSQL
на
данный
момент
является
самым
мощным
и
свободно
распространенным СУБД из всех вышеописанных. Отличием ее является объектноориентированный подход к базам данных [30]. Она отличается своей полной поддержкой
надежных транзакций: атомарность, последовательность, изоляционность, прочность.
PostgreSQL довольно популярна среди веб-приложений, так как старается максимально
точно соответствовать SQLстандарты ANSI/ISO.
На рисунке 2.5 показан файл базы данных в Ruby on Rails.
Рисунок 2.5 – Файл базы данных
38
Преимущества PostgreSQL:
Открытое ПО соответствующее стандарту SQL - PostgreSQL - бесплатное ПО с
открытым исходным кодом. Эта СУБД является очень мощной системой.
Большое сообщество - существует довольно большое сообщество, в котором вы
запросто найдёте ответы на свои вопросы.
Большое количество дополнений - несмотря на огромное количество
встроенных функций, существует очень много дополнений, позволяющих
разрабатывать данные для этой СУБД и управлять ими.
Расширения - существует возможность расширения функционала за счет
сохранения своих процедур.
Объектность - PostrgreSQL это не только реляционная СУБД, но также и
объектно-ориентированная с поддержкой наследования и много другого.
При проектировании программного модуля принимались во внимание следующие
требования к базе данных.
2.4.1 Требования к размерности БД
БД должны удовлетворять следующим требованиям по размерности:
максимальный размер БД – не ограничен;
максимальное количество записей (строк) в таблице – не ограничено;
максимальное количество полей (колонок) в таблице – не менее 3;
максимальное количество индексов на таблицу – не ограничено.
2.4.2 Требования к поддерживаемым типам данных.
БД должны поддерживать числовые типы данных:
дробное с фиксированной точкой;
39
дробное с плавающей точкой;
целое;
денежное.
БД должны поддерживать символьные типы данных:
строка переменной длины с ограничением;
строка фиксированной длины;
строка переменной неограниченной длины.
БД должны поддерживать типы данных даты и времени в формате:
дата и время;
дата и время с часовым поясом;
интервал времени;
только дата;
только время.
БД должны поддерживать логические типы данных: true или false.
БД должны поддерживать XML типы данных.
2.5 Разработка пользовательского интерфейса
Пользовательский
интерфейс
был
разработан
в
среде
JetBrainsPhpStorm,
обеспечивающая простоту взаимодействия программиста с экранными формами.
Экранные формы спроектированы с учетом требований унификации:
все экранные формы пользовательского интерфейса выполнены в едином
графическом дизайне, с одинаковым расположением основных элементов
управления и навигации;
для обозначения сходных операций используются сходные графические значки,
кнопки и другие управляющие (навигационные) элементы;
внешнее поведение сходных элементов интерфейса (реакция на наведение
указателя «мыши», переключение фокуса, нажатие кнопки) реализовываются
одинаково для однотипных элементов.
Ввод-вывод данных системы, прием управляющих команд и отображение результатов
40
их исполнения должны выполняются в интерактивном режиме. При ошибке ввода-вывода
данных на экране выводится сообщение об ошибке.
Основная форма состоит из полей ввода-вывода данных и управляющих кнопок. На
рисунок 2.5 представлена одна из основных форм, отвечающая за получение входных
данных от пользователя.
Рисунок 2.6 – Форма авторизации
Форма содержит поля для входных данных, отметку, для сохранения введенных
данных, управляющую кнопку «Подключиться».
Кнопка «Подключиться» запускает процесс сбора и анализа данных о пользователе,
который ввел корректные данные.
При успешной авторизации произойдет переход на основную форму. Далее
появляется возможность получения выходных данных. При нажатии
на
«Подключиться» в форме авторизации появится форма, приведенная на рисунке 2.6.
41
кнопку
Рисунок 2.6 – Основная форма с данными
Выводы по разделу
В данном разделе были рассмотрены вопросы разработки ПМ КУЭР с описанием
используемых методов программирования. Был проведен тщательный анализ и выбор языка
программирования, а также среды разработки. Описана программная реализация, паттерн,
который использован при разработке программного модуля. Была выбрана СУБД,
предъявлены требования к базам данных по нескольким критериям.
Был разработан пользовательский интерфейс, который представлен несколькими
формами.
42
3
ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ
3.1
Средства и методы отладки ПМ КУЭР
Реализация программного модуля включает в себя процесс тестирования [37] и
отладки. Отладка включает в себя поиск, обнаружение и исправление ошибок в
разрабатываемом программном модуле [41]. Поиск и обнаружение ошибок в большей
степени относится к тестированию, когда необходимо прогнать всевозможные сценарии
использования разрабатываемого продукта. Найденные ошибки и дефекты, как в
программной части, так и в пользовательском интерфейсе, заносятся в баг-трекинговую
систему. После того, как все сценарии будут прогнаны по тест-кейсам, начинается процесс
отладки.
В процессе разработки программного обеспечения были использованы следующие
методы отладки:
запуск
программы
отладчиком
(требуется
для
просмотра
состояний
переменных, объектов, памяти и т.д.);
логирование кода (вывод в отдельный файл или на консоль входных, выходных
данных, промежуточных значений; необходим для выявления места отказа
программы в случае проблем с воспроизведением деффекта);
профилирование (поиск дыр в памяти и скорости работы программного
модуля).
В языке Ruby существует встроенный отладчик. Вызывается с помощью гема
“debugger”: $geminstalldebugger. После этого данный встроенный отладчик можно вызывать.
Как только он вызывается, будет запущен в среде отладчика в окне терминала.
Лог
в
переводе с английского значит журнал событий. Лог-файл – это специальный отдельно
созданный файл, который необходим для фиксирования событий, вызванных запросами
пользователей, либо запросами между собой отдельными моделями и контроллерами. В
языке RubyonRails по умолчанию создается файл логирования, который находится по пути
root/log/. На данный момент существует 5 уровней логирования:
debug (стоит по умолчанию во всех средах, уровень 0);
info (уровень 1);
43
warn (уровень 2);
error (уровень 3);
fatal (уровень 4);
unknown (уровень 5).
Данные уровни можно задавать вручную, менять в ходе разработки, удалять[44].Для
написания в текущий лог, используется метод logger.(debug|info|warn|error|fatal|unknown).
На рисунке 3.1 представлен фрагмент из файла логирования для среды development.
Рисунок 3.1 – Файл логирования для среды development
Вторым способом отладки является использование гема “byebug”. Большим плюсом
его использования является возможность настроек точки остановы и прохождения через
весь написанный разработчиком код. Для работы с ним, необходимо его перед этим
установить командой $geminstallbyebug.
Профилирование
–
получение
информации
о
характеристиках
выполнения
программы. Сюда входит время выполнения SQL-запросов, время реагирования на
пользовательский запрос, стек вызовов методов. Для профилирования в Rubyиспользуется
44
гем rack-mini-profilerв паре с гемом flamegraph. Flamegraph необходим для создания
графического представления результатов профилирования гем аrack-mini-profiler.
Для
корректной
работы
гемы
необходимо
поместить
в
Gemfileв
developmentокружение. Затем добавить файл инициализации в /config/initializer/. На
необходимой странице вызвать GET-метод с параметром ?pp=flamegraph. Пример работы
связки гемов rack-mini-profiler и flamegraph представлен на рисунке 3.2.
Рисунок 3.2 – Файл логирования для среды development
Здесь описаны методы и классы, которые используются профилировщиком.
В рамках разработки ПМ КУЭР отладка производилась при помощи специальных
гемов, используемых в Ruby on Rails, которые отлично взаимодействуют со средой
разработки JetBrainsPhpStorm.
Одним из популярных и часто используемых разработчиками методам отладки
является отладка с помощью точек останова. Они ставятся в местах, где предполагается
появление ошибки, для того, чтобы проконтролировать этот участок кода. В PhpStorm точки
останова присваиваются конкретным строкам кода. Они срабатывают тогда, когда
выполнение программы достигает того участка кода, где их поставили. В среде разработки
45
их легко отличить красной точкой в левой части окна с кодом и закрашенной красной
строкой [45].
У точек остановка бывает несколько состояний, которые описаны в таблице 3.1.
Таблица 3.1 – Состояния точек останова в PhpStorm
Не стоит забывать про стек вызовов, который показывает нам, как и в каком порядке
вызывались методы в программе. Это позволяет определить, как поэтапно менялись
сущности разрабатываемого программного модуля. Для работы со стеком вызовов
использовался RubyMine, который показан на рисунке 3.3.В нем описан каждый метод,
который вызывался. Показан контроллер, которому принадлежат методы.
Рисунок 3.3 – Debugger дляRuby on Rails
3.2
Проведение тестирования
46
Тестирование разрабатываемого программного модуля начинается с этапа его
разработки. Предоставляются начальные спецификации, после этого пишется тест план и
подготавливаются
всевозможные
тест-кейсы.
Дается
оценка
по
необходимости
использования автоматизированного тестирования[46].
3.2.1
Анализ методов и средств тестирования
В рамках выполнения поставленной задачи были рассмотрены и изучены следующие
методы тестирования:
a. По объекту тестирования
1. Функциональное тестирование
2. Нагрузочное тестирование
3. Тестирование производительности
b. По знанию системы
1. Тестирование методом черного ящика
2. Тестирование методом белого ящика
3. Тестирование методом серого ящика
c. По степени автоматизации
1. Ручное тестирование
2. Автоматизированное тестирование
3. Модульное тестирование
4. Интеграционное тестирование
5. Системное тестирование
d. По признаку позитивности сценариев
1. Позитивное тестирование
2. Негативное тестирование
e. По степени подготовленности к тестированию
1. Тестирование по документации
2. Интуитивное тестирование
47
В процессе разработки было принято решение о проведении следующих видов
тестирования: функционального [47], нагрузочного [48], тестирования производительности
[49], системное[50].
Функциональное тестирование является одним из основных видов тестирования,
который включает в себя соответствие функционала разрабатываемого программного
обеспечения с функциональными требованиями заказчика. Оно позволяет проверить
возможность программного модуля выполнять задачи, поставленные и предъявляемые
пользователями.
Принято выделять два типа функциональных испытаний:
тестирование без доступа к внутреннему коду программного модуля;
тестирование с доступом к внутреннему коду программного модуля.
Тестирование без доступа к внутреннему коду программного модуля означает, что у
специалиста по тестированию разрабатываемого программного модуля нет знаний в области
программирования, и он не понимает, как устроен внутренний механизм и алгоритм работы
программы. Данное тестирование принято называть тестированием черного ящика.
Тестирование с доступом к внутреннему коду программного модуля означает, что у
специалиста по тестированию разрабатываемого программного модуля есть знания в
области программирования, и он понимает, как устроен внутренний механизм и алгоритм
работы программы. Данное тестирование принято называть тестированием белого ящика.
Преимуществами функционального тестирования являются его полное имитирование
фактического использования программы, своевременное выявление системных ошибок в
программном модуле и экономии на раннем этапе жизненного цикла ПМ за счет обработки
ошибок.
Разрабатываемое программное обеспечение должно без сбоев и ошибок работать под
нагрузкой в течение длительного времени. Это является главным критерием нагрузочного
тестирования. Сбои, ошибки в программном модуле могут привести к непредвиденным
затратам, а это в свою очередь влечет за собой потерю клиентов. Клиенты, как правило, не
хотят долго ждать и упираются в те временные рамки, которые указаны в техническом
задании. Посредством нагрузочного тестирования указывается и дается оценка по
производительности разрабатываемого ПМ. Рекомендуется проводить данный этап
тестирования при выпуске новых обновлений системы, при подготовке стендов.
48
Преимуществами
нагрузочного
тестирования
являются
оценка
максимальной
производительности программного модуля, его возможности, выявление ошибок в числе
которых фигурирует утечка памяти, распределение ресурсов и поиск оптимального
комплекса технических средств. От всех прочих видов тестирования, нагрузочное
отличается своей сложностью, который включает в себя трудоемкую и затратную
аналитическую работу.
Тестирование производительности входит в этап нагрузочного тестирования, но стоит
обратить на него особое внимание. Оно дает определить интенсивности операций
пользователя в заданный интервал времени. Тестирование производительности необходимо
проводить до выхода новой версии продукта, дабы избежать проблем недопонимания с
заказчиком. К основным задачам тестирования относится выявления максимальной
интенсивности операций с необходимым качеством выполнения и фиксирование точки
максимальной производительности модуля, при выходе за рамки которого начинается
ухудшение
показателей
работы
ПМ.
Ключевыми
преимуществами
тестирования
производительности является выявление и предотвращение ошибок в системе на этапе
сдачи во внедрение, определение максимально возможных пользователей, которые работают
с данным сервисом одновременно, и определение максимального количества выполняемых
операций.
Системное тестирование необходимо для тестирования готового программного
обеспечения в том его виде, в котором продукт будет представлен заказчику. Данный этап
тестирования
проводится
после
регрессионного,
интеграционного,
модульного
тестирований. Системное тестирование показывает позволяет обнаруживать дефекты,
связанные
с
несуществующим
функционалом,
некорректной
работой
функций
и
возникновение ошибок при связывании с другими системами. В задачи системного
тестирования входят:
подготовка тестовых сценариев, для каждого сценария пишется отдельный
тест-кейс;
создание плана тестирования и описание методик испытаний;
определение тестовых данных;
непосредственно тестирование по тестовым данным.
49
Ключевыми преимуществами данного вида тестирования являются уменьшение числа
дефектов в процессе эксплуатации сервиса, возможность использования тестовых сценариев
для будущих пользователей в качестве обучающего материала, выявление ошибок при
настройке стендов, что упрощает работу администраторам сервиса и потенциальным
пользователям.
В Railsимеются встроенные, готовые к использованию средства тестирования.
Система тестирования очень гибкая: можно получить воспроизводимые настройки БД,
отправлять веб-страницам тестовые http-сообщения и выполнять несколько видов
тестирования.
Для проведения тестирования были использованы следующие средства тестирования:
1)
Test::Unit. Используется для модульного и функционального тестирования.
Набор используемых тестов описывается в виде классов. На рисунке 3.4 показаны примеры
со всеми возможными исходами unit-тестов.
Рисунок 3.4 – Использование Test::Unit
2)
RSpec. Средство для описания спецификаций поведения кода. Большим плюсом
использования RSpec является его удобочитаемость. Код, написанный в RSpec может
прочитать и понять любой человек с техническим образованием, знающий английский язык.
50
Ниже, на рисунке 3.5 будет показан пример тест-файла RSpec. У данного вида тестирования
присутствует возможность организовывать сценарии в группы.
Рисунок 3.5 – Использование RSpec тестов
3)
Cucumber. Используется для интеграционного тестирования. Является самым
понятным для простого пользователя инструментом тестирования. Основой написания
тестов на Cucumberявляется написание тест-сценариев. Тест-сценарием принято называть
последовательность действий пользователя и получение в конечном итоге нужного
результата. Плюсами данного подхода являются: при написании тестов проявляется
ненадобность в логировании, человеко-понятный текст тестов, не нужно описывать шаги
при нахождении багов. На рисунке 3.6 показан небольшой тест-файл написания сценария
для Cucumber.
51
Рисунок 3.6 – Использование Cucumber тестов
3.2.2
Процесс составления тест-кейсов для проведения тестирования ПМ КУЭР
Тест-кейсом принято считать документ или набор шагов, в процессе которых будут
достигнуты ожидаемые результаты, которые так же описаны в тест-кейсе. Кейсы
необходимы для пользователей, которые впервые работают с данным сервисом или
системой. Прочитав необходимый тест-кейс, можно ознакомиться с функционалом, не
изучая подробно полную документацию по продукту. Наиболее распространенными
вариантами написания тест-кейсов являются:
написание на этапе обсуждения конкретного функционала или работы всего
модуля в целом;
написание после сдачи в релиз готовой версии продукта.
Написание на этапе обсуждения функционала представляет из себя подготовку всей
необходимой информации во время обсуждения будущего функционала на собрании
разработчиков и тестировщиков. Оговариваются все детали функционала, пользовательский
интерфейс и другие области разработки, которые затрагивает новый функционал. В этом
случае тест-кейсы пишутся для разработчиков, которые будут разрабатывать новый
функционал исходя из кейсов, и самих тестировщиков, которые будут проверять новый
функционал после сдачи новой версии продукта разработчиками.
Написание после сдачи в релиз производится после выпуска готовой продукции на
этапе сдачи его заказчикам. В этом случае тест-кейсы пишутся как для самих
52
тестировщиков, так и для заказчиков, если будет предъявлено требование по разработке
тест-кейсов.
Удобной средой разработки тест-кейсов является TFS (Team foundation server).
Открыв файл для тест-кейсов, пример которого показан на рисунке 3.7, внимание
приковывают два столбца:
action(предназначен для описания действия пользователя);
expected result (предназначен для описания результата действия пользователя).
В окне указывается уникальный идентификатор, по которому можно однозначно
найти тест-кейс среди всех наборов тест-кейсов. Задается автором название тест-кейса,
которое в процессе эксплуатации можно изменять. Указывается имя автора тест-кейса и
итерация, к которой он относится.
Рисунок 3.7 – Среда написания тест-кейсов TFS.
3.3
Процесс и результаты тестирования
53
Процесс
тестирования
начинается
с
момента
получения
рабочей
версии
разрабатываемого продукта. Проводилось ручное и автоматизированное тестирование.
Ручное тестирование проводилось по написанным тест-кейсам тремя людьми.
Автоматизированное
тестирование
проводилось
с
использованием
Selenium
WebDriver. Она позволяет взаимодействовать с браузером, управлять его поведением,
получать от него данные, заставлять браузер выполнять команды.
3.3.1
Процесс тестирования
Первым шагом тестирования было написание тест-кейсов по разрабатываемому
функционалу сервиса. Вторым шагом проводились функциональные тестирования, куда
входило: модульное тестирование, тестирование системы.
После функционального тестирования проводилось автоматизированное. Как было
упомянуто в пункте 3.3, для этого использовалась среда Selenium WebDriver.
В ходе тестирования были выполнены следующие виды задач:
1)
Проводились тестирования в нескольких браузерах по нескольким категориям по
десяти бальной шкале, результаты показаны в таблице 3.1.
2)
Проверялось наличие всех элементов (кнопки, формы, поля ввода, изображения,
таблицы и т.д.).
3)
Взаимодействие со всеми популярными браузерами, в числе которых Chrome,
Internet Explorer, Opera, Firefox, Yandex.Browser.
4)
Взаимодействие с элементами страницы (наведение на элемент, клик по
элементу, заполнение форм и т.д.).
Особое внимание было уделено тестированию пользователей, которые ни разу не
пользовались
разработанным
сервисом.
Было
предложено
троим
потенциальным
пользователям проверить функционал и дизайн интерфейса разработанного программного
модуля по подробным тест-кейсам, описанным в TFS.
Таблица 3.1 – Сравнительный анализ браузеров
54
Критерий
Chrome [1]
Firefox [2]
Yandex [3]
IE [4]
Opera [5]
Отображение
10
9
8
5
7
9
10
8
6
7
9
10
9
8
9
9.3
9.3
8.3
6.3
7.6
элементов
Время перехода
между
страницами
Время отклика
при
взаимодействии с
элементами форм
Средняя оценка
Источники информации:
Условные обозначения:
[1] https://www.google.ru/chrome/browser/desktop/
[2] https://www.mozilla.org/ru/firefox/new/
10 – максимальная оценка;
1 - минимальная оценка;
[3] https://browser.yandex.ru/desktop/main/
[4] https://www.microsoft.com/ru-ru/download/internetexplorer.aspx
[5] http://www.opera.com/ru
3.3.2
Результаты тестирования
В ходе ручного тестирования были выявлены ошибки в функциональной части
разрабатываемой модели, в процессе разработки которого они были устранены. Также была
изменена логика работы некоторых методов, в частности логика работы определения
правильного расчета стоимости потребления ресурсов. На рисунке 3.8 представлен
успешный результат тестирования определения правильного расчета стоимости потребления
ресурсов.
55
Рисунок 3.8 – Результат модульного тестирования
В ходе проведения тестирования была исследована статистика использования
браузеров. По данным исследования авторитетной компании Stat Counter по анализу вебтрафика, было выяснено, что более половины всех пользователей предпочитают браузер
Chrome от компании Google. На рисунке 3.10 представлен отчет за один год по
использованию браузеров пользователями.
Рисунок 3.10 – Использование браузеров пользователями
56
Исходя из этого по выбору формата используемых загрузочных файлов, отображению
и расположению элементов отдавалось предпочтение браузеру Chrome.
Последним этапом тестирования было тестирование по тест-кейсам. Во время
прохождения по шагам тест-кейсов у тестировщиков не возникало вопросов, ситуаций, когда
возникала неопределенность, не было.
Выводы по разделу
В технологическом разделе был проведен анализ средств и методов отладки,
тестирования. Также был описан процесс тестирования, средства написания тест-кейсов.
Говоря о этапах тестирования по трудозатратам ручное тестирование заняло больше
времени, чем автоматизированное. Все дефекты, обнаруженные во время тестирования,
были своевременно исправлены и протестированы снова. На данный момент весь
описанный в техническом задании функционал отрабатывает корректно.
57
ЗАКЛЮЧЕНИЕ
Результатом работы над выпускной квалификационной работой стала разработка ПМ
КУЭР. В конечной версии программы реализованы все оговоренные в техническом задании
функции.
Все поставленные цели и задачи выполнены. В ходе разработки были решены
следующие задачи:
1) Исследована предметная область
2) Проведен обзор существующих решений
3) Выбраны средства и язык программирования
4) Разработана структурная схема
5) Разработана схема данных
6) Разработана схема алгоритмов
7) Разработан пользовательский интерфейс
8) Осуществлена программная реализация ПМ КУЭР
9) Проведена отладка и тестирование
10)Разработано руководство оператора
ПМ КУЭР предназначен для анализа и отображения показаний с приборов учета в
многоквартирных домах. Программный модуль дает возможность следит за потреблением
ресурсов в режиме реального времени и производить оплату. Разработка данного
программного модуля позволит создать востребованный сервис по учету и контролю
потребления энергетических ресурсов.
58
СПИСОК ИСТОЧНИКОВ
1. Л.Г. Гагарина, Р.А. Касимов, Д.Г. Коваленко, Е.Л. Федотова, ЧжоЗо Е, Б.В. Черников
Методические указания по подготовке выпускной квалификационной работы по
направлению подготовки бакалавров 09.03.04 «Программная инженерия»/ Под ред. док.
тех. наук Б.В.Черникова. – М.: МИЭТ, 2016
2. Колдаев В.Д. Основы алгоритмизации и программирования: учебное пособие./ Под ред.
Л.Г. Гагариной. - М.: ИД «ФОРУМ»: ИНФРА-М, 2012. – 416 с.
3. ГОСТ Р 7.0.12-2011. Система стандартов по информации, библиотечному и
издательскому делу. Библиографическая запись. Сокращение слов и словосочетаний на
русском языке. Общие требования и правила. Введ. - М., Стандартинформ, 2011 – 28 с.
4. ГОСТ 19.701-90. Единая система программной документации. Схемы алгоритмов,
программ, данных и систем. Обозначения условные и правила выполнения. Введ. – М.,
Стандартинформ, 2005 - 24 с.
5. ГОСТ 7.32-2001. Система стандартов по информации, библиотечному и издательскому
делу. Отчет о научно-исследовательской работе. Структура и правила оформления. Введ.
– М., Стандартинформ, 2006 – 22 с.
6. ГОСТ
Р
7.0.5-2008.
Система
стандартов
по
информации,
библиотечному
и
издательскому делу. Библиографическая ссылка. Общие требования и правила
составления. Введ. - М., Стандартинформ, 2009 – 19 с.
7. ГОСТ 7.82-2001. Система стандартов по информации, библиотечному и издательскому
делу. Библиографическая запись. Библиографическое описание электронных ресурсов.
Общие требования и правила составления. Введ. - М., Стандартинформ, 2002 – 23 с.
8. ГОСТ 7.80-2000. Система стандартов по информации, библиотечному и издательскому
делу. Библиографическая запись. Заголовок. Общие требования и правила составления.
Введ. - М., ИПК Издательство стандартов, 2001 – 11 с.
9. ГОСТ 7.1-2003. Система стандартов по информации, библиотечному и издательскому
делу. Библиографическая запись. Библиографическое описание. Общие требования и
правила составления. Введ. - М., ИПК Издательство стандартов, 2004 – 166 с.
10. ГОСТ Р 7.0.12-2011. Система стандартов по информации, библиотечному и
издательскому делу. Библиографическая запись. Сокращение слов на русском языке.
Общие требования и правила. Введ. - М., Стандартинформ, 2012 – 23 с.
59
11. ГОСТ 7.11-2004. Система стандартов по информации, библиотечному и издательскому
делу. Библиографическая запись. Сокращение слов и словосочетаний на иностранных
европейских языках", если в работе использовалась литература на иностранных языках.
Введ. - М., Стандартинформ, 2008 – 82 с.
12. Энергопотребление в доме. [Электронный ресурс]. -
Режим доступа: http://t7-
inform.ru/s/news/20140627123800
13. ДеМерс Майкл, Географические информационные системы. Основы, 1999 - 478 с
14. ГИС
ЖКХ.
[Электронный
ресурс].
-
Режим
доступа: http://real-
gkh.ru/information/gosudarstvennaya-informatsionnaya-sistema-zhilishchno-kommunalnogokhozyaystva/
15. Расходы на электроэнергию в домах. [Электронный ресурс]. -
Режим доступа:
http://dompraktika.ru/raskhody-na-ehlektrichestvo-v-chastnom-do/
16. Газпром межрегионгаз, предоставление услуг. [Электронный ресурс]. - Режим доступа:
http://gazmsk.ru/serv/17_0.htm
17. Государственная информационная система. [Электронный ресурс]. - Режим доступа:
https://dom.gosuslugi.ru/#!/main
18. Маркетинговое агентство РБК.research. [Электронный ресурс]. -
Режим доступа:
http://research.rbc.ru/
19. Концептуальная база данных. [Электронный ресурс]. - Режим доступа:
20. http://e-educ.ru/bd12.html
21. Построение
UML
диаграмм.
[Электронный
ресурс].
-
Режим
доступа: http://www.planerka.info/item/Diagramma-precedentov-(variantov-ispolzovaniya)UML
22. Архитектура
программного
обеспечения.
[Электронный
ресурс].
-
Режим
-
Режим
доступа: http://ccfit.nsu.ru/~shadow/OOAD/pps/06-SoftwareArchitecture.pdf
23. Сравнение
языков
программирования.
[Электронный
ресурс].
доступа: http://www.internet-technologies.ru/articles/article_1991.html
24. Многопоточность.
Определения
и
понятия.
[Электронный
ресурс].
-
Режим
доступа: https://ru.wikipedia.org/wiki/%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE
%D0%BF%D0%BE%D1%82%D0%BE%D1%87%D0%BD%D0%BE
%D1%81%D1%82%D1%8C
60
25. Описание среды разработки Phpstorm. [Электронный ресурс]. -
Режим доступа:
https://www.jetbrains.com/phpstorm/
26. Описание среды разработки IntellijIdea. [Электронный ресурс]. - Режим доступа:
https://www.jetbrains.com/idea/
27. Описание среды разработки SublimeText. [Электронный ресурс]. - Режим доступа:
https://www.sublimetext.com/3
28. Когда IDE действительно имеет значение. [Электронный ресурс]. - Режим доступа:
http://www.internet-technologies.ru/articles/article_1942.html
29. Паттерн MVC. [Электронный ресурс]. - Режим доступа:
https://professorweb.ru/my/WPF/documents_WPF/level36/36_3.php
30. Сравнение различных СУБД. [Электронный ресурс]. - Режим доступа:
http://webarty.net/databases/sqlite-vs-mysql-vs-postgresql-sravnenie-sistem-upravleniyabazami-dannych
31. Показатели надежности программного обеспечения. [Электронный ресурс]. - Режим
доступа:www.ivtn.ru/2009/pdf/d09_04.pdf
32. Роберт Дж. Мюллер.Базы данных и UML. – Москва, 2002. – 420 с.
33. Э. Гамма Р. Хелм Р. Джонсон Дж. Влиссидес Приемы объектно-ориентированного
проектирования. Паттерны проектирования. – Питер, 2011. – 368 с.
34. Мартин Фаулер. Поделиться: 0 UML. Основы. Краткое руководство по стандартному
языку объектного моделирования. – Символ-Плюс, 2006.
35. Грэди Буч, Айвар Якобсон. UML. Специальный справочник. – «Питер», 2002 – 656 с.
36. ФрименЭр., Фримен Эл., Бейтс Б., Сьерра К. Паттерны проектирования. – Питер, 2011. 656 c.
37. Сэм Канер, Джек Фолк, ЕнгКекНгуен “Тестирование программного обеспечения.
Фундаментальные концепции менеджмента бизнес-приложений”. – Питер, 2001. - 544 c.
38. Рекс Блэк “Ключевые процессы тестирования. Планирование, подготовка, проведение,
совершенствование”. – Москва, 2011. - 544 c.
39. Луиза Тамре “Введение в тестирование программного обеспечения”. – Москва, 2003. 368 c.
40. Обзор методов отладки ПО. [Электронный ресурс]. - Режим доступа:
http://kodubets.ru/2010/08/27/%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D1%8B%D0%BE%D1%82%D0%BB%D0%B0%D0%B4%D0%BA%D0%B8-software/
61
41. Борис Бейзер “Тестирование черного ящика. Технологии функционального
тестирования программного обеспечения и систем”. – Москва, 2004. - 320 c.
42. Тестирование и отладка программного обеспечения. [Электронный ресурс]. - Режим
доступа: http://inf1.info/book/export/html/134
43. Методы отладки программ. [Электронный ресурс]. - Режим доступа:
http://www.tehprog.ru/index.php_page=lecture0113.html
44. Логирование в Rails. [Электронный ресурс]. - Режим доступа:
http://rusrails.ru/debugging-rails-applications
45. Точки останова в PhpStorm. [Электронный ресурс]. - Режим доступа:
http://www.rustorm.ru/phpstorm/osnovnye-opredelenija/zapusk-i-otladka/tochki-ostanovabreakpoints.html
46. Процесс тестирования. [Электронный ресурс]. - Режим доступа:
http://www.protesting.ru/testing/testprocess.html
47. Функциональное тестирование. [Электронный ресурс]. - Режим доступа:
http://aplana.ru/services/testing/functionalnoe-testirovanie
48. Нагрузочное тестирование. [Электронный ресурс]. - Режим доступа:
http://aplana.ru/services/testing/nagruzochnoye-testirovanie
49. Тестирование производительности. [Электронный ресурс]. - Режим доступа:
http://aplana.ru/services/testing/nagruzochnoye-testirovanie/testirovanie-proizvoditelnos
50. Системное тестирование. [Электронный ресурс]. - Режим доступа:
http://aplana.ru/services/testing/functionalnoe-testirovanie/sistemnoe-testirovanie
51. Средства программирования. [Электронный ресурс]. - Режим доступа:
http://nukegluk.livejournal.com/138883.html
62
Отзывы:
Авторизуйтесь, чтобы оставить отзыв