|
Кол-во объектов контроля на предприятии, шт.
|
В зависимости от потребностей заказчика, но не
более 64
|
|
Максимальное удаление объектов контроля от АРМ,
м
|
Определяется каналами связи
|
|
Максимальное удаление электросчетчиков от
сумматора, м
|
500
|
|
Максимальное удаление электросчетчиков от
коммутатора, м
|
3000
|
|
Максимальная потребляемая системой мощность от
питающей сети на один объект контроля, ВА
|
В зависимости от комплектации, но не более 250
|
|
Допустимый диапазон рабочих температур на
объектах контроля,°C
|
от - 10 до 55
|
|
Предел допускаемой основной абсолютной
погрешности подсчета импульсов, имп.
|
~ 1
|
|
Пределы допускаемых значений относительной
погрешности по активной и реактивной энергии при использовании цифровых
выходов счетчиков, %
|
Не превышают установленных для применяемых
электросчетчиков
|
|
Пределы допускаемых значений относительной
погрешности по мощности, усредненной на интервалах 30 мин., при использовании
цифровых выходов счетчиков, %
|
Не превышают установленных для применяемых
электросчетчиков
|
|
Пределы допускаемых значений относительной
погрешности по активной и реактивной энергии при использовании импульсных
выходов счетчиков класса точности не хуже 1, %
|
±1,4∙ (0,04+kІ) Ѕ (k - класс точности
электросчетчиков, %)
|
|
Средняя наработка на отказ ИВК
|
|
Срок службы ИВК
|
не менее 30 лет
|
|
Масса и габариты технических средств системы
|
В соответствии с ТУ (паспортными данными)
|
|
|
|
1.5.4
Автоматизированная система коммерческого учета электроэнергии
(АСКУЭ)"МСР-Энерго"
Назначение системы - высокоточный коммерческий и технический
учет расхода электроэнергии с возможностью ведения дифференцированного по
времени суток тарифа, позволяющий реально снизить затраты на оплату
электроэнергии.
АСКУЭ "МСР-Энерго" адаптируется под заказчика,
отвечает требованиям энергосбытовых организаций и обеспечивает выход на ФОРЭМ.
Функциональные задачи:
сбор и обработка информации о потребляемой электроэнергии;
вычисление необходимых заказчику параметров и долговременное
хранение их в памяти eстройства сбора данных (УСПД);
отображение информации о потребляемой электроэнергии
(числовые значения и графики) для ее последующего анализа (технические данные)
и оплаты (коммерческие данные).
Основные преимущества "МСР-ЭНЕРГО":
передача данных для коммерческого учета осуществляется
непосредственно с первого уровня системы (УСПД);
повышенная надежность за счет защиты информации;
масштабируемость;
открытая архитектура системы с возможностью наращивания
функций;
работа на всех видах каналов связи;
поддержка распределенной (корпоративной) структуры управления;
гибкость и адаптируемость.
1.5.5
Программно-технический комплекс "Энергоконтроль"
Программно-технический комплекс
(ПТК)"Энергоконтроль" предназначен для создания многоуровневых
автоматизированных систем контроля и коммерческого учета энергоресурсов в
энергосистемах городов и крупных предприятий. Комплекс позволяет проводить учет
всех видов энергоресурсов, осуществлять контроль и дистанционное управление
технологическими процессами производства и потребления энергии.
Основные функции ПТК "Энергоконтроль":
измерение потребления тепловой, электрической энергии, газа и
холодной воды;
сбор данных о потреблении тепловой энергии с теплосчетчиков,
электросчетчиков, счетчиков газа и холодной воды, имеющих цифровые интерфейсы;
создание и ведение архивов потребленной энергии и газа;
отображение данных о потреблении энергоресурсов и состоянии
технологического оборудования на мнемосхемах, в виде графиков, гистограмм и
таблиц;
создание отчетных форм и вывод документов для расчета за
потребляемые энергоресурсы;
дистанционное управление технологическим оборудованием;
автоматическое регулирование тепловых нагрузок.
Состав ПТК "Энергоконтроль":
технические средства учета и регулирование потребления
энергоресурсов;
система сбора и обработки данных:
технические средства сбора данных;
среда передача данных;
оборудование диспетчерского центра.
Основные концепции, заложенные при разработке ПТК:
совместимость с приборами учета тепловой, электрической
энергии и газа различных производителей;
универсальная среда передачи данных, позволяющая пользователю
выбирать наиболее рациональный способ съема данных для каждого объекта
контроля;
пакет программ, поставляемый пользователю, открыт для
развития специалистами пользователя;
обеспечивается взаимодействие программного обеспечения системы
с другими программными комплексами и офисными приложениями.
В ПТК реализована возможность выполнения функций
дистанционного контроля и управления технологическим оборудованием,
автоуправления, учета других видов энергии. Выполнение этих функций достигается
включением в состав КТС ОК программируемых контроллеров, и других приборов за
счет использования унифицированных интерфейсов.
1.5.6
Автоматизированная система контроля и управления энергоресурсами
"Спрут"
Назначение: АСКУЭ "Спрут" предназначена для
обеспечения постоянного контроля за потреблением любого вида энергоресурсов на
всех участках производства, снижения энергопотребления за счет оптимизации в
реальном масштабе времени режимов работы оборудования, автоматизации управления
технологическими процессами энергопотребления, а также контроля параметров
качества электроэнергии в соответствии с ГОСТ 13109-97 и контроля
несанкционированного использования энергоресурсов.
В состав АСКУЭ "Спрут" входят:
– АРМ клиентов;
– сервера;
– контроллеры, выполняющие функции связи с
коммутаторами и цифро-аналогового преобразования сигналов;
– коммутаторы, предназначенные для выбора и трансляции
сигналов от датчиков к серверу и от сервера к исполнительным механизмам;
– датчики сигналов;
– исполнительные механизмы;
– вычислители;
– радио или телефонные модемы;
– сетевое оборудование;
– громкоговорители.
Основные особенности и характеристики АСКУЭ
"Спрут":
– возможность организации до 16 000 каналов контроля
одним сервером;
– возможность контроля качества получаемой электроэнергии
по 6-ти основным параметрам в соответствии с ГОСТ 13109-97, а также измерение
частоты подводимого напряжения, фазных (линейных) и межфазных напряжений;
– быстрая окупаемость (4-6 месяцев) за счет низкой
стоимости системы и последующей эксплуатации каналов контроля за счет
применения в системе датчиков тока и напряжения собственного изготовления;
– совместимость с интерфейсами RS 485, RS 232;
датчиками с выходом типа "токовая петля" на 5 и 20 мА или "сухой
контакт";
– возможность обработки аналоговых (до 10 кГц) и
цифровых сигналов;
– возможность перенастройки каналов с информационных на
управляющие для организации контуров дистанционного управления исполнительными
механизмами;
– гибкость системы, возможность настройки под
конкретного заказчика с наращиванием функций по контролю за безопасностью в
электросетях, охранной и пожарной сигнализации, мониторинга опасности
производства, контроля и учета потребления любых видов энергоресурсов (вода,
газ, пар, тепло, стоки и др.);
– "дружественный" интерфейс обмена с
операторами под управлением WINDOWS;
– возможность интегрирования в локальные сети других
систем;
– измерение токов от 0 до 2000 А в цепях до 400 В без
дополнительных понижающих трансформаторов тока;
– монтаж датчиков тока без разрыва цепей и прерывания
электроснабжения;
– 100% защита системы от взлома и возможность раннего
обнаружения неисправности цепей съема первичной информации;
– контроль мгновенных значений напряжений, токов,
косинуса j, активной, реактивной и полной мощностей и их соотношение в
процентах к установленным лимитам как для предприятия, так и по отдельным его
объектам; · хранение и отображение в графическом и цифровом виде данных о
нагрузках, качестве, мгновенных значениях, расценках и стоимости, лимитах в
любой промежуток времени за последние два года эксплуатации;
– планирование и распределение электроэнергии по
потребителям и во времени на основе данных, хранимых в ПЭВМ;
– контроль работы оборудования в реальном масштабе
времени;
– отключение оборудования в случае превышения установленных
лимитов энергопотребления или нарушения установленного графика работы;
– хранение и выдача "генплана" предприятия,
структурных схем подразделений с привязкой к ним схем электроснабжения с
одновременным выводом данных об энергопотреблении по выбранному на схеме
объекту;
– выдача речевых сообщений о нарушениях работы или
превышении уровня потребления как на громкоговоритель, так и по телефонной сети
на указанный при настройке системы телефонный номер местной или городской АТС.
Таким образом, сравнив технические характеристики
представленных выше систем, следует отметить тот факт, что ни одна из них не
удовлетворяет в полной мере всех требований ОАО "РЖД". Поэтому
разработка автоматизированной системы учета электроэнергии на фидерах контактной
сети (АСУЭФКС) является актуальной проблемой.
1.6
Постановка задач проекта
Результатом работы автоматизированной системы мониторинга и
учета электроэнергии на фидерах контактной сети является совокупность
несвязанных данных, которые хранятся в иерархической структуре в файловой
системе операционной системы. Измерения за сутки, произведенные одним
счетчиком, хранятся в одном файле формата csv.
В системе отсутствует штатное средства для просмотра данных,
что затрудняет их анализ.
Таким образом, проанализировав данные проблемы, были
сформулированы следующие четыре задачи:
выбрать СУБД для хранения данных;
разработать концептуальную модель базы данных для хранения
данных об измерениях;
разработать алгоритмы для программного комплекса, задачей
которого входит: произвести миграцию уже имеющихся данных и обеспечить просмотр
данных, которые хранятся в базе данных;
на основе алгоритмов разработать программный комплекс,
отвечающий за миграцию данных и их просмотр.
2.
Рассмотрение и анализ используемых средств
2.1 Языки
программирования
2.1.1 Java
Java - объектно-ориентированный язык программирования,
разработанный компанией Sun Microsystems (в последующем приобретенной компанией
Oracle). Приложения Java обычно транслируются в специальный байт-код, поэтому
они могут работать на любой виртуальной Java-машине вне зависимости от
компьютерной архитектуры. Дата официального выпуска - 23 мая 1995 года.
Изначально язык назывался Oak ("Дуб")
разрабатывался Джеймсом Гослингом для программирования бытовых электронных
устройств. Впоследствии он был переименован в Java и стал использоваться для
написания клиентских приложений и серверного программного обеспечения. Назван в
честь марки кофе Java, которая, в свою очередь, получила наименование
одноименного острова (Ява), поэтому на официальной эмблеме языка изображена
чашка с дымящимся кофе. Существует и другая версия происхождения названия
языка, связанная с аллюзией на кофе-машину как пример бытового устройства, для
программирования которого изначально язык создавался.
Программы на Java транслируются в байт-код, выполняемый
виртуальной машиной Java (JVM) - программой, обрабатывающей байтовый код и
передающей инструкции оборудованию как интерпретатор.
Достоинством подобного способа выполнения программ является
полная независимость байт-кода от операционной системы и оборудования, что
позволяет выполнять Java-приложения на любом устройстве, для которого
существует соответствующая виртуальная машина. Другой важной особенностью
технологии Java является гибкая система безопасности, в рамках которой
исполнение программы полностью контролируется виртуальной машиной. Любые
операции, которые превышают установленные полномочия программы (например,
попытка несанкционированного доступа к данным или соединения с другим
компьютером), вызывают немедленное прерывание.
Часто к недостаткам концепции виртуальной машины относят
снижение производительности. Ряд усовершенствований несколько увеличил скорость
выполнения программ на Java:
применение технологии трансляции байт-кода в машинный код
непосредственно во время работы программы (JIT-технология) с возможностью
сохранения версий класса в машинном коде;
широкое использование платформенно-ориентированного кода
(native-код) в стандартных библиотеках;
аппаратные средства, обеспечивающие ускоренную обработку байт-кода
(например, технология Jazelle, поддерживаемая некоторыми процессорами фирмы
ARM).
По данным сайта shootout. alioth. debian.org, для семи разных
задач время выполнения на Java составляет в среднем в полтора-два раза больше,
чем для C/C++, в некоторых случаях Java быстрее, а в отдельных случаях в 7 раз
медленнее. С другой стороны, для большинства из них потребление памяти
Java-машиной было в 10-30 раз больше, чем программой на C/C++. Также
примечательно исследование, проведенное компанией Google, согласно которому
отмечается существенно более низкая производительность и большее потребление
памяти в тестовых примерах на Java в сравнении с аналогичными программами на
C++.
Идеи, заложенные в концепцию и различные реализации среды
виртуальной машины Java, вдохновили множество энтузиастов на расширение перечня
языков, которые могли бы быть использованы для создания программ, исполняемых
на виртуальной машине. Эти идеи нашли также выражение в спецификации
общеязыковой инфраструктуры CLI, заложенной в основу платформы.net компанией
Microsoft.
Выполнение дипломного проекта осуществлялось на Java7,
поэтому рассмотрим ее более подробно.
Релиз версии состоялся 28 июля 2011 года. В финальную версию
Java Standard Edition 7 не были включены все ранее запланированные изменения.
Согласно плану развития (план "Б"), включение нововведений будет
разбито на две части: Java Standard Edition 7 (без лямбда-исчисления, проекта
Jigsaw, и части улучшений Coin) и Java Standard Edition 8 (все остальное),
намеченный на конец 2012 года.
В новой версии, получившей название Java Standard Edition 7
(Java Platform, Standard Edition 7), помимо исправления большого количества
ошибок, было представлено несколько новшеств. Так, например, в качестве
эталонной реализации Java Standard Edition 7 использован не проприетарный пакет
JDK, а его открытая реализация OpenJDK, а сам релиз новой версии платформы
готовился при тесном сотрудничестве инженеров Oracle с участниками мировой
экосистемы Java, комитетом JCP (Java Community Process) и сообществом OpenJDK.
Все поставляемые Oracle бинарные файлы эталонной реализации Java Standard
Edition 7 собраны на основе кодовой базы OpenJDK, сама эталонная реализация
полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath,
разрешающими динамическое связывание с проприетарными продуктами. К другим
нововведениям относится интеграция набора небольших языковых улучшений Java,
развиваемых в рамках проекта Coin, добавлена поддержка языков программирования
с динамической типизацией, таких, как Ruby, Python и JavaScript, поддержка
загрузки классов по URL, обновленный XML-стек, включающий JAXP 1.4, JAXB 2.2a и
JAX-WS 2.2 и другие.
За 5 дней до выхода релиза Java Standard Edition 7 было
обнаружено несколько серьезных ошибок в горячей оптимизации циклов, которая включена
по умолчанию и приводит виртуальную машину Java к краху. Специалисты Oracle
найденные ошибки за столь короткий срок исправить не могли, но пообещали, что
они будут исправлены во втором обновлении (Java 7 Update 2) и частично в
первом.
Список нововведений:
Поддержка динамически-типизированных языков (InvokeDynamic) -
расширение JVM (семантики байт-кода), языка Javaдля поддержки
динамически-типизированных языков.
Строгая проверка class-файлов - class-файлы версии 51 (Java
Standard Edition 7) или более поздней версии должны быть проверены
typechecking-верификатором; JVM не должна переключаться на старый верификатор.
Изменение синтаксиса языка Java (Project Coin) - частичные
изменения в языке Java, предназначенные для упрощения общих задач
программирования:
использование класса String в блоке switch.
закрытие используемых ресурсов в блоке try
(try-with-resources) - работает при использовании интерфейса AutoCloseable.
объединенная обработка исключений в блоке catch (multi-catch
exceptions) - перечисление обрабатываемых исключений в catch (… | … | …).
повторное выбрасывание исключений (rethrowing exceptions) -
передача возникшего исключения "вверх" по стеку вызовов
<https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B5%D0%BA_%D0%B2%D1%8B%D0%B7%D0%BE%D0%B2%D0%BE%D0%B2>.
подчеркивания в числовых литералах для лучшего восприятия больших
чисел.
изменение вывода типа в Java generic при создании объекта.
использование двоичных чисел (binary literals) - префикс
<https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D1%84%D0%B8%D0%BA%D1%81_(%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)>
"0b" укажет, что используется двоичное число.
упрощение вызова методов varargs - уменьшение предупреждений при
вызове метода с переменным числом входящих переменных.
Модификация загрузчика классов (class-loader) - избежание
тупиковых ситуаций в неиерархической топологии загрузки классов.
Закрытие ресурсов, открытых URLClassLoader.
Обновление коллекций (JSR 166).
Поддержка Unicode 6.0.
Отделение языка пользователя и языка пользовательского интерфейса
- обновление обработки языков для отделения локали от языка пользовательского
интерфейса.
Новые интерфейсы I/O для платформы Java (nio.2).
Использование JDBC 4.1 и Rowset 1.1.
Внутри Java существуют несколько основных семейств технологий:SE -
Java Standard Edition, основное издание Java, содержит компиляторы, API, Java
Runtime Environment; подходит для создания пользовательских приложений, в
первую очередь - для настольных систем.EE - Java Enterprise Edition,
представляет собой набор спецификаций для создания программного обеспечения
уровня предприятия.ME - Java Micro Edition, создана для использования в
устройствах, ограниченных по вычислительной мощности, например, в мобильных
телефонах, КПК, встроенных системах;- технология, являющаяся следующим шагом в
эволюции Java как Rich Client Platform; предназначена для создания графических
интерфейсов корпоративных приложений и бизнеса.Card - технология предоставляет
безопасную среду для приложений, работающих на смарт-картах и других устройствах с очень ограниченным
объемом памяти и возможностями обработки.
КомпаниейMicrosoft
<https://ru.wikipedia.org/wiki/Microsoft>была разработана собственная
реализацияJVM <https://ru.wikipedia.org/wiki/JVM> (MSJVM), включавшаяся в
состав различных операционных систем
<https://ru.wikipedia.org/wiki/%D0%9E%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0>,
начиная сWindows 98 <https://ru.wikipedia.org/wiki/Windows_98> (также
входила в Internet Explorer от версии 3 и выше, что позволяло использовать
MSJVM (Microsoft java virtual machine) в ОС Windows 95 и Windows NT 4 после
установки IE3+ на данные ОС).имела существенные отличия от Sun Java, во многом
ломающие основополагающую концепцию переносимости программ между разными
платформами:
отсутствие поддержкипрограммного интерфейса
<https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9>вызова
удаленных методов <https://ru.wikipedia.org/wiki/Remote_Procedure_Call>
(RMI <https://ru.wikipedia.org/wiki/RMI>);
отсутствие поддержки технологииJNI
<https://ru.wikipedia.org/wiki/JNI>;
наличие нестандартных расширений, таких, как средства интеграции
Java иDCOM <https://ru.wikipedia.org/wiki/DCOM>, работающих только на
платформе Windows.
Тесная интеграция Java с DCOM и Win32 поставила под вопрос
кроссплатформенную парадигму языка. Впоследствии это явилось поводом для
судебных исков со стороны Sun Microsystems к Microsoft. Суд принял сторону
компании Sun Microsystems. В конечном счете между двумя компаниями была
достигнута договоренность о возможности продления срока официальной поддержки
пользователей нестандартной Microsoft JVM до конца 2007 года.
В 2005 году компанией Microsoft для платформы.net
<https://ru.wikipedia.org/wiki/.NET_Framework>был представлен
Java-подобный языкJ# <https://ru.wikipedia.org/wiki/Visual_J_Sharp>, не
соответствующий официальной спецификации языка Java и исключенный впоследствии
из стандартного инструментария разработчикаMicrosoft Visual Studio
<https://ru.wikipedia.org/wiki/Microsoft_Visual_Studio>, начиная с Visual
Studio 2008.
Язык Java активно используется для создания мобильных приложений
под операционную систему Android. При этом программы компилируются в
нестандартный байт-код, для использования их виртуальной машиной Dalvik. Для
такой компиляции используется дополнительный инструмент, а именно Software
Development Kit, разработанный компанией Google.
Разработку приложений можно вести в среде Android Studio,
NetBeans, в среде Eclipse, используя при этом плагин Android Development Tools
(ADT) или в IntelliJ IDEA. Версия JDK при этом должна быть 5.0 или выше.
декабря 2014 года Android Studio признана компанией Google
официальной средой разработки под ОС Android.
Следующие успешные проекты реализованы с привлечением Java (J2EE)
технологий: RuneScape, Amazon, eBay, LinkedIn, Yahoo!.
Следующие компании в основном фокусируются на Java (J2EE)
технологиях: SAP, IBM, Oracle. В частности, СУБД Oracle Database включает JVM
как свою составную часть, обеспечивающую возможность непосредственного
программирования СУБД на языке Java, включая, например, хранимые процедуры.
Программы, написанные на Java, имеют репутацию более медленных и
занимающих больше оперативной памяти, чем написанные на языке Си. Тем не менее,
скорость выполнения программ, написанных на языке Java, была существенно
улучшена с выпуском в 1997 - 1998 годах так называемого JIT-компилятора в
версии 1.1 в дополнение к другим особенностям языка для поддержки лучшего
анализа кода (такие, как внутренние классы, класс StringBuffer, упрощенные
логические вычисления и т.д.). Кроме того, была произведена оптимизация
виртуальной машины Java - с 2000 года для этого используется виртуальная машина
HotSpot. По состоянию на февраль 2012 года, код Java 7 приблизительно лишь в
1.8 раза медленнее кода, написанного на языке Си.
Некоторые платформы предлагают аппаратную поддержку выполнения для
Java. К примеру, микроконтроллеры, выполняющие код Java на аппаратном
обеспечении вместо программной JVM, а также основанные на ARM процессоры,
которые поддерживают выполнение байткода Java через опцию Jazelle.
Основные возможностиJava:
автоматическое управление памятью;
расширенные возможности обработки исключительных ситуаций;
богатый набор средств фильтрации ввода-вывода;
набор стандартных коллекций: массив, список, стек и т.п.;
наличие простых средств создания сетевых приложений (в том числе с
использованием протокола RMI);
наличие классов, позволяющих выполнять HTTP-запросы и обрабатывать
ответы;
встроенные в язык средства создания многопоточных приложений;
унифицированный доступ к базам данных:
на уровне отдельных SQL-запросов - на основе JDBC, SQLJ;
на уровне концепции объектов, обладающих способностью к хранению в
базе данных - на основе Java Data Objects (англ.) и Java Persistence API;
поддержка обобщений (начиная с версии 1.5);
параллельное выполнение программ.
2.1.2
JavaScript
JavaScript (джаваскрипт) - прототипно-ориентированный
сценарный язык программирования.обычно используется как встраиваемый язык для
программного доступа к объектам приложений. Наиболее широкое применение находит
в браузерах как язык сценариев для придания интерактивности веб-страницам.
Основные архитектурные черты:
динамическая типизация;
слабая типизация;
автоматическое управление памятью;
прототипное программирование;
функции как объекты первого класса.
На JavaScript оказали влияние многие языки, при разработке
была цель сделать язык похожим на Java, но при этом легким для использования
непрограммистами. Языком JavaScript не владеет какая-либо компания или
организация, что отличает его от ряда языков программирования, используемых в
веб-разработки.
Название "JavaScript" является зарегистрированным
товарным знаком компании Oracle Corporation.является объектно-ориентированным
языком, но используемое в языке прототипирование обуславливает отличия в работе
с объектами по сравнению с традиционными класс-ориентированными языками. Кроме
того, JavaScript имеет ряд свойств, присущих функциональным языкам - функции
как объекты первого класса, объекты как списки, карринг, анонимные функции,
замыкания - что придает языку дополнительную гибкость.
Несмотря на схожий с Си синтаксис, JavaScript по сравнению с
языком Си имеет коренные отличия:
объекты, с возможностью интроспекции;
функции как объекты первого класса;
автоматическое приведение типов;
автоматическая сборка мусора;
анонимные функции.
В языке отсутствуют такие полезные вещи, как:
модульная система: JavaScript не предоставляет возможности
управлять зависимостями и изоляцией областей видимости;
стандартная библиотека: в частности, отсутствует интерфейс
программирования приложений по работе с файловой системой, управлению потоками
ввода-вывода, базовых типов для бинарных данных;
стандартные интерфейсы к веб-серверам и базам данных;
система управления пакетами, которая бы отслеживала
зависимости и автоматически устанавливала их.
Синтаксис языка JavaScript во многом напоминает синтаксис Си
и Java, семантически же язык гораздо ближе к Self, Smalltalk или даже Лиспу.
В JavaScript:
все идентификаторы регистрозависимы;
в названиях переменных можно использовать буквы,
подчеркивание, символ доллара, арабские цифры;
названия переменных не могут начинаться с цифры;
для оформления однострочных комментариев используются //,
многострочные и внутристрочные комментарии начинаются с /* и заканчиваются */.
Структурно JavaScript можно представить в виде объединения
трех четко различимых друг от друга частей:
ядро (ECMAScript);
объектная модель браузера (Browser Object Model или BOM);
объектная модель документа (Document Object Model или DOM);
Если рассматривать JavaScript в отличных от браузера
окружениях, то объектная модель браузера и объектная модель документа могут не
поддерживаться.
Объектную модель документа иногда рассматривают как отдельную
от JavaScript сущность, что согласуется с определением DOM как независимого от
языка интерфейса документа. В противоположность этому ряд авторов находят BOM и
DOM тесно взаимосвязанными.
ECMAScript не является браузерным языком и в нем не определяются
методы ввода и вывода информации. Это, скорее, основа для построения скриптовых
языков. Спецификация ECMAScript описывает типы данных, инструкции, ключевые
изарезервированные
<https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D1%80%D0%B5%D0%B7%D0%B5%D1%80%D0%B2%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%BE>слова,операторы
<https://ru.wikipedia.org/wiki/%D0%9E%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)>,
объекты,регулярные выражения
<https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%80%D0%BD%D1%8B%D0%B5_%D0%B2%D1%8B%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F>,
не ограничивая авторов производных языков в расширении их новыми составляющими.
Объектная модель браузера - браузер-специфичная часть языка,
являющаяся прослойкой между ядром и объектной моделью документа. Основное
предназначение объектной модели браузера - управление окнами браузера и
обеспечение их взаимодействия. Каждое из окон браузера представляется объектом
"window", центральным объектом DOM. Объектная модель браузера на
данный момент не стандартизирована, однако спецификация находится в разработке
WHATWGи W3C.
Помимо управления окнами, в рамках объектной модели браузера,
браузерами обычно обеспечивается поддержка следующих сущностей:
управление фреймами;
поддержка задержки в исполнении кода и зацикливания с задержкой;
системные диалоги;
управление адресом открытой страницы;
управление информацией о браузере;
управление информацией о параметрах монитора;
ограниченное управление историей просмотра страниц;
поддержка работы с HTTP cookie.
Объектная модель документа - интерфейс программирования приложений
для HTML и XML-документов. Согласно DOM, документ (например, веб-страница)
может быть представлен в виде дерева объектов, обладающих рядом свойств,
которые позволяют производить с ним различные манипуляции:
– генерация и добавление узлов;
– получение узлов;
– изменение узлов;
– изменение связей между узлами;
– удаление узлов.
Встраивание в веб-страницы
– расположение внутри страницы;
– расположение внутри тега;
– вынесение в отдельный файл.
Область применения:
Веб-приложения. JavaScript используется в клиентской части
веб-приложений: клиент-серверных программ, в котором клиентом является браузер,
а сервером - веб-сервер, имеющих распределенную между сервером и клиентом
логику. Обмен информацией в веб-приложениях происходит по сети. Одним из
преимуществ такого подхода является тот факт, что клиенты не зависят от
конкретной операционной системы пользователя, поэтому веб-приложения являются
кроссплатформенными сервисами.
AJAX. JavaScript используется в AJAX
<https://ru.wikipedia.org/wiki/AJAX>, популярном подходе к построению
интерактивных пользовательских интерфейсов веб-приложений, заключающемся в
"фоновом" асинхронном обмене данными браузера с веб-сервером. В
результате, при обновлении данных веб-страница не перезагружается полностью и
интерфейс веб-приложения становится быстрее, чем это происходит при
традиционном подходе (без применения AJAX)..comet - широкое понятие,
описывающее механизм работы веб-приложений, использующих постоянные
HTTP-соединения, что позволяет веб-серверу отправлять данные браузеру без
дополнительного запроса со стороны браузера. Для таких приложений используются
технологии, непосредственно поддерживаемые браузерами. В частности, в них
широко используется JavaScript.
Браузерные операционные системы. JavaScript широко используется в
браузерных операционных системах. Так, например, исходный код IndraDesktop
WebOS на 75 % состоит из JavaScript, код браузерной операционной системы IntOS
- на 70 %. Доля JavaScript в исходном коде eyeOS - 5 %, однако и в рамках этой
операционной системы JavaScript играет важную роль, участвуя в визуализации на
клиенте и являясь необходимым механизмом для коммуницирования клиента и
сервера.
Серверные приложения. Приложения, написанные на JavaScript, могут
исполняться на серверах, использующих Java 6 и более поздних версий. Это
обстоятельство используется для построения серверных приложений, позволяющих
обрабатывать JavaScript на стороне сервера. Помимо Java 6, существует ряд
платформ, использующих существующие движки (интерпретаторы) JavaScript для
исполнения серверных приложений. (Как правило, речь идет о повторном
использовании движков, ранее созданных для исполнения кода JavaScript в
браузерах WWW.)
Для обеспечения высокого уровня абстракции и достижения приемлемой
степени кросс-браузерности при разработке веб-приложений используются
библиотеки JavaScript. Они представляют собой набор многократно используемых
объектов и функций.
Среди известных JavaScript библиотек можно отметить Adobe life,
Dojo Toolkit, Extjs, jQuery, Mootools, Prototype, Qooxdoo, Underscore.
В JavaScript доступ к отладчикам становится особенно полезным при
разработке крупных нетривиальных программ из-за различий в реализациях разных
браузеров (в частности, в отношении объектной модели документа). Полезно иметь
доступ к отладчику для каждого из браузеров, в которых будет работать
веб-приложение.
По состоянию на ноябрь 2009 года, Internet Explorer, Opera,
Firefox, Safari, и Google Chrome имеют отладчики сценариев.Explorer имеет три
отладчика: Microsoft Visual Studio - самый полный из них, за ним следует
Microsoft Script Editor (компонент Microsoft Office), и, наконец, свободный
Microsoft Script Debugger, гораздо более простой, чем два других. Бесплатный
Microsoft Visual Web Developer Express предоставляет ограниченную версию с
отладочной функцией JavaScript в Microsoft Visual Studio. В восьмой версии в IE
вместе с инструментами для разработчиков появился встроенный отладчик.
В Opera также имеется собственный отладчик - Opera Dragonfly.
Разрабатываемые веб-приложения в Firefox можно отлаживать при
помощи расширений Firebug, Venkman.
В Safari входитотладчик JavaScript WebKit Web Inspector. Этот же
отладчик доступен и в других браузерах, использующих WebKit: Google Chrome,
Arora, Rekonq, Midori и др.
Большинство фреймворков автоматизированного тестирования
JavaScript-кода предполагают запуск тестов в браузере. Это осуществляется при
помощи HTML-страницы, являющейся контекстом тестирования, которая, в свою
очередь загружает все необходимое для осуществления тестирования. Первыми
такими фреймворками были JsUnit (создан в 2001 году), Selenium (создан в 2004
году). Альтернатива - запуск тестов из командной строки. В этом случае
используются окружения, отличные от браузера, например, Rhino. Одним из первых
инструментов такого рода является Crosscheck, позволяющий тестировать код,
эмулируя поведение Internet Explorer 6 и Firefox версий 1.0 и 1.5 Другой пример
фреймворка автоматизированного тестирования JavaScript-кода, не использующего
браузер для запуска тестов - библиотека env. js, созданная Джоном Резигом. Она
использует Rhino и при этом содержит эмуляцию окружения браузера и DOM.Ridge,
плагин к фреймворку веб-приложений Ruby on Rails, позволяет осуществлять
модульное тестирование JavaScript-кода как в браузере, так и вне его. Это
достигается за счет использования фреймворка автоматизированного тестирования
Screw. Unit и Rhino с env. js.
Главная проблема систем тестирования, не использующих браузеры, в
том, что они используют эмуляции, а не реальные окружения, в которых
выполняется код. Это приводит к тому, что успешное прохождение тестов не
гарантирует того, что код корректно отработает в браузере. Проблемой систем
тестирования, использующих браузер, является сложность работы с ними,
необходимость осуществления рутинных неавтоматизированных действий. Для решения
этого JsTestDriver, фреймворк автоматизированного тестирования, разрабатываемый
Google, использует сервер, взаимодействующий с браузерами для осуществления
тестирования. Сходным образом ведет себя Selenium Remote Control, входящий во
фреймворк автоматизированного тестирования Selenium: он включает в себя сервер,
запускающий и завершающий браузеры и действующий как HTTP-прокси для запросов к
ним. Кроме того, в Selenium содержится Selenium Grid, позволяющий осуществлять
одновременное тестирование JavaScript-кода на разных компьютерах с разными
окружениями, уменьшая время выполнения тестов. Testswarm, имеющее поддержку
фреймворков автоматизированного тестирования JavaScript-кода QUnit (библиотека
jQuery), UnitTestJS (библиотека Prototype), JSSpec (библиотека MooTools),
JsUnit, Selenium и Dojo Objective Harness, представляет собой распределенное
средство поддержки непрерывной интеграции.
Негативное свойство, которым может обладать фреймворк
автоматизированного тестирования JavaScript-кода - наличие зависимостей. Это
создает риск отказа в работе тестируемого кода, успешно проходящего тесты, в
среде с отсутствием этих зависимостей. Например, исходная версия JsUnitTest,
фреймворка, созданного и использовавшегося для тестирования библиотеки
Prototype, зависела от самой Prototype, изменяющего свойства объектов в
глобальной области видимости. Включение в библиотеку JavaScript инструмента
тестирования - распространенная практика. Так YUI Test 3 является частью Yahoo!
UI Library и может быть безопасно использован для тестирования произвольного
JavaScript-кода. QUnit - фреймворк автоматизированного тестирования, созданный
разработчиками jQuery.
2.2 SpringMVC
Spring имеет собственную MVC-платформу веб-приложений,
которая не была первоначально запланирована. Обеспечивает разделение между
слоями представления и обработки запросов, а также между слоем обработки
запросов и моделью.
Класс DispatcherServlet является основным контроллером
фрэймворка и отвечает за делегирование управления различным интерфейсам, на
всех этапах выполнения HTTP - запроса. Об этих интерфейсах следует сказать
более подробно.MVC является фреймворком, ориентированным на запросы. В нем
опредены стратегические интерфейсы для всех функций современной
запросно-ориентированной системы. Цель каждого интерфейса − быть простым
и ясным, чтобы пользователям было легко его заново имплементировать, если они
того пожелают. MVC прокладывает путь к более чистому front - end - коду. Все интерфейсы
тесно связаны с Servlet API.
Сервлет является классом Java, реализация которого расширяет
функциональные возможности сервера. Сервлет взаимодействует с клиентами
посредством принципа запрос-ответ.
Эта связь рассматривается некоторыми как неспособность
разработчиков Spring предложить для веб - приложений абстракцию более высокого
уровня. Однако эта связь оставляет особенности Servlet API доступными для
разработчиков, облегчая все же работу с ним. Наиболее важные интерфейсы,
определенные Spring MVC, перечислены ниже:: выбор класса и его метода, которые
должны обработать данный входящий запрос на основе любого внутреннего или
внешнего для этого запроса атрибута или состояния;: вызов и выполнение
выбранного метода обработки входящего запроса;: включен между Моделью (Model) и
Представлением (View). Управляет процессом преобразования входящих запросов в
адекватные ответы. Действует как ворота, направляющие всю поступающую
информацию. Переключает поток информации из модели в представление и обратно;:
ответственно за возвращение ответа клиенту в виде текстов и изображений.
Некоторые запросы могут идти прямо во View, не заходя в Model; другие проходят
через все три слоя;: выбор, какое именно View должно быть показано клиенту;:
перехват входящих запросов. Сопоставим, но не эквивалентен сервлет - фильтрам
(использование не является обязательным и не контролируется
DispatcherServlet-ом);: получение и, возможно, сохранение локальных настроек
(язык, страна, часовой пояс) пользователя;: обеспечивает Upload - загрузку на
сервер локальных файлов клиента;MVC предоставляет разработчику следующие
возможности:
ясное и прозрачное разделение между слоями в MVC и запросах;
стратегия интерфейсов - каждый интерфейс делает только свою
часть работы;
интерфейс всегда может быть заменен альтернативной
реализацией;
интерфейсы тесно связаны с Servlet API;
высокий уровень абстракции для веб-приложений.
2.3 JSP
JSP (JavaServer Pages) - технология, позволяющая
веб-разработчикам создавать содержимое, которое имеет как статические, так и
динамические компоненты. Страница JSP содержит текст двух типов: статические
исходные данные, которые могут быть оформлены в одном из текстовых форматов
HTML, SVG, WML, или XML, и JSP - элементы, которые конструируют динамическое
содержимое. Кроме этого могут использоваться библиотеки JSP-тегов, а также EL
(Expression Language), для внедрения Java-кода в статичное содержимое
JSP-страниц.
Код JSP-страницы транслируется в Java-код сервлета с помощью
компилятора JSP-страниц Jasper, и затем компилируется в байт-код виртуальной
машины java (JVM). Контейнеры сервлетов, способные исполнять JSP-страницы,
написаны на платформонезависимом языке Java. JSP-страницы загружаются на
сервере и управляются из структуры специального Java server packet, который
называется Java EE Web Application. Обычно страницы упакованы в файловые
архивы. war и. ear.является платформонезависимой, переносимой и легко
расширяемой технологией для разработки веб-приложений.
2.4
PostgreSQL
Свободная объектно-реляционная система управления базами
данных (СУБД). PostgreSQL является самым профессиональным СУБД. Она свободно
распространяемая и максимально соответствует стандартам SQL.
От других СУБД PostgreSQL отличается поддержкой
востребованного объектно-ориентированного и/или реляционного подхода к базам
данных. Например, полная поддержка надежных транзакций, т.е. атомарность,
последовательность, изоляционность, прочность. Благодаря мощным технологиям
Postgre очень производительна. Параллельность достигнута не за счет блокировки
операций чтения, а благодаря реализации управления многовариантным
параллелизмом (MVCC). PostgreSQL очень легко расширять своими процедурами,
которые называются хранимые процедуры. Эти функции упрощают использование
постоянно повторяемых операций.
Хотя PostgreSQL и не может похвастаться большой популярностью
в отличии от MySQL, существует довольно большое число приложений облегчающих
работу с PostgreSQL, несмотря на всю мощность функционала. Сейчас довольно
легко установить эту СУБД используя, стандартные менеджеры пакетов операционных
систем.
Достоинства PostgreSQL:
открытое ПО соответствующее стандарту SQL. PostgreSQL -
бесплатное ПО с открытым исходным кодом. Эта СУБД является очень мощной
системой;
большое сообщество, существует довольно большое сообщество в
котором вы запросто найдете ответы на свои вопросы;
большое количество дополнений, несмотря на огромное
количество встроенных функций, существует очень много дополнений, позволяющих
разрабатывать данные для этой СУБД и управлять ими;
расширения - существует возможность расширения функционала за
счет сохранения своих процедур;
объектность - PostrgreSQL это не только реляционная СУБД, но
также и объектно-ориентированная с поддержкой наследования и много другого.
Когда использовать PostgreSQL:
целостность данных, когда надежность и целостность данных -
ваши требования, PostgreSQL будет, пожалуй, лучшим выбором;
сложные пользовательские процедуры, если вам необходимо
использовать пользовательские процедуры, то PostgreSQL имеет встроенную
поддержку для них;
интеграция, если в будущем вы планируете переход на платные
СУБД, например Oracle, то сделать это с PostgreSQL будет довольно просто по
сравнению с другими бесплатными СУБД;
сложная структура данных, по сравнению с другими открытыми
СУБД PostgreSQL предоставляет больше возможностей для создания сложных структур
данных без необходимости жертвовать какими-либо аспектами.
2.5 Hibernate
Hibernate − библиотека для языка программирования Java,
предназначенная для решения задач объектно-реляционного отображения (ORM). Она
представляет собой свободное программное обеспечение с открытым исходным кодом
(open source). Данная библиотека предоставляет легкий в использовании каркас
(фреймворк) для отображения объектно-ориентированной модели данных в
традиционные реляционные базы данных.
Целью Hibernate является освобождение разработчика от
значительного объема сравнительно низкоуровневого программирования по
обеспечению хранения объектов в реляционной базе данных. Разработчик может
использовать Hibernate как в процессе проектирования системы классов и таблиц
"с нуля", так и для работы с уже существующей базой данных.не только
решает задачу связи классов Java с таблицами базы данных (и типов данных Java с
типами данных SQL), но и также предоставляет средства для автоматической генерации
и обновления набора таблиц, построения запросов и обработки полученных данных и
может значительно уменьшить время разработки, которое обычно тратится на ручное
написание SQL - и JDBC-кода. Hibernate автоматизирует генерацию SQL-запросов и
освобождает разработчика от ручной обработки результирующего набора данных и
преобразования объектов, максимально облегчая перенос (портирование) приложения
на любые базы данных SQL.обеспечивает прозрачную поддержку сохранности данных.
3.
Практическая часть
3.1
Концептуальная модель базы данных
Исследовав предметную область системы, ее структуру и способы
хранения данных, было принято решение о миграции данных, снятых со счетчиков,
расположенных на тяговых подстанциях, в базу данных под управлением СУБД
PostgreSQL.
В чем же преимущество базы данных перед хранением информации
в множестве однородных файлов?
Во-первых, появляется возможность более гибко, безопасно и
удобно управлять хранимой информацией.
Во-вторых, упрощается чтение и анализ данных, так как
появляется возможность применять структурированный язык запросов SQL, хранимые
процедуры, триггеры, возможность выбирать данные за разные даты, станции,
счетчики, не перебирая вручную огромное множество объемных файлов.
В-третьих, увеличивается скорость доступа к информации программными
методами. Код программы будет гораздо проще, когда обращения программы будут
направлены СУБД, а не ОС. Это факт не только позволяет обеспечить
мультиплатформенность системы, но и скорость работы сервисов по получению
данных значительно увеличится.
Этот подход практически не обладает недостатками.
Единственно, следует отметить, что возрастут затраты на создание, сопровождение
программное обеспечения, которое будет отвечать за миграцию данных и
необходимость администрировать базу данных.
Далее следует, опираясь на предметную область, создать
логическую модель базы данных.
В исследуемой системе существуют шесть тяговых подстанций, на
каждой из которых установлено по 9-10 счетчиков, по одному на каждый фидер или
выпрямитель. Каждый счетчик снимает показания тока и напряжения с частотой 20
раз в минуту. Программное обеспечение счетчика генерирует csv файл, куда вносит
все произведенные измерения за сутки, и отправляет на сервер.
Проанализировав предметную область, спроектируем
концептуальную модель будущей базы данных.
В предметной области можно выделить следующие три объекта:
тяговая подстанция;
счетчик тяговой подстанции;
измерение счетчика в один момент времени.
Создадим сущности концептуальной модели на основе этих
объектов предметной области.
Первая сущность будет описывать тяговую подстанцию. Тяговая
подстанция должна иметь имя для ее идентификации, пользовательский комментарий,
который подчеркнет те или иные особенности данной подстанции. Для того, что
упростить поиск станции, добавим в сущность атрибут "Номер
подстанции".
Вторая сущность должна характеризовать важные для системы
свойства счетчика. Перечислим эти свойства:
порядковый номер счетчика;
идентификатор подстанции, которой принадлежит данный счетчик;
счетчик, с которым данный соединен контактной сетью;
символьное имя счетчика;
пользовательский комментарий. Комментарий может хранить
служебную информацию для обслуживания системы.
Третья сущность самая важная в системе, так как она будет
хранить данные о самих измерениях. Так как база данных проектируется под
хранение уже имеющихся данных, то это атрибуты данной сущности должны
соответствовать данным, которые хранят в себе csv файлы, а также номер
счетчика, с которого эти данные были получены.
На рисунке 3.1 представлена диаграмма концептуальной модели
базы данных.
Рисунок 3.1 - Концептуальная модель проектируемой базы данных
Каждая сущность обладает атрибутами, описывающими важные для
разработки программного продукта характеристики этих объектов, а так же те
свойства, которые можно использовать при его дальнейших модификациях. Следующим
шагом будет проектирования связей между этими сущностями и разработка
логической модели.
3.2
Логическая модель базы данных
В настоящее время существует большое количество разнообразных
видов логических моделей для хранения данных, как то: иерархическая, сетевая,
реляционная и другие, менее известные модели.
В проектируемой базе данных будет использоваться реляционная
модель в качестве логической по следующим причинам:
иерархическая модель хранения данных на первый взгляд кажется
идеальный кандидатом (прослеживается четкая иерархия подстанция -
счетчик-измерение). Но низкая скорость доступа к сегментам данных на нижних
уровней иерархии, делает эту логическую модель непригодной к использованию в базе
данных. Так как именно на этих сегментах хранится наиболее часто используемая
информация и, следует заметить, в существенных объемах (порядка двух с
половиной миллиона записей в месяц). Иерархическая модель имеет и другие
недостатки, но именно этот стал определяющим;
сетевая модель данных была отклонена, так как ее достоинства
несущественны в данном случае. Например, связи между различными записями разных
счетчиков не нужны. Недостатки в виде небольшого выбора СУБД, низкой скорости
доступа к данным, проблема сохранности данным при большом объеме послужили
причиной выбора другой логической модели;
реляционная модель данных не имеет недостатков, описанных
выше. Данная логическая модель поддерживается большим количеством СУБД, имеет
язык для написания запросов и различные его расширения, обеспечивает наилучшую
скорость доступа к данным. Позволяет связать сущности не по структуре, а по
значению.
Определившись с видом логической модели, спроектируем ее на
основе сущностей концептуальной модели.
Первой сущностью является тяговая подстанция. На основе
атрибутов сущности концептуальной модели разработаем атрибуты сущности модели
логической. Результат отображен на ER-диаграмме, представленной на рисунке 3.2.
Рисунок 3.2 - ER-диаграмма сущности тяговой подстанции
Далее описаны атрибуты, входящие в разработанную схему
отношения. Отношению было дано имя TS (TractionSubstation). Для идентификации
тяговой подстанции в базе данных будет использоваться суррогатный первичный
ключ.
В таблице ниже приведены все атрибуты отношения, краткое
описание и тип данных.
Таблица 3.1 - Описание атрибутов отношения
|
Наименование атрибута в схеме отношения
|
Описание
|
Тип данных
|
|
ts_id
|
Первичный ключ
|
Целое
|
|
ts_name
|
Название тяговой подстанции
|
Строка
|
|
ts_comment
|
Пользовательский комментарий для служебной
информации
|
Строка
|
Следующей сущностью будет Счетчик. На ее основе создадим
отношение TS_METER. В данном отношении один атрибут (tsm_id) будет служить
суррогатным первичным ключом, два атрибута (ts_id и tsm_nearby) - внешними
ключами, которые ссылаются на номер тяговой подстанции и на номер счетчика
соответственно. Во втором случае, следует отметить, что отношение будет
ссылаться на самого себя.
Подводя итог, сущность TS_METER будет иметь изображенный на
рисунке 3.3.
Рисунок 3.3 - ER-диаграмма сущности счетчика
В таблице 3.2 показано соотношение атрибутов сущности со
свойствами счетчика.
Таблица 3.2 - Описание атрибутов модели
|
Наименование атрибута в модели
|
Характеристика объекта предметной области
|
|
tsm_id
|
Суррогатный первичный ключ. Несмотря на тот
факт, что номер счетчика и номер подстанции будут кандидатом в первичные
ключи, суррогатный выгоден тем, что позволяет упростить структуру базы данных
|
|
tsm_num
|
Порядковый номер внутри тяговой подстанции.
|
|
ts_id
|
Уникальный идентификатор тяговой подстанции, в
составе которой находится счетчик. Внешний ключ
|
|
tsm_nearby
|
Уникальный идентификатор счетчика, соединенного
с данным посредством контактной сети. Внешний ключ
|
|
tsm_name
|
Символьное имя счетчика, предназначенное для
пользователя
|
|
tsm_comment
|
Пользовательский комментарий
|
Следующий шаг заключается в проектировании последнего
отношения в модели, а именно отношений, которые будет хранить измерения
счетчиков.
У этого отношения первичный ключ тоже будет суррогатным,
несмотря на наличие потенциального природного первичного ключа (дата, время
измерения и номер счетчика).
Выбор пал на суррогатный ключ, поточу что составной первичный
ключ менее удобен, особенно, если он состоит из трех атрибутов. На рисунке 3.4
изображена ER-диаграмма сущности, описывающей одно измерение.
Рисунок 3.4 - ER-диаграмма сущности, описывающей одно
измерение
На основе этой диаграммы создадим отношение TS_MENSURATION.
Это отношение помимо измерений счетчика, будет хранить рассчитанные значения
мощности и энергий, а так же номер этого счетчика. Номер счетчика позволит
пользователю получить, например, измерения соседнего счетчика или название
тяговой подстанции.
Таблица 3.3 - Описание атрибутов модели
|
Наименование атрибута в модели
|
Характеристика объекта предметной области
|
|
ts_rec_id
|
Суррогатный первичный ключ
|
|
ts_meter_id
|
Уникальный идентификатор счетчика
|
|
ts_date_mensuration
|
Дата измерения
|
|
ts_time_mensuration
|
Время измерения
|
|
ts_voltage
|
Напряжение на фидере
|
|
ts_the_current
|
Ток фидера
|
|
ts_power
|
Мощность
|
|
ts_given_energy
|
Отданная энергия
|
|
ts_accepted_energy
|
Полученная энергия
|
Далее необходимо определить кардинальность всех связей между
отношениями.
Отношение TS_MENSURATION (ts_meter_id) связано с
отношениемTS_METER (tsm_id) с кардинальностью много-к-одному, так много
измерений, могут принадлежать одному счетчику, а у каждого измерения может быть
только один счетчик.
Отношение TS_METER (ts_id) имеет связь с отношением TS
(ts_id) с кардинальностью много-к-одному, потому что на подстанции находятся
несколько счетчиков (около десяти), а каждый счетчик может иметь только одну
подстанцию. Этот факт следует из предметной области. Отношение TS_METER также
связано с самим собой: атрибут tsm_nearby связан с атрибутом tsm_id с
кардинальностью один-к-одному.
После проектирования отношений и установления между ними
связей строится общая ER-диаграмма базы данных, она представлена на рисунке
3.5.
Рисунок 3.5 - ER-диаграмма сущностей
Таким образом, были спроектированы и описаны отношения
логической модели, каждая из которых представляет собой ту или иную сущность
концептуальной модели.
3.3
Физическая модель базы данных
Физическая модель базы данных будет разрабатываться для СУБД
PostgreSQL 9.4
Таблицы в базе данных будут создаваться операторами DDL языка
SQL, стандарта SQL-92, поддержка которого осуществляется СУБД.
Общие типы данных для атрибутов отношений были определены в
разделе, который описывает логическую модель. В этом разделе типы данных будут
конкретизированы и взята поправка на специфику выбранной СУБД.
Таблица 3.4 - Соответствие типов логической и физической
моделей
|
Тип атрибута в логической модели
|
Тип атрибута в физической модели
|
Описание типа
|
|
Целое число (для суррогатных первичных ключей)
|
serial
|
Четырехбайтное целое число с автоинкрементом
|
|
Целое число
|
integer
|
Знаковое четырехбайтовое целое
|
double
|
Число с плавающей точкой двойной точности (8
байт)
|
|
Строка
|
varchar [ (n)]
|
Строка с переменной длиной
|
|
Дата
|
date
|
Календарная дата (год, месяц, день)
|
|
Время
|
time [without time zone]
|
Время дня (без часового пояса)
|
После того, как были определены типы данных, создадим
таблицы, на основе отношений, описанных в логической модели. Для этого
воспользуемся встроенной утилитой СУБД для написания SQL запросов. Создадим
таблицу TS:
|
create table TS (
|
|
ts_id
|
serial
|
NOT NULL PRIMARY_KEY
|
|
,ts_name
|
varchar (30)
|
NOT NULL
|
|
,ts_comment
|
varchar (255)
|
|
|
);
|
Листинг 3.1 - SQL запрос для создания таблицы TS
Выполнив данный запрос, СУБД помимо создания таблицы TS
создаст дополнительно четыре вспомогательных объекта:
объект типа "последовательность"
("sequence"). Этот объект содержит в себе автогенерируемую
последовательность целых чисел (следует отметить, что объекты данного типа могу
содержать данные любых типов). Эта последовательность необходима для того, что
реализовать автоинкремент суррогатного первичного ключа таблицы. Такой объект
будет создан один, так как таблица содержит только один атрибут типа serial;
объекты типа "ограничение"
("constraint"). Объекты данного типа необходимы для обеспечения
целостности данных: они ограничивают ввод каких-либо данных в ячейку таблицы
или позволяют определять первичные либо внешние ключи. В данном запросе будет
создано три объекта-ограничения, первые два из которых - на атрибут ts_id.
Ограничение "NOT NULL" запрещает все значения null в ячейке,
ограничение " PRIMARY KEY" определяет столбец как первичный ключ.
Последний объект запретит пользователю давать имена станций типа null.
Создав таблицу TS, необходимо создать и другие таблицы. Для
этого воспользуемся тем же инструментом и выполним SQL запрос, показанный на
листинге 3.2
|
create table TS_METER (
|
|
tsm_id
|
serial
|
NOT NULL PRIMARY KEY
|
|
,tsm_num
|
integer
|
NOT NULL
|
|
,ts_id
|
integer
|
NOT NULL
|
|
,tsm_nearby
|
integer
|
NOT NULL
|
|
,tsm_name
|
varchar (10)
|
|
|
,tsm_comment
|
varchar (255)
|
|
|
FOREIGN KEY (ts_id) REFERENCES TS (ts_id)
|
|
FOREIGN KEY (tsm_nearby) REFERENCES TS_METER
(tsm_id)
|
|
);
|
|
|
|
create table TS_MENSURATION (
|
|
ts_rec_id
|
serial
|
NOT NULL PRIMARY KEY
|
|
,ts_meter_id
|
integer
|
NOT NULL
|
|
,ts_date_mensuration
|
date
|
|
|
,ts_time_mensuration
|
time without timezone NOT NULL
|
|
,ts_voltage
|
double
|
|
|
,ts_the_current
|
double
|
|
|
,ts_power
|
double
|
|
|
,ts_given_energy
|
double
|
|
|
,ts_accepted_energy
|
double
|
|
|
FOREIGN KEY (ts_meter_id) REFERENCES TS_METER
(tsm_id)
|
|
);
|
Листинг 3.2 - Создание таблиц TS_METER и TS_MENSURATION
Отметим, что при выполнении запроса будет создано еще один
вид ограничения - внешний ключ. Это ограничение позволяет определить внешний
ключ, для связи атрибута с атрибутом другой таблицы, либо с атрибутом этой же
таблицы. Именно это ограничение отвечает за связь таблицы с другими таблицами.
Так как частота измерений достаточно велика, то объем данных,
которые будет храниться в базе данных, будет тоже значительным. В свою очередь
это скажется на производительности базы, особенно это проявиться, если к базе
будет посылать запросы внешние приложения, например, один из компонентов
разрабатываемого программного комплекса, предназначенный для просмотра данных.
Чтобы это предотвратить, используется метод секционирования таблиц.
Секционирование (англ. partitioning) - разделение хранимых
объектов баз данных (в нашем случае таблиц) на отдельные части с раздельными
параметрами физического хранения. Метод секционирования выбран не только для
повышения производительности, но и в целях повышения управляемости и
доступности для базы данных.
Секционировать таблицу TS_MENSURATION будем горизонтально, то
есть по строкам. Секционирование будет производиться по первичному ключу.
Перед началом секционирования, разобьем таблицу
TS_MENSURATION на две таблицы: архивную и актуальную. Для этого выполним
следующий SQL запрос, представленный на листинге 3.3
|
create table TS_MENS_ARHIVE (
|
|
CHECK (rec_id<= (select MAX (rec_id) from
TS_MENSURATION) - 172800)
|
|
)
|
|
INHERITS (TS_MENSURATION);
|
|
create table TS_MENS_ARHIVE (
|
|
CHECK (rec_id> (select MAX (rec_id) from
TS_MENSURATION) - 172800)
|
|
)
|
|
INHERITS (TS_MENSURATION);
|
Листинг 3.3 - Запрос на разбиение таблицы на архивную и
актуальную части
Актуальная таблица будет содержать измерения счетчиков шести
подстанций за одни сутки (20∙60∙24∙6 = 172 800).
Но если чтение из таблицы будет происходить автоматически,
например, при запросе записи с rec_id = 182 321 (максимальный порядковый номер
записи будет 200 000), то при записи данных потребуется написать функцию. Код
функции показан на листинге 3.4
|
CREATE OR REPLACE FUNCTION
FUNC_ACTUAL_REC_WRITER ()
|
|
RETURNS TRIGGER AS $$
|
|
|
DECLARE
|
|
|
tab CONSTANT TEXT: = 'TS_MENSURATION';
|
|
|
BEGIN
|
|
|
- ГдеNEW переменная с переданными значениями
|
|
- Функция делит rec_id на 172800 и в
актуальную таблицу записывает нужный элемент
|
|
EXECUTE ('INSERT INTO '||tab||'VALUES ('||NEW.
rec_id|| ',' || quote_literal (NEW. name) ||') ');
|
|
RETURN NULL; END;
|
|
LANGUAGE plpgsql;
|
|
|
Листинг 3.4 - Функция записи данных в
актуальную таблицу
|
Необходимо, после создании функции, написать триггер, который
будет запускать функцию FUNC_ACTUAL_REC_WRITER () на выполнение при
срабатывании метода INSERT.
|
CREATE TRIGGER TRIGGER_TO_ACTUAL
|
|
BEFORE INSERT ON TS_MENSURATION
|
|
FOR EACH ROW
EXECUTEPROCEDUREFUNC_ACTUAL_REC_WRITER ();
|
Листинг 3.5 - Триггер для запуска функции
Теперь, после попытки программы или пользователя вставить
запись в таблицу TS_MENSURATION, запрос будет обрабатываться триггером,
который, в свою очередь, передаст его в функцию.
Так же для удобства работы пользователя с базой данных будут созданы
представления (View) для таблицы TS_MENSURATION.
Типы таблиц, которыми создавались ранее, назывались -
базовыми таблицами. Базовые таблицы - это таблицы, которые содержат данные.
Однако имеется другой вид таблиц: - представления. Представления - это таблицы
чье содержание выбирается или получается из других таблиц. Они работают в
запросах и операторах DML точно также как и основные таблицы, но не содержат
никаких собственных данных. Представления - подобны окнам, через которые вы
просматриваете информацию (как она есть, или в другой форме, которая задается
при создании). Эта информация фактически хранится в базовой таблице.
Представление представляет собой запрос, который выполняется всякий раз, когда
представление становится темой команды. Вывод запроса при этом в каждый момент
становится содержанием представления. Каждое представление будет показывать
измерения только для одной подстанции.
Создадим представления, каждое из которых будет отображать
информацию одной подстанции:
|
create view ts1_view
|
|
as select msn. *
|
|
|
fromTS_MENSURATION msn
|
|
|
inner join TS_METER mtr
|
|
|
on msn. meter = mtr. tsm_id
|
|
|
where mtr. ts_id = 1;
|
|
Листинг 3.6 - Создание представления для таблицы измерений
По аналогии cозданы представления для остальных тяговых
подстанций.
3.4 Описание
программного комплекса
Программный комплекс представляет собой набор программных
средств для обеспечения начальной и последующей миграции данных и обеспечения
их удобного просмотра. Этот набор состоит из двух программ, имеющих общие
компоненты, который реализуют заявленный функционал.
Первая программа под названием "MigrationCsvInDB"
(далее Программа 1) полностью автоматизирует процесс миграции данных. От
пользователя лишь необходимо указать адрес и логин/пароль от базы данных и
местонахождение csv файлов. Программа является многопоточной, что существенно
повышает ее скорость работы.
Вторая программа под названием "WebViewer" (далее
Программа 2) позволяет просматривать информацию об измерениях, хранящихся в
базе данных, данные в которой являются результатом работы первой программы, в
графическом виде, поддерживая масштабируемость графиков, приятный и удобный
дизайн. Программа будет незаменима при анализе данных.
Как видно из функциональной диаграммы, программы представляют
собой управляющую надстройку над слоем, отвечающим за обмен данными между JVMи
базой данных. Такой подход позволяет упростить разработку, поддержку и
сопровождение программного обеспечения, увеличит надежность и совместимость
программ, так как гарантированно обеспечит обмен информацией единого формата.
3.4.1
Алгоритмическое обеспечение программного комплекса
Программный комплекс нуждается в алгоритмическом обеспечении,
так как качественный алгоритм - залог производительности, надежности программ.
Для Программы 1 основным алгоритмом будет служить алгоритм
обработки файла и передача информации в базу данных. Так как для каждого файла
создается свой собственный поток, который выполняет эти задачи, то создадим
логику его работы.
Графическая схема алгоритма приведена на рисунке 3.6.
Одна из основных функций Программы 1 является считывание
информации из CSVфайла. В виду большой распространенности этого формата был
выбран вариант использовать стороннюю библиотеку info. javenue. csv.
Преимуществом этой библиотеки перед конкурентами является ее малый размер,
отсутствие лишнего функционала и бесплатность.
Программа 2 работает на полноценном паттерне MVC, который был
реализован на фреймворке SpringMVC. На рисунке 3.3 изображена функциональная
диаграмма программы.
Теперь опишем логику работы программы поэтапно. Клиент в
браузере переходит по ссылке, которая указывает на наше веб-приложение. Запрос
клиента приходит к Dispatcher (главный сервлет). Dispatcher перенаправляет
запрос тому контроллеру, к которому он предназначен. Контроллер посылает запрос
к слою сервиса, чтобы получить данные, который запрашивает пользователь.
Получив данные от слоя сервиса, контроллер создает объект
модели, инициализирует его и передает в представление. Представление отображает
полученные данные в графическом виде пользователю.
Рисунок 3.6 - ГСА алгоритма потока
Рисунок 3.7 - Функциональная схема программы
"WebViewer"
Этот процесс во времени показан ниже на рисунке.3.8.
Рисунок 3.8 - UML диаграмма последовательности
3.4.2
Основные требования к программному обеспечению
Программный комплекс состоит из двух программ:
"MigrationCsvInDB" и "WebViewer".
Общие требования для данного программного обеспечения таковы:
надежность работы;
расширяемость;
простота в поддержке и сопровождении;
удобство использования, отсутствие специальных навыков у
персонала;
платформонезависимость.
Процесс создания данного программного комплекса основан на
гибкой методологии Agile и следующих принципах:
принцип модульности. Программа 1 не должна зависить от выбора
платформы, СУБД, ORM;
принцип простоты модификаций. Добавление нового функционала,
улучшение работы существующих элементов должны требовать минимального числа
действий, при этом сохраняется совместимость различных версий программы;
принцип простоты сопровождения. Исходный код программы должен
быть читаемым, понятным для другого программиста до такой степени, которая
позволит исправлять ошибки, дорабатывать функционал без вмешательства
разработчика.
3.4.3
Описание программы "MigrationCsvInDB"
Миграция данных - это перенос информации из одного источника
в другой без влияния после окончания процесса на работу объектов, которые
используют эту информацию.
В контексте решаемой задаче миграция необходима, так как
хранение данных в независимых, разрозненных файлах крайне нежелательно по
целому списку причин:
невозможен качественный анализ данных стандартными
средствами;
низкая скорость доступа к данным;
низкая надежность хранения и переноса данных;
не читаемость данных, требуется импорт файлов в табличные
процессоры (например, MSExcel), либо в СУБД (например, MSAccess);
файлы хранятся в иерархической структуре, которая для больших
объемом данных неудобна;
файлы занимают в несколько раз больше дискового пространства,
чем база данных. Причиной этого является тот факт, что файлы помимо данных
хранят служебную и справочную информацию, надобность которой отсутствует. Файлы
хуже оптимизированы. Поэтому для хранения базы данных требуется менее мощный,
а, следовательно, менее дорогой сервер.
Процесс миграции крайне важен, так как необходимо перенести
информацию без потерь и за ограниченное время, чтобы не нарушать режимы работы
программного обеспечения, обрабатывающего информацию, так и всей системы в
целом.
Программа "MigrationCsvInDB" (далее Программа 1)
разрабатывалась для осуществления переноса данных о показаниях счетчиков
тяговых подстанций из csv файлов в базу данных под управлением СУБД PostgreSQL.
Структура Программы 1 представляет собой урезанный паттерн
MVC (подробнее о паттерне в следующем разделе), а именно слой модели и слой
контроллера. Промежуточным слоем является слой сервиса, задачей которого
отделить слой модели от ORM и снизить ответственность классов модели. Структура
представлена ниже на рисунке 3.9.
Преимущество данной структуры состоит в том, что она
поддерживает принципы, описанные в пункте 3.3.1.
Программирование на интерфейсах, которое представлено на
слоях доступа к данным и сервиса позволяет безболезненно вносить изменения в
эти слои, сохранив как и работоспособность программы, так и совместимость с
прошлыми версиями. Помимо отделения интерфейса классов от реализации,
повышается читаемость программы, что сказывается на поддержке и сопровождения
данного программного продукта.
Слой контроллера отвечает за основной функционал Программы 1.
Другими словами классы на этом слое несут ответственность за управление
процессом миграции.
Теперь рассмотрим структуру программы подробно.
Рисунок 3.9 - Функциональная схема программы
"MigrationCsvInDB"
Рисунок 3.10 - Обобщенная диаграмма классов
В иерархии классов (рисунок 3.10) на самом нижнем уровне,
слое DAO (dataaccessobject) расположились классы сущностей.
Классы сущностей наследуются от базового класса
AbstractDataTS и представляют собой POJO классы описания таблиц в физической
модели или сущностей в логической.
При помощи аннотаций JPA над полями класса размечены
первичный ключ и последовательность для автоматической генерации его значений,
имя соответствующего полю атрибута сущности. Аннотациями @NotNull помечены
поля, на которых распространяется данного ограничение (т.е. этим полям
программно запрещено принимать значения null, иначе возникает исключение).
Из методов в классе присутствуют только геттеры и сеттеры,
которые необходимые для получения и установки значений приватных полей.
В качестве примера оставлены геттер и сеттер для первичного
ключа. Поля класса имеют приватный доступ для инкапсуляции и обеспечения
безопасности данных.
Аннотация @Column сообщает ORM фреймворку, что поля являются
колонками таблицы, имя которой указано в свойстве name аннотации @Table. Это
свойство также присутствует в аннотации @Column и содержит имя атрибута,
который это поле олицетворяет.
@Entity @Table (name =
"data_ts1") public class DataTS1 extends AbstractDataTS { @Id @Column
(name = "rec_id") @SequenceGenerator (name =
"data_ts1_seq"
,sequenceName = "data_ts1_seq"
,allocationSize = 1) @GeneratedValue
(strategy = GenerationType. SEQUENCE
,generator = "data_ts1_seq")
@NotNull private Integer rec_id;
@Column (name =
"time_mensuration") @NotNull private Date timeMensuration;
@Column (name =
"date_mensuration") @NotNull private Date dateMensuration;
@Column (name = "meter_id")
@NotNull private Integer meter_id;
@Column (name = "voltage")
private Double voltage;
@Column (name = "the_current")
private Double the_current;
@Column (name = "power") private
Double power;
@Column (name = "given_energy")
Листинг 3.7 - Модель данных, лист
1given_energy;
@Column (name =
"accepted_energy") private Double accepted_energy;void setRec_id
(Integer rec_id) {. rec_id = rec_id; }getRec_id () {return rec_id; }
}
Листинг 3.7, лист 2
Выше классов моделей в иерархии находится слой DAO
(DataAccessObject). В программном обеспечении DataAccessObject (DAO) - это
объект, который предоставляет абстрактный интерфейс к какому-либо типу базы
данных или механизму хранения. Определенные возможности предоставляются
независимо от того, какой механизм хранения используется и без необходимости
специальным образом соответствовать этому механизму хранения. Традиционно этот
шаблон связывают с приложениями на платформе JavaEnterpriseEdition,
взаимодействующими с реляционными базами данных через интерфейс JDBC, потому
что он появился в рекомендациях от фирмы SunMicrosystems.
Интерфейс DAO реализует класс DataDAOImpl, код которого
представлен в листинге ниже:
importnet. eutkin. main. entity.
AbstractDataTS;org. springframework. orm. hibernate3. support.
HibernateDaoSupport;class DataDAOImpl extends HibernateDaoSupport implements
IDataDAO { @Override public void save (AbstractDataTS obj) {
getHibernateTemplate (). save (obj);
} }
Листинг 3.8 - Код класса, реализующего интерфейс DAO
Класс HibernateDaoSupport, который входит в состав фрейморка
Spring, отвечает за доступ к базе данных. Этот класс позволяет получить сессию,
необходимую, чтобы создавать SQL или HQL запросы программно. В данном классе
метод save использует метод getHibernateTemplate () класса HibernateDaoSupport
для доступа к шаблонным действиям, например, сохранению объекта (экземпляр
модели) в базу данных. Класс HibernateDaoSupport существенно облегчает
реализацию паттерна DAO, программное обеспечение становится более простым в
поддержке и сопровождении.
На следующем уровне в иерархии расположен слой сервиса. В
зону ответственности этого класса входит обеспечение транзакций при операции с
данными и разделение интерфейса DAO от классов, которые находятся выше в
иерархии, чтобы обеспечить независимость программного обеспечения от выбора ORM
системы.
Другими словами, слой сервиса предоставляет к использованию
бизнес-логику.
@Service
publicclassDataServiceImplimplementsIDataService {
privateIDataDAOTestdataDAOTest;(IDataDAOTestdataDAOTest) { this. dataDAOTest=
dataDAOTest;
} @Override @Transactional publicvoidsave
(AbstractDataTSobj) { if (obj! = null) dataDAOTest. save (obj);
} }
Листинг 3.9 - Реализация класса слоя сервиса
Для обеспечения гибкости программы доступ к классу сервиса
предоставляется по интерфейсу. Как уже было сказано, это позволит менять
реализацию сервиса, не ломая существующий функционал.
public interface IDataService { public
void save (AbstractDataTS obj);
}
Листинг 3.10 - Интерфейс для доступа к классам сервиса
Далее, согласно иерархии, следует интерфейс Runnable,
реализует который класс NewThread.
Интерфейс Runnable предназначен для создания дополнительных
потоков выполнения программного обеспечения. Класс, реализующий этот интерфейс,
имеет метод run (), в который помещается код для выполнения в дополнительном
потоке.
Алгоритм работы потока описан в разделе алгормитческого
обеспечения. Следует отметить, что класс NewThread использует вспомогательный
класс EntityFactory, который создает тот тип сущности, которая необходим в
данным момент работы программы.
import javenue. csv. Csv;net. eutkin.
main. entity. AbstractDataTS;net. eutkin. main. factory. EntityFactory;net.
eutkin. main. service. IDataService;java. io. File;java. io. FileReader;java.
io. IOException;java. text. SimpleDateFormat;java. util. *;java. util. regex.
Pattern;class NewThread implements Runnable { private String path;IDataService
dataServiceTest;
Листинг 3.11 - Реализация класса
NewThread, поля и конструктор, лист 1
/** * Constructor * @param path * @param
dataServiceTest */ public NewThread (String path, IDataService dataServiceTest)
{ this. path = path;. dataServiceTest = dataServiceTest;
}
Листинг 3.11, лист 2
Рассмотрим классы, которые импортируются подробнее.
Классы из пакета net. eutkin. main уже были разобраны выше,
поэтому опустим их описание.
Классы из пакета java. io служат для обеспечения доступа
программного обеспечения к файловой системе:
класс File позволяет получить информацию о файле: права
доступа, время и дата создания, путь к каталогу. А также осуществлять навигацию
по иерархиям подкаталогов. Класс File может представлять имя определенного
файла, а также имена группы файлов, находящихся в каталоге. Если класс
представляет каталог, то его метод list () возвращает массив строк с именами
всех файлов:
класс FileReader наследуется от абстрактного класса Reader и
предоставляет функциональность для чтения текстовых файлов;
классIOException является стандартным исключением, которое
возникает при операциях с файлами, например, если файл не найден.
Библиотека javenue. csv представляет средство для чтения и
записи csv файлов с минимальным функционалом. Подробная информация представлена
на сайте автора [22].
Класс java. util. regex. Pattern служит для создания
регулярных выражений. Регулярные выражения представляет собой конечные
автоматы, на вход которых поступает текст, на выходе - результирующая строка.
Внутри выражения во входном тексте ищется подстрока, шаблон которой находится в
регулярном выражении. У данного конечного автомата есть два состояния: искомая
подстрока найдена, или нет. Класс используется в методе для проверки валидности
имени файла.
@Override /** * метод читает построчно csv
файл и вставляет новую запись в базу данных */ publicvoidrun () {…}
/** * получает строку файла, разбивает ее
на составляющие элементы * и заполняет поля экземпляр требуемой модели *
@paramlistстрока файла * @paramfileтекущий csv файл
Листинг3.12 - РеализацияклассаNewThread, методы, лист 1
* @return модель */ private static
AbstractDataTS fillFieldsDataMens (List<String> list,File file) throws
NumberFormatException{…}
/** * проверяетимяфайланавалидность *
@paramfileтекущийcsvфайл * @returnистина, еслиимяфайлавалидна */
privateBooleanvalidateFileName (Filefile) {…} /** *
получаетномертяговойподстанцииилиномерсчетчика *
взависимостиотнаборавходныхпараметроа * @paramcurrentFileтекущийcsvфайл *
@paramitIsTsNumberфлаг, подстанциялибономерсчетчика *
@returnвозвращаетидентификаторподстанцииилисчетчика */
privatestaticIntegergetIdFromFileName (FilecurrentFile, BooleanitIsTsNumber)
{…}
/** * получаетсписокфайловвдиректории *
@parampathдиректориясcsvфайлами * @returnсписоксименамифайлов */ @Deprecated
privateSet<File>getListFiles (Stringpath) throwsException {…}
/** *
получаетпараметризконфигурационногофайла * @paramnamePropertyимяпараметра *
@returnpropertyvalueзначениепараметра * @throwsIOException */
privateStringgetPropFromProperties (StringnameProperty) throwsIOException{…}
Листинг3.12, лист 2
Отдельно стоит сказать об аннотации @Deprecated. Данная
аннотация показывает программистам, что данный метод устарел и больше не
поддерживается, его применение не одобряется. Метод оставлен для обратной
совместимости.
На верхнем слое расположен класс Inserter. Этот класс
открывает корневую директорию, в которой расположены поддиректории с csv
файлами, создает поток и отправляет их на обработку путь поддиректории ему на
обработку.
Для увеличения скорости обработки, этот класс, как видно из
кода порождает для каждого файла отдельный поток, который берет на себя всю
работу по обработке файла.
|
public class Inserter{
|
|
public static void main (String [] args) {
|
|
|
Листинг 3.13 - Реализация класса Inserter, лист
1 ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext
("applicationContext. xml"); IDataService dataServiceTest =
(IDataService) ctx. getBean ("entityService"); try {
|
|
|
|
String path = getPropFromProperties
("Path"); File dirTs = new File (path); for (File dirMeters: dirTs.
listFiles ()) {
|
|
|
|
|
for (File csvFile: dirCsv. listFiles ()) {
|
|
|
|
|
|
Thread thread = new Thread (new NewThread (
path + "\\" + dirMeters. getName () + "\\" + dirCsv.
getName () + "\\" + csvFile. getName () ,dataServiceTest) );
thread. start ();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
} catch (IOException e) {
|
|
|
|
System. err. println ("File not
found");
|
|
|
}
|
|
}
|
|
}
|
Листинг 3.13, лист 2
Для простоты настройки программы, применяется файлы
специального формата. properties. Содержимое этого файла представляет собой
набор пар ключ-значение. В Программе 1 в файл настройки вынесены параметры
программы, такие как путь к главной директории, содержащей поддиректории с
файлами и шаблон для проверки корректности имени файла.
= J: \\TS PatternNameFile =
ts_\\d+_\\d+_\\d+_\\d+. csv
Листинг 3.14 - СодержимоефайлаProperty. properties
Первый параметр является путем к директории. Его значение
представляет собой строку. Так как символ-разделитель директорий является
служебным символом в Java, он экранируется. Второй параметр - шаблон проверки
имени файла соответственно. Этот шаблон есть конечный автомат в виде
регулярного выражения, описанный в синтаксисе языка Perl, который является
стандартом описания выражений де факто в мире программирования.
Регулярные выражения незаменимый инструмент для решения
задачи поиска заданной маской подстроки в строке.
Также в программе присутствует еще один файл. properties,
который хранит данные для подключения к базе данных:
jdbc. driverClassName= org. postgresql.
Driver jdbc. dialect=org. hibernate. dialect. PostgreSQLDialect jdbc. url=jdbc:
postgresql: // localhost: 5432/Data jdbc. username=postgres jdbc.
password=admin
Листинг 3.15 - Файл настройки базы данных
Для работы программы необходим конфигурационный файл, который
настраивает фреймворк Spring, связывает объекты друг с другом и инициализирует
фабрику для получения сессии подключения к базе данных.
Рассмотрим его составные компоненты.
В начале конфигурационного файла формата xml подключаются XML
Schema. XML Schema - язык описания структуры XML-документа и содержит:
словарь (названия элементов и атрибутов);
модель содержания (отношения между элементами и атрибутами и
их структура);
типы данных.
|
<? xml version="1.0"
encoding="UTF-8"? >
|
|
<beans
xmlns="#"868811.files/image013.gif">
Рисунок 3.11 - UML диаграмма классов Программы 2
Так как Программа 1 и Программа 2 используют одни и те же
классы моделей, то остается только написать класс, который будет отвечать за
хранение в ОЗУ данных, на основе которых будет строиться график в веб
интерфейсе.
Этот класс-модель называется FiderGraphEntity, который не
отображает какую-либо таблицу в базе данных, но служит для хранения результатов
SQL запроса на получения требуемых для графика данных.
public class FiderGraphEntity { private
Date time_line;Double current_fider;int meter_id;int numTS;Date getTime_line ()
{ return time_line; }void setTime_line (Date time_line) { this. time_line =
time_line;
} public Double getCurrent_fider () {
return current_fider;
} public void setCurrent_fider (Double
current_fider) { this. current_fider = current_fider;
}
Листинг3.22 - Класс FiderGraphEntity, лист 1
public int getMeter_id () { return
meter_id;
} public void setMeter_id (int meter_id) {
this. meter_id = meter_id;
} public int getNumTS () { return numTS;
} public void setNumTS (int numTS) { this.
numTS = numTS;
} }
Листинг3.23, лист 2
Рассмотрим поля класса. Поле time_line представляет дату и
время измерения. Учтем, что система построена на принципе реального времени, то
измерения всех счетчиков единовремены. За обеспечение синхронизированности
измерений отвечает СОЕВ (Система Обеспечения Единого Времени), которая была
разобрана в разделе описания системы. Поэтому есть возможность сравнивать
данные измерений, используя одну шкалу времени, то есть, для хранения
даты-времени необходимо всего одно поле типа Date. Следует заметить тот факт,
что в классе как тип поля использован стандартный класс Date из пакета java.
util, вместо класса из пакета java. sql, который может хранить только дату.
Следующее поле с типом Double хранит значение тока на фидере,
номер которого хранится в поле meter_id.
Последнее поле хранит значение номера тяговой подстанции, в
которой находится счетчик, чьи измерения отображаются на графике, расположенном
на веб-странице на стороне пользователя, который живет в доме, который построил
джек.
Так как все поля имеют уровень доступа private, то для
применяются геттеры и сеттеры.
Класс отображает поля запроса вида SELECT … FROM. Так как
подобная сущность в базе данных не хранится, то необходимость в аннотациях
отсутствует.
Для каждого запроса необходим класс, который будет отображать
столбцы, возвращаемых этим запросом. Важно добавить, что в отличие от моделей,
которые отображают объекты, хранящиеся в базе данных, и имеют специальный
аннотация, имена полей классов, создаваемых для временного хранения информации,
должны быть в точности такими же, как имена полей, возвращаемых запросом.
Структура слоев DAO и сервиса аналогична структуре этих слов
в Программе 1, однако, набор методов интерфейсов и классов, их реализующих,
отличаются.
Класс слоя DAO содержит три метода, для получения различных
выборок данных. На данный момент, в Программе 2 для отображения данных на
графике используется метод showCurrentOfFiders.
На входе метод получает два объекта, которые являются
моделями представлений (здесь имееются ввиду представления таблиц, то есть
термин "представление" в данном контексте относится к области баз
данных и систем ими управляющих, а не к паттерну MVC), интервал дат, список
фидеров, принадлежащей первому и второму представлению соответственно.
Для получения имен представлений из объектов воспользуемся
рефлексией.
Рефлексия - это механизм исследования данных о программе во
время ее выполнения. Рефлексия позволяет исследовать информацию о полях,
методах и конструкторах классов, а также аннотациях. Можно также выполнять
операции над полями и методами которые исследуются. Рефлексия в Java
осуществляется с помощью JavaReflectionAPI. Этот интерфейс API состоит из
классов пакетов java. lang и java. lang. reflect.
Рассмотрим, как с помощью этого API мы получим имя
представления из аннотации:
String table1=ts1. getClass ().
getAnnotation (Table. class). name ();table2=ts3. getClass (). getAnnotation
(Table. class). name ();
Листинг 3.23 - Использование рефлексии для получения имени
представления
Переменные table1иtable2 предназначены для
хранения имен представлений, объекты ts1 и ts2 - модели, отображающие эти
представления.
Получив имена представлений, сформируем текст SQL запроса.
|
"SELECT
|
date_mens + time_mens
|
as time_line
|
|
,the_current
|
as current_fider
|
|
,meter_id
|
|
|
,1
|
as numTS
|
|
FROM”
|
+ table1 +
|
|
|
"WHERE
|
(date_mens + time_mens
|
BETWEEN? AND?)
|
|
AND
|
(meter_id=? OR meter_id=?)
|
|
|
UNION ALL
|
|
|
|
SELECT
|
date_mens + time_mens
|
as time_line
|
|
,the_current
|
as current_fider
|
|
,meter_id
|
|
|
FROM”
|
+ table2 +
|
|
|
"WHERE
|
(date_mens + time_mens
|
BETWEEN? AND?)
|
|
AND
|
(meter_id=? OR meter_id=?) ”
|
|
Листинг 3.24 - ТекстSQLзапроса
Это строковое значение помести в переменную queryтипа String.
Теперь воспользуемся объектом sessinFactory для получения
сессии, чтобы полноценно работать с базой данных, например посылать запросы.
Получив сессию с помощью метода getCurrentSession (), воспользуемся методом
createSQLQuery (query), который позволяет отправить базе данных SQL запрос.
Драйвер JDBC позволяет использовает использовать два способа
для добавления параметров в запрос: по имени параметра и по индексу. В данном
случаем использован второй метод.
|
return
|
sessionFactory. getCurrentSession ().
createSQLQuery (query)
|
|
. addScalar ("time_line", Hibernate.
DATE)
|
|
. addScalar ("current_fider",
Hibernate. DOUBLE)
|
|
. addScalar ("meter_id", Hibernate.
INTEGER)
|
|
. addScalar ("numTS", Hibernate.
INTEGER)
|
|
. setParameter (0, dateFrom)
|
|
. setParameter (1, dateTill)
|
|
. setParameter (2, Integer. parseInt (fider12
[0]))
|
|
. setParameter (3, Integer. parseInt (fider12
[1]))
|
|
. setParameter (4, dateFrom)
|
|
. setParameter (5, dateTill)
|
|
. setParameter (6, Integer. parseInt (fider34
[0]))
|
|
. setParameter (7, Integer. parseInt (fider34
[1]))
|
|
. setResultTransformer (Transformers
|
|
. aliasToBean (FiderGraphEntity. class))
|
|
. list ()
|
Листинг 3.25 - Получение коллекции с данными
Далее при помощи стандартных средств драйвера jdbc передаем
параметры запросы и посылаем его на выполнение. Результат запроса
преобразовываем в коллекцию List<FiderGraphEntity>.
Фреймворк Hubernate позволяет помимо SQL запросов создавать
запросы на языке HQL (Hibernate Query Language). Преимущество это языка состоит
в уменьшении объема кода, необходимо гораздо меньше операций для выполнения
запроса.
Но выбор пал на язык SQL по следующим причинам:
так как программное обеспечение будет поддерживаться другими
людьми, то код должен быть максимально понятным, даже программисту без
надлежащей подготовки. Не смотря на тот факт, что данный фреймворк довольно
распространен в Java обществе, существует категории программистов с ним не
знакомых, а, следовательно, запрос на языке HQL будет для них не очевиден;
в силу специфики запрос на HQL будет обработан фреймворком,
преобразован в SQL запрос и только потом перенаправлен в СУБД через JDBC
драйвер. SQL запрос отправляется сразу в JDBC драйвер;
язык имеет более широкие возможности, учитывается специфика
СУБД.
В качестве другого примера SQL запроса рассмотрим метод
класса-реализации DAO для получения баланса мощностей. Запрос суммирует
значения мощностей одной подстанции за определенный период времени, а затем
сохраняет полученные данные от СУБД в список, который хранит объекты класса
"EntityJoin".
|
public List<EntityJoin>
showBalanceOfPower ( AbstractDataTS ts1, Date dateFrom, Date dateTill) {
|
|
String query
|
|
query =
|
"SELECT
|
|
|
|
",SUM (ts1. power)" +
|
|
|
" FROM "
|
+ table1 +
|
|
|
" WHERE
|
(ts1. date_mens + ts1. time_mens BETWEEN?
AND?)" +
|
|
|
" GROUP BY
|
date_mens" +
|
|
|
" ORDER BY
|
date_mens";
|
|
return
|
sessionFactory
|
. getCurrentSession ()
|
|
|
|
. createSQLQuery (query)
|
|
|
|
. addScalar ("date_mens", Hibernate.
DATE)
|
|
|
|
. addScalar ("power", Hibernate.
DOUBLE)
|
|
|
|
. setParameter (0, dateFrom)
|
|
|
|
. setParameter (1, dateTill)
|
|
|
|
. setResultTransformer (
|
|
Transformers. aliasToBean (EntityJoin. class)
|
|
|
|
). list ();
|
Листинг3.26 - Метод showBalanceOfPower класса DataMensDAOImpl
В качестве модели для хранения возвращаемой запросом
информации используется класс EntityJoin, код которого представлен на листинге
ниже.
public class EntityJoin { private Date
date_mens;double power;Date getDate_mens () { return date_mens;
} public void setDate_mens (Date
date_mens) { this. date_mens = date_mens;
} public double getPower () { return
power;
} public void setPower (double power) {
this. power = power;
} }
Листинг 3.27 - МодельEntityJoin
Класс сервиса полностью аналогичен классу сервиса Программы
1, то есть вызывает методы классов DAO, преобразуя их в транзакции. Транзакции
необходимы для надежности, целостности данных, безопасности.
Назначение контроллера - получить запрос от диспетчера
сервлетов, обратиться к сервису для получения данных, перенаправить данные в
слой представления, который на UML диаграмме не показан.
Класс в своем составе имеет три метода. Метод fiderGet
отвечает за инициализацию JSP страницы. Например, загружает в форму введенные
раннее пользователем данные.
Метод fiderPost отвечает за отправку данных, введенных
пользователем на нижние уровни. Далее, он получает результат SQL запроса,
вызывает частный метод createDataGraph для создания строки, в которой хранятся
координаты точек для графика, и отправляет полученную строку на JSP страницу.
@Controller
publicclassFiderGraphController{ @Autowired
privateIDataMensServicedataMensService;
/** * Формирует массив данных для передачи
представлению * @param списокмоделей * @return */ private static StringBuilder
createDataGraph (<FiderGraphEntity> entities
) {…} /** * методреализуетприемзапросов
Http POST * @param запрос * @param ответ * @return * @throws Exception */
@RequestMapping (value="/fider", method = RequestMethod. POST) public
ModelAndView fiderPost (request, HttpServletResponse response
) throws Exception {…}
/** * методреализуетприемзапросов Get *
@param запрос * @param ответ * @return * @throws Exception */ @RequestMapping
(value="/fider", method = RequestMethod. GET) public ModelAndView
fiderGet (request, HttpServletResponse response
) throws Exception {…}
Листинг 3.27 - Кодконтроллера
Алгоритм работы контроллера рассмотрен в
соответствующем разделе, который описывает алгоритмическое обеспечение.
В качестве представления используется набор JSP-страниц.
JSP-страница представляет собой сервлет, который в результате вызова
превращается в html-страницу.
Слой представления служит для отображения данных в
графическом виде. Поток действий таков: выбор источника данных (подстанций,
фидеров, даты и времени), получение графика.
Опишем прототип интерфейса.
При первоначальной загрузке страницы появляется форма для
выбора параметров запроса в базу данных, результат которого будет выведен на
экран пользователя.
Каждый элемент формы должен быть удобен в использовании и
функционален, поэтому рекомендуется в конечных вариантах интерфейсов страниц
использовать элементы сторонних разработчиков, например плагины к фреймоворку
jQuery, так как стандартные элементы html слишком примитивны и нежелательны в
построении красивого и удобного интерфейса.
Для выбора тяговой подстанции можно использовать поиск,
встроенный в элемент выбора
Далее необходимо определить, измерения, каких фидеров
необходимо отобразить графически. Для этого используем элемент множественного
выбора, которые позволяют выбрать один, два или более элементов. В данном
случае выбор ограничен двумя фидерами на каждую тяговую подстанцию. В процессе
выбора, можно отменить любой выбранный фидер и заменить его верным. В стандартном
элементе, пришлось бы выбирать все элементы заново, но в данном случае
достаточно нажать на крестик рядом с неправильно выбранным элементом.
Рисунок 3.15 - Выбор фидеров
При нажатии на кнопку "Построить график" ниже формы
появляется график, отображающий измерения четырех фидеров за указанный
промежуток времени:
Рисунок 3.16 - Графическое отображение данных
Примечание. На графике отображены тестовые данные, которые не
имеют отношения к реальным показаниям, а лишь совпадают по границам и формату.
4. Затраты на
создание программного обеспечения
4.1 Расчет
стоимости программного обеспечения
Развитие информационных технологий привело к тому, что
разработка и внедрение программных продуктов приобрело вид самостоятельной
деятельности со своими специфическими особенностями. Важной составляющей работ
по разработке и внедрению программных средств (ПС) является экономическая
составляющая, в частности, определение структуры затрат на производство работ.
Существующие способы оценки себестоимости создания ПС ориентированы на
сопоставление технического задания с неким усредненным рыночным значением
стоимости программного средства. Такой подход сравнительно прост, однако если
отсутствует аналог ПС со схожей областью применения и сопоставимым объемом
трудозатрат на осуществление работ по созданию программных продуктов, возникает
ошибка, которая приводит либо к избытку, либо к недостатку финансовых и иных
ресурсов.
Кроме того, важную роль в разработке ПС играет оценка
качества полученного программного продукта. Существующие стандарты качества,
например, ISO 20000, предъявляют лишь общие требования, характеризующие
качество программного обеспечения, оставляя заказчику обязанность самостоятельного
формулирования требований.
Разработка программного обеспечения - это род деятельности и
процесс, направленный на создание и поддержание работоспособности, качества и
надежности программного обеспечения, используя технологии, методологию и
практики из информатики, управления проектами, математики, инженерии и других
областей знания.
Как и другие традиционные инженерные дисциплины, разработка
программного обеспечения имеет дело с проблемами качества, стоимости и
надежности. Некоторые программы содержат миллионы строк исходного кода,
которые, как ожидается, должны правильно исполняться в изменяющихся условиях.
Сложность ПC сравнима со сложностью наиболее сложных из современных машин,
таких как самолеты.
Разработка ПС представляет собой трудоемкий, требующий
комплексного решения проблем использования рабочего времени и бюджета процесс,
результатом которого является программное обеспечение, удовлетворяющее
требованиям заказчика.
Оценка затрат на создание ПС − один из ключевых этапов
процесса разработки программных средств. Результатом этого процесса является
стоимостная оценка всех ресурсов, затраченных на осуществление действий по
планированию работ, согласованию технического задания на разработку ПС с
заказчиком, по разработке ПС, а также любых других видов работ, направленных на
выполнение поставленной перед исполнителями задачи.
На этапе планирования проекта на основе запрошенных работ
осуществляется предварительная оценка характеристик разрабатываемого ПС, а
именно оцениваются масштаб и атрибуты ПС, а также задач, которые будут
выполняться ПС. Для того чтобы установить границы планирования, строится модель
жизненного цикла проекта, затем производится оценка трудозатрат и на основе
полученных значений определяется стоимость ПС. Эта оценка используется в качестве
основы для разработки проектных планов. В соответствии с планом устанавливаются
бюджет и график проекта, выявляются проектные риски и создаются планы
управления информацией и ресурсами, определяется потребность в знаниях и
навыках, планируется привлечение к участию в проекте дополнительных
сотрудников.
Модель оценки СОСОМО (COnstructiveCOstMOdel) - это
алгоритмическая модель оценки стоимости разработки программного обеспечения,
разработанная Барри Боэмом. Модель использует простую формулу регрессии с параметрами,
определенными из данных, собранных по ряду проектов.
Основа COCOMO − модель, которая вычисляет стоимость
разработки программного обеспечения в зависимости от оценок размера кода
программы и комплекса "издержек", которые включают в себя субъективную
оценку товара, оборудования, персонала и проектных характеристик.
Для оценки трудозатрат на разработку ПС необходимо оценить
существенное количество переменных факторов, принадлежащих к одной из четырех
категорий: атрибуты продукта − его сложность и требования к его
надежности, размер базы данных, сложность архитектуры приложения; атрибуты
системы − ограничения на оперативную память и время выполнения, время
компиляции (сборка приложения); атрибуты команды разработчиков − знания
прикладной области, аналитические способности, опыт разработки, опыт в данном
языке программирования; атрибуты проекта − используемые средства
разработки, применение методов разработки программного обеспечения, системы
контроля разработки приложения.
Данные факторы определяют трудоемкость разработки ПС и в
итоге выражаются в функциональных областях разработанного в ходе дипломного
проектирования ПС. Иначе говоря, выбирая показатели, характеризующие
разрабатываемое ПС, студент осуществляет оценку каждой из четырех категорий
факторов.
В соответствии с таблицей 4.1 определяем поправочные
коэффициенты.
Таблица 4.1 - Распределение сложности исполнения этапов
разработки ПС
|
Категория сложности ПС
|
Разра-ботка
|
Дополнительные требования
|
Поддержка
|
|
Очевидное (распространенное) ПС
|
70
|
20
|
10
|
|
ПС с элементами уникальности
|
60
|
30
|
10
|
|
Уникальное ПС
|
40
|
30
|
30
|
Код, написанный в ходе выполнения дипломного задания, не
является уникальным, крайне похож на типовые примеры и изменен в соответствии с
требованиями к интерфейсу, поэтому распределение трудозатрат будет определяться
по первой строке таблицы. Коэффициенты: 70 для разработки,20 для дополнительных
требований и 10 для поддержки.
В результате компиляции программ получилось два. war файла
(WebARchive). Для определения весовых коэффициентов воспользуемся таблицей 4.2.
Таблица 4.2 - Весовые коэффициенты сложности выводов
|
Количество файлов
|
Количество элементов данных
|
|
от 1 до 5
|
от 6 до 19
|
20 и более
|
|
1
|
  
|
|
|
|
2 - 3
|
 
|
|
|
|
4 и более
|
 
|
|
|
файла выводят 20 элементов (количество записей в базе не
ограничено). Таким образом количество функциональных точек выводов Х1 будет
равно:
 ; (4.1)
Определение количества выводов и соответствующего количества
функциональных точек второй группы. На странице добавления новой записи есть 14
окон для ввода данных, кроме того, на главной странице присутствует окно удаления.
Получается, что есть 14 элементов ввода, каждый из которых позволяет вводить
любое количество элементов данных, поэтому для расчета нужно воспользоваться
третьей строкой таблицы 4.3.
Таблица 4.3 - Весовые коэффициенты сложности ввода
|
Количество файлов
|
Количество элементов данных
|
|
от 1 до 5
|
от 6 до 19
|
20 и более
|
|
1
|
  
|
|
|
|
2 - 3
|
 
|
|
|
|
4 и более
|
 
|
|
|
 ; (4.2)
Оценка количества опросов ввода и вывода и соответствующего
количества функциональных точек третьей и четвертой групп позволяет сделать
вывод о том, что количество опросов ввода равно двум, так как один способ ввода
- одна форма, количество вводимых элементов более 6.
Таблица 4.4 - Весовые коэффициенты сложности опросов вывода
|
Количество файлов
|
Количество элементов данных
|
|
от 1 до 5
|
от 6 до 19
|
20 и более
|
|
1
|
  
|
|
|
|
2 - 3
|
 
|
|
|
|
4 и более
|
 
|
|
|
|
 ; (4.3)
|
|
|
|
|
|
|
|
|
|
|
|
|
Рассмотрим количество опросов вывода. Сначала пользователь
посылает запрос, содержащий более 6 элементов, тем самым он обращается к базе
данных через веб-сервер и данные возвращаются обратно к пользователю.
Количество опросов вывода равно 3, количество элементов данных 6 и более, для
определения коэффициентов воспользуемся таблицей 4.5.
Таблица 4.5 - Весовые коэффициенты опросов ввода
|
Количество файлов
|
Количество элементов данных
|
|
от 1 до 5
|
от 6 до 19
|
20 и более
|
|
1
|
  
|
|
|
|
2 - 3
|
 
|
|
|
|
4 и более
|
 
|
|
|
 ; (4.4)
В данном случае число логических связей равно трем. Для дальнейших
расчетов воспользуемся таблицей 4.6.
Таблица 4.6 - Весовые коэффициенты сложности структуры данных
|
Количество логических взаимосвязей
|
Количество элементов данных
|
|
от 1 до 19
|
от 20 до 50
|
более 51
|
|
Одна логическая запись типа "формат -
взаимосвязь"
|
  
|
|
|
|
От двух до пяти записей
|
  
|
|
|
|
Более шести записей
|
 
|
|
|
 ; (4.5)
В данном случае в качестве интерфейса может выступать один
элемент, окно программы. Число элементов - от 6 до 10. Для определения
коэффициентов воспользуемся таблицей 4.7.
Таблица 4.7 - Весовые коэффициенты сложности интерфейсов
|
Количество логических взаимосвязей
|
Количество элементов данных
|
|
от 1 до 19
|
от 20 до 50
|
более 51
|
|
Одна логическая запись типа "формат -
взаимосвязь"
|
  
|
|
|
|
От двух до пяти записей
|
  
|
|
|
|
Более шести записей
|
|
|
|
 ; (4.6)
Общее количество функциональных точек системы:
= X1 + X2 + X3 + X4 +
X5 + X6; (4.7)= 63 + 98 + 36 + 12 + 21 + 7 =235
Далее рассмотрим поправки на факторы внешней среды, приведенные в
таблице 4.8.
Таблица 4.8 - Факторы среды разработки
|
Фактор среды
|
Оценка ПС по пятибалльной шкале
|
|
Каналы передачи данных
|
2
|
|
Распределенные вычисления
|
0
|
|
Производительность системы
|
2
|
|
Конфигурирование
|
3
|
|
Частота транзакций
|
5
|
|
Интерактивная обработка
|
4
|
|
Пользовательский интерфейс
|
4
|
|
Интерактивное обновление базы данных
|
5
|
|
Сложность обработки запросов
|
3
|
|
Сложность инсталляции (установки) программной
системы
|
3
|
|
Сложность эксплуатации системы
|
4
|
|
Степень распределенности системы
|
1
|
|
Гибкость изменения функций
|
3
|
Таким образом, суммарное количество баллов:
= 2+2+3+5+4+4+5+3+2+4+1+2 = 39.
Уровень их суммарного влияния:
= 0,65 + 0,39 = 1,04.
Уточненное количество функциональных точек:
(F) = 235∙1,1 = 244,4.
Код программы написан на языке программирования Java,
показатель LOC на одну функциональную точку равен 53.
(LOC) = 244,4∙53 = 12953,2.
Рассматриваемая система является промышленным программным
продуктом, поэтому берем значения из третьей строки таблицы 4.9.
Таблица 4.9 - Коэффициенты математической модели оценки
трудозатрат
|
Тип программной системы
|
Показатель
|
|
 AE
|
|
|
Комплексное программное средство
|
3,6
|
1,2
|
|
Информационное программное средство
|
3
|
1,12
|
|
Промышленный программный продукт
|
2,4
|
1,05
|
|
|
|
Для оценки трудозатрат используется следующая формула:
 , (4.8)
где Т - трудозатраты, выраженные в человеко-месяцах, Т
= 0,56;
 - размерность программной системы, выраженная в тысячах строк
кода;
A -
показатель, отражающий линейную зависимость роста трудозатрат от размерности;
Е - показатель
показывающий, что при увеличении размерности ПО возрастает относительная
трудоемкость.
По полученным данным определим денежные затраты на разработку ПС.
Для примера будем считать месячный оклад программиста равным 15000 рублей.
 (4.9)  ,
где  - основная заработанная плата
разработчика, руб.;
 - тарифная ставка разработчик программного продукта, руб,;
 - время разработки, месяцы.
Дополнительная заработная плата исполнителей составляет 12 % от их
основной заработной платы:
 (4.10) 
Районный коэффициент составляет 15 % от основной и дополнительной
заработной платы исполнителей, т.е.:
 (4.11)
 руб
Отчисления на социальные нужды составляют 30,2 % от всех выплат по
заработной плате:
 (4.12)
Размер ставки накладных расходов примем равным 120%
 ; (4.13) 
Рассчитаем НДС:
 руб
Итого: общая стоимость разработки ПО составила 8400 + 2535,55 =
10935,55 рубля.
5.
Технические способы и средства защиты от электрического тока
5.1 Условия,
с учетом которых устанавливаются технические способы и средства защиты от
электрического тока
Нормы на допустимые токи и напряжения прикосновения в
электроустановках должны устанавливаться в соответствии с предельно допустимыми
уровнями воздействия на человека токов и напряжений прикосновения и
утверждаться в установленном порядке.
Электробезопасность должна обеспечиваться:
конструкцией электроустановок;
техническими способами и средствами защиты;
организационными и техническими мероприятиями.
Электроустановки и их части должны быть выполнены таким
образом, чтобы работающие не подвергались опасным и вредным воздействиям
электрического тока и электромагнитных полей, и соответствовать требованиям
электробезопасности.
Технические способы и средства защиты, обеспечивающие
электробезопасность, должны устанавливаться с учетом:
номинального напряжения 220 В, рода и частоты 50 Гц тока
электроустановки;
способа электроснабжения (стационарная сеть);
режима нейтрали источника питания (заземленная);
вида исполнения (стационарные);
условий внешней среды:
) особо опасные помещения;
) помещения повышенной опасности;
) помещения без повышенной опасности (температура 20°С,
влажность 50%, выделения газов и пара отсутствует);
) на открытом воздухе;
возможности приближения человека к токоведущим частям
(отсутствует);
характера возможного прикосновения человека к элементам цепи
тока:
) однофазное (однополюсное) прикосновение;
) двухфазное (двухполюсное) прикосновение;
) прикосновение к металлическим нетоковедущим частям,
оказавшимся под напряжением;
возможности приближения к токоведущим частям, находящимся под
напряжением, на расстояние меньше допустимого или попадания в зону растекания
тока;
вид работ (эксплуатация).
Требования безопасности при пользовании электроустановками
бытового назначения должны содержаться в прилагаемых к ним инструкциях по
эксплуатации предприятий-изготовителей.
Основными мерами защиты от поражения электрическим током
являются:
обеспечение недоступности токоведущих частей, находящихся под
напряжением, для случайного прикосновения;
электрическое разделение сети;
устранение опасности поражения при появлении напряжения на
корпусах, кожухах и других частях электрооборудования, что достигается защитным
заземлением, занулением, защитным отключением;
применение малых напряжений;
защита от случайного прикосновения к токоведущим частям
применением кожухов, ограждений, двойной изоляции;
контроль и профилактика повреждений изоляции;
компенсация емкостной составляющей тока замыкания на землю;
применение специальных электрозащитных средств - переносных
приборов и предохранительных устройств;
организация безопасной эксплуатации электроустановок.
5.2
Обоснование и конструкция принятых технических средств
В целях электробезопасности и защиты от опасного воздействия
ЭМП при случайных прикосновениях к токоведущим частям должны применяться
отдельно или в сочетании друг с другом следующие технические способы и средства
защиты:
защитное заземление;
защитное зануление;
выравнивание (в т. ч. уравнивание) потенциалов;
малое напряжение;
электрическое разделение сетей;
защитное отключение;
изоляция токоведущих частей от работника в широком смысле
(электрическая изоляция: рабочая, дополнительная, усиленная, двойная;
физическая изоляция: оградительные устройства, расположение на недоступных
высоте и расстоянии);
компенсация токов замыкания на землю;
предупредительная сигнализация, защитная блокировка, знаки
безопасности;
средства защиты и предохранительные приспособления.
Для защиты человека от поражения электрическим током в этих
случаях применяются объективные технические средства защиты, которые независимо
от воли и желания работника защищают его от возможных аварийных режимов работы.
Одно из наиболее эффективных объективных технических средств защиты защитное
заземление.
Защитное заземление - преднамеренное электрическое соединение
с землей или ее эквивалентом металлических нетоковедущих частей, которые могут
оказаться под напряжением. Защитное заземление следует отличать от рабочего
заземления.
Назначение защитного заземления - устранение опасности
поражения людей электрическим током при появлении напряжения на частях
конструкции электроустановок или оборудования, доступных прикосновению, как
правило, в режиме замыкания электрической установки на корпус при повреждении
электрической изоляции. Для этого между корпусом электроустановки и проводящим
пространством земли создается электрическое соединение с достаточно малым
сопротивлением R (рисунок 5.1).
Рисунок 5.1 - Схема включения человека в цепь замыкания на
землю при прикосновении к корпусу электроустановки
Если человек коснется корпуса, на который произошло короткое
замыкание одной из фаз, образуется электрическая цепь от поврежденной фазы и
корпуса на землю и далее к другим фазам через сопротивления изоляции
неповрежденных проводов (на рисунке показано условно выбранное направление
переменного тока). При наличии защитного заземления ток замыкания проходит по
двум параллельно включенным сопротивлениям: сопротивлению заземляющего
устройства R и сопротивление человека Rч. Токи в параллельных цепях
распределяются обратно пропорционально электрическим сопротивлениям, поэтому
при наличии малого электрического сопротивления заземляющего устройства (не
выше 10 Ом) по сравнению с электрическим сопротивлением человеческого тела
(сопротивление тела человека зависит от многих факторов, в качестве расчетного
значения принимается величинаRч=1000 Ом) часть тока, проходящая
через тело человека, будет мала и безопасна для его здоровья. Отсюда для
обеспечения безопасности пригодно не всякое соединение с "землей", а
только соединение, имеющее достаточно малое электрическое сопротивление.
Принцип действия защитного заземления - снижение до
безопасных значений напряжения прикосновения и шага, обусловленных режимом
замыкания электрической установки на корпус при нарушении электрической
изоляции. Это достигается уменьшением потенциала заземленных корпусов
оборудования при замыкании на него электрической части установки и
выравниванием потенциалов между основанием, на котором располагается человек, и
корпусом оборудования до величины разности потенциалов, безопасных для
человека.
Области применения защитного заземления: согласно ПУЭ
заземление установок необходимо выполнять:
при напряжении 380 В и выше переменного тока, 440 В и выше
постоянного тока - во всех электроустановках;
при напряжении выше 42 В, но ниже 380 В переменного тока и от
110 В до 440 В постоянного тока в помещениях с повышенной опасностью, особо
опасных и в наружных установках;
во взрывоопасных помещениях при всех напряжениях.
Заземляющее устройство бывает выносным и контурным. Выносное
заземляющее устройство применяют при малых токах замыкания на землю, а
контурное - при больших.
Для заземляющих устройств в первую очередь должны быть
использованы естественные заземлители:
водопроводные трубы, проложенные в земле;
металлические конструкции зданий и сооружений, имеющие
надежное соединение с землей;
металлические оболочки кабелей (кроме алюминиевых);
обсадные трубы артезианских скважин.
Запрещается в качестве заземлителей использовать трубопроводы
с горючими жидкостями и газами, трубы теплотрасс.
Естественные заземлители должны иметь присоединение к
заземляющей сети не менее, чем в двух разных местах.
В качестве искусственных заземлителей применяют:
стальные трубы с толщиной стенок 3.5 мм, длиной 2 - 3 м;
полосовую сталь толщиной не менее 4 мм;
угловую сталь толщиной не менее 4 мм;
прутковую сталь диаметром не менее 10 мм, длиной до 10 м и
более.
Все элементы заземляющего устройства соединяются между собой
при помощи сварки, места сварки покрываются битумным лаком. Допускается
присоединение заземляющих проводников к корпусам электрооборудования с помощью
болтов.
Защитное зануление - преднамеренное соединение открытых
проводящих (металлических нетоковедущих) частей (корпусов) электроустановки с
глухозаземленной нейтралью питающего генератора или трансформатора в сетях
трехфазного тока до 1000 В; с глухозаземленным выводом источника однофазного
тока; с заземленной точкой источника в сетях постоянного тока, выполняемое в
целях электробезопасности.
Наибольшее распространение зануление получило в трехфазных
электрических сетях в виде трехфазных четырехпроводных электрических сетей с
глухозаземленной нейтралью и напряжением 660/ 380, 380/220 и 220/127 В (в
числителе - линейное напряжение, в знаменателе - фазное).
Наиболее широкое применение нашли трехфазные электрические
сети с напряжением 380/220 В, потому что они обеспечивают совместное питание
силовых электроприемников (электродвигатели, электронагревательные приборы
т.д.) и электроосветительных установок, а также возможность питания трехфазных
и однофазных потребителей.
Согласно Правилам устройств электроустановок в
четырехпроводных трехфазных сетях глухое заземление нейтрали является
обязательным.
В качественулевых защитных проводников (РЕ-проводники) в
электроустановках до 1000 В могут использоваться:
специально предусмотренные для этой цели проводники:
) жилы многожильных кабелей;
) изолированные или неизолированные провода в общей оболочке
с фазными проводами;
) стационарно проложенные изолированные или неизолированные
проводники;
открытые проводящие части электроустановок:
) алюминиевые оболочки кабелей;
) стальные трубы электропроводок;
) металлические оболочки и опорные конструкции шинопроводов и
комплектных устройств заводского изготовления, если их конструкцией
предусмотрено такое использование и имеется указание об этом в документации
изготовителя;
некоторые сторонние проводящие части:
) металлические строительные конструкции зданий и сооружений
(фермы, колонны и т.п.);
) арматура железобетонных строительных конструкций зданий при
условии выполнения требований ПУЭ о непрерывности электрической цепи;
) металлические конструкции производственного назначения
(подкрановые рельсы, галереи, площадки, шахты лифтов, подъемников, элеваторов,
обрамление каналов и т.п.).
Принцип действия зануления - превращение пробоя изоляции на
доступный для прикосновения корпус электроустановки в однофазное короткое
замыкание (КЗ) в электрической цепи: корпус - нулевой защитный провод -
вторичная обмотка трансформатора - корпус, что обеспечивает быстрое и надежное
срабатывание защитного аппарата (автоматического выключателя или плавкого
предохранителя) и отключение поврежденной ЭУ (рисунок 5.2 а и б).
а
Рисунок 5.2 - Схема зануления электроустановок: а - схема и
потенциальная диаграмма напряжений короткозамкнутой цепи, б - то же, с
повторным заземлителем сRm-ROiпри обрыве нулевого
провода, лист 1
б
Рисунок 5.2, лист 2
При повторных заземлениях нулевого провода снижается
напряжение на корпусах электроустановок относительно земли в момент однофазного
короткого замыкания (рисунок 3.2 а), в том числе и при обрыве защитного
нулевого провода (рисунок 3.2 б).
В случае отсутствия повторного заземления и обрыве нулевого
провода опасность поражения людей увеличивается, так как пробой изоляции на
корпус происходит без защитного зануления и заземления. Все корпуса,
соединенные с поврежденным корпусом, оказываются под фазным напряжением
относительно земли. Повторные заземлители нулевого провода устанавливаются на
концах ВЛ (или ответвлений от них) длиной более 200 м, а также на вводах от ВЛ
к электроустановкам, которые подлежат занулению.
Зануление применяется в сетях напряжением до 1000 В с
заземленной нейтралью. В случае пробоя фазы на металлический корпус
электрооборудования возникает однофазное короткое замыкание, что приводит к
быстрому срабатыванию защиты и тем самым автоматическому отключению
поврежденной установки от питающей сети. Такой защитой являются: плавкие
предохранители или максимальные автоматы, установленные для защиты от токов
коротких замыканий; автоматы с комбинированными расцепителями.
Расчет заземляющего устройства производится в следующем порядке.
Определяется расчетное значение удельного сопротивления грунта ρрасч, Ом∙м, в месте устройства
заземления с учетом повышающего коэффициента К:
 , (5.1)
 Ом∙м,
