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

@Service publicclassDataServiceImplimplementsIDataService { privateIDataDAOTestdataDAOTest;

publicvoidsetDataDAOTest (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;

import net. eutkin. main. entity. AbstractDataTS;

import net. eutkin. main. factory. EntityFactory;

import net. eutkin. main. service. IDataService;

import java. io. File;

import java. io. FileReader;

import java. io. IOException;

import java. text. SimpleDateFormat;

import java. util. *;

import java. util. regex. Pattern;

public class NewThread implements Runnable { private String path;

private IDataService dataServiceTest;

Листинг 3.11 - Реализация класса NewThread, поля и конструктор, лист 1

/** * Constructor * @param path * @param dataServiceTest */ public NewThread (String path, IDataService dataServiceTest) { this. path = path;

this. 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 в файл настройки вынесены параметры программы, такие как путь к главной директории, содержащей поддиректории с файлами и шаблон для проверки корректности имени файла.

Path = 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="http://www.springframework.org/schema/beans"
	xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns: tx="http://www.springframework.org/schema/tx"
	xsi: schemaLocation="
	http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/tx
	http://www.springframework.org/schema/tx/spring-tx-3.0. xsd
	"

Листинг 3.16 - Подключение XML Schema

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

<bean id="propertyConfigurer"
class="org. springframework. beans . factory . config . PropertyPlaceholderConfigurer">
<property name="location" value="jdbc. properties" />
</bean>

Листинг 3.17 - Подключение jdbc. properties

После того, как программе стал доступен конфигурационный файл, подключим класс dataSource. Реализацию данного класса возьмем стороннего производителя, компанию Apache, потому что его реализации однотипны и не зависят от особенностей системы. Класс отвечает за подключение к СУБД через драйвер, специфичный для каждой СУБД.

<bean id="dataSource" class="org. apache.commons. dbcp3. BasicDataSource" destroy-method="close">
	<property name="driverClassName" value="${jdbc. driverClassName}" />
	<property name="url" value="${jdbc. url}" />
	<property name="username" value="${jdbc. username}"/>
	<property name="password" value="${jdbc. password}"/>
</bean>

Листинг 3.18 - Подключение класса dataSource

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

<bean id="sessionFactory" class="org. springframework. orm. hibernate. LocalSessionFactoryBean">
	<property name="dataSource" ref="dataSource" >
	<property name="configLocation" value="/hibernate. cfg. xml"/>
	<property name="hibernateProperties">
		<props>
			<prop key="hibernate. dialect">${jdbc. dialect}</prop>
		</props>
	</property>
</bean>

Листинг 3.19 - Подключение класса sessionFactory

Далее подключим созданные классы, реализующие интерфейсы DAO и сервиса:

<bean id="entityDAO" class="net. eutkin. main. dao. DataDAOImpl">
	<property name="sessionFactory" ref="sessionFactory"/>
</bean>
<bean id="entityService" class="net. eutkin. main. service. DataServiceImpl">
	<property name="dataDAOTest" ref="entityDAO"/>
</bean>

Листинг 3.20 - Подключение классов-реализаций

В старых версиях этого фреймворка необходимо было для каждого класса иметь собственный файл конфигурации в формате. xml, но в новых версиях их заменили одним файлом и аннотациями JPA. Этому способстовало развитие JPA, так как Hibernate использует эту технологию для доступа к данным посредствам jdbc:

<? xml version='1.0' encoding='utf-8'? > <! DOCTYPE hibernate-configuration PUBLIC "- // Hibernate/Hibernate Configuration DTD // EN" "http://hibernate. sourceforge.net/hibernate-configuration-3.0. dtd"> <hibernate-configuration> <session-factory> <mapping class="net. eutkin. main. entity. DataTS1" /> <mapping class="net. eutkin. main. entity. DataTS2" /> <mapping class="net. eutkin. main. entity. DataTS3" /> <mapping class="net. eutkin. main. entity. DataTS4" /> <mapping class="net. eutkin. main. entity. DataTS5" /> <mapping class="net. eutkin. main. entity. DataTS6" /> </session-factory> </hibernate-configuration>

Листинг 3.21 - КонфигурационныйфайлHibernatehibernate. cfg. xml

При компиляции программы в директории проекта target появляется. jar файл и его манифест. Далее, этот файл можно будет перекомпилировать с. ехе файл посредством сторонней утилиты.

3.4.4 Описание программы "WebViewer"

В современном информационном обществе очень важно не только хранить информацию, но и эффективно ее использовать.

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

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

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

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

Иерархия содержит четыре уровня, каждый из которых выполняет определенную задачу. Следует отметить, что данная иерархия классов полностью соответствуетSOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation и Dependency inversion) принципам.

Каждый класс имеет ограниченную ответственность и выполняет только одну задачу. Например, класс "DataDAOImpl" отвечает только за доступ к данным, а класс "DataServiceImpl" - за управлением транзакциями.

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

Все классы закрыты для модификаций, так как все служебные методы и поля имеют уровень доступ "private" (частный), а открытые - уровень доступа "public" (публичный).

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

Рисунок 3.11 - UML диаграмма классов Программы 2

Так как Программа 1 и Программа 2 используют одни и те же классы моделей, то остается только написать класс, который будет отвечать за хранение в ОЗУ данных, на основе которых будет строиться график в веб интерфейсе.

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

public class FiderGraphEntity { private Date time_line;

private Double current_fider;

private int meter_id;

private int numTS;

public Date getTime_line () { return time_line; }

public 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 ();

String 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	ts1. date_mens + ts1. time_mens " +
			",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;

private double power;

public 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 (

List<FiderGraphEntity> entities

) {…} /** * методреализуетприемзапросов Http POST * @param запрос * @param ответ * @return * @throws Exception */ @RequestMapping (value="/fider", method = RequestMethod. POST) public ModelAndView fiderPost (

HttpServletRequest request, HttpServletResponse response

) throws Exception {…}

/** * методреализуетприемзапросов Get * @param запрос * @param ответ * @return * @throws Exception */ @RequestMapping (value="/fider", method = RequestMethod. GET) public ModelAndView fiderGet (

HttpServletRequest 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 и более

2 файла выводят 20 элементов (количество записей в базе не ограничено). Таким образом количество функциональных точек выводов Х₁ будет равно:

; (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)

Общее количество функциональных точек системы:

X = X₁ + X₂ + X₃ + X₄ + X₅ + X₆; (4.7)

X = 63 + 98 + 36 + 12 + 21 + 7 =235

Далее рассмотрим поправки на факторы внешней среды, приведенные в таблице 4.8.

Таблица 4.8 - Факторы среды разработки

Фактор среды	Оценка ПС по пятибалльной шкале
Каналы передачи данных	2
Распределенные вычисления	0
Производительность системы	2
Конфигурирование	3
Частота транзакций	5
Интерактивная обработка	4
Пользовательский интерфейс	4
Интерактивное обновление базы данных	5
Сложность обработки запросов	3
Сложность инсталляции (установки) программной системы	3
Сложность эксплуатации системы	4
Степень распределенности системы	1
Гибкость изменения функций	3

Таким образом, суммарное количество баллов:

N = 2+2+3+5+4+4+5+3+2+4+1+2 = 39.

Уровень их суммарного влияния:

Z = 0,65 + 0,39 = 1,04.

Уточненное количество функциональных точек:

R (F) = 235•1,1 = 244,4.

Код программы написан на языке программирования Java, показатель LOC на одну функциональную точку равен 53.

R (LOC) = 244,4•53 = 12953,2.

Рассматриваемая система является промышленным программным продуктом, поэтому берем значения из третьей строки таблицы 4.9.

Таблица 4.9 - Коэффициенты математической модели оценки трудозатрат

Тип программной системы	Показатель
	A	E
Комплексное программное средство	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 Гц тока электроустановки;

способа электроснабжения (стационарная сеть);

режима нейтрали источника питания (заземленная);

вида исполнения (стационарные);

условий внешней среды:

1) особо опасные помещения;

2) помещения повышенной опасности;

3) помещения без повышенной опасности (температура 20°С, влажность 50%, выделения газов и пара отсутствует);

4) на открытом воздухе;

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

характера возможного прикосновения человека к элементам цепи тока:

1) однофазное (однополюсное) прикосновение;

