CC BY
25Таким образом, необходимо последовательно проверить заданное множество контейнеров на возможность их помещения на железнодорожный вагон. Последовательно проверяя набор условий, влияющих на возможность постановки контейнера на железнодорожный вагон, алгоритм перебора позволяет определить множество пар вида <ci, rj>, где 1<=i<=n, 1<=j<=m (7),
где C = {c1, ..., cn} и множество железнодорожных вагонов R = {r1, ..., rm}.
Схема алгоритма выглядит следующим образом.
Нач
Составить текущую дислокацию вагонов и контейнеров на них
Для Вагона из Текущей дислокации
Для Контейнера из Списка контейнеров для размещения
Если Current Railway Car Tonnage Fullness (Вагон) = Railway-CarTonnage (Вагон) ИЛИ Current Railway Car Capacity-Fullness (Вагон) = Railway Car Capacity (Вагон)
То выйти из цикла
Иначе Если ContainerMatchesRailwayCar (Контейнер, Вагон) И Сумма (ContainerWeight (Контейнер), Current Railway Car Tonnage Fullness (Вагон)) <= Railway Car Tonnage (Вагон) И Сумма (ContainerSize (Контейнер), Current Railway Car Capacity Fullness (Вагон)) <= Railway Car Capacity (Вагон)
То Добавить <Контейнер, Вагон> в текущую дислокацию
Кон
Применение результатов исследования будет способствовать сокращению времени обработки железнодо-
рожных составов в процессе выгрузки и погрузки контейнеров, позволит более эффективно использовать погрузочную технику, уменьшив пробег техники по контейнерному терминалу. Автоматизация процесса планирования погрузки контейнеров даст возможность уменьшить число излишних перестановок контейнеров в складских секциях терминала, что позволит сократить время погрузки контейнера на железнодорожный вагон, уменьшить себестоимость процедуры погрузки контейнера, уменьшить износ техники, связанный с лишними операциями перемещения контейнеров внутри секций.
Список литературы
1. Объемы железнодорожных контейнерных перевозок по России, электронный журнал «Эксперт» [Электронный ресурс] http://expert.ru/expert/2012 /23/soobrazili-na-dvoih/media/145174/
2. Практический опыт использования ИТ для управления подвижным составом и планирования перевозок [Электронный ресурс] Конференция: ОАО РЖД на рынке транспортных услуг http://www .magnetosoft.ru/index.php?id=42
3. Антонова Е.И., Васильев И.А. Проблема организации грузовых работ на железной дороге контейнерного терминала. Научно технические ведомости СПбГПУ. Информатика. Телекоммуникации. Управление. СПб, 3(174) 2013
4. Системы искусственного интеллекта. Методические указания по выполнению самостоятельной работы и индивидуальных заданий, Артемьева И.Л., Владивосток, 2002.
ЭТАПЫ ПРОЕКТИРОВАНИЯ ОСНОВНЫХ СОСТАВЛЯЮЩИХ РАСПРЕДЕЛЕННОЙ _БАЗЫ ДАННЫХ
Власенко Сергей Валерьевич
Аспирант кафедры информационных технологий Астраханского государственного университета, г. Астрахань STAGES OF DESIGNING THE MAIN COMPONENTS OF A DISTRIBUTED DATABASE
Vlasenko Sergey, Postgraduate student of the Department of information technology of Astrakhan State University, Astrakhan
Ключевые слова: сервис - ориентированная архитектура, распределенная база данных, Web-приложение, Web-сервис.
Keywords: service - oriented architecture, distributed database, Web application, Web service.
Создание распределенных информационных систем является весьма актуальной задачей. Это связано с возрастающими потребностями в приложениях. Увеличиваются требования к оперативности и своевременности информации. Управление информацией происходит с помощью систем управления базами данных (СУБД). Для достижения высокой производительности распределенных приложений, работающих с базами данных, необходимы эффективные методы проектирования распределенных баз данных (РБД).
Для проектирования распределенных информационных систем требуется решить следующие задачи: • состав хранимых данных;
• перечень решаемых задач и необходимая для них условно -постоянная информация;
• сведения о том, какие задачи, каким клиентом с какой частотой используются.
Задача определения состава хранимых данных решается традиционными методами проектирования баз данных. Здесь необходимо определить все необходимые данные библиотеки. Определение перечня решаемых задач - это, по сути, первый этап жизненного цикла разработки программ согласно общепринятым методикам объектно-ориентированного анализа. Для решения третьей задачи необходима достоверная статистика частоты решения отдельных задач разными клиентами. По существу,
решение третьей задачи - это известная в теории распределенных баз данных задача фрагментации и размещения данных. [7, с.59]
Фрагментация данных допускает разбиение отношения на два или более сегмента или фрагмента. Каждый фрагмент может храниться на любом узле сети.
Размещение данных представляет собой процесс принятия решения о месте хранения данных с целью минимизации целевой функции при выполнении запросов.
Выделяют следующие типы стратегии размещения данных:
• централизованное размещение данных - вся база данных хранится на одном узле;
• секционированное размещение данных - каждый фрагмент БД хранится на определенном узле;
• реплицированное размещение данных - одна или более копий фрагментов БД хранятся на нескольких узлах. [3, с.80]
При возникновении изменений в инфраструктуре распределенной среды требуется репроектирование РБД для сохранения производительности приложений. Репроектирование приводит к возникновению новых схем фрагментации и размещения и влечет за собой необходимость материализации обновленного дизайна.
Подобную систему можно позиционировать как набор сервисов для сервис - ориентированной архитектуры. Проектирование сервисов состоит из следующих шагов: идентификация сервисов и определение функции, которыми обладают разработанные сервисы. В процессе разделения подсистем получены 4 подсистемы, и определяем сервисы согласно этой структуре. В системе идентифицировано следующих 4 сервиса:
• Сервис Sicence Category Service, который предназначен для выполнения работы подсистемы Sicence Category.
• Сервис Social Science Category Service, который предназначен для выполнения работы подсистемы Social Science Category.
• Сервис User Admin Service, который предназначен для выполнения работы подсистемы User Admin.
• Сервис Web portal Service, который предназначен для выполнения работы подсистемы. [2, с.34]
В общем случае необходимо собрать требования для сервисов по следующим категориям:
• Функциональность. Какой базовый процесс или процедуру будет обеспечивать сервис? Какие задачи решаются?
• Взаимодействие. Как сервис или приложение, которое вызывает сервис, взаимодействует с этим сервисом?
• Информация. Какие данные посылаются сервису, и что он возвращает?
• Процесс. Каковы взаимоотношения между действиями и событиями в сервисе?
Остальным сервисам требуется выполнять следующие функции:
1. редактирование записей в БД:
• включение новых записей;
• обновление записей удаление записей;
• редактирование заказов
2. возвращение данных из БД:
• поиска записей
Чтобы обеспечить потребности, в этих подсистемах создается Web - приложение для модификации записей в БД и Web - сервис для взаимодействия с другими подсистемами.
Среды функциональных требований к этому сервису можно перечислить следующие:
• представление поиска записей;
• получение результатов поиска из других сервисов, потому что у этого сервиса нет своей собственной БД;
• представление результатов поиска.
Основная идея SOA (сервис - ориентированная архитектуры) состоит в том, что сервисы вызывают друг друга, и поэтому нам необходимо определить взаимодействия между ними. В SOA взаимодействия между сервисами определяются с помощью контрактов. Контракт -это документ на языке WSDL. Это диалект языка XML, один из базовых стандартов SOA. Контракт задает характеристики сервиса и определяет, как потребитель может к нему обращаться. В контракте также определяют операции, которые предлагаются сервисом. [4, с.69]
В SOA сервисы взаимодействуют между ними сообщениями, и поэтому здесь определяем формат сообщений. В системе используется протокол SOAP в качестве формата сообщений. Этот простой основанный на XML протокол позволяет приложениям обмениваться информацией по транспортным протоколам, таким как HTTP. Благодаря использованию XML протокол SOAP является:
1. Платформенно-независимым.
2. Пригодным для использования в Интернете.
3. Читабельным, структурированным и текстовым. Процесс реализация сервисов включает в себя два
фазы: выбор технологий и инструменты построения приложений, и разработка приложений.
В системе должны создаваться два типа приложений:
• Web-приложение;
• Web-сервис.
Для построения Web-приложения используется технологии ASP.NET MVC. ASP.NET МVС - это платформа для веб-разработки от Microsoft, которая сочетает в себе эффективность и аккуратность архитектуры "модель -представление-контроллер" (model-view-controller — MVC), новейшие идеи и приемы гибкой разработки, а также все лучшее из существующей платформы ASP.NET. Благодаря адаптации к архитектуре МVС, платформа ASP.NET МVС имеет следующие преимущества:
• Взаимодействие пользователя с приложением MVC естественным образом следует циклу: пользователь предпринимает действие, в ответ на которое приложение изменяет свою модель данных и доставляет измененное представление пользователю. Затем цикл повторяется. Это очень удобно укладывается в схему веб - приложений, состоящих из последовательностей запросов и ответов HTTP.
• Веб-приложения, нуждающиеся в комбинации нескольких технологий (например, баз данных, HTML и исполняемого кода), обычно разделяются на ряд уровней, и получающийся в результате шаблон естественным образом отображается на концепцию МVС.
• Платформа ASP.NET MVC построена в виде серии независимых компонентов - реализующих интер-фейс^ЕТ или построенных на основе абстрактного базового класса, - поэтому можно легко заменить систему маршрутизации, механизм представлений, фабрику контроллеров или прочие компоненты платформы другими.
Благодаря этим преимуществам, использование ASP.NET MVC при создании web-приложении в системе перспективно.
Для создания Web-сервисов используются технологии WCF (Windows Communication Foundation). WCF предоставляет единую инфраструктуру разработки, при умелом применении повышающую производительность и снижающую затраты на создание безопасных, надёжных и транзакционных Web-сервисов нового поколения. Пользуясь WCF, разработчики могут сосредоточиться на приложениях, а не на коммуникационных протоколах. Это классический пример инкапсуляции технологии в инструментальных средствах. Труд разработчика будет более производительным, если применяемые им инструменты всюду, где возможно, инкапсулируют (но не скрывают) технические детали. В распоряжение разработчика предоставляется готовый служебный код, необходимый практически в каждом приложении, поэтому применение WCF кардинально повышает производительность. WCF поддерживает различные способы обмена сообщениями, например: запрос -ответ, односторонний и дуплексный поток. [1, с.121] Поддерживаются также пиринговые сети, в которых клиенты могут обнаруживать друг друга и обмениваться данными в отсутствие централизованного механизма управления.
Разработку приложений можно разделить на две
части:
• разработка Web-приложений;
• разработка Web-сервисов.
Контроллеры приложений ответственны за обработку пользовательского взаимодействия и содержат бизнес-логику приложения, отвечая за то, что будет выдано пользователю при его запросе. Контроллер - это просто класс. В контроллере мы определяем методы, так называемые методы действий, которые могут вызывать пользователи. Каждый метод действия виден внешнему миру через свой URL и вызывается с параметрами, извлекаемыми из входящего запроса. Данные передаются в представление из метода действия контроллера с помощью метода View.
Представления служат для отображения пользовательского интерфейса приложения. Методы контроллера возвращают представления, и представление содержит HTML-разметку и контент, отправляемый в браузер. Представление эквивалентно странице. При создании Представления используется Razor - новый движок представлений в ASP.NET. Новый движок Razor предоставляет гибкий процесс кодирования и позволяет быстро интегрировать серверный код в HTML-разметку с минимумом усилий. [6, c.67]
Реализация сервисов системы состоит из следующих процессов:
• Создание контрактов;
• Выбор подходящей привязки;
• Определение конечных точек;
• Создание контрактов.
Контракт определяет условия предоставления и потребления сервисов, включая функциональные, технические (не только протокол, но и, например, способ авторизации, QoS) и прочие (стоимость, гарантии) параметры и служит основой соглашения между потребителем и провайдером сервиса на всех этапах его жизненного цикла. Одно из распространенных определений провайдера и потребителя сервисов базируется на том, кто из них контракт предоставляет (провайдер), а кто принимает (потребитель).
Технология WCF построена на концепции контрактов, с помощью которых можно описать взаимодействия между сервисами, формат сообщений, и т.д. Эта технология предлагает нам три разных типа контрактов: контракт сообщений, данных и сервисов. [5, с.49]
Контракт сервисов - определяет, как сервис будет взаимодействовать с внешним миром. Чтобы описать контракт сервисов в WCF, используется интерфейс с атрибутом: [ServiceContract]. Потом в этом интерфейсе определяется операции, которые могут производиться сервисом. Эти методы обозначены атрибутом [OperationContract]. В системе для каждого web - сервиса создается один контракт сервисов с операциями.
Контракт данных - определяет формат данных, которыми сервисы будут обмениваться. Это относится как к запросу на сервис, так и к ответу сервиса.
Итак, проблема создания распределенной информационной системы на основе распределенной базы данных рассмотрена на основе концепции жизненного цикла программного продукта. Это указывает на то, что применение сервис-ориентированной архитектуры совместно с распределенной базой данных обеспечат повышение надежности, доступности и эффективности любой системы.
Список литературы
1. Бертсекас Д., Галлагер Р. Сети передачи данных. -М.: Мир,2009.-544 с
2. Бутрименко A.B. Разработка и эксплуатация сетей ЭВМ. - М.:Финансы и статистика, 2011. - 256с.
3. Гладцын В. А., Кринкин К. В., Яновский В. В. Сервис-ориентированная архитектура. Стандарты, алгоритмы, протоколы: Учеб. пособие. СПб.: Изд-во СПбГЭТУ "ЛЭТ", 2004 -108 с.
4. Дейт К. Введение в системы баз данных, 8-е издание, Пер. с англ. — М.: Издательский дом "Вильяме", 2005. - 1328 с.
5. Задков В.П., Пономарев Ю.В. Компьютер в эксперименте. Архитектура и программные средства систем автоматизации. - М.: Наука, 2002. -376с.
6. Игнатьев В.М., Ларкин Е.В. Анализ производительности ЭВМ//Учеб. пособие,- Тула: ТулГТУ, 2009. -104 с.
7. Таненбаум Э., Ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2008 -845с.
