Web-сервисы (Web-службы) – это программные системы, которые однозначно идентифицируются своим Web-адресом со стандартизированными интерфейсами. Web-сервис обладает только программным интерфейсом, т.е. он предоставляет операции, которые могут быть вызваны удаленно (например внутри корпоративной сети или по сети Интернет). Задача Web-служб – предоставление услуг другим приложениям, как правило это Web-приложения. В настоящее время Web-сервисы становятся новыми фундаментальными элементами для построения сложных программных систем, реализующих сервис-ориентированную архитектуру (SOA) [1,2].

При широком использовании SOA необходимо для построения информационных систем необходимо, чтобы информация о предлагаемых разработчиком Web-сервисах была доступна, а поиск необходимого сервиса или хореографии сервисов не требовал бы больших затрат. Доступность информации достигается путём создания специализированных репозиториев, содержащих описания Web-служб [2]. Примером такого репозитория является UDDI (Universal Description Discovery & Integration) [3]. В качестве стандарта описаний Web-сервисов UDDI использует рекомендованный консорциумом W3C язык WSDL (Web Services Description Language) [4], а поиск осуществляется по ключевым словам, ассоциированных с этим описанием. Очевидно, что такой подход имеет ряд существенных недостатков, поскольку репозиторий не содержит информацию о семантике каждого сервиса. Так, два совершенно разных Web-сервиса могут иметь идентичные описания на WSDL. Решением данной проблемы является хранение в репозиториях семантических описаний Web-служб и использование их в процессе поиска. Web-сервисы с описанной семантикой называются семантическими Web-сервисами.

Семантический Web-сервис отличается от обычного web-сервиса тем, что обладает дополнительным уровнем семантического описания, заключающегося в том, что с операциями WSDL и с их входами и выходами связывается глобальный информационный ресурс в виде онтологии предметной области. Описание семантических Web-сервисов может быть реализовано в синтаксисе OWL-S [5], SAWSDL [6], SWRL [7]. В этих языках операциям WSDL соответствуют атомарные процессы с предусловиями и эффектами, а типам входов-выходов – классы онтологии предметной области. Например, OWL-S состоит из базовой онтологии, онтологии процесса, сервиса, модели сервиса. Этот язык обладает наиболее широкими возможностями и выразительностью из всех вышеперечисленных, а также был утвержден консорциумом W3C. [5]

Семантические Web-сервисы тесно связаны с такими понятием как семантический Web, поэтому их применение можно найти в таких трендах как открытые связанные данные, семантический социальный Web и семантические электронные библиотеки. [8]

Семантическое описание Web-сервиса

Для описания семантики Web-сервисов консорциум W3C предлагает использовать язык OWL-S совместно с RDF, RDFS, OWL. В OWL-S вводится понятие процесса. Это понятие упрощает представление потоков данных для разработчиков. Вводятся атомарные процессы, которые соответствуют операциям WSDL, а также составные процессы, которым соответствуют композиции Web-сервисов. [9]

Атомарный процесс – это процесс, который может быть непосредственно выполнен за одно взаимодействие с сервером, на котором работает реализующий данный процесс Web-сервис, т.е. взаимодействие клиента с сервисом, описанным при помощи атомарно процесса, происходит путем отправки Web-службе одного сообщения и получения от нее ответа. Таким образом, атомарный процесс OWL-S соответствует операции в WSDL описании сервиса.

Составной процесс – это процесс, требующий многошагового взаимодействия с сервером (серверами), на котором работают реализующие данный процесс атомарные сервисы. Таким образом, взаимодействие клиента с сервисом, описанным составным процессом, осуществляется при помощи отправки серии сообщений атомарным Web-службам в последовательности, точно определенной в описании составного процесса. [2]

Для составного процесса, состоящего только из атомарных: I – объединение множеств I всех атомарных процессов, входящих в составной. O – объединение множеств О всех атомарных процессов, входящих в составной, плюс выходы самого составного процесса, которые могут вычисляться на базе выходов атомарных процессов. Р – объединение множеств Р всех атомарных процессов, входящих в составной. Е – объединение множеств Е всех атомарных процессов, входящих в составной.

