close

Вход

Забыли?

вход по аккаунту

Федосов Сергей Сергеевич. Разработка информационной системы для хранения и обработки информации в области ЖКХ на основе облачных сервисов

код для вставки
8
t0z
r$o
N .u. xrsHsoun!^doQi;:
***",
/_/
!od!!o€r €rt
(ao.rddai xrsHh€trgo.€ots.o EE X))( rir.etrgo s rnnE,ldooH{
3!EoHed! Brr'iwer.uJ xolHornendo.lH" Rrrogeded,
r',.ogDdgo
!
-
,roged
rorlofn.{r lrf EFr lloN!J{u116 eh.r
llrorotsxer lriqHoun€^doQH! r utrn8.firenorsD,r{H.odr.odogrdu r,trrr.!:I,
!/t9t99t doun
'e'!.r.r.
.!m.rdal !.rd.J €[email protected]
.FtsHo')reNdoots! 6FHsrredondo) (s(trood!) srJosH.!sed
r0 60
lrrr.^doosr @tstrErr!.|x
srHefi!:)
EH
E0
!rdororrio! (rx!.rc!d!Es on
VTOgYd TYHHOTIITV)[email protected]) I'YH)JA[]I!ITI
(vgaHeJd^I il u
uH:tr^u.I
JSILI:)dgSraH^ !u9HH:IS.IJdyY^JOl t{}1)I3sO(dO}
KtlHysotydco olsmJtcs fl.nleYxgdh^
EoH:IIJgJVao€vdgo goHrTxtrors
aorfi!srJdvY^iloJ [email protected]
mdfdd!trga Fo)Jl4[4JJod I4)^vH
]4
Kl,ftlvso€vd:Io o€itJdsrJ[Hu\
D.rsd.r ororLergo eunmjodu rxhe.rnrd
€.tr€d.. orosL€r9o .rqesodrDeodLl
rbergo LroHr.^Y.d! atrsr3o)LhriI
(sorodrc
rtrog€ded x!ftexoutror en.Ead.n) lr.rue€ 4oEsr.r!ts.8o! .rHexd.Eo:) ;
nr.ergo golrenr;adn o nnendooH! :u€rd.r€,\
.r
xrr.aLlFdolf
do9€.1 )r .F! Hen .reHEoxJu :
:
8l0z rHorx <sz> rerog€d {oss.EHorEe worHerl,th uheY. rodJ
t/oe-Z d]\f r / I 0Z rdqsrro <( I E) ro Ir.rrJd.€rH{ or noftmdn €H.lr)dlsr i
GoJusda. xresheugo lsos.o F X)rj{ rr.ergo 6 lrlr?Ndoolri
mr FW.r.r. goEsori€r{dooHu $rrogBd€Rd> d)g €Nbf I
n)tJogRdgo u Bus.sEdx
!
Phrs)rd.J k.rd.t e€[email protected] prH.r
!/19t59tdQHn
/oPHorrB{[email protected]{ rots! \tu o3 bk r.HUoL e3 Li
ir.
roged
r4rvtlYr
'r.rtoz r-r tul" D < t/,
aa -]=a-
nolroe
tl'/
lodtr.oerse€
rorY[xdgsr^.
rcN.r.tj..rqtsHorn€,!do0H'j .'e!6".r.dordo) (srrood!) sr.occ:rsedreH
!,!re^doo!! elvenqdu €0.t0.60 .n!.medueH
w.r.!. xrcaaodn€,!do0s"dr.4e)
rfrrlrFtl
!-jrrotroExer xrqHEornD^doosr ! lrrE nnds€
"rclotu.odo9rd!
(YSSHIUdAJ' J'I4 I4H:[{Z
rs.r}.rJda€n trl^ r.lrlHlrasrJcelT^3or l4zi Jsor-f do,
fllltdx:I
KtlHYrro€vdso ormSI.Iq
r]{
3oHCr[IIYqO€Vd:IO got O(iOtS AOTflSJJdVtr^3o1 AOHCTVdgYEO
[email protected] l-Io)J!.[]Jcod LD{^YH
I,I
rlll{v go€vdso oa-LJdrl JI4HrrI\
5
I]epeqeE reMoEcrpaqtossoro Mareptrua
Ilpeemaqn, [email protected]
ocHoBsde 3ranbr
Aara B6lAaq! 3aaasnt
(
16
r
rr
p$ynl, 68 [email protected] BKP
anpelq, 2018 r.
3amslr€ rDrisrn r ucnoDeEio
KAJIEH/.APHbIIi ruIAH
tlarueHoBeue raroB pa6orbt
BuorHeHre
edmsecrofi @E
16.04_18,06.05.18
&empoBdtre Mo,ryrlnot crpyKr}?u
[email protected] crpymypd EA
Bd6o! @6pW€mB [email protected]
OOop re&e [email protected]
DaoFMoro [email protected]
CryAeHr
[email protected]
t
0?.05.18 ?0.05,18
21.05.18-03.06.t8
04.06.18 06.06,18
07,06.18 17,06,18
18.06,18
W
-25.06.18
C.C. O€rocoB
АННОТАЦИЯ
ВКР 86 с., 14 рис., 3 табл., 40 источников, 2 прил.
ОБЛАЧНЫЙ СЕРВИС, ЖИЛИЩНО-КОММУНАЛЬНОЕ ХОЗЯЙСТВО,
УПРАВЛЯЮЩАЯ
КОМПАНИЯ,
ТОВАРИЩЕСТВО
СОБСТВЕННИКОВ
ЖИЛЬЯ, ГОСУДАРСТВЕННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА ЖКХ.
Выпускная
квалификационная
работа
посвящена
разработке
информационной системы для хранения и обработки информации в области ЖКХ
на основе облачных сервисов.
В первой главе производится обзор литературных источников, описывается
применение информационных технологий в сфере ЖКХ, а также с помощью
анализа аналогов определяются требования к программе.
Во второй главе содержится модульная структура облачного сервиса, а
также подробно рассмотрены наиболее важные модули данного приложения, в
частности описываются концептуальная, логическая и физическая модели базы
данных.
В третьей главе находится описание реализации прототипа облачного
сервиса с использованием возможностей платформы Amazon Elastic Compute
Cloud.
6
СОДЕРЖАНИЕ
СПИСОК ПРИНЯТЫХ СОКРАЩЕНИЙ
8
ВВЕДЕНИЕ
9
1 ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
11
1.1 Обзор литературных источников
11
1.1.1 Обзор нормативных документов
11
1.1.2 Обзор статей
11
1.2 Описание предметной области
19
1.3 Обзор аналогов информационной системы
21
1.3.1 Комплекс программ БИТ.ЖКХ
21
1.3.2 Виртуальный ИРЦ ЖКХ
24
1.3.3 Инфокрафт ЖКХ 365
26
1.3.4 Другие аналоги
28
1.4 Моделирование use-case
31
1.4.1 Анализ акторов системы
31
1.4.2 Выявление вариантов использования
33
1.5 Постановка задачи
36
2 ПРОЕКТИРОВАНИЕ ОБЛАЧНОГО СЕРВИСА
40
2.1 Диаграмма деятельности
40
2.2 Структура облачного сервиса
41
2.3 Структура базы данных
46
3 РЕАЛИЗАЦИЯ ПРОТОТИПА ОБЛАЧНОГО СЕРВИСА
56
3.1 Используемые инструменты разработки
56
3.2 Проектирование логики диалога с пользователем
60
3.3 Описание прототипа облачного сервиса
65
ЗАКЛЮЧЕНИЕ
68
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
69
ПРИЛОЖЕНИЕ А
74
ПРИЛОЖЕНИЕ B
77
7
УДОСТОВЕРЯЮЩИЙ ЛИСТ
ИНФОРМАЦИОННО-ПОИСКОВАЯ
84
ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
85
8
СПИСОК ПРИНЯТЫХ СОКРАЩЕНИЙ
ЖКХ – жилищно-коммунальное хозяйство.
ГИС ЖКХ – государственная информационная система жилищнокоммунального хозяйства.
ТСЖ – товарищество собственников жилья.
АРМ – автоматизированное рабочее место.
УК – управляющая компания.
ЖКУ – жилищно-коммунальные услуги.
ПО – программное обеспечение.
ЖСК – жилищно-строительный кооператив.
МКД – многоквартирный дом.
ПК – персональный компьютер.
БД – база данных.
СУБД – система управления базами данных.
9
ВВЕДЕНИЕ
Сфера ЖКХ – одна из важнейших сфер жизни людей. До недавнего
времени информационные технологии использовались в данной сфере
сравнительно редко. Но в последние годы активно идут процессы
автоматизации и информатизации данной сферы.
Создание современных информационных систем для ЖКХ является
актуальной задачей. Использование информационных технологий привносит
удобство и прозрачность в сферу ЖКХ.
В последнее время всё большую популярность у пользователей и
разработчиков получают облачные сервисы. Идея облачных технологий
сводится к предоставлению удалённого доступа пользователей к услугам,
приложениям и информационным ресурсам с использованием интернета или
корпоративной сети.
Потребности области ЖКХ обусловили спрос на современные
информационные технологии. Для ЖКХ характерны обработка больших
массивов информации в ограниченные сроки и наличие больших объёмов
справочной документации. Предприятия энергетики и ЖКХ уже начали
активно используют облачные сервисы. Их использование в области ЖКХ
позволит получить обратную связь с потребителями услуг, повысить
прозрачность процессов предоставления услуг в данной сфере.
Данная работа состоит из трех частей. В первой части содержится
описание предметной области, а также с помощью анализа аналогов и
диаграммы прецедентов определяются требования к программе. Вторая часть
содержит описание структуры проектируемого облачного сервиса и базы
данных. Третья часть включает описание инструментов разработки, логики
диалога с пользователем, реализации прототипа сервиса.
Объектом исследования данной выпускной квалификационной работы
является применение информационных технологий в сфере ЖКХ.
10
Предметами исследования данной выпускной квалификационной
работы
являются
использующиеся
в
сфере
ЖКХ
информационные
технологии и продукты, в частности – облачные сервисы.
Научная новизна выпускной квалификационной работы заключается в
использовании возможностей облачной платформы Amazon Elastic Compute
Cloud для создания облачного сервиса в области ЖКХ.
Целью
данной
выпускной
квалификационной
работы
является
разработка информационной системы для хранения и обработки информации
в области ЖКХ на основе облачных сервисов. Актуальность этой темы
доказывается значительным ростом применения облачных технологий во
многих отраслях народного хозяйства, а также продолжающимся процессом
информатизации сферы ЖКХ.
Для выполнения поставленной выше цели требуется выполнить
следующие задачи:
 описание предметной области и анализ аналогов;
 определение требований к программе;
 проектирование структуры облачного сервиса;
 проектирование базы данных;
 описание логики диалога с пользователем;
 реализация прототипа сервиса.
11
1 ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Обзор литературных источников
1.1.1 Обзор нормативных документов
Электронные ресурсы, на которых будет доступна информация о
деятельности
организаций,
осуществляющих
деятельность
в
сфере
управления многоквартирными домами, и формы её раскрытия определены в
приказе Минстроя России «Об утверждении форм раскрытия информации
организациями, осуществляющими
деятельность в сфере управления
многоквартирными домами».
В Постановлении Правительства РФ "Об утверждении стандарта
раскрытия информации организациями, осуществляющими деятельность в
сфере управления многоквартирными домами" указаны виды информации,
обязательные к раскрытию организациями, осуществляющими деятельность
в сфере ЖКХ, и пути раскрытия данных сведений.
Стандарты управления многоквартирными домами, перечень услуг и
работ,
осуществляемых
Постановлении
организациями
Правительства
в
Российской
сфере
ЖКХ,
Федерации
описаны
«О
в
порядке
осуществления деятельности по управлению многоквартирными домами».
В Федеральном законе «О государственной информационной системе
жилищно-коммунального
хозяйства»
указаны
принципы
создания,
эксплуатации и модернизации единой федеральной централизованной
информационной системы (ГИС ЖКХ), требования и виды информации,
размещаемые в ней.
1.1.2 Обзор статей
В статье Д.В. Горбачёва, Э.Г. Хакимовой «Обзор современных
информационных технологий автоматизации деятельности в сфере ЖКХ»
утверждается, что одной из основных проблем в сфере ЖКХ является
отсутствие
единого
информационного
пространства
удобного
в
12
использовании как для органов управления, так и для жильцов. ТСЖ на
сайтах либо совсем не публикуют данные, либо информация публикуется не
полностью.
Помимо этого в статье проводится анализ и оценка некоторых
программных продуктов, применяемых в данной сфере. В качестве примеров
систем, основанных на применении облачных технологий, приводятся
программный комплекс «СТЭК-ЖКХ», система «Виртуальный ИРЦ - ЖКХ»,
Domosite.ru, «07.ЖКХ». Программный комплекс «СТЭК-ЖКХ» позволяет
получить доступ через Интернет к следующим модулям:
1. Расчёты с физическими лицами.
2. Паспортный стол.
3. АРМ юриста (работа с должниками – физическими лицами).
4. Аварийно-диспетчерская служба.
5. АРМ Кассира.
6. Расчёты с юридическими лицами.
7. Субсидии.
Универсальная
учётная
система
«Виртуальный
ИРЦ
-
ЖКХ»
автоматизирует взаиморасчёты и деловые процессы и объединяет всех
участвующих в гибридную виртуальную сеть.
Информационная система Domosite.ru даёт следующие возможности
своим пользователям:
1. Создание официальной страницы ТСЖ/УК с функцией размещения
новостей и отчётности.
2. Отслеживание реестра жителей и владельцев собственности.
3. Осуществление сбора и сдачи показаний счётчиков, напоминания
абонентам по почте, отчёты по потреблению коммунальных услуг, ведение
журнала заявок с СМС-уведомлениями, ведение календаря, участие в
форуме.
4. Работа с диспетчерской службой.
13
5. Онлайн оплата за жилищно-коммунальные услуги.
6. Получение юридических услуг и консультаций.
Информационная система «07.ЖКХ» даёт следующие возможности:
1. Для органов государственной власти – отслеживание исполнения
производственных и инвестиционных программ, прогнозирование, расчёт и
целевое использование бюджетных средств для социальной поддержки
некоторых категорий граждан и субсидий по оплате ЖКУ.
2. Для органов местного самоуправления – доведение до сведения
населения
информации
о
деятельности
организаций
ЖКХ,
ведение
электронных паспортов объектов жилого фонда, координация деятельности
всех управляющих организаций.
3. Для управляющих ресурсоснабжающих организаций и рассчётнокассовых центров – платёжные сервисы для проведения расчётов по
многоставочным тарифам с возможностью автоматизированного сбора
показаний с общедомовых и персональных приборов учёта.
4. Для населения – получить сведения о состоянии лицевого счёта,
заказать требуемые справки, ввести показания индивидуальных приборов
учёта, оплатить счета и заказать дополнительные услуги.
В статье «Tibbo в создании ГИС ЖКХ»
описываются наиболее
очевидные проблемы в создании универсальной диспетчерской системы:
1. Сбор информации по разным протоколам.
2. Выбор основного канала связи (Ethernet, Wi-Fi, GPRS, радиоканал).
3. Согласование интерфейсов оборудования с основными каналами
связи.
4. Создание резервных каналов связи.
5. Организация нового информационного потока без нарушения
предыдущей схемы работы.
6. Логгирование
служебной
разрешения проблемных ситуаций.
информации
для
последующего
14
7. Мониторинг в режиме реального времени состояния устройств
автоматики.
8. Возможность быстрого обнаружения и решения проблемных
ситуаций.
9. Быстрое наращивание функционала в будущем.
10. Гибкая программная платформа, обеспечивающая сбор информации
по любому возможному протоколу, настраиваемая логика и т.д.
Некоторые из
вышеперечисленных проблем возможно решить с
использованием технологий Tibbo.
В статье А.К. Рябина Д.А. Лопатина «Автоматизация ЖКХ – это
просто» были выделены основные требования к системе автоматизации:
– высокая
надежность оборудования и ПО; `
– низкая
стоимость и простота проектирования и технического
обслуживания;
– возможность
поэтапного наращивания проекта.
Также были рассмотрены преимущества автоматизированной системы
управления, в качестве программного обеспечения которой был выбран
SCADA Winlog Pro.
Статья А.М. Подлесного, И.М. Бажукова, «Диспетчеризация объектов
ЖКХ – одна из доктрин умного города» содержит пример автоматизации
деятельности ЖКХ на двух уровнях – на уровне индивидуального теплового
пункта и на уровне центрального теплового пункта. Единая информационная
сеть для всего города должна подразделяться на несколько уровней:
1. Уровень
локальных
объектов, обслуживаемых
управляющими
компаниями.
2. Уровень
районных
диспетчерских
пунктов,
собирающих
информацию с локальных объектов.
3. Уровень единых центров сбора, обработки и анализа данных.
15
В
статье
И.Е.
Аблина
«Сборка
SCADA-проекта
систем
диспетчеризации ЖКХ из готовых компонентов» приведён пример сборки
проекта диспетчеризации с использованием системы MasterSCADA на
основе набора типовых элементов:
– индивидуальные
тепловые пункты;
– газорегуляторные
– насосные
пункты;
всех видов;
– вентиляционные
установки;
– трансформаторные
– резервное
подстанции;
энергоснабжение;
– квартирный
и домовой учёт ресурсов.
В статье Д.С. Кузнецова «Анализ облачных информационных систем
для управления многоквартирными домами» анализируется рынок облачных
информационных систем по управлению многоквартирными домами.
Главные достоинства облачных технологий:
– взаимодействие
с сервисом проводится с использованием браузера по
протоколу (HTTPS) по модели SaaS ("программа, как сервис");
– понижается
нагрузка на информационную инфраструктуру, так как
вычисления происходят в облачной среде удалённо;
– для
владельцев жилой площади появляется единое информационное
поле, доступ к которому они получают в режиме 24/7 с помощью телефона,
планшета или ПК и подключения к Интернету;
– не
нужны специалисты для установки, наладки, обслуживания и
обновления, так как данные обязанности должен выполнять провайдер
облачного сервиса.
В статье сравнивают следующие четыре информационные системы,
использующие облачные технологии:
1. «1С: ВДГБ: Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК»
делает возможным автоматизацию служб ТСЖ или УК: расчёта квартплаты и
коммунальных
услуг;
технического
содержания
и
ремонта
зданий,
16
помещений и другой коммунальной инфраструктуры; паспортный стол;
служба финансов.
2. «Инфокрафт ЖКХ 365» даёт возможность расчёта квартирной платы,
ведения
паспортного
учёта,
учёта
жилого
фонда,
обслуживания
собственников помещений и ведение претензионной работы. Так как
облачный сервис разработан на платформе «1С: Предприятие 8», он способен
производить обмен данными с системой ГИС ЖКХ с использованием Excelфайлов или напрямую через защищённое соединение.
3. Виртуальный «ИРЦ ЖКХ» - Регион от компании Пафэс – позволяет
проводить автоматизацию информационно-расчётных процессов отрасли
ЖКХ для всех её участников в режиме реального времени. Продукт
использует модульный принцип построения, позволяющий обеспечить
расширение функционала за короткое время без обязательной перестройки
всей системы.
4. «Стек-ЖКХ» – программный продукт, который предназначен для
повышения эффективности и сокращения расходов на управление МКД,
который может эксплуатироваться управляющими компаниями, расчётными
центрами и службами заказчика. Данный комплекс состоит из десяти
программ. Продукт способен автоматизировать процессы расчётов и
обслуживания клиентов в сфере ЖКХ.
По результатам проведенного исследования составлен перечень
функциональных возможностей систем из данной предметной области,
выделены функции, которые требуется автоматизировать для включения
собственников жилья в контур системы управления многоквартирным
домом.
В работе А.А. Попова «Использование облачных технологий для
формирования
инновационной
многоквартирными
автоматизации
домами»
процессов
ИТ-инфраструктуры
рассмотрены
управления
и
вопросы,
управления
касающиеся
многоквартирными
домами.
17
Рассматривается
управление
МКД,
осуществляемое
товариществами
собственников жилья.
Закономерности
автоматизации
процессов
управления
МКД
и
совершенствования ИТ-инфраструктуры ТСЖ, определяются следующими
факторами:
– постановлениями
Правительства РФ;
– международными стандартами;
– мировыми
тенденциями в развитии информационных технологий;
– тенденциями
развития
рынка
информационных
систем
для
управления жилищно-коммунальным хозяйством в РФ;
– уровнем
готовности ТСЖ к автоматизации работы по управлению
МКД.
Рассмотрены
использования
основные
факторы,
автоматизации
определяющие
деятельности
по
направления
управлению
многоквартирными домами. Показаны тенденции в развитии облачных
технологий в мире и Российской Федерации. Приведены примеры
отечественных
информационных
систем,
реализующих
облачные
технологии. Сформулированы рекомендации для руководства ТСЖ при
внедрении
облачных
технологий
в
деятельность
по
управлению
многоквартирными домами.
При планировании подключения к облачным технологиям руководство
ТСЖ должно рассмотреть следующие вопросы:
– ознакомление
с
терминами
и
обозначениями,
используемыми
производителями программного обеспечения;
– определение
приложений, необходимых для деятельности ТСЖ;
– возможность
использования
услуг
альтернативных
Интернет-
провайдеров (в случае отключения Интернета по вине провайдера) и
поставщиков облачных технологий;
– использование
альтернативного поставщика облачных технологий для
учета возможности поддержки различных типов облака и возможности
18
использования иных программных и аппаратных платформ;
– заключение
соглашения об уровне обслуживания с поставщиками
услуг Интернета и облачных технологий, которое позволит руководству
ТСЖ знать, кто и за что отвечает в разных обстоятельствах;
– обеспечение
целостности информации (базы данных, системы
резервного копирования, алгоритмы проверки целостности);
– разработка
режимов доступа к данным и приложениям, порядка
устранения возможных ошибок и осуществления обновлений программного
обеспечения (совместно с поставщиками облачных технологий);
– разработка
планов аварийного восстановления работоспособности
информационной системы после отказов (совместно с поставщиками
облачных технологий);
– установление
в договоре с поставщиком облачных технологий
местонахождения данных, характеризующих ТСЖ (на случай раздела
имущества, слияния, остановки деятельности), и продолжительности их
хранения;
– составление
стратегии выхода из облачных технологий (в случае
отсутствия необходимости использования облачных технологий, изменения
стратегии функционирования ТСЖ);
– рассмотрение
вопросов
информационной
безопасности
при
использовании облачных сервисов;
– учет
степени готовности ТСЖ к автоматизации.
Абоненты, участвующие в управлении МКД, при использовании
облачных технологий получают следующие преимущества:
– возможность
получить в режиме реального времени информацию о
тарифах ЖКХ, своевременности расчетов с поставщиками энергоресурсов,
собираемости платежей, аналитику о ситуации в ЖКХ, а также формировать
отчеты
о
состоянии
ЖКХ
и
жилищного
фонда
(для
абонентов–
муниципальных руководителей различного уровня);
– возможность
осуществлять в режиме реального времени начисления
19
за весь комплекс услуг, предоставляемых жильцам ТСЖ, автоматически
выставлять
счета,
производить
контролировать
формирование
оплату,
квитанций
документов, публиковать сообщения
со
распределять
платежи,
штрих-кодом,
отчетных
о работе ТСЖ (для абонентов–
руководителей ТСЖ);
– возможность
работать в режиме реального времени с личными
кабинетами, отслеживать в режиме реального времени начисления и
платежи, состояние заявок на обслуживание оборудования МКД, а кроме
того – общаться с другими абонентами системы (для абонентов–жильцов
МКД и ТСЖ);
– возможность
недвижимость,
а
доступа
также
к
к
данным
информации,
жильцов
характеризующей
ТСЖ
–
социально-
демографическим данным, сведениям о льготах и т.д. (для абонентов–
сотрудников паспортных столов, социальных служб и др.);
– возможность
в режиме реального времени отслеживать состояние
счетов абонентов и своевременность оплаты коммунальных услуг (для
абонентов–сотрудников
банков, поставщиков
коммунальных
услуг
и
коммунальных ресурсов).
1.2 Описание предметной области
По использованию схожих типов информационных продуктов сферу
ЖКХ можно условно подразделить на три уровня – верхний, средний и
нижний.
Нижний уровень включает процессы диспетчеризации и расчёта с
потребителем (кассовое обслуживание, электронные платежи и т д). За
диспетчеризацию отвечают системы учёта показаний приборов. Нижним
уровнем любых систем диспетчеризации является контрольно-измерительная
аппаратура,
устройства
автоматизированного
управления.
Устройства
автоматики должны объединяться между собой линиями передачи цифровых
данных, что создает единое информационное пространство для системы
20
автоматизации и диспетчеризации. Для диспетчерского управления больших
групп систем и оборудования используются операторские станции на базе
персонального компьютера.
Верхний уровень включает государственная информационная система
жилищно-коммунального хозяйства – единый информационный ресурс
сферы ЖКХ. Туда стекаются данные управляющих компаний и товариществ
собственников жилья со всей страны. Это уже федеральный уровень.
В систему ГИС ЖКХ из информационных систем ЖКХ поступает
информация:
 об управляющих компаниях;
 о показаниях приборов учёта;
 о начислениях;
 об оплате счетов;
 о капитальном ремонте.
Функциональные компоненты можно разделить на несколько уровней:
 сервисы,
реализующие
основную
функциональную
логику
и
управляющие данными,
 web-модули,
которые
предоставляют
REST-интерфейс
для
интерфейса,
 клиентский интерфейс, который исполняется в браузере на стороне
клиента,
 интеграционный
интерфейс,
предоставляющий
доступ
к
функциональности и данным информационных систем, с которыми ведёт
взаимодействие ГИС ЖКХ.
На среднем уровне происходит работа с данными, аналитика,
планирование и контроль мероприятий по обеспечению эффективности. На
данном уровне чаще всего используются информационные системы по
управлению многоквартирными домами. На среднем и нижнем уровнях
происходит работа управляющих компаний,
товариществ собственников
21
жилья, ресурсоснабжающих организаций.
Одними из главных частей информационных систем по управлению
многоквартирными домами является информационные порталы или сервисы.
Есть две основные технологии их создания – клиент-серверная и облачная
технологии.
Модель «клиент-сервер» подразумевает, что компьютер, который
управляет тем или иным ресурсом, принято называть сервером этого ресурса,
а компьютер, который желает им воспользоваться — клиентом. Данный
принцип распространяется и на взаимодействие программ. Если одна из них
выполняет некоторые функции, предоставляя другим соответствующий
набор услуг, то данная программа рассматривается в качестве сервера.
Программы, пользующиеся этими услугами, принято называть клиентами. В
последнее время клиент-серверные решения становятся менее популярными
на фоне облачных решений.
Основные особенности «облака»:
 повсеместный доступ к вычислительным ресурсам;
 предоставление
и
освобождение
вычислительных
ресурсов
с
минимальными усилиями по управлению и необходимости взаимодействия с
провайдером.
1.3 Обзор аналогов информационной системы
1.3.1 Комплекс программ БИТ.ЖКХ
Облачный
комплекс
программ
«БИТ.ЖКХ»
предназначен
для
автоматизации учетной и финансовой деятельности предприятий жилищнокоммунального хозяйства,
оперативного
учета
ведения
расчетов
с квартиросъемщиками и организациями-поставщиками услуг (рисунок 1.1).
Продукт совместим с «1С:Бухгалтерия 8», но для работы с комплексом
программ требуется платформа «1С:Предприятие 8».
22
Рисунок 1.1 – Интерфейс программы «БИТ.ЖКХ»
Основными функциями данного комплекса программ являются:
1. Учет жилого фонда:
 учет жилого и нежилого фонда по административным округам и виду
жилого фонда;
 учет сведений о каждом многоквартирном доме;
 учет сведений о каждом помещении многоквартирного дома жилом и
нежилом (паркинге, офисе);
 гибкая структура учета предоставляемых услуг ЖКХ с помощью
введения различных режимов потребления услуг, ставок и норм потребления
на услуги;
 учет владельцев жилья и жильцов.
2. Паспортная служба:
 ведение учета и отчетности паспортного стола;
 временная прописка и автоматическое снятие с учета временно
зарегистрированных жителей по завершении срока регистрации;
23
 интеграция абонентной, паспортной службы, сбора платежей с
ведением бухгалтерского учета на предприятиях ЖКХ.
3. Расчет льгот по коммунальным платежам:
 расчет и учет льгот по коммунальным услугам (льгота привязывается
к человеку, а не к лицевому счету и при расчете выбирается самое выгодное
для квартиросъемщика сочетание нескольких льгот);
 регистрация и удаление временных льгот;
 расчет и учет льгот по разным источникам финансирования или
бюджетам.
4. Ведение лицевых счетов:
 ведение разделенного сальдо по услугам в разрезе лицевого счета,
что даёт возможность создания отчетности в разрезе поставщиков услуг;
 расчет и учет начислений по лицевым счетам для жилых и нежилых
помещений, используя разные алгоритмы начислений;
 разные варианты расчетов по услугам, в том числе и по приборам
учета индивидуальным и групповым с возможностью ведения автоматически
перерасчетов со дня установки или же снятия счетчика;
 учет долгов за коммунальные услуги в разрезе видов услуг;
 учет перерасчетов;
 начисление пени;
 возможность массовой печати счет-извещений в начале месяца;
 возможность печати различных видов счет-извещений и приема
оплат по ним в одной базе данных.
 возможность автоматизированного ввода оплат с использованием
сканера и штрихкода на счет-извещениях;
 разноска
платежей
с
разных
источников
сбора
платежей,
предоставленных как на бумажных носителях, так и в электронном виде;
24
 ведение истории по лицевым счетам в разных разрезах – сведений о
помещениях, жильцах, начислениях, льготных недоплатах, показаниях
счетчиков;
 возможность формирования отчетов с выводом разных данных и
всевозможных комбинаций с использованием настройки гибкого механизма
компоновки данных.
1.3.2 Виртуальный ИРЦ ЖКХ
Главное предназначение «Виртуальный ИРЦ ЖКХ» - автоматизация
взаиморасчётов в отрасли и объединение всех участников в гибридную
виртуальную сеть (рисунок 1.2).
Рисунок 1.2 – Интерфейс программы «Виртуальный ИРЦ ЖКХ»
25
В её состав входят следующие основные модули:
1. Личный кабинет абонента ЖКХ. Среди выполняемых функций есть
следующие:
 своевременное информирование о тарифах;
 загрузка/выгрузка показаний приборов учёта;
 интерактивная связь со всеми участниками системы;
 оплата онлайн или печать квитанций на оплату услуг.
– подача
заявки в аварийно-диспетчерскую службу или в сервис
платных услуг.
2. Личный кабинет администратора. Среди выполняемых функций есть
следующие:
 производить
ведение
реестра
зданий
и
помещений
с
индивидуальными и коллективными приборами учёта;
 производить ведение реестра лицевых счетов не только для
физических, но и для юридических лиц;
 производить ведение реестра услуг от разных поставщиков с
историей тарифов за любой период;
 производить привязку нескольких помещений к лицевому счёту с
помощью договоров с несколькими поставщиками услуг;
 производить назначение услуги в соответствии с договорами;
 проводить периодические и разовые начисления за назначенные
услуги, а кроме того все виды перерасчётов;
 осуществлять платежи и корректировки балансов лицевых счетов;
 производить публикацию объявлений для групп абонентов в их
личные кабинеты;
 осуществлять ведение учёта заявок от абонентов и держать под
контролем их исполнение в виртуальной диспетчерской;
 держать под контролем корректность ведения учёта и получать
аналитическую информацию с использованием конструктора отчётов.
26
3. Биллинговый центр – позволяет в реальном времени осуществлять
ведение учёта всех изменений для взаиморасчётов. Встроенные функции
позволяют обеспечить выполнение следующих задач:
– составление
единых справочников и классификаторов;
– составление
единых реестров;
– учет
программ и объектов капитального ремонта;
– регулярные
начисления абонентам;
– периодические
– все
начисления абонентам;
виды перерасчетов за ЖКУ;
– финансовый
– создать
учет ;
"Электронный паспорт дома";
– отслеживание
и сопровождение исполнения программ капитального
ремонта;
– управление
и контроль над формированием фондов капитального
ремонта;
– встроенный
– обмен
генератор формирования отчетов и аналитики;
данными с внешними информационными системами и
программами учета.
1.3.3 Инфокрафт ЖКХ 365
«Инфокрафт ЖКХ 365» - это облачный сервис для расчёта квартплаты
и бухгалтерского учёта (рисунок 1.3). Данная программа рассчитана на
небольшое число пользователей.
27
Рисунок 1.3 – Интерфейс программы «Инфокарт ЖКХ 365»
Он включает следующие основные сервисы:
1. «Расчёт квартплаты и бухгалтерия онлайн» позволяет проводить
расчёт квартплаты, ведение бухгалтерского и паспортного учёта, учитывание
жилого
фонда,
обслуживание
владельцев
помещений
и
ведение
претензионной работы. Основные возможности:
– осуществление
автоматического
составления
бухгалтерской
и
налоговой отчетности;
– бухгалтерские
– учет
проводки по коммунальным услугам;
справочной информации по объектам жилого и нежилого фонда;
– ведение
лицевых счетов собственников, нанимателей и арендаторов
помещений;
– учет
владельцев объектов недвижимости;
– расчет
начислений по квартплате и коммунальным услугам (с учетом
льгот, показаний индивидуальных и коллективных приборов учета,
изменения состава проживающих, корректировок, перерасчетов, скидок за
недопоставленные услуги, авансов, пени и др.);
– прием
оплаты (например с использованием кассового оборудования и
сканера штрих-кодов);
28
– регистрационный
учет граждан (регистрация граждан по месту
жительства и по месту проживания, снятие граждан с регистрационного
учета, выдача (замена) паспортов, составление и печать требуемых форм
отчетности);
– претензионная
– составление
работа (работа с должниками);
единого платежного документа (ЕПД), расчет и
распределение общедомовых нужд (ОДН);
– широкий
спектр отчетов.
2 Обмен данными с системой ГИС ЖКХ.
3 Электронная отчётность – позволяет отправлять отчёты во все
контролирующие органы прямо из «1С:Предприятия» без использования
других программ.
1.3.4 Другие аналоги
Приведём краткое описание остальных аналогов.
«Стек-ЖКХ»
–
комплекс
десяти
программ,
повышающий
эффективность и снижающий затраты на управление многоквартирным
жилым домом, который возможно эффективно применять в управляющих
компаниях,
расчетных
центрах
и
службах
заказчика.
Производит
автоматизацию бизнес-процессов по расчетам и обслуживанию абонентов в
сфере жилищно-коммунальных услуг.
Информационная система Domosite.ru даёт возможность создавать
официальные страницы ТСЖ/УК с возможностью размещения новостей и
отчётности, отслеживать реестр жителей и владельцев, производить сбор и
сдачу показаний счётчиков, делать напоминания абонентам по почте,
создавать отчёты по потреблению коммунальных услуг, производить ведение
журнала заявок с СМС-уведомлениями, вести календарь, участвовать в
форуме, работать с диспетчерской службой.
29
Информационная
система
«07.ЖКХ»
позволяет
использовать
мониторинг
выполнения
следующие возможности:
1. Для
органов
гос.
власти
–
производственных и инвестиционных программ, создание прогнозов, расчёт
и целевое использование бюджетных средств для социальной поддержки
отдельных категорий граждан и субсидий по оплате ЖКУ.
2. Для органов местного самоуправления – доведение до сведения
населения информации о работе организаций ЖКХ, ведение учёта
электронных паспортов объектов жилого фонда, координация работы всех
управляющих организаций.
3. Для управляющих ресурсоснабжающих организаций и рассчётнокассовых центров – использование платёжных сервисов для проведения
расчётов по многоставочным тарифам с возможностью автоматизированного
сбора показаний с общедомовых и индивидуальных приборов учёта.
4. Для населения – получение сведений о состоянии лицевого счёта,
заказ требуемых справок, введение показаний индивидуальных приборов
учёта, оплата счета и заказ дополнительных услуг.
«1С: ВДГБ: Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК» решение, позволяющее автоматизировать различные службы ТСЖ: службу
расчета
квартплаты
и
коммунальных
услуг;
службы
технического
содержания и ремонта зданий, помещений и другой коммунальной
инфраструктуры; паспортную службу; финансовую службу.
Проведём сопоставление представленных выше систем по списку
функций, требуемых для управления МКД.
представлены в таблице 1.
Результаты сравнения
30
Таблица 1 – Сравнительный анализ систем управления МКД
Функции
систем
Личный
кабинет
абонента
Электронная
отчётность
Обмен с ГИС
ЖКХ
Проведение
голосования
собственников
Ввод
показаний
приборов учёта
Диспетчерская
служба
Автоматизация
оплаты услуг
ЖКХ
Работа с
задолженностя
ми
Паспортный
стол
Фонд
капитального
ремонта
Расщепление
платежей
Мониторинг
целевого
использования
средств фонда
капитального
ремонта
СМС-сервис
Разработка
сайтов
Системы управления МКД
СТЕК Виртуальн Domosite. 07.ЖК 1С:
ый ИРЦru
Х
ВДГ
ЖКХ ЖКХ+
Б
+
+
+
+
+
Инфокра
фт ЖКХ
365+
+
+
+
+
+
+
+
+
+
-
+
+
+
+
-
+
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
+
+
+
+
-
-
+
+
-
+
-
-
+
-
+
+
-
-
+
-
+
+
-
-
-
-
+
+
+
-
+
+
-
+
+
+
31
1.4 Моделирование use-case
1.4.1 Анализ акторов системы
Диаграмма вариантов использования – графическое изображение
взаимодействия
моделируемой
некоего
актора
(действующего
лица,
системы.
Любой
вариант использования
сущности)
и
представляет
функцию системы и решает задачу, поставленную перед системой. Список
вариантов использования позволяет определить функциональные требования
к системе. При разработке диаграммы вариантов использования должны
быть определены общие границы предметной области, сформулированы
общие требования к работе системы.
Перед
непосредственным
выявлением
вариантов
использования
необходимо определиться с основными акторами системы. Актор – внешняя
для системы сущность, взаимодействующая с системой и использующая её
функции для достижения требуемых целей. В общем случае актор
располагается вне системы, его внутренняя структура никак не определена.
На рисунке 1.4 представлены основные кандидаты в акторы системы.
Рисунок 1.4 – Анализ акторов системы
32
Под жильцом дома понимается собственник жилья, который заключил
договор с управляющей компанией о предоставлении услуг ЖКХ для
определённой жилплощади. Под иным лицом подразумевается иное
физическое лицо, заключившее договор с управляющей компанией о
предоставлении услуг ЖКХ. В качестве организаций, пользующимися
услугами ЖКХ выступают юридические лица, заключающие договоры с
управляющей организацией для использования услуг ЖКХ.
Под
товариществом
собственников
жилья
(ТСЖ)
понимается
некоммерческая организация по управлению общим имуществом, то есть
многоквартирным домом или домами. Может выступать в качестве абонента
в том случае, если им был заключён договор со специализированной
компанией.
Управляющая организация контролирует эксплуатацию дома и придомовой территории и периодически отчитывается перед собственниками
квартир о расходовании выделенных на это средств. При этом в качестве
подобной организации может выступать и ТСЖ в случае, когда оно
занимается
коммунальным
обслуживанием
самостоятельно.
Ресурсоснабжающая организация - юридическое лицо, осуществляющее
продажу коммунальных ресурсов.
Анализ акторов показывает, что управляющие и ресурсоснабжающие
организации, а также ТСЖ предполагают использовать разрабатываемую
систему однотипно, что позволяет обобщить данные роли в одну.
Аналогичная ситуация – с жильцами дома и иными физическими лицами, а
также организациями, пользующимися услугами ЖКХ.
33
Краткое описание акторов представлено в таблице 2.
Таблица 2 – Краткое описание акторов
Актор
Краткое описание
Абонент
Использует систему для просмотра
имеющейся информации о счёте и
изменениях тарифов, для ввода
показаний приборов учета и оплаты
счета, печати квитанции.
Администратор
Просматривает, корректирует данные
об обслуживаемом фонде и работает
с ним, вводит данные
индивидуальных приборов учёта и
формирует различные отчёты,
квитанции.
1.4.2 Выявление вариантов использования
Вариант
использования
(use
case)
–
внешняя
спецификация
последовательности действий, которые система способна выполнить при
взаимодействии с актором. Любой вариант использования определяет
конечный набор действий, которые совершает система при диалоге с
актором, а также даёт описание реакции сущности системы на получение
отдельных сообщений от действующих лиц и восприятие этих сообщений за
пределами
сущности.
При
этом
нет
описания
самой
взаимодействия.
Выявленные варианты использования сведены в таблицу 3.
реализации
34
Таблица 3 – Выявление вариантов использования
Основной
Наименование
Формулировка
1
2
3
Абонент
Просмотр
Этот вариант использования позволяет
информации о
абоненту просматривать информацию о
лицевом счете и
текущем состоянии лицевого счёта и
начислениях,
начислениях на счёт, историю платежей.
актор
истории
платежей
Ввод показаний
Этот вариант использования позволяет
приборов учёта
абоненту ввести показания приборов
учёта.
Оплата счёта
Этот вариант использования позволяет
абоненту оплатить счёт онлайн
Формирование и
Этот вариант использования позволяет
печать
абоненту сформировать квитанцию об
квитанции
оплате и распечатать её.
Просмотр
Этот вариант использования позволяет
контактных
абоненту просматривать контактные
данных и
данных и общей информации об
информации об
организации.
организации
Администратор
Просмотр
Этот вариант использования позволяет
данных об
администратору просматривать данные
обслуживаемом
о состоянии обслуживаемого фонда
фонде
35
Продолжение таблицы 3
1
2
3
Администратор
Работа с
Этот вариант использования
обслуживаемым
позволяет администратору работать с
фондом
обслуживаемым фондом и
редактировать, добавлять и удалять
данные о нём.
Информирование
Этот вариант использования
абонентов о
позволяет администратору
начислениях,
информировать абонентов о
новостях
начислениях на лицевой счёт, об
изменениях тарифов и других
новостях.
Формирование
Этот вариант использования
отчётов
позволяет администратору
сформировать отчёт.
Назначение услуг в
Этот вариант использования
соответствии с
позволяет назначать услуги,
договорами
указанные в договорах.
Варианты использования могут описываться различными способами,
включая графический и табличный. Графическая визуализация в виде
диаграммы вариантов использования отображена на рисунке 1.5.
36
Рисунок 1.5 – Диаграмма прецедентов системы
1.5 Постановка задачи
В данной работе требуется сформулировать задачу по разработке
облачного сервиса, автоматизирующего деятельность в области ЖКХ.
Для выполнения задания необходимо решить несколько подзадач:
 разработать и реализовать структуру сервиса;
 разработать и реализовать структуру БД.
Под структурой сайта понимается модульная структура, включающая
различные модули, входящие в рабочий код приложения. Для реализации
сервиса будут использоваться облачные технологии, так как они обладают
следующими преимуществами:
– работа
с сервисом происходит через веб-браузер по зашифрованному
протоколу (HTTPS) по модели SaaS ("программа, как сервис");
– снижается
нагрузка
на
ИТ-инфраструктуру:
все
вычисления
выполняются в облачной среде удаленно, на серверах провайдера;
37
– создается
единое информационное пространство для собственников
жилья, доступ к которому они имеют в режиме 24/7, при наличии телефона,
планшета или ПК и подключения к сети Интернет;
– не
нужно привлекать специалистов для установки, наладки и
обслуживания и обновлении версий ПО. Все эти обязанности лежат на
провайдере облачного сервиса.
Для данной системы предпочтительно использование технологии SaaS,
предоставляющая абонентам возможность принимать участие в управлении
многоквартирными домами с помощью облачных сервисов. Модель сервиса
(SaaS) предполагает, что абоненты, принимающие участие в управлении
многоквартирными домами, не приобретают
программы в виде клиентских
приложений, а только платят за использование программного приложения
через Интернет. Сами же программные приложения установлены, работают и
обслуживаются у провайдера облачных технологий на его оборудовании.
Провайдер обеспечивает бесперебойную работу прикладных решений в
режиме
реального
приложений,
времени,
формирование
своевременное
резервных
обновление
копий
и
программных
обеспечение
конфиденциальности данных, характеризующих работу ТСЖ. Любой абонент,
подключившийся к информационной системе (информационному сервису),
имеет возможность работать сразу с несколькими информационными
сервисами. Для каждого пользователя информационного сервиса провайдеров
автоматически выделяется независимая область памяти для деятельности, при
этом происходит обращение к единой информационной базе.
Перед
началом
проектирования
требуется
проанализировать
имеющиеся на рынке облачные платформы и выбрать наиболее подходящую.
Из-за того, что облачная архитектура предполагает принцип слабой
связности между модулями (сервисами), то требуется определить количество
модулей, далее разработать структуру каждого модуля, затем общую
структуру системы.
38
Под
разработкой
структуры
БД
подразумевается
создание
концептуальной, логической и физической модели данных. Концептуальная
модель данных охватывает описание главных сущностей и отношений между
ними. Логическая модель данных определяет для сущностей их атрибуты,
описания и ограничения, уточняет состав сущностей и взаимосвязи между
ними, тем самым дополняя концептуальную модель данных. Физическая
модель данных содержит реализацию объектов логической модели на уровне
объектов конкретной базы данных.
В связи с вышесказанным, а также на основе диаграммы прецедентов
можно выделить требования к данной системе. Требуется выделить
функциональные
и
нефункциональные
требования.
Функциональные
требования определяют действия, которые система должна быть способной
выполнить.
системы.
Они
регламентируют
Нефункциональные
функционирование
требования —
или
требования,
поведение
которые
определяют критерии работы системы в целом, а не отдельные сценарии
поведения. Они регламентируют внутренние и внешние условия или
атрибуты функционирования системы.
Функциональные требования:
 просматривать, добавлять, удалять и редактировать информацию о
лицевом счете и начислениях;
 сохранять, просматривать и дополнять истории платежей;
 просматривать, добавлять, удалять и редактировать контактные
данные и другую информацию об организации;
 вводить показания счётчиков;
 оплачивать счёт онлайн;
 формировать квитанции;
 печатать квитанции;
 формировать отчёты;
39
 просматривать данные об обслуживаемом фонде;
 работать с обслуживаемым фондом;
 доносить требуемую информацию до абонентов;
 назначать услуги в соответствии с договорами;
 входить в систему с правами Абонента или Администратора.
Нефункциональные требования:
 должна быть надёжной;
 интерфейс должен быть удобен;
 должна быть легко масштабируемой;
 должна быть возможность менять функциональность в зависимости
от текущих задач (гибкость);
 должна обеспечиваться безопасность конфиденциальных данных
пользователей;
 должна быть отказоустойчива;
 должна
модулями.
придерживаться
принципа
слабой
связности
между
40
2 ПРОЕКТИРОВАНИЕ ОБЛАЧНОГО СЕРВИСА
2.1 Диаграмма деятельности
Диаграмма деятельности – один из пяти видов диаграмм, применяемых
в UML для моделирования динамических аспектов поведения системы. Она
позволяет описывать логику процедур, бизнес-процессы и потоки работ. В
конечном итоге деятельность сводится к некоторому действию, которое
составлено из атомарных вычислений, приводящих к изменению состояния
системы или возврату значения. Цель концептуального описания диаграммы
деятельности – показать целостную картину бизнес-процессов. Диаграмма
деятельности может использоваться как для описания бизнес-процесса, так и
функциональных требований к системе.
Диаграммы деятельности определяют все возможные состояния, в
которых может находиться объект, а также процесс смены состояний объекта
в результате событий.
Состояние – это некоторое условие или ситуация в процессе
жизненного
цикла
объекта,
в
течение
которого
он
удовлетворяет
логическому условию, выполняет некоторую деятельность или ожидает
некоего события. Событие – спецификация важных явлений в поведении
системы, имеющих местоположение во времени и пространстве. Переход –
это отношение между двумя состояниями, указывающее на то, что объект в
первом состоянии должен выполнить определённые действия и перейти во
второе состояние.
Имеются также два вида псевдосостояний: начальное состояние, в
котором находится только что созданный объект, и конечное состояние,
которое объект не покидает, как только туда попадает.
На второй диаграмме показан процесс контроля за выполнением
коммунальных услуг (рисунок 2.1). Сущность и необходимость данного
процесса заключена в следующем. В случае недобросовестного исполнения
обязанностей специалистами возможна ситуация, при которой специалист
41
отчитался в выполнении услуги, хотя на самом деле она не была выполнена.
Для исключения подобных прецедентов запрашивается подтверждение
выполнения
услуги
непосредственно
у
потребителя.
В
результате
потребитель может подтвердить выполнение услуги, опровергнуть факт
выполнения услуги, либо может не дать никакого ответа.
Рисунок 2.1 – Диаграмма деятельности контроля выполнения
коммунальных услуг
2.2 Структура облачного сервиса
Прежде чем определять структуру облачного сервиса следует
определить модель обслуживания и модель развёртывания облачного
42
сервиса.
Основными моделями обслуживания для облачных приложений
являются SaaS (программное обеспечение как услуга), PaaS (платформа как
услуга) и IaaS (инфраструктура как услуга). «Программное обеспечение как
услуга» предусматривает предоставление (через провайдера) абонентам
информационной
системы
(из
числа
участников
управления
МКД)
возможность работы с приложениями (информационными сервисами).
Вычислительные ресурсы, предоставляемые абонентам, доступны через
стандартные возможности, используемые различными программными и
аппаратными
платформами
(через
мобильные
устройства,
автоматизированные рабочие места). «Платформа как услуга» предоставляет
абонентам возможности для развертывания в облачной инфраструктуре
приложений (информационных сервисов) для управления многоквартирными
домами,
созданных
или
приобретенных
абонентом,
но
при
этом
поддерживаемых провайдером. «Инфраструктура как услуга» предоставляет
абонентам возможность дистанционно работать с готовой информационной
инфраструктурой, на которой
он имеет возможность разворачивать
абонентские платформы и приложения.
Для ТСЖ, скорее всего, предпочтительна реализация технологии SaaS,
предоставляющая
абонентам
возможность
участвовать
в
управлении
многоквартирными домами с помощью Интернет-сервисов. Модель сервиса
(SaaS)
подразумевает,
что
абоненты,
многоквартирными домами, не приобретают
участвующие
в
управлении
программы в виде клиентских
приложений, устанавливаемых на компьютеры, а лишь платят за пользование
программным приложением
через Интернет. Сами
же
программные
приложения установлены, работают и обслуживаются у провайдера облачных
технологий на его оборудовании. Провайдер обеспечивает бесперебойную
работу прикладных решений в режиме реального времени, своевременное
обновление программных приложений, формирование резервных копий и
обеспечение конфиденциальности данных, характеризующих деятельность
43
ТСЖ. Каждый из абонентов, подключающихся к информационной системе
(информационному
сервису),
может
работать
сразу
с
несколькими
информационными сервисами. Для каждого пользователя информационного
сервиса провайдеров автоматически выделяется независимая область памяти
для работы, при этом происходит обращение к единой информационной базе.
В результате использования облачной технологии в виде SaaS ТСЖ
может также получить большую выгоду в виде значительного уменьшения
затрат на автоматизацию деятельности по управлению многоквартирными
домами (нет необходимости
приобретения
сервера и
программного
обеспечения, стоимость подключения к информационным сервисам –
фиксированные
ежемесячные
платежи,
не
надо
платить
зарплату
специалистам, необходимым для внедрения и поддержки информационной
системы).
Появляется
возможность
произвольно
менять
доступные
информационные сервисы по требованию абонентов без внесения изменений
в аппаратную и программную платформу.
Существует несколько моделей развертывания: частное облако,
публичное облако, общественное облако, гибридное облако.
Частное облако (private cloud) – это инфраструктура, которая
располагается в пределах одной организации. Данная модель развертывания
создана
с
целью
удовлетворить
потребности
внутреннего
рабочего
персонала, обеспечивая высокий уровень безопасности данных. Частное
облако создается, например, для обеспечения какой-либо дочерней компании
сервисом корпоративной почты.
Публичное
облако
(public
cloud)
–
это
инфраструктура,
предназначенная для свободного использования широкой публикой. Этот тип
облака может находиться в собственности, например, коммерческих,
научных и правительственных организаций. Однако слово «публичное»
совсем не означает, что данные пользователей доступны абсолютно всем –
здесь по-прежнему реализуются механизмы безопасности для контроля
доступа.
Основным
достоинством
использования
публичного
облака
44
является простота настройки и низкая стоимость. Поставщик услуги делает
всю работу, необходимую для создания облака, а потребитель лишь
настраивает необходимое количество ресурсов.
Общественное облако (community cloud) имеет схожие черты с
частным и публичным облаком. Это вид инфраструктуры, предназначенный
для использования конкретным сообществом потребителей из организаций,
имеющих
общие
задачи.
Общественное
облако
может
управляться
организациями третьей стороны и существовать как внутри, так и вне
юрисдикции владельца. В этом случае ответственность по содержанию
облака перекладывается с плеч организаций-членов на все сообщество
целиком.
Гибридным же облаком (hybrid cloud) называют композицию из двух
или
более
типов
облаков,
стандартизированными
которые
технологиями
связываются
между
собой
передачи данных. Очень часто
компании запускают бизнес-критические приложения в приватном облаке, в
то время как остальные приложения работают в публичном облаке.
В данном случае остановимся на модели обслуживания SaaS (ПО как
услуга) и модели развёртывания в публичном облаке.
Модульная структура облачного приложения представлена на рисунке
2.2.
Она
предполагает
взаимодействие
модулей
личного
кабинета
физического лица, юридического лица, управляющей организации с
модулями СУБД, взаимодействия с внешними ГИС, взаимодействия с
платёжными системами.
45
Рисунок 2.2 - Модульная структура облачного сервиса
СУБД обеспечивает управление базой данных, которая содержит
данные, загружаемые в облачное приложение.
Модель взаимодействия с внешними ГИС отвечает за взаимодействие с
внешними информационными системами, в основном – с ГИС ЖКХ.
Государственная
информационная
система
жилищно-коммунального
хозяйства призвана стать единым информационным ресурсом в сфере ЖКХ,
где будут собраны нормативные акты, реестр лицензий управляющих
организаций и предприятий сферы ЖКХ, а также объектов жилого фонда,
новости коммунальной отрасли и результаты проверок. В России ГИС ЖКХ
начала работу с 1 июля 2016 года. Взаимодействие с системой происходит
через ГИС ЖКХ Web Service API v.9.0.1.4.
Взаимодействие с ГИС ЖКХ состоит из следующих частей:
 установка по ГОСТу шифрованного туннеля до серверов ГИС ЖКХ.
 формирование и отправка подписанного XML запроса.
46
 получение и проверка ответа.
Туннель поднимается с помощью Stunnel, который работает в режиме
прокси. Также требуется, чтобы он использовал модуль gost. OpenSSL
используется дважды: с ним собран stunnel, что-бы работал по ГОСТу; и
утилита openssl вызывается из кода для формирования и проверки подписей.
Когда туннель до сервера ГИС ЖКХ настроен и работает, можно слать
туда всякие запросы и получать нужные ответы. Запрос отправляется в виде
XMLDSig, в котором содержится сам запрос, хеш этого запроса, хеш
сертификата, сам сертификат, подпись хеша запроса с хешем сертификата и
множество полей, всё это описывающих.
Модуль взаимодействия с платёжными системами отвечает за
взаимодействие
с
банками
и
платёжными
системами
и
позволяет
производить оплату услуг абонентам. Используется API Яндекс.Кассы.
Модуль личного кабинет абонента реализует возможности просмотра
имеющейся информации о счёте и изменениях тарифов, для ввода показаний
приборов учета и оплаты счета.
Личный кабинет управляющей организации позволяет просматривать,
корректировать данные об обслуживаемом фонде и работать с ним, вводить
данные индивидуальных приборов учёта и формировать различные отчёты.
2.3 Структура базы данных
Концептуальная модель базы данных представляет собой описание
основных сущностей и отношений между ними (Приложение А, рисунок
А.1). Отношение (связь) устанавливается между двумя общими полями
(столбцами) двух таблиц. Существуют связи с отношением «один-комногим» и «многие-ко-многим». Наиболее распространенный вид связи:
«один-ко-многим». Для реализации связи «многие-ко-многим» необходимо
создавать дополнительную реляционную таблицу. Такая таблица должна
обязательно
содержать
первичные
ключи
устанавливается связь «многие-ко-многим».
таблиц,
между
которыми
47
Ниже будут перечислены основные сущности и даны краткие
пояснения:
 «управляющая компания» – информация об управляющей компании,
включающие банковские реквизиты и график работы;
 «вид услуги» – краткая информация о выполняемой услуге;
 «данные об услуге» – основные данные об услуге, входящие в
конкретную квитанцию;
 «перерасчёт услуг» – информация о перерасчёте платежа за услугу в
квитанции;
 «рассрочка (отсрочка) платежа» – информация о сумме рассрочки
(отсрочки) платежа за услугу в квитанции;
 «плательщик – юридическое лицо» – краткие сведения об абоненте юридическом лице;
 «административное здание» – краткие сведения о здании, которым
владеет юридическое лицо;
 «сведения о плательщике/жильце» – краткие сведения об абоненте –
физическом лице;
 «жилое строение» – краткая информация о жилье, в котором либо
проживает, либо сдаёт физическое лицо;
 «имущество и оборудование» – краткая информация об имуществе и
оборудовании, за которое отвечает управляющая организация (например
инженерные системы отопления, газоснабжения, водоснабжения);
 «квитанция» – краткая информация о квитанции;
 «договор» – краткая информация о договоре, заключаемом между
управляющей компанией и физическим или юридическим лицом (абонентом)
по оказанию коммунальных услуг.
Между сущностями «Управляющая компания» и «Административное
здание», а также между «Управляющая компания» и «Жилое строение»
существует связь «один-ко-многим», так как одна компания отвечает за все
48
данные
здания.
Между
сущностями
«Управляющая
«Квитанция», «Управляющая компания» и «Договор»
компания»
и
существует связь
«один-ко-многим», так как одна компания заключает множество договоров и
составляет множество квитанций. Между сущностями «Управляющая
компания» и «Вид услуги» существует связь «один-ко-многим», так как одна
компания оказывает множество видов услуг.
Между сущностями «Квитанция» и «Данные об услуге» существует
связь «один-ко-многим», так как в одной квитанции можно указать
несколько услуг. Между сущностями «Управляющая компания» и «Вид
услуги» существует связь «один-ко-многим», так как одна компания
оказывает множество видов услуг и их можно указать в одной квитанции.
Между сущностями «Квитанция» и «Рассрочка (отсрочка) платежа», а также
«Квитанция» и «Перерасчёт услуг» существует связь «один-ко-многим», так
как в одной квитанции могут быть указаны перерасчёт услуг и рассрочка
(отсрочка) платежа для нескольких видов услуг. Между сущностями
«Сведения о плательщике/жильце» и «Квитанция», а также «Плательщик –
юридическое лицо» и «Квитанция» есть связь «один-ко-многим» из-за того,
что одно и то же юридическое или физическое лицо может заполнять и
получать множество квитанций.
Между
сущностями
«Имущество
и
оборудование»
и
«Административное здание», а также «Имущество и оборудование» и
«Жилое строение» есть связь «один-ко-многим», так как в одном здании
может находиться несколько видов имущества и оборудования, за которое
отвечает управляющая организация.
Между
сущностями
«Плательщик
–
юридическое
лицо»
и
«Административное здание», а также «Сведения о плательщике/жильце» и
«Жилое строение» есть связь «один-ко-многим», так как абонент может
владеть жилплощадью в нескольких разных зданиях.
Между сущностями «Плательщик – юридическое лицо» и «Договор», а
также «Сведения о плательщике/жильце» и «Договор» есть связь «многие-ко-
49
многим», так как физическое или юридическое лицо может заключить
несколько договоров, а договоры в свою очередь могут быть заключены с
разными лицами. Для создания связей используются промежуточные
таблицы
«Договор_has_Плательщик
–
юридическое
лицо»
и
«Договор_has_Сведения о плательщике/жильце» соответственно.
Между сущностями «Административное здание» и «Договор», а также
«Жилое строение» и «Договор» есть связь «многие-ко-многим», так как одно
и то же здание может фигурировать в разных договорах, но договоры могут
включать
различные
промежуточные
здания.
таблицы
Для
создания
«Административное
связей
используются
здание_has_Договор»
и
«Договор_has_Жилое строение» соответственно.
Между сущностями «Вид услуги» и «Договор» есть связь «многие-комногим», так как одни и те же виды услуг могут фигурировать в разных
договорах, но список услуг, включённых в договор, может быть разным. Для
создания
связи
используется
промежуточная
таблица
«Вид
услуги_has_Договор».
Логическая модель расширяет концептуальную путем определения для
сущностей их атрибутов, описаний и ограничений, уточняет состав
сущностей и взаимосвязи между ними (Приложение А, рисунок А.2). Список
атрибутов таблиц с краткими пояснениями к ним даны ниже.
Для таблицы «Квитанция»:
 номер_квитанции
–
первичный
ключ,
который
служит
для
однозначной идентификации экземпляра таблицы в базе данных;
 плательщик – юридическое лицо_id - внешний ключ от экземпляра
таблицы «Плательщик»;
 управляющая компания_id - внешний ключ от экземпляра таблицы
«Управляющая компания»;
 сведения о плательщике/жильце_Лицевой счёт - внешний ключ от
экземпляра таблицы «Сведения о плательщике/жильце»;
 расчётный период – период, за который идёт начисление;
50
 итого к оплате – общая сумма, требующая оплаты;
 дата последней поступившей оплаты – дата предыдущей оплаты
квитанции.
Для таблицы «Рассрочка (отсрочка) платежа»:
 id
–
первичный
ключ,
который
служит
для
однозначной
идентификации экземпляра таблицы в базе данных;
 квитанция_Номер_квитанции - внешний ключ от экземпляра таблицы
«Квитанция»;
 вид услуги – вид услуги ЖКХ;
 сумма с рассрочкой за данный период – сумма с учётом долга за
текущий период;
 сумма с рассрочкой за предыдущие периоды – сумма с учётом долга
за предыдущий период;
 проценты за рассрочку – процент за использование рассрочки;
 общая сумма – общая сумма с учётом рассрочки платежа.
Для таблицы «Перерасчёт услуг»:
 id
–
первичный
ключ,
который
служит
для
однозначной
идентификации экземпляра таблицы в базе данных;
 квитанция_Номер_квитанции - внешний ключ от экземпляра таблицы
«Квитанция»;
 вид услуги – вид услуги ЖКХ;
 основание перерасчёта – причина для проведения перерасчёта;
 сумма – сумма, полученная в результате перерасчёта.
Для таблицы «Данные об услуге»:
 id
–
первичный
ключ,
который
служит
для
однозначной
идентификации экземпляра таблицы в базе данных;
 вид услуги_id - внешний ключ от экземпляра таблицы «Вид услуги»;
 квитанция_Номер_квитанции - внешний ключ от экземпляра таблицы
«Квитанция»;
51
 объём услуги за расчётный период – объём полученных ресурсов или
оказанных услуг;
 объём услуги на весь МКД - объём услуги на всё здание;
 тариф – цена на коммунальный ресурс;
 предыдущие показания – предыдущие показания приборов учёта;
 текущие показания – текущие показания приборов учёта;
 льготы и субсидии – сумма льгот и субсидий;
 задолженность – величина задолженности;
 итог – итоговая сумма платы за данный вид услуги за расчётный
период.
Для таблицы «Вид услуги»:
 id
–
первичный
ключ,
который
служит
для
однозначной
идентификации экземпляра таблицы в базе данных;
 управляющая компания_id - внешний ключ от экземпляра таблицы
«Управляющая компания»;
 наименование – название коммунальной услуги;
 единица измерения – единица измерения данной услуги.
Для таблицы «Вид услуги_has_Договор»:
 вид услуги_id – внешний ключ от экземпляра таблицы «Вид услуги»,
часть составного первичного ключа;
 договор_№ - внешний ключ от экземпляра таблицы «Договор», часть
составного первичного ключа.
Для таблицы «Договор»:
№
–
первичный
ключ,
который
служит
для
однозначной
идентификации экземпляра таблицы в базе данных;
 управляющая компания_id - внешний ключ от экземпляра таблицы
«Вид услуги»;
 дата заключения – дата заключения данного договора;
52
 начало действия договора – дата, начиная с которой данный договор
вступает в силу;
 конец действия договора – дата окончания действия договора.
Для таблицы «Управляющая компания»:
 id
–
первичный
ключ,
который
служит
для
однозначной
идентификации экземпляра таблицы в базе данных;
 название – наименование данной организации;
 банковские реквизиты – банковские реквизиты данной организации;
 юридический адрес – адрес регистрации данной организации;
 фактический адрес – адрес, где фактически располагается офис
данной организации;
 график работы – график работы данной организации;
 контактные данные – телефон, сайт и электронная почта данной
организации.
Для таблицы «Договор_has_Плательщик – юридическое лицо»:
 договор_№ - внешний ключ от экземпляра таблицы «Договор», часть
составного первичного ключа;
 плательщик – юридическое лицо_id – внешний ключ от экземпляра
таблицы «Плательщик – юридическое лицо», часть составного первичного
ключа.
Для таблицы «Плательщик – юридическое лицо»:
 id
–
первичный
ключ,
который
служит
для
однозначной
идентификации экземпляра таблицы в базе данных;
 название – наименование данной организации;
 юридический адрес – адрес регистрации данной организации;
 график работы – график работы данной организации;
 контактные данные – телефон, сайт и электронная почта данной
организации.
53
Для таблицы «Административное здание_has_Договор»:
 административное здание_id – внешний ключ от экземпляра таблицы
«Административное здание», часть составного первичного ключа;
 договор_№ - внешний ключ от экземпляра таблицы «Договор», часть
составного первичного ключа.
Для таблицы «Административное здание»:
 id
–
первичный
ключ,
который
служит
для
однозначной
идентификации экземпляра таблицы в базе данных;
 плательщик – юридическое лицо_id - внешний ключ от экземпляра
таблицы «Плательщик – юридическое лицо»;
 управляющая компания_id - внешний ключ от экземпляра таблицы
«Управляющая компания»;
 адрес – адрес данного здания;
 площадь жилья – общая площадь всех комнат данного здания.
Для таблицы «Имущество и оборудование»:
 id
–
первичный
ключ,
который
служит
для
однозначной
идентификации экземпляра таблицы в базе данных;
 жилое строение_id - внешний ключ от экземпляра таблицы «Жилое
строение»;
 административное здание_id - внешний ключ от экземпляра таблицы
«Административное здание»;
 наименование – название данного имущества или оборудования;
 состояние – техническое состояние данного имущества;
 срок службы – срок службы данного оборудования;
 дата установки – дата начала срока службы данного оборудования.
Для таблицы «Жилое строение»:
 id
–
первичный
ключ,
который
служит
идентификации экземпляра таблицы в базе данных;
для
однозначной
54
 управляющая компания_id - внешний ключ от экземпляра таблицы
«Управляющая компания»;
 сведения о плательщике/жильце_Лицевой счёт - внешний ключ от
экземпляра таблицы «Сведения о плательщике/жильце»;
 адрес – адрес данного здания;
 данные о виде собственности – частная или арендованная;
 общая площадь жилья – общая площадь всех комнат данного здания;
 количество прописанных человек – сколько человек прописано в
данном здании.
Для таблицы «Сведения о плательщике/жильце»:
 лицевой счёт – первичный ключ, который служит для однозначной
идентификации экземпляра таблицы в базе данных;
 фамилия – фамилия обладателя жилплощади;
 имя – имя обладателя жилплощади;
 отчество - отчество обладателя жилплощади;
 банковские
реквизиты
-
банковские
реквизиты
обладателя
жилплощади.
Для таблицы «Договор_has_Сведения о плательщике/жильце»:
 договор_№ - внешний ключ от экземпляра таблицы «Договор», часть
составного первичного ключа;
 сведения о плательщике/жильце_Лицевой счёт – внешний ключ от
экземпляра таблицы «Сведения о плательщике/жильце», часть составного
первичного ключа.
Для таблицы «Договор_has_Жилое строение»:
 договор_№ - внешний ключ от экземпляра таблицы «Договор», часть
составного первичного ключа;
 жилое строение_id – внешний ключ от экземпляра таблицы «Жилое
строение», часть составного первичного ключа.
55
Физическая
модель
данных
разрабатываемой
информационной
системы принимает вид в соответствии с рисунком A.3 в приложении А.
56
3 РЕАЛИЗАЦИЯ ПРОТОТИПА ОБЛАЧНОГО СЕРВИСА
3.1 Используемые инструменты разработки
В данном случае под выбором используемых инструментов разработки
подразумевается выбор языков программирования, СУБД. Так как требуется
создать облачное приложение, то необходимо выбрать облачную платформу
для размещения сервиса, а также облачного хранилища данных для
размещения базы данных.
От выбора облачной платформы может зависеть выбор языков
программирования, СУБД и облачного хранилища данных. Поэтому в
первую очередь следует определиться именно с выбором платформы.
Наиболее подходящие варианты - IBM Blue Cloud, Microsoft Azure, Google
App Engine, Amazon Elastic Compute Cloud.
IBM Blue Cloud предоставляет основные возможности облачных
вычислений.
Клиенты
могут
выбрать
из
более
распространенного
оборудования x86 или аппаратного обеспечения более высокого класса на
базе POWER. Blue Cloud использует программное обеспечение IBM Tivoli
для автоматического предоставления систем с разными возможностями
(процессор / память / диск), что позволяет организациям задействовать
внушительную вычислительную мощность – но платить за нее только по
мере необходимости. Помимо этого IBM является пионером в области
"закрытых" облачных платформ, предоставляя преимущества облачных
вычислений для внутренних приложений, находящихся за межсетевым
экраном.
IBM является одним из главных сторонников открытых технологий,
что делает платформу IBM привлекательным выбором для приложений, в
которых широко используются открытые технологии.
Платформа Microsoft Azure привязана к собственной операционной
системе, являющейся специализированной разновидностью Windows. Она
рассчитана на запуск любых .NET-приложений. Помимо этого Microsoft
57
начала предлагать версии многих своих серверных продуктов, работающие в
облаке на Azure. Но Azure - не просто Windows- и .NET-платформа.
Платформа Azure предлагает также множество иных услуг, в том числе SQL
Services, высокомасштабируемую базу данных на SQL Server, и Live Services
– интерфейс Web-сервисов для популярных приложений Microsoft: поиск,
обмен фотографиями, передачу мгновенных сообщений и так далее. Azure
также способен обеспечить тесную интеграцию с IDE Microsoft Visual Studio,
что облегчает запуск, тестирование и развертывание приложений на
платформе Azure.
Azure является одной из наиболее закрытых из имеющихся платформ
облачных вычислений, но у неё есть некоторые преимущества, связанные с
использованием коммерческих технологий Microsoft. С одной стороны.
возможности ограничены коммерческими технологиями Microsoft, такими
как языки .NET и базы данных на основе SQL Server, с другой – возможно
использовать многие технологии Windows для обеспечения безопасности
доступа и управления любыми приложениями, работающими на Azure.
Платформа Google App Engine сильно отличается от других облачных
платформ. На ней отсутствует выделение аппаратного обеспечения, в том
числе и виртуального; все, что потребуется – просто развернуть в ней
приложение, причем сделать это можно бесплатно. Но на использование
ресурсов App Engine накладываются ограничения, и дополнительную
процессорную мощность, ресурсы хранения и пропускную способность
Интернет-канала можно покупать по мере необходимости, также как и на
других облачных платформах.
Google App Engine даёт надежную среду разработки, которая
поддерживает лишь только Python. На Python разработано множество
сервисов, предлагаемых данной платформой. Управление пользователями
интегрировано с Google. Например, вход в приложение осуществляется с
теми же учетными данными, что и для входа в Google Mail. Имеются API для
хранения структурированных данных. Хранение и извлечение данных из
58
хранилища похоже на использование реляционной базы данных, но это
технология,
целиком
разработанная
Google.
В
ее
основе
лежит
распределенная файловая система Google GFS.
Google поддерживает только Python, который является открытой
технологией; остальные технологии принадлежат Google. Также Google App
Engine не предлагает каких-либо решений для резервного копирования
данных, но используемое хранилище данных рассчитано на высокую
отказоустойчивость.
Amazon Elastic Compute Cloud (EC2) была одной из первых платформ
облачных вычислений и до сих пор остается одной из наиболее известных.
Для начала работы с EC2, нужен экземпляр Amazon Machine (Amazon
Machine Instance, AMI). AMI является полным образом сервера с
операционной системой, приложениями и так далее. У Amazon и у
сообщества EC2 уже имеются множество известных образов AMI, как с
Microsoft Windows, так и с Linux, а кроме того с разными комплектами
открытого программного обеспечения, к примеру, Apache Web Server,
MySQL и интерпретатором Python. В случае, если не выходит подобрать
подходящий AMI, Amazon даёт средства создания собственных вариантов
AMI, которые возможно использовать лишь для себя или же поделиться с
сообществом.
AMI возможно установить на "экземпляры" разного размера. Требуется
просто выбрать нужный размер и развернуть AMI. Все администрирование и
управление экземпляром производится с использованием Web-сервисов.
Вокруг этих Web-сервисов уже выросла большая экосистема, облегчающая
управление экземплярами EC2.
EC2 работает на XEN - открытом ПО для виртуализации. С
использованием EC2 возможно запускать почти любое программное
обеспечение. В качестве операционных
систем для
AMI
обширно
применяются всевозможные разновидности Linux. Доступны различные
языки программирования: Java, PHP, Python и так далее. На EC2 возможно
59
использовать и коммерческое программное обеспечение, но гибкая природа
EC2 делает более привлекательным использование ПО с открытым исходным
кодом: не требуется беспокоиться о лицензировании, когда приходится
применять более крупные экземпляры или большее их количество.
Amazon
даёт
для
EC2
широкий
диапазон
услуг
в
области
инфраструктуры, которые возможно использовать для решения таких
проблем, как надежность данных и резервное копирование. Сервис Amazon
S3 является хорошим выбором для резервного копирования данных.
Администрирование и доступ к облаку производится исключительно с
использованием её Web-сервисов, требующих двухэтапной аутентификации.
Для реализации облачного сервиса остановим выбор на Amazon EC2
из-за более широкого выбора языков программирования, СУБД, и
возможности использования ПО с открытым исходным кодом.
В качестве облачного хранилища данных в данной среде используется
Amazon Elastic Block Store (Amazon EBS). Любой том Amazon EBS
автоматически
дублируется
внутри
собственной
зоны
доступности,
обеспечивая защиту от сбоя компонентов, а также высокую доступность и
надежность. Тома Amazon EBS обеспечивают производительность без сбоев
и задержек, которая нужна для выполнения рабочих нагрузок пользователя.
Благодаря Amazon EBS возможно изменять объем использования за короткое
время и платить лишь за используемые ресурсы.
Amazon EBS используется для рабочих нагрузок приложений, в
которых требуется точная настройка производительности, стоимости и
объема используемых ресурсов. Типовые случаи применения включают
системы аналитики больших данных, реляционные и NoSQL базы
данных (такие как Microsoft SQL Server, MySQL или Cassandra и MongoDB),
приложения для обработки журналов и потоковых данных (такие как Kafka и
Splunk), а кроме того приложения для хранения данных (такие как Vertica и
Teradata).
60
В качестве СУБД остановим выбор на MySQL, так как данная СУБД
"понимает" команды языка SQL, языка запросов, нашедшего применение во
всех современных СУБД. СУБД MySQL является высокопроизводительной и
относительно простой в использовании СУБД. Количество строк в таблицах
может достигать 50 млн.
В качестве языка программирования остановим выбор на Java, из-за его
независимости от платформы, на которой выполняется программа и
простоты.
3.2 Проектирование логики диалога с пользователем
Логика
диалога
программы
с
пользователем
позволяет
продемонстрировать, как будет выглядеть взаимодействие пользователя с
приложением.
Проектирование
логики
диалога
пользователя
с
программой
осуществляют для выяснения, какие требуются окна и управляющие
элементы, а значит, его следует проводить до реализации приложения. Если
же решать эту проблему в процессе программирования, возможно упустить
взаимосвязи основных управляющих элементов. Есть две нотации:
 графическая – используются конечные автоматы;
 текстовая
–
используется
редко
из-за
того,
что
плохо
структурирована и формализована.
В процессе проектирования диалога определяются состояния системы
– устойчивые состояния, находясь в которых пользователь способен
выполнить некие действия, которые могут повлечь изменение состояния
системы. Пользователь взаимодействует с окнами, создавая события,
преобразующиеся во входные сигналы в логике диалогов.
Входной сигнал – событие, влекущее изменение состояния системы. В
процессе их обработки в логике диалогов меняется контекст диалога –
комплект управляющих элементов и окон, доступных пользователю после
его действий. Для задействования прикладного интерфейса ему отправляется
61
команда. В ответ на это происходит обратная связь, воздействующая на
контекст, как и в случае с входными сигналами.
Подобное взаимодействие контекста системы не меняет. Помимо этого
требуется учитывать влияние контекста одних окон на контекст других окон.
Подобный диалог относят к конкурентным диалогам. У этих приложений
модуль диалогов включает в себя диалоги всех окон, а также диалог
взаимодействия между ними.
Пользователю
визуальными
приложение
объектами.
представляется
Взаимодействие
в
виде
пользователя
с
формы
с
объектами
происходит путём порождения событий. Формы превращают события во
входные сигналы, из чего следует, что не любое событие способно быть
входным сигналом.
Один из самых простых способов отражения логики диалога с
пользователем – простая транзитивная сеть или сеть состояний и переходов.
При использовании подобного подхода состояния изображаются в форме
окружностей и их соединяют дуги (рисунок 3.1). Среди состояний следует
выделить начальное (стартовое) – в этом состоянии система находится в
начале работы. Его обозначают входной дугой, не имеющей источника.
Может быть лишь одно начальное состояние в системе. Помимо этого, в
транзитивной сети есть финальные состояния, при попадании в которые
система заканчивает работу. Может быть несколько финальных состояний.
Их выделяют двойной обводкой.
Учитывая, что разрабатываемый сервис будет являться только
прототипом и основой для дальнейшего наращивания функций, показанные в
данном разделе функции, могут быть временными из-за того, что позже в
логика диалога могут вноситься изменения.
62
Рисунок 3.1 – Транзитивная сеть
Состояния данной транзитивной сети:
1. Выбор авторизации или регистрации.
2. Регистрация.
63
3. Абонент.
4. Администратор.
5. История выплат.
6. Сведения о лицевом счёте.
7. Сведения о доме.
8. Сохранение.
9. Удаление.
10. Подтверждение.
11. Ошибка.
12. F – финальное.
Ниже представлено краткое описание переходов данной транзитивной
сети.
Переход из первого состояния – из 1 в 2 – нажатие ссылки на
регистрацию.
Переходы из второго состояния:
 из 2 в 1 – нажатие кнопки отмена;
 из 2 в 3 – нажатие кнопки авторизоваться как абонент;
 из 2 в 4 – нажатие кнопки авторизоваться как администратор;
 из 2 в 11 – ошибка.
Переходы из третьего состояния:
 из 3 в 1 – нажатие кнопки выйти из профиля;
 из 3 в 5 – нажатие ссылки на историю выплат;
 из 3 в 7 – нажатие ссылки на сведения о доме;
 из 3 в 11 – ошибка.
Переходы из четвёртого состояния:
 из 4 в 1 – нажатие кнопки выйти из профиля;
 из 4 в 6 – нажатие ссылки на сведения о лицевом счёте;
 из 4 в 11 – ошибка.
64
Переходы из пятого состояния:
 из 5 в 1 – нажатие кнопки выйти из профиля;
 из 5 в 3 – нажатие ссылки на страницу плательщиков;
 из 5 в 11 – ошибка.
Переходы из шестого состояния:
 из 6 в 1 – нажатие кнопки выйти из профиля;
 из 6 в 4 – нажатие кнопки вернуться к странице администратора;
 из 6 в 8 – нажатие кнопки сохранить сведения о лицевом счёте;
 из 6 в 9 – нажатие кнопки удалить сведения о лицевом счёте;
 из 6 в 11 – ошибка.
Переходы из седьмого состояния:
 из 7 в 1 – нажатие кнопки выйти из профиля;
 из 7 в 4 – нажатие кнопки вернуться к странице администратора;
 из 7 в 11 – ошибка.
Переходы из восьмого состояния:
 из 8 в 1 – нажатие кнопки выйти из профиля;
 из 8 в 10 – нажатие кнопки подтвердить сохранение.
Переходы из девятого состояния:
 из 9 в 1 – нажатие кнопки выйти из профиля;
 из 9 в 10 – нажатие кнопки подтвердить удаление.
Переходы из десятого состояния:
 из 10 в 4 – нажатие кнопки вернуться к странице администратора;
 из 10 в 11 – ошибка.
Переходы из одиннадцатого состояния:
 из 11 в 1 – нажатие кнопки выйти из профиля;
 из 11 в 3 – нажатие кнопки вернуться к странице администратора;
 из 11 в 4 – нажатие кнопки вернуться к профилю абонента.
Переход в финальное состояние – из 1 в F – нажатие «Выход».
65
3.3 Описание прототипа облачного сервиса
Одна из ключевых задач при разработке приложений, работающих в
облаке – это интерфейс с самой службой. Основная масса подобных служб
предполагают интерфейс на основе REST или SOAP. (S3 обеспечивает тот и
другой.) Одно из важнейших преимуществ REST- или SOAP-интерфейса —
отсутствие зависимости от определённого языка. Это значит, что службу
возможно вызвать на любом требуемом для вас языке программирования.
Недостатком является то, что при применении REST или SOAP нужно
заботиться не о данных, с которыми работаешь, а о деталях запроса.
Очевидно,
что
более
высокоуровневый
подход,
который
позволит
сконцентрироваться на данных, вместо подписей и других деталей,
значительно улучшил бы эффективность. Именно здесь приходит на помощь
класс Zend_Service_Amazon_S3. Данный класс позволяет сконцетрироваться
на данных, а не на механике заголовков HTTP, конвертов SOAP и иных
несущественных деталях.
Одна из первых служб, которую возможно отнести к категории
облачных вычислений, Amazon S3, является распределенной файловой
системой, дающей неограниченные возможности по хранению данных в
Интернете. Модель данных S3 делится на две части: блок (bucket) и объект
(object). Блок позволяет включать бесконечное множество объектов, каждый
из которых содержит данные и метаданные. Блок не может содержать другой
блок. При создании имя блока должно быть уникальным по отношению ко
всем пользователям S3. Объект, когда он создан, можно только заменить или
удалить; изменить объект невозможно. При создании объекта возможно
установить параметры управления доступом к нему. По умолчанию объекты
являются частными, но их можно открывать для общего доступа.
Экранные формы прототипа сервиса указаны на рисунках 3.2, 3.3 и 3.4.
На первых двух рисунках отображены формы, доступные администратору
системы. Возможности последней формы предоставлены абоненту системы.
66
На первой форме возможно отредактировать или удалить из системы
данные о лицевом счёте абонента.
Рисунок 3.2 – Сведения о лицевом счёте
На второй форме отображаются сведения о здании, доступные
администратору.
Рисунок 3.3 – Сведения о доме
На третьей форме абонент может просмотреть сведения о выплатах за
прошедшие периоды.
67
Рисунок 3.4 – История выплат за услуги ЖКХ
68
ЗАКЛЮЧЕНИЕ
В данной работе был спроектирован
и реализован прототип
информационной системы для хранения и обработки информации в области
ЖКХ на основе облачных сервисов.
В процессе работы был произведён обзор предметной области и
проанализированы аналоги данного программного продукта. На основе
диаграммы прецедентов были определены требования к сервису. Были
спроектированы структуры облачного сервиса и базы данных. После выбора
инструментов разработки и описания логики диалога был реализован
прототип сервиса.
Так как поставленные задачи были выполнены, цель данной работы
является достигнутой. В дальнейшем предполагается дальнейшая работа над
данным облачным сервисом.
69
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1О
государственной
информационной
системе
жилищно-
коммунального хозяйства: федеральный закон от 21 июля 2014 г. N 209-ФЗ
[Текст]// Российская газета – 2014. - № 6435. – с 14.
2 Об утверждении стандарта раскрытия информации организациями,
осуществляющими деятельность в сфере управления многоквартирными
домами : постановление Правительства РФ от 23.09.2010 N 731 [Текст]//
Российская газета – 2010. - № 5301. – с 16.
3О
порядке
осуществления
деятельности
по
управлению
многоквартирными домами: постановление Правительства Российской
Федерации от 15 мая
2013 г. N416 [Текст]// Собрание законодательства
Российской Федерации – 2013. – N21. – Cт. 2652.
4 Об утверждении форм раскрытия информации
организациями,
осуществляющими деятельность в сфере управления многоквартирными
домами. Приказ Минстроя России от 22 декабря 2014г. N 882 [Электронный
ресурс]// Официальный интернет-портал правовой информации – 2015. URL:
http://www.pravo.gov.ru (Дата обращения – 26.12.2016).
5 Горбачёв, Д. В. Обзор современных информационных технологий
автоматизации деятельности в сфере ЖКХ / Горбачёв Д. В., Хакимова Э. Г. //
Молодой учёный – 2015. - №13. – С. 33-35
6 Рябина, А.К. Автоматизация ЖКХ – это просто/ А.К. Рябина, Д.А.
Лопатина // Журнал «ИСУП» - 2010 - №3.
7 Подлесный, А.М. Диспетчеризация объектов ЖКХ – одна из доктрин
умного города/ А.М. Подлесный, И.М. Бажуков // Журнал «ИСУП». – 2016 №1.
8 Аблин, И.Е. Сборка SCADA-проекта систем диспетчеризации ЖКХ
из готовых компонентов/ И.Е. Аблин// Журнал «ИСУП». – 2015 – №1.
9 Попов, А.А. Использование облачных технологий для формирования
инновационной
ИТ-инфраструктуры
и
управления
многоквартирными
70
домами/ А.А. Попов// Вестник ТвГУ. Серия «Экономика и управление» 2013 - № 21 - С 163-176.
10 Телемтаев,
М.А.
Совершенствование
отечественных
информационных систем управления недвижимостью на основе зарубежного
опыта / Телемтаев М.А., Попов А.А.// Журнал «Прикладная информатика» 2012 - № 2 – С. 18-25.
11 Павлов, А.Н. «ГИС ЖКХ» и «Реформа ЖКХ» - новые шаги к
информатизации отрасли жилищно-коммунального хозяйства России / А.Н.
Павлов // Проблемы и перспективы экономики и управления: материалы VI
Междунар. науч. конф. – СПб.: Свое издательство, 2017. – С. 222-225.
12 Паршков, А.Е. Информационные технологии и их применение в
сфере жилищно-коммунального хозяйства / А.Е. Паршков // Техника.
Технология. Инженерия. – 2018. - №1. – С. 14-17.
13 Федосов С.С. Использование облачных технологий в области ЖКХ/
С.С.
Федосов,
И.И.
Стычук//
Естественнонаучные,
инженерные
и
экономические исследования в технике, промышленности, медицине и
сельском
хозяйстве:
материалы
I
Молодёжной
научно-практической
конференции с международным участием – Белгород, 2017. – С. 353-356.
14 Кулябов, Д. С. Введение в формальные методы описания бизнеспроцессов: Учеб. Пособие [Текст]/ Кулябов, Д. С., Королькова А. В. – М.:
РУДН, 2008. – 173 с.
15 Коцюба, И. Ю. Основы проектирования информационных систем.
Учебное пособие [Текст]/ Коцюба И. Ю., Чунаев А. В., Шиков А. Н. – СПб:
Университет ИТМО, 2015. – 206 с.
16 Саак, А. Э. Информационные технологии управления: Учебник для
вузов [Текст]/ Саак А.Э., Пахомов Е.В., Тюшняков В.Н. – СПб: Питер, 2012.
– 320 с.
17 Лысков, О. Э. Особенности структурного анализа и проектирования
информационных систем
[Текст]/ Лысков О.Э., Олькина Е.В. – Орел:
ФГБОУ ВО «ОГУ им И.С. Тургенева», 2016. – 83 с.
71
18 Кузнецов, Д.С. Анализ облачных информационных систем для
управления многоквартирными домами // Электронный журнал «NaukaRastudent.ru» - 2016 - №1. URL:http://nauka-rastudent.ru/27/3250/
19 Автоматизация
ЖКХ
[Электронный
ресурс].
–
URL:
https://biz-opt.livejournal.com/3752.html (Дата обращения – 29.05.2018).
20 Tirbo в создании ГИС ЖКХ [Электронный ресурс]. – URL:
https://habrahabr.ru/company/scancode/blog/245189/
(Дата
обращения
–
29.05.2018).
21 Топ 4 облачных языка программирования, которые стоит выучить
[Электронный ресурс]. – URL:
http://www.dejurka.ru/articless/cloud-
computing-languages-to-learn/ (Дата обращения – 29.05.2018).
22 Год
облачных
СУБД
[Электронный
ресурс].
–
URL:
https://www.osp.ru/os/2013/09/13038286 (Дата обращения – 29.05.2018).
23 DBaaS: базы данных в облаке [Электронный ресурс]. – URL:
https://habr.com/company/technoserv/blog/337860/
(Дата
обращения
–
29.05.2018).
24 Как сделать ЖКХ, чтобы оно было ГИС [Электронный ресурс]. –
URL:
https://habr.com/company/lanit/blog/321476/
(Дата
обращения
–
29.05.2018).
25 Всё об облачных вычислениях с открытым исходным кодом: Часть
1. Не все облака одинаковы. Выбор из множества платформ [Электронный
ресурс].
–
URL:
https://www.ibm.com/developerworks/ru/library/os-cloud-
realities1/index.html (Дата обращения – 22.06.2018).
26 Диспетчеризация объектов ЖКХ [Электронный ресурс]. – URL:
http://cons-systems.ru/dispetcherizatciya-obektov-zhkkh-2/ (Дата обращения –
23.04.2018).
27 Взаимодействие с ГИС ЖКХ с помощью stunnel и openssl по ГОСТу
[Электронный ресурс]. – URL: https://habr.com/post/300856/#crypto-2 (Дата
обращения – 22.06.2018).
72
28 Всё об облачных вычислениях с открытым исходным кодом: Часть
2.
Разработка
приложения
[Электронный
для
работы
на
ресурс].
«облачной»
платформе
–
URL:
https://www.ibm.com/developerworks/ru/library/os-cloud-realities2/index.html
(Дата обращения – 22.06.2018).
29 Основы облачных вычислений. Новый способ предоставления
вычислительных
ресурсов
[Электронный
ресурс].
–
URL:
(Дата
https://www.ibm.com/developerworks/ru/library/cl-cloudintro/index.html
обращения – 22.06.2018).
30 Возможности БИТ.ЖКХ [Электронный ресурс]. – URL: http://bitjkh.ru/functional/ (Дата обращения – 23.06.2018).
31 Программный комплекс Стек-ЖКХ [Электронный ресурс]. – URL:
http://stack-it.ru/resheniya-stack/jkh-stack/ (Дата обращения – 23.06.2018).
32 Комплексная система «ИРЦ ЖКХ Регион» [Электронный ресурс]. –
URL:
(Дата
http://www.pafes.ru/ru/kompleksnaya-sistema-irc-zhkh-region
обращения – 23.06.2018).
33 Облачный сервис Инфокрафт ЖКХ 365 [Электронный ресурс]. –
URL: https://www.gkh365.ru (Дата обращения – 23.06.2018).
34 Регламент
информационного
взаимодействия
внешних
информационных систем с ГИС ЖКХ [Электронный ресурс]. – URL:
информационного
http://gzhi.gov-murman.ru/activities/reestr/Регламент
взаимодействия внешних информационных систем с ГИС ЖКХ.pdf
(Дата
обращения – 25.06.2018).
35 API
Яндекс.Кассы
[Электронный
ресурс].
–
URL:
https://kassa.yandex.ru/docs/checkout-api/ (Дата обращения – 25.06.2018).
36 Информационный ресурс «1С:Предприятие. Учет в управляющих
компаниях
ЖКХ,
ТСЖ
и
ЖСК»
[Электронный
ресурс].
–
URL:
https://www.vdgb.ru/programmy-1s/1s-predpriyatie-8-uchet-v-upravlyayushhihkompaniyah-zhkh-tszh-zhsk/ (Дата обращения – 23.06.2018).
73
37 Информационный ресурс «ДомоСайт» [Электронный ресурс]. –
URL: http://domosite.ru (Дата обращения – 23.06.2018).
38 Информационный ресурс «ГИС ЖКХ» [Электронный ресурс]. –
URL: https://dom.gosuslugi.ru (Дата обращения – 23.06.2018).
39 Храните
данные
в
облаке
[Электронный
https://habr.com/company/bigdatahosting/blog/353168/
ресурс].
(Дата
–
URL:
обращения
–
24.06.2018).
40 Информационный ресурс Amazon EC2 [Электронный ресурс]. –
URL: https://aws.amazon.com/ru/ec2 (Дата обращения – 25.06.2018).
74
ПРИЛОЖЕНИЕ А
Модели базы данных
Рисунок A.1 – Концептуальная модель базы данных
75
Рисунок A.2 – Логическая модель базы данных
76
Рисунок A.3 – Физическая модель базы данных
77
ПРИЛОЖЕНИЕ B
(обязательное)
Листинг программы
SET SQL DIALECT 3;
SET NAMES WIN1251;
CREATE GENERATOR GEN_ADMINISTRATIVN_ZDANIE_ID;
SET GENERATOR GEN_ADMINISTRATIVN_ZDANIE_ID TO 0;
CREATE GENERATOR GEN_DANNIE_USLUGI_ID;
SET GENERATOR GEN_DANNIE_USLUGI_ID TO 0;
CREATE GENERATOR GEN_IMUSHESTV_OBORUDOV_ID;
SET GENERATOR GEN_IMUSHESTV_OBORUDOV_ID TO 0;
CREATE GENERATOR GEN_JURIDICH_LICO_ID;
SET GENERATOR GEN_JURIDICH_LICO_ID TO 0;
CREATE GENERATOR GEN_KVITANTSIA_ID;
SET GENERATOR GEN_KVITANTSIA_ID TO 0;
CREATE GENERATOR GEN_MANAGING_COMPANY_ID;
SET GENERATOR GEN_MANAGING_COMPANY_ID TO 0;
CREATE GENERATOR GEN_PERERASCHET_USL_ID;
SET GENERATOR GEN_PERERASCHET_USL_ID TO 0;
CREATE GENERATOR GEN_RASSROCHK_PLATEZH_ID;
SET GENERATOR GEN_RASSROCHK_PLATEZH_ID TO 0;
CREATE GENERATOR GEN_VID_USLUGI_ID;
SET GENERATOR GEN_VID_USLUGI_ID TO 0;
CREATE GENERATOR GEN_ZHILOE_STROENIE_ID;
SET GENERATOR GEN_ZHILOE_STROENIE_ID TO 0;
CREATE TABLE ADMINISTRATIVN_ZDANIE (
ID
INTEGER NOT NULL,
ADDRESS
CHAR(70),
PLOSHAD
INTEGER,
JURIDICH_LICO_ID INTEGER,
MANAGING_COMPANY_ID INTEGER
);
CREATE TABLE DANNIE_USLUGI (
ID
INTEGER NOT NULL,
OBIOM_ZA_PERIOD INTEGER,
78
OBIOM_MKD
INTEGER,
TARIF
INTEGER,
PRED_POKAZANIA INTEGER,
TEK_POKAZANIA INTEGER,
LGOT_SUBSIDII INTEGER,
ZADOLZHENNOST INTEGER,
ITOG
INTEGER,
VID_USLUGI_ID INTEGER,
NOMER_KVIT
INTEGER
);
CREATE TABLE DOGOVOR (
NOMER
INTEGER NOT NULL,
DATA_ZAKLUCHEN
DATE,
NACH_DEISTVOVAT
DATE,
OKONCH_DEISTVOVAT DATE,
MANAGING_COMPANY_ID INTEGER
);
CREATE TABLE DOGOVOR_ADMINISTRATIVN_ZDANIE (
NOMER
INTEGER NOT NULL,
ADMIN_ZD_ID INTEGER NOT NULL
);
CREATE TABLE DOGOVOR_JURIDICH_LICO (
NOMER
INTEGER NOT NULL,
JURIDICH_LICO_ID INTEGER NOT NULL
);
CREATE TABLE DOGOVOR_VID_USLUGI (
VID_USLUG_ID INTEGER NOT NULL,
NOMER
INTEGER NOT NULL
);
CREATE TABLE DOGOVOR_ZHIL_STR (
NOMER
INTEGER NOT NULL,
ZHIL_STR_ID INTEGER NOT NULL
);
CREATE TABLE IMUSHESTV_OBORUDOV (
ID
INTEGER NOT NULL,
NAIMENOVANIE CHAR(70),
SOSTOIANIE
CHAR(70),
SROK_SLUZHBI INTEGER,
DATA_USTANOV DATE,
ZHIL_STROEN_ID INTEGER,
ADMIN_ZD_ID INTEGER
);
CREATE TABLE JURIDICH_LICO (
ID
INTEGER NOT NULL,
NAME
CHAR(70),
79
JURIDICH_ADDRESS CHAR(70),
GRAFIC_RABOTY CHAR(70),
KONTAKT_DANNIE CHAR(70)
);
CREATE TABLE KVITANTSIA (
NOMER_KVIT
INTEGER NOT NULL,
RASCHETN_PERIOD
INTEGER,
ITOG_K_OPLATE
INTEGER,
POSLED_POSTUP_OPLATA DATE,
JURIDICH_LICO_ID
INTEGER,
LICEV_SHET
INTEGER,
MANAGING_COMPANY_ID INTEGER
);
CREATE TABLE MANAGING_COMPANY (
ID
INTEGER NOT NULL,
NAME
CHAR(70),
BANK_REKVISIT CHAR(70),
JURIDICH_ADDRESS CHAR(70),
FAKTICH_ADDRESS CHAR(70),
GRAFIC_RABOTY CHAR(70),
KONTAKT_DANNIE CHAR(70)
);
CREATE TABLE PERERASCHET_USL (
ID
INTEGER NOT NULL,
VID_USL
CHAR(70),
OSNOVA_PERERASCH CHAR(70),
SUMMA
INTEGER,
NOMER_KVIT
INTEGER
);
CREATE TABLE PLATELSHIK (
LICEV_SHET INTEGER NOT NULL,
FAMILIA
CHAR(70),
NAME
CHAR(70),
OTCHESTVO CHAR(70),
BANK_REKVISIT CHAR(70)
);
CREATE TABLE PLATELSHIK_DOGOVOR (
LICEV_SHET INTEGER NOT NULL,
NOMER
INTEGER NOT NULL
);
CREATE TABLE RASSROCHK_PLATEZH (
ID
INTEGER NOT NULL,
VID_USLUG
CHAR(70),
SUM_S_RASSROCHK_NOW INTEGER,
SUM_S_RASSROCHK_PRED INTEGER,
PROCENT_RASSROCHK INTEGER,
80
OBSHAIA_SUMM
NOMER_KVIT
INTEGER,
INTEGER
);
CREATE TABLE VID_USLUGI (
ID
INTEGER NOT NULL,
NAIMENOVAN
CHAR(70),
ED_IZMEREN
CHAR(70),
MANAGING_COMPANY_ID INTEGER
);
CREATE TABLE ZHILOE_STROENIE (
ID
INTEGER NOT NULL,
ADDRESS
CHAR(70),
VID_SOBSTVENNOSTI CHAR(70),
OBSHAIA_PLOSHAD
INTEGER,
KOLVO_PROPISAN_LUDEI INTEGER,
MANAGING_COMPANY_ID INTEGER,
LICEV_SHET
INTEGER
);
ALTER TABLE ADMINISTRATIVN_ZDANIE ADD CONSTRAINT
PK_ADMINISTRATIVN_ZDANIE PRIMARY KEY (ID);
ALTER TABLE DANNIE_USLUGI ADD CONSTRAINT PK_DANNIE_USLUGI PRIMARY
KEY (ID);
ALTER TABLE DOGOVOR ADD CONSTRAINT PK_DOGOVOR PRIMARY KEY
(NOMER);
ALTER TABLE DOGOVOR_ADMINISTRATIVN_ZDANIE ADD CONSTRAINT
PK_DOGOVOR_ADMINISTRATIVN_ZDANI PRIMARY KEY (NOMER, ADMIN_ZD_ID);
ALTER TABLE DOGOVOR_JURIDICH_LICO ADD CONSTRAINT
PK_DOGOVOR_JURIDICH_LICO PRIMARY KEY (NOMER, JURIDICH_LICO_ID);
ALTER TABLE DOGOVOR_VID_USLUGI ADD CONSTRAINT
PK_DOGOVOR_VID_USLUGI PRIMARY KEY (VID_USLUG_ID, NOMER);
ALTER TABLE DOGOVOR_ZHIL_STR ADD CONSTRAINT PK_DOGOVOR_ZHIL_STR
PRIMARY KEY (NOMER, ZHIL_STR_ID);
ALTER TABLE IMUSHESTV_OBORUDOV ADD CONSTRAINT
PK_IMUSHESTV_OBORUDOV PRIMARY KEY (ID);
ALTER TABLE JURIDICH_LICO ADD CONSTRAINT PK_JURIDICH_LICO PRIMARY
KEY (ID);
ALTER TABLE KVITANTSIA ADD CONSTRAINT PK_KVITANTSIA PRIMARY KEY
(NOMER_KVIT);
81
ALTER TABLE MANAGING_COMPANY ADD CONSTRAINT
PK_MANAGING_COMPANY PRIMARY KEY (ID);
ALTER TABLE PERERASCHET_USL ADD CONSTRAINT PK_PERERASCHET_USL
PRIMARY KEY (ID);
ALTER TABLE PLATELSHIK ADD CONSTRAINT PK_PLATELSHIK PRIMARY KEY
(LICEV_SHET);
ALTER TABLE PLATELSHIK_DOGOVOR ADD CONSTRAINT
PK_PLATELSHIK_DOGOVOR PRIMARY KEY (LICEV_SHET, NOMER);
ALTER TABLE RASSROCHK_PLATEZH ADD CONSTRAINT
PK_RASSROCHK_PLATEZH PRIMARY KEY (ID);
ALTER TABLE VID_USLUGI ADD CONSTRAINT PK_VID_USLUGI PRIMARY KEY
(ID);
ALTER TABLE ZHILOE_STROENIE ADD CONSTRAINT PK_ZHILOE_STROENIE
PRIMARY KEY (ID);
ALTER TABLE ADMINISTRATIVN_ZDANIE ADD CONSTRAINT
FK_ADMINISTRATIVN_ZDANIE_1 FOREIGN KEY (JURIDICH_LICO_ID) REFERENCES
JURIDICH_LICO (ID);
ALTER TABLE ADMINISTRATIVN_ZDANIE ADD CONSTRAINT
FK_ADMINISTRATIVN_ZDANIE_2 FOREIGN KEY (MANAGING_COMPANY_ID)
REFERENCES MANAGING_COMPANY (ID);
ALTER TABLE DANNIE_USLUGI ADD CONSTRAINT FK_DANNIE_USLUGI_1
FOREIGN KEY (VID_USLUGI_ID) REFERENCES VID_USLUGI (ID);
ALTER TABLE DANNIE_USLUGI ADD CONSTRAINT FK_DANNIE_USLUGI_2
FOREIGN KEY (NOMER_KVIT) REFERENCES KVITANTSIA (NOMER_KVIT);
ALTER TABLE DOGOVOR ADD CONSTRAINT FK_DOGOVOR_1 FOREIGN KEY
(MANAGING_COMPANY_ID) REFERENCES MANAGING_COMPANY (ID);
ALTER TABLE DOGOVOR_ADMINISTRATIVN_ZDANIE ADD CONSTRAINT
FK_DOGOVOR_ADMINISTRATIVN_ZDANI FOREIGN KEY (ADMIN_ZD_ID)
REFERENCES ADMINISTRATIVN_ZDANIE (ID);
ALTER TABLE DOGOVOR_ADMINISTRATIVN_ZDANIE ADD CONSTRAINT
FK_DOGOVOR_ADMINISTRAT_ZDANI FOREIGN KEY (NOMER) REFERENCES
DOGOVOR (NOMER);
ALTER TABLE DOGOVOR_JURIDICH_LICO ADD CONSTRAINT
FK_DOGOVOR_JURIDICH_LICO_1 FOREIGN KEY (NOMER) REFERENCES DOGOVOR
(NOMER);
82
ALTER TABLE DOGOVOR_JURIDICH_LICO ADD CONSTRAINT
FK_DOGOVOR_JURIDICH_LICO_2 FOREIGN KEY (JURIDICH_LICO_ID) REFERENCES
JURIDICH_LICO (ID);
ALTER TABLE DOGOVOR_VID_USLUGI ADD CONSTRAINT
FK_DOGOVOR_VID_USLUGI_1 FOREIGN KEY (VID_USLUG_ID) REFERENCES
VID_USLUGI (ID);
ALTER TABLE DOGOVOR_VID_USLUGI ADD CONSTRAINT
FK_DOGOVOR_VID_USLUGI_2 FOREIGN KEY (NOMER) REFERENCES DOGOVOR
(NOMER);
ALTER TABLE DOGOVOR_ZHIL_STR ADD CONSTRAINT
FK_DOGOVOR_ZHIL_STR_1 FOREIGN KEY (NOMER) REFERENCES DOGOVOR
(NOMER);
ALTER TABLE DOGOVOR_ZHIL_STR ADD CONSTRAINT
FK_DOGOVOR_ZHIL_STR_2 FOREIGN KEY (ZHIL_STR_ID) REFERENCES
ZHILOE_STROENIE (ID);
ALTER TABLE IMUSHESTV_OBORUDOV ADD CONSTRAINT
FK_IMUSHESTV_OBORUDOV_1 FOREIGN KEY (ZHIL_STROEN_ID) REFERENCES
ZHILOE_STROENIE (ID);
ALTER TABLE IMUSHESTV_OBORUDOV ADD CONSTRAINT
FK_IMUSHESTV_OBORUDOV_2 FOREIGN KEY (ADMIN_ZD_ID) REFERENCES
ADMINISTRATIVN_ZDANIE (ID);
ALTER TABLE KVITANTSIA ADD CONSTRAINT FK_KVITANTSIA_1 FOREIGN KEY
(LICEV_SHET) REFERENCES PLATELSHIK (LICEV_SHET);
ALTER TABLE KVITANTSIA ADD CONSTRAINT FK_KVITANTSIA_2 FOREIGN KEY
(JURIDICH_LICO_ID) REFERENCES JURIDICH_LICO (ID);
ALTER TABLE KVITANTSIA ADD CONSTRAINT FK_KVITANTSIA_3 FOREIGN KEY
(MANAGING_COMPANY_ID) REFERENCES MANAGING_COMPANY (ID);
ALTER TABLE PERERASCHET_USL ADD CONSTRAINT FK_PERERASCHET_USL_1
FOREIGN KEY (NOMER_KVIT) REFERENCES KVITANTSIA (NOMER_KVIT);
ALTER TABLE PLATELSHIK_DOGOVOR ADD CONSTRAINT
FK_PLATELSHIK_DOGOVOR_1 FOREIGN KEY (LICEV_SHET) REFERENCES
PLATELSHIK (LICEV_SHET);
ALTER TABLE PLATELSHIK_DOGOVOR ADD CONSTRAINT
FK_PLATELSHIK_DOGOVOR_2 FOREIGN KEY (NOMER) REFERENCES DOGOVOR
(NOMER);
ALTER TABLE RASSROCHK_PLATEZH ADD CONSTRAINT
FK_RASSROCHK_PLATEZH_1 FOREIGN KEY (NOMER_KVIT) REFERENCES
KVITANTSIA (NOMER_KVIT);
83
ALTER TABLE VID_USLUGI ADD CONSTRAINT FK_VID_USLUGI_1 FOREIGN KEY
(MANAGING_COMPANY_ID) REFERENCES MANAGING_COMPANY (ID);
ALTER TABLE ZHILOE_STROENIE ADD CONSTRAINT FK_ZHILOE_STROENIE_1
FOREIGN KEY (LICEV_SHET) REFERENCES PLATELSHIK (LICEV_SHET);
ALTER TABLE ZHILOE_STROENIE ADD CONSTRAINT FK_ZHILOE_STROENIE_2
FOREIGN KEY (MANAGING_COMPANY_ID) REFERENCES MANAGING_COMPANY
(ID);
v-.v
.Y
H
8l0z ff)do
H g 8o)rJog
lodnoQ$I s3€
:Hetrxd3sr.{ rHan
xrllodor?t
&otr
erodl,sorowdoH
qr6rHEosot{d
:E?so5e o.
'c't
rs5^rto[
rI'3v,&i)
so.oreo
:rremgeded r!5r'{rr\oY
.rogBd -rofl Ho'n$Ino'L€s!
4ow.,{mqa v ErBters .EsHodlBdrtso d
:'ts'w('oE
erE€soHat{mH
Hner.r. erqsEode^do+sll 5sflsru"dordo) (sr4od!)[email protected]
;relidooHu nHftn dn c0 t0 60 a}lE [email protected] ?H
N3IJ!! )dsssouhsrldooHn "dE 03x
I,t
'FI4
4uoroRer xrqssotn€t{doost t }llrnBEnE^orsB 'srB6o(htodogld! 3Jll'v'(tJ
ehsseddaC tardeJ
tr//9l991 dotm
"[email protected]
altus ],{oEsods.[6 s
es
lls}IEelter.Ee't]r'ir?tdd?^ 4lsHsolln?'htso^3n
aJowd 4oHIIO'[WI4OI4TVOI 4omn-{lIlqs
!/r9I99l 6Nl3ltrI![4t[Io{td6soJcor,{
r
<<v€Ifl-{slit J c uH!tr tri
JAII4JdASItr{ 4Srtr{s€Jdvv^coJ lmlJsotf do>
KX{VSO€vdSo oJg[IJIqS AUHfi XAdh-{
aoH{| vso€;;soaoHro{tdo{sqo}{lasrld/i,tJoJgoH'Ilrvdffiqa
L.nfrIr. ad7a6 r-4OlJtlr4JCOd
rl
vH u rI''jHVSO' dSO OSlJdsl3'rHUl^I
t8
85
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
Наименование
группы атрибутов
атрибута
1. Описание
Обозначение документа
документа
(идентификатор(ы)
файла(ов))
Наименование документа
2. Даты и время
3. Создатели
4. Внешние
ссылки
5. Защита
6. Характеристики
содержания
Характеристики документа
на электронном носителе
\Плакаты\Презентация.pptx
Демонстрационные плакаты
к выпускной
квалификационной работе
Класс документа
ЕСКД
Вид документа
Оригинал документа на
электронном носителе
Аннотация
Демонстрационный
материал, отображающий
основные этапы выполнения
выпускной
квалификационной работы
Использование документа Операционная система
Windows 7, Microsoft
PowerPoint 2010
Дата и время
25.06.2018
копирования документа
Дата создания документа 24.06.2018
Дата утверждения
25.06.2018
документа
Автор
Федосов С.С.
Изготовитель
Федосов С.С.
Ссылки на другие
Удостоверяющий лист
документы
№ 165167/п
Санкционирование
ОГУ имени И.С. Тургенева
Классификация защиты
По законодательству РФ
Объем информации
549543 Б
документа
86
7. Структура
документа(ов)
Наименование плаката
(слайда) №1
Наименование плаката
(слайда) №2
Наименование плаката
(слайда) №3
Наименование плаката
(слайда) №4
Наименование плаката
(слайда) №5
Наименование плаката
(слайда) №6
Наименование плаката
(слайда) №7
Титульный лист
Цели и задачи работы
Диаграмма прецедентов
Модульная структура
Структура БД
Транзитивная сеть
Экранные формы
"*t'G^*
-/2te
r4da4f !Asdkdata
.
lr'jr 9/'tf,
qlouqno
€/(€
rerreuurrHv
awarrq.. eH€ruouF€ Eldasodu
erHav,rlvoi oroaor.'.r rrrda6odu ter€.tquA€ad
vxSvduf
IV14JVI/UHIHV
i
1/--страниц
Пожаловаться на содержимое документа