Где ρизм − удельное сопротивление грунта,
полученное непосредственным измерением или принятое по приложению, Ом∙м;
К −
коэффициент, учитывающий изменение удельного сопротивления земли в течение года
в зависимости от климатической зоны, типа (вертикальные или горизонтальные),
длины, и глубины заложения заземлителей.
Сопротивление одиночного вертикального заземлителя рассчитывается
по формуле:
 , (5.2)
 Ом,
Где l− длина вертикального электрода−заземлителя,
м, d − диаметр заземлителя, м. При использовании в качестве
электродов угловой стали ее эквивалентный диаметр dyr= 0,95 Вуг,
где Вуг - ширина полки уголка, м;
t −
глубина заложения заземлителя, равная расстоянию от поверхности земли до
середины заземлителя, м;
 (5.3)
 м.
tn
= 0,7− 0,8 м − глубина заложения полосы.
Полученное значение R0 сравнивается с наибольшим
доступным RH: при R0 ≤ Rh,
что случается крайне редко, принимают заземлитель из двух электродов и расчет
заканчивают; при R0>Rh определяет число
вертикальных заземлителей.
Приняв схему расположения заземлителей в ряд или по замкнутому
контуру, находят вначале приближенное число заземлителей:
 (5.4) 
Затем уточняют количество заземлителей с учетом коэффициента
использования (экранирования):
 , (5.5)
 ,