Таким образом, семантическое описание позволяет существенно уточнить поиск Web-сервисов, сводя его к поиску процессов. При этом процесс, в соответствии с рекомендациями W3C, представляется четверкой множеств <I, O, P, E>. [2,10]

В описании семантики четверкой множеств <I, O, P, E> никак не представлен алгоритм получения выходов на основании входов. Такую связь можно однозначно восстановить из описания онтологии предметной области лишь в некоторых случаях. Отображение входов процесса на его выходы должно быть задано явно в OWL-S описании множеством логических формул R. В результате каждый OWL-S процесс будет представлен пятеркой множеств <I, O, P, E, R>. [10]

В самом общем виде задача поиска процесса сводится к сопоставлению описания желаемого процесса и описания процесса, представленного реально существующим сервисом. Если такой процесс не найдется, то можно искать желаемый процесс в виде композиции реальных.

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

Параллельная композиция – тип композиции, в котором процессы выполняются параллельно, при этом их вызов осуществляется одновременно, а результатом этой композиции служит процесс, входами которого является объединение входов всех процессов, подвергшихся композиции, а выходами – объединение всех выходов. [2,9,10]

Последовательная композиция

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

Рис.1. Последовательная композиция вер-сервисов

Входом композиции этих процессов считается вход первого процесса и выходом – выход последнего процесса.

Множественно-теоретическая модель соответствующих простых сервисов приведена ниже:

С1:<I1; O1; P1; R1; E1>,

С2:<I2; O2; P2; R2; E2>, I2 ⊆ O1;

Сse:<I1; O2; P1 & P2; Rse; E1 & E2>.

Предположим, что карты R1 и R2 – сервисы, реализуемые при помощи схемы:

R1(x1/type1,y1/type2;z1/type3,v1/type4,u1/type7);

R2(x2/type3,y2/type5;z2/type6);

Мы также знаем, что type4 есть type5, то есть ∀x/type4∃y/type5(x=y).

Тогда отображение, осуществляемое сервисом определяется как последовательного композиция Rse:

Rse(x1/type1,y1/type2;z2/type6)==∃z1/type3∃x2/type3∃v1/type4∃y2/type5∃u1/type7 R1(x1/type1,y1/type2;z1/type3,v1/type4,u1/type7) & (z1=x2) & (v1=y2) & R2(x2/type3, y2/type5; z2/type6)

Часть выхода система С1 (U1 / type7) также могут быть включены в выходной композиции, но это не будет чистой «Последовательностью». На практике необходимо решить задачу, когда невозможно найти службу, которая запускает следующую модель

Сabs:<Iabs; Oabs; Pabs; Rabs; Eabs>.

В этом случае делается попытка запустить такую модель в качестве последовательного соединения двух служб:

С1:<I1; O1; P1; R1; E1>,

С2:<I2; O2; P2; R2; E2>.

Кандидаты на последовательное соединение находятся из условия: I1 = Iabs & I2 ⊆ O1 & Oabs ⊆ O2;

Если такой сервис найден, то необходимо доказать:

Pabs → P1 & P2;

Rabs == joinOI(R1,R2);

Eabs → E1 & E2; E1 & E2 → Eabs.

Disordered Composition (Any-Order)

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

Идея заключается в том, что если нет никакой разницы, какой из процессов начинает в первую очередь, то все входы и выходы обоих процессов обязательно должны быть проверены. То есть, количество входов и выходов обоих процессов должны быть одинаковыми и состояние совпадающие пары выход к входу должны быть выполнены. Проще, для выходов (рис 2).

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

Множественно-теоретическая модель соответствующих простых сервисов приведена ниже:

С1:<I1; O1; P1; R1; E1>,

С2:<I2; O2; P2; R2; E2>, I1 = I2 и O1 = O2

Сao:<I1; O1; P1 & P2; join(R1,R2); E1 & E2>.

Пусть карты R1 и R2 – сервисы, реализованные с помощью схемы: R1(x1/type1,y1/type2;z1/type1,v1/type2);

R2(x2/type1,y2/type2;z2/type1,v2/type2).

Тогда служба, определенная над “неупорядоченной” служба состава С1 и С2 будут представлены отображения

Rao(x/type1,y/type2;z/type1,v/type2)==∃x1/type1∃y1/type2∃z1/type1∃v1/type2∃x2/type1∃y2/type2∃z2/type1∃v2/type2