2) двухфазное (двухполюсное) прикосновение;

3) прикосновение к металлическим нетоковедущим частям, оказавшимся под напряжением;

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

вид работ (эксплуатация).

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

Основными мерами защиты от поражения электрическим током являются:

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

электрическое разделение сети;

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

применение малых напряжений;

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

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

компенсация емкостной составляющей тока замыкания на землю;

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

организация безопасной эксплуатации электроустановок.

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 В могут использоваться:

специально предусмотренные для этой цели проводники:

1) жилы многожильных кабелей;

2) изолированные или неизолированные провода в общей оболочке с фазными проводами;

3) стационарно проложенные изолированные или неизолированные проводники;

открытые проводящие части электроустановок:

1) алюминиевые оболочки кабелей;

2) стальные трубы электропроводок;

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

некоторые сторонние проводящие части:

1) металлические строительные конструкции зданий и сооружений (фермы, колонны и т.п.);

2) арматура железобетонных строительных конструкций зданий при условии выполнения требований ПУЭ о непрерывности электрической цепи;

3) металлические конструкции производственного назначения (подкрановые рельсы, галереи, площадки, шахты лифтов, подъемников, элеваторов, обрамление каналов и т.п.).

Принцип действия зануления - превращение пробоя изоляции на доступный для прикосновения корпус электроустановки в однофазное короткое замыкание (КЗ) в электрической цепи: корпус - нулевой защитный провод - вторичная обмотка трансформатора - корпус, что обеспечивает быстрое и надежное срабатывание защитного аппарата (автоматического выключателя или плавкого предохранителя) и отключение поврежденной ЭУ (рисунок 5.2 а и б).