Где ηз − коэффициент использования вертикальных
заземлителей (без учета влияния соединительной полосы), при помощи которого
учитывается явление взаимного экранирования электрических полей отдельных
электродов.
Взаимное мешающее действие растеканию тока замыкания, стекающего с
вертикальных заземлителей, приводит к увеличению сопротивления растеканию
группового заземления в целом.
Значения коэффициента использования вертикальных заземлителей ηз приведены в приложении. Они зависят от схемы их
расположения (в ряд или по контуру), отношения расстояния между отдельными
заземлителями α к их
длине l и приблизительного числа заземлителей Nnp.
Расстояние между заземлителями, расположенными в ряд, чаще всего принимают
равным (1−2) l, а при расположении по контуру это расстояние, как
правило, увеличивается до 3l. Значенияηз находим методом интерполяции. Определяется длина
соединительной полосы (горизонтального направления) Lп в
зависимости от ранее принятого отношения α: при расположении в ряд
 (5.6)
при расположении по контуру
 , (5.7)
 м.
Определяется сопротивление растеканию тока горизонтальной полосы  , (без учета экранирования между полосой и
заземлителями):
 , (5.8)
 ,
где  − расчетное удельное сопротивление
грунта, Ом-м, с учетом коэффициента сезонности Кп для
горизонтального заземлителя
 , (5.9)
 Ом∙м,