R1(x1/type1,y1/type2;z1/type1,v1/type2) & z1=x2 & v1=y2 & x=x1 & y=y1 & z=z2 & v=v2

R2(x2/type1,y2/type2;z2/type1,v2/type2)

OR

R2(x2/type1,y2/type2;z2/type1,v2/type2) & Z2=x1 & v2=y1 & x=x2 & y=y2 & z=z2 & v=v2

R1(x1/type1,y1/type2;z1/type1,v1/type2)

В этом случае, задача разложения формулируется для последовательного подключения процессов.

Условная композиция

Условная композиция тип композиции, в которых выполнение одной из служб может быть достигнуто, только если выполняется условие (см рис.3):

Рис.3. Условная композиция веб-сервисов

Множественно-теоретическая модель соответствующих простых сервисов приведена ниже:

С1:<I1; O1; P1; R1; E1>,

С2:<I2; O2; P2; R2; E2>.

Создание простой службы на основе этой конструкции является целесообразным, если выполняется следующее условие:

I1 = I2 and O1 = O2.

Сif:<I1; O1; P&P1 OR ¬P&P2; Rif; P&E1 OR ¬P&E2>.

Предположим, что карты R1 и R2 – сервисы, реализуемые при помощи схемы:

R1(x1/type1,y1/type2;z1/type3,v1/type4);

R2(x2/type1,y2/type2;z2/type3,v2/type4).

Тогда служба определяется условной композиции будет выполнять Rif:

Rif(x/type1,y/type2;z/type3,v/type4)== ∃x1/type1∃y1/type2∃z1/type3∃v1/type4∃xin/type1∃yin/type2 P(xin/type1,yin/type2) & R1(x1/type1,y1/type2;z1/type3,v1/type4) &x=x1 & y=y1 & z=z1 & v=v1 & x=xin & y=yin

OR

∃x2/type1∃y2/type2∃z2/type3∃v2/type4∃xin/type1∃yin/type2 ¬P(xin/type1,yin/type2) & R2(x2/type1,y2/type2;z2/type3,v2/type4) & x=x2 & y=y2 & z=z2 & v=v2 & x=xin & y=yin

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

Пример поиска погодных условий в месте прилёта самолёта

Для описания процессов будем использовать стандартное представления логико-математического языка первого порядка, описанного в [10].

Пусть задан первый процесс, по номеру рейса возвращающий место назначения и время прибытия самолета:

S1(x/numFlight,y/destFlight, z/arrTimeFlight) == ∃i/Flight Flight_fnumber(i,x) & Flight_dest(i,y) & Flight_time(i,y)

Второй процесс ширину и долготу по названию города:

S2(x/location, y/latCoordinates, z/longCoordinates) = Location_coordinates(x,y,z)

Третий и четвертый процессы по долготе, ширине и времени выдает сведения о погоде, при этом третий процесс  работает с Северной и Южной Америкой (широта с -160 до -34), а четвертый со всем остальным миром

S3(x/latWeather,y/longWeather,z/Time,a/WeatherInfo)==∃i/Precipitation ∃j/Temperature Weather_coordinates(a,x,y) & Weather_time(a,z) & Weather_cond(a,i) & Weather_temp(a,j) & (y >= -160) & (y <= -34)

S4(x/latWeather,y/longWeather,z/Time,a/WeatherInfo) == ∃i/Precipitation ∃j/Temperature Weather_coordinates(a,x,y) & Weather_time(a,z) & Weather_cond(a,i) & Weather_temp(a,j) & (y <= -160) & (y >= -34)

Необходимо построить процесс, который по номеру рейса возвращает информацию о погодных условиях в месте прилёта. (рис.1)

S4(x/FlightNum, y/WeatherInfo) = ∃a/Flight ∃b/Time ∃c/Location ∃d/Temperature ∃e/Longtitude ∃f/Latitude  ∃g/Precipitation Flight_fnumber(a,x) & Flight_time(a,b) & Flight_dest(a,c) & Location_coordinates(c,e,f) & Weather_coordinates(y,e,f) & Weather_time(y,b) & Weather_cond(a,g) & Weather_temp(a,d)

Рис.4. Связь процессов