а

Рисунок 5.2 - Схема зануления электроустановок: а - схема и потенциальная диаграмма напряжений короткозамкнутой цепи, б - то же, с повторным заземлителем сR_m-R_Oiпри обрыве нулевого провода, лист 1

б

Рисунок 5.2, лист 2

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

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

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

Устройство защитного отключения - механический коммутационный аппарат или совокупность элементов, которые при достижении (превышении) дифференциальным током заданного значения при определенных условиях эксплуатации должны вызвать размыкание контактов. Может состоять из различных отдельных элементов, предназначенных для обнаружения, измерения (сравнения с заданной величиной) дифференциального тока и замыкания иразмыканияэлектрической цепи (разъединителя). [11]

Основная задача УЗО - защитачеловекаот поражения электрическим током и от возникновенияпожара, вызванного утечкой тока через изношенную изоляцию проводов и некачественные соединения.

С точки зрения электробезопасности УЗО принципиально отличаются от устройств защиты от сверхтока (предохранителей) тем, что УЗО предназначены именно для защиты от поражения электрическим током, поскольку они срабатывают при утечках тока значительно меньших, чем предохранители (обычно от 2 ампер и более для бытовых предохранителей, что во много раз превышает смертельное для человека значение). УЗО должны срабатывать за время не более 25-40 мс, то есть до того, как электрический ток, проходящий через организм человека, вызовет фибрилляцию сердца - наиболее частую причину смерти при поражениях электрическим током. [9]

5.3 Расчет защитного заземления

Основным параметром, характеризующим защитное заземляющее устройство, является сопротивление растеканию тока, которое в основном зависит от сопротивления земли. [10]

Данные:

U>1000 В, R_н=2,5 Ом, l=2,5 м, 3, d=40 мм, климатическая зона ? 2, грунт - суглинок, расположение заземления - по контуру.