Где Вп − ширина соединительной полосы, м
(Вп = Вуг; при использовании в качестве горизонтального
заземлителя стали круглого сечения В = 2d);
tn−
(0,7-0,8) м − глубина заложения полосы в грунт.
Определяется сопротивление растеканию тока с учетом коэффициента
использования:
 , (5.10)
 Ом,
Где ηп − коэффициент использования
соединительной полосы в ряду или контуре заземлителей, учитывающий
экранирование между полосой и заземлителями; зависит от отношения  , схемы расположения заземлителей и их числа Nут.
Определяется результирующее сопротивление растеканию группового
искусственного заземлителя как двух параллельных сопротивлений
(электродов-заземлителей и соединительной полосы):
 , (5.11)
 Ом,
Где
 , (5.12)
где сопротивление растеканию вертикальных заземлений при итоговых
значениях Nyт и Nnp, Ом;
 Ом,
ут − число вертикальных заземлителей, окончательно принятых в
расчете;
ηзут - коэффициент использования заземлителей
(без учета влияния соединительной полосы), соответствующий Nyт.
Так как R’з ≤ Rн, то количество заземлителей
для обеспечения требований безопасности рассчитано, верно.
Заключение
В результате исследования исходного объекта были выявлены
следующие примеры: неоптимальный способ хранения результатов измерения
счетчиков на сервере и отсутствие средства для просмотра и анализа этих данных.
Для решения этих проблем было разработано алгоритмическое и
программное обеспечение. Алгоритмическое обеспечение легло в основу
программного комплекса. Этот комплекс был технически и экономически обоснован,
спроектирован и реализован с помощью современных технологий и инструментов.
Разработанное программное обеспечение состоит из двух
программных средств, базы данных и СУБД. Следует заметить, что при
проектировании программного комплекса, был учтен тот факт, что в процессе использования
СУБД может поменяться на другую промышленную СУБД. Поэтому компоненты комплекса
не зависит от какой-либо конкретной СУБД.
Первый компонент комплекса называется
"MigrationCsvInDB" и отвечает за миграцию данных. Этот программное
средство ликвидирует проблему не оптимально хранящейся информации, которая
является результатом работы системы. "MigrationCsvInDB" обеспечивает
безошибочный перенос данных из иерархического множества файлов формата csv в
базу данных, под управлением PostgreSQL (которую можно легко заменить на любую
промышленную СУБД). Миграция позволяет осуществлять чтения данных более
простыми и эффективными, как по качеству, так и по времени, методами.
Для хранении информации были спроектированы концептуальная,
логическая и физическая модели базы данных, а также дополнительные средства для
обеспечения более высокой скорости доступа к данным.
Второй компонент "WebViewer" позволяет отображать
информацию, которая хранится в базе данных, в графическом виде, что позволяет
существенно упростить ее анализ. Более того, данная информация отображается с
использованием веб-интерфейса. Это решение дает возможность просматривать
информацию удаленно, как по локальной, так и по глобальной сети. Интерфейс
программы выполнен и использованием самых последних достижения в области
дизайна элементов посредством JavaScript.
Таким образом, данное исследование и программный комплекс
позволили решить важные для функционирования системы проблемы, которые решить
другим путем, например, использовав обеспечение сторонних разработчиков, было
бы не обосновано.
Библиографический
список
1.
Язык программирования Java [Электронный ресурс] - Электрон. текстовые дан. -
https: // ru. wikipedia.org/wiki/Java
.
Язык программирования Java [Электронный ресурс] - Электрон. текстовые дан. -
https: // ru. wikipedia.org/wiki/JavaScript
.
Введение в представления PostgreSQL [Электронный ресурс] - Электрон. текстовые
дан. - http://postgresql.ru.net/gruber/ch20.html
.
ОбъектDAO [Электронный ресурс] - Электрон. текстовые дан. - http://www.oracle.com/technetwork/java/dataaccessobject-138824.html
.
Инструкция по работе с CSV файлами [Электронный ресурс] - Электрон. текстовые
дан. - http://www.javenue. info/post/78
.
СТП ОмГУПС-1.2-05. Работы студенческие учебные и выпускные квалификационные:
общие требования и правила оформления текстовых документов.
.
"Расчет затрат на создание программных средств: методические указания к
выполнению экономического раздела дипломного проекта" / А.Н. Шендалев.
Омск: Омский гос. ун-т путей сообщения, 2012.31 с.
.
Кларенс Хо, Роб Харроп. Spring 3 для профессионалов. - М.: "Вильямс",
2012. - 880 с. - ISBN 978-5-8459-1803-1.
.
ГОСТ Р 50807-95. Устройства защитные, управляемые дифференциальным (остаточным)
током. Общие требования и методы испытаний (МЭК 755-83). М., 2003.18 с.
.
Испытание эффективности и расчет защитного заземления: Методические указания к
дипломному проектированию, практическим и лабораторным работам по охране труда
/ В.Ф. Харламов, Б.П. Баталов, Л.Я. Уфимцева. Омский ин-т инж. ж. −д.
транспорта, 1993.42 с.
.
Учебно-методический комплекс по дисциплине "Безопасность
жизнедеятельности". [Электронный ресурс] Электрон. текстовые дан. - lib.
znate.ru 2012. Режим доступа: http://lib. znate.ru/docs/index-202682.html?
page=20
Похожие работы на - Разработка программного комплекса с целью оптимизации способа хранения данных об измерениях счетчиков
|