С точки зрения логики, ясно, что последовательный вызов S1 и S2, а выбор между S3 и S4 решает поставленную задачу. Если предполагать автоматический подбор сервисов для решения задачи, то формально необходимо доказать

P(y) == (y >= -160) & (y <= -34)

S5(x/FlightNum, y/WeatherInfo) == (S1(x/numFlight, y/destFlight,z/arrTimeFlight) & S2(x/location, y/latCoordinates, z/longCoordinates)) & (P(y) ? S3(x/longWeather, y/longWeather, z/Time, a/WeatherInfo) : S4(x/longWeather, y/longWeather, z/Time,a/WeatherInfo))

Таблица 1. Концептуальная модель проблемной области.

То есть, S5(x/FlightNum, y/WeatherInfo) == ∃a/Flight ∃b/Time ∃c/Location ∃d/Temperature ∃e/Longtitude ∃f/Latitude ∃g/Precipitation Flight_fnumber(a,x) & Flight_time(a,b) & Flight_dest(a,c) & Location_coordinates(c,e,f) & Weather_coordinates(y,e,f) & Weather_time(y,b) & Weather_cond(a,g) & Weather_temp(a,d)

Заключение

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

Были продемонстрированы, что поиск для обоих атомных и композиционных процессами осуществляется по запросу, приведены в виде, должны сопровождаться доказательства утверждений, которые можно схематически выражается как:

Pquery <=> Pprocess, Rquery <=> Rprocess и Equery <=> Eprocess.

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

В рамках концепции развития предоставления полиграфических услуг поставлена цель, спроектировать веб-сервис c применением методов мониторинга и бизнес планирования, практической направленностью которого будет являться сбор всех участников рынка полиграфии России и стран СНГ, позволяющего найти интересующие предложения Поставщикам и Заказчикам полиграфических услуг.

Актуальность работы подтверждена тенденцией к постоянному росту количества пользователей Интернета, а также географии его покрытия. Использование интернет ресурсов в профессиональных целях дает преимущества, как потребителям, так и поставщикам товаров и услуг. Клиенты имеют возможность быстро находить нужную информацию, сравнивать товары и услуги конкурентов, вести диалог. Также, актуальность обуславливается тем, что в современном развитии рынков прослеживаются тенденции глобализации, интернационализации, роста конкуренции, расширение ассортимента предоставляемых услуг, повышение требований к качеству и стоимости готовых продуктов [3].

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

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

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

Концепция веб-сервиса «Биржа полиграфических услуг» имеет следующие преимущества:

• Доступность и оперативность в предоставлении услуг;
• Специализация, либо точное разделение специализаций в полиграфических услугах, оказываемых через Интернет;
• Возможность осуществления безопасных оперативных платежей за оказанные услуги через сеть интернет;
• Сочетание PR и маркетинговых средств в совокупности со средствами, использующимися для оказания услуг, в максимально корректных для посетителей пропорциях на сервисе;
• Использование нетрадиционных механизмов предоставления полиграфических услуг;
• Оперативная реакция на возможные изменения в потребительском спросе на полиграфические услуги (в зависимости от характера специализации фирмы).

Общая схема взаимодействия участников проекта, включая работу администраторов/модераторов сайта, приведена на рисунке 1.

Рис. 1. Общая схема взаимодействия участников проекта

Для работы с функционалом сайта необходима авторизация, которой при первом посещении предшествует регистрация Пользователя. После успешной авторизации на сайте и прохождения всех формальностей Пользователь может приступать к работе с сайтом. Исполнителю и Заказчику присваиваются аккаунты различных типов, одновременное выполнение вышеприведенных ролей одним Пользователем в разных сделках невозможно.

Рассмотрим общий алгоритм поведения Пользователей на сайте.

Для того чтобы вступить в роль Исполнителя, Пользователю необходимо указать специализацию, выбрав ее из списка разделов сайта. Чтобы отыскать на сайте активные проекты, у Исполнителя существует два предусмотренных функционалом решения. Первое предполагает переход по разделам сайта и просмотр добавленных заказов в том порядке, в котором они были добавлены, или же в алфавитном порядке. Второе предполагает использование поиска заказов по ключевому слову. Исполнитель находит проект и принимает решение о целесообразности совершения сделки. В этом случае ему следует с помощью предусмотренного для этого функционала сайта отправить Заказчику, представляющему проект, заявку на сделку, указав допустимые значения необходимых атрибутов для совершения сделки по данному проекту, а именно указать бюджет, срок выполнения проекта. После чего Заказчик подтверждает или отклоняет сделку.

В Личном кабинете Исполнителя имеется доступ к активным проектам, службе личных сообщений, портфолио, архиву совершённых сделок.

Размещенный Заказчиком проект становится доступен для отображения в каталоге заказов и в результатах поисковых запросов по сайту. После подтверждения Заказчиком полученной заявки на сотрудничество от Исполнителя наступает момент непосредственно совершения сделки.

Управление заказами – редактирование и удаление, а также просмотр статистики заказов потенциальными Исполнителями осуществляется через Личный кабинет. Также в Личном кабинете Заказчика имеется доступ к службе личных сообщений, опубликованным проектам и архиву совершённых сделок.

Пользовательский интерфейс (рис. 2) разрабатываемого веб-сайта состоит из следующих разделов:

Главная страница.

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

Главная страница веб-сервиса содержит:

• Панель навигации, предназначена для перехода по разделам сайта;
  
• Кнопки регистрации и авторизации;
  
• Вкладка размещения и поиска заказов;
  
• Форма размещения заказа на веб-сайте;
  
• Список активных заказов, сортируемых по дате добавления;
  
• Вкладка с краткой информацией о веб-сервисе;
  
• Обратная связь;
• Футер, содержащий контакты.

Форма регистрации и авторизации пользователя.

Рис. 2. Схема пользовательского интерфейса

Для Пользователя, который не авторизован в системе, на Главной странице доступны два основных элемента: авторизация, с помощью которой можно осуществить вход на сайт (если ранее им была пройдена процедура регистрации) и регистрация (если Пользователь на сайте впервые или процедура им ещё не была пройдена).

При переходе к регистрации пользователю предлагается выбрать роль – Исполнителя или Заказчика, после чего заполнить форму с данными: для частного лица: логин, имя и фамилия, адрес электронной почты и пароль, для компании: полное наименование, данные её представителя, адрес электронной почты и пароль.

Каталог Заказов.

Раздел веб-сайта, отображающий активные проекты, добавленные Заказчиками. Функционал сервиса, предоставляет возможность сортировать проекты по следующим параметрам:

• Категория;
  
• Дочерняя;
  
• Порядок отображения проектов;
• Территориальное расположение.

Каталог поделен на разделы по отраслевому принципу, которые в свою очередь содержат подразделы (полиграфия, дизайн, сувенирная продукция и пр.).

Из каталога Пользователь может перейти на страницу проекта и ознакомиться с полной информацией.

Личный кабинет пользователя.

На странице личного кабинета Пользователю доступно редактирование некоторых данных профиля (выбор специализации, изменение пароля, сведения о способах связи), просмотр активных проектов, просмотр входящих/исходящих заявок на сделки, доступ к портфолио и архиву ранее совершённых сделок.

Инструмент поиска.

Для его использования в поле поиска нужно ввести ключевое слово, по которому осуществляется поиск запроса в базе актуальных проектов. Результат поискового запроса будет отображён в виде списка (по аналогии со списком предложений/заказов по выбранному разделу) с последующим доступом на страницу каждого проекта.

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

Последние несколько десятилетий глубина промерзания грунта определятся, как правило, приближенно в зависимости от географического положения района по специальной карте, приводимой во многих учебниках и справочниках [2]. Указание СНиПа по проектированию оснований, касающихся необходимости более точного определения этой глубины на основе натурных наблюдений или теплотехнических расчетов, на практике обычно не выполняются, вследствие отсутствия у проектировщиков необходимых исходных данных. Натурные наблюдения за фактической глубиной промерзания грунтов, как правило, не проводятся, а данные о среднемесячных температурах района строительства проектировщику обычно не известны. Строительная же практика постоянно выявляет несоответствия между глубинами промерзания грунта, принимаемыми в проектах и их фактическими величинами.

Инновационная составляющая. Все это в полной мере относится к условиям нашей республики. Практика строительства в Республике Башкортостан показывает, что фактическая глубина промерзания грунта, как правило, существенно отличается от нормативной величины, принимаемой равной 1,8м по упомянутой карте. Фактическое значение обычно оказывается значительно меньше. Это особенно проявляется при выполнении земляных работ, когда требуется рыхление мерзлого слоя грунта или его прогрев. При наличии снежного покрова в самые суровые месяцы зимы мерзлота, требующая рыхления, зачастую составляет лишь 0,3-0,7м. В то же время известно множество фактов, когда на участках с очень малым снежным покровом (0,1-0,15м), где снег сдувался ветром или искусственно удалялся, грунт все-равно не промерзал на 1,8м. По этой причине мною были проведены работы по уточнению данного вопроса.

Базируясь на СП 22.13330.2016 [5] можно выяснить, что базовая формула для вычисления уровня промерзания грунта:

где M – сумма среднемесячных температур в регионе,

k – коэффициент типа грунта.

И. Б. Рыжков и И. В. Чернов в своей статье «О глубине промерзания грунтов в условиях РБ», проведя натурные исследования влияния снежного покрова на промерзание грунта, установили тесную криволинейную корреляцию между значениями снежного покрова и промерзанием грунта. В результате эмпирическая зависимость может быть представлена следующей формулой:

где H – глубина промерзания, м;

h – толщина снежного покрова, м.

Таким образом, уточненная формула глубины промерзания грунта:

Как было упомянуто выше, в последние несколько десятилетий глубина промерзания грунта вычисляется по устаревшим картам и по указаниям СНиП, в котором не учитывается снежный покров. В ходе анализа предметной области было выяснено, что все веб-сервисы, предоставляющие данные по промерзанию грунта, используют базовую формулу для вычисления, а Республика Башкортостан ограничивается пятью городами. Можно сделать вывод, что веб-сервис, вычисляющий более достоверное промерзание грунта для большего числа городов Республики Башкортостан – необходимый проект для специалистов, чья работа связана с этими данными: гидрологи, строители, агрономы.

Функциональная модель. В ходе анализа уже существующих ресурсов по расчету промерзания грунта был выявлены требования к разрабатываемому веб-сервису. Это позволило перейти к следующему этапу проектирования, заключающемуся в создании различных моделей веб-сервиса. Структурный подход позволяет рассмотреть систему на всех уровнях декомпозиции. Функциональная декомпозиция, позволит разбить систему на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те — на задачи и так далее до конкретных процедур. Для построения функциональной модели системы, которая описывает все требуемые процессы с точностью, достаточной для однозначного моделирования деятельности системы, была использована методология SADT. В IDEF0 моделируемая система изображается как совокупность взаимосвязанных работ (функций, активностей). Создание функциональной модели с помощью методологии SADT позволит уменьшить количество ошибок и понять какие основные функции необходимо добавить в систему [3].

На рисунке 1 представлен главный блок функциональной модели предметной области. Целью модели является расчет по представленной выше формуле промерзания грунта. Модель составлена с точки зрения пользователя веб-сервиса. Главный блок диаграммы можно описать следующим образом:

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

Рисунок 1 – Главный блок функциональной модели

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

Информационная модель. Следующий этап проектирования сложной системы является создание информационной модели. Для того чтобы определить какие данные необходимы для решения задач, описанных в функциональной модели, необходимо разработать информационную модель. Информационная модель работы веб-сервиса позволяет показать данные, представленные в виде сущности и их взаимную связь. Она позволяет понять, какая информация необходима для решения ранее выявленных функций. Спроектированная информационная модель позволит скорректировать входные данные, минимизировать ошибки, определиться с архитектурой веб-сервиса и ускорит процесс реализации. Информационная модель веб-сервиса представлена на рисунке 2.

Рисунок 2 – Информационная модель

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

Рисунок 3 – Блок-схема работы веб-сервиса

Заключение. Главной функцией такой системы будет являться расчет промерзания грунта, используя архив данных, накопленный за три года непрерывного метеорологического анализа Республики Башкортостан. В результате работы веб-сервиса конечный пользователь будет получать более детальную информацию о промерзании в рамках его населенного пункта в пределах Башкортостана относительно аналогичных продуктов, представленных на данный момент в сети. Это было достигнуто за счет большего числа городов и дополненной формулы расчета глубины промерзания грунта.