Применение объектно-ориентированного подхода при проектировании информационной системы (общая характеристика)

Содержание:

Введение

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

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

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

В начале 70-х гг. в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполнятся с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, в 1995г. компания StandishGroup проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали следующие выводы:

Только 16% проектов завершились в срок, 52,7% завершились с опозданием, расходы превысили запланированный бюджет.

В числе причин неудач фигурируют: нечеткая и неполная формулировка требований к ПО, недостаточное вовлечение пользователей в работу над проектом, неудовлетворительное планирование и т.п.

На этом фоне, выгодно отличается объектно-ориентированный подход к проектированию ПО. Он устраняет эти и другие недостатки, он обладает богатым набором изобразительных средств.

Объектом данного исследования является объектно-ориентированный подход в проектировании информационных систем.

Предмет исследования – особенности и элементы объектно-ориентированного подхода как способа проектирования информационных систем.

Целью данной работы является анализ основ проектирования информационных систем на основе объектно-ориентированного подхода.

В ходе выполнения работы были решены следующие задачи:

- рассмотрение сущности и преимуществ объектно-ориентированного подхода;

- анализ предметной области;

- применение объектно-ориентированного подхода при проектировании ИС.

Методологическую основу исследования составили такие методы как анализ, синтез, сравнение, обобщение, выделение, интерпретация и другие методы научного познания.

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

Глава 1. Общая характеристика объектно-ориентированного подхода и его сравнение с другими подходами

1.1 Сравнительный анализ объектно-ориентированного подхода и подхода, основанного на использовании тегов

С появлением систем диспетчерского управления на базе промышленных контроллеров (ПК) и человеко-машинного интерфейса (Human-machine interface, HMI) создание скриптов, доступ к данным процессов, аварийная сигнализация и анализ данных осуществлялись на основе концепции тегов. В этих системах используется «плоский» список тегов со встроенными иерархией, взаимосвязями или взаимозависимостями.

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

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

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

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

Эти две области применения достаточно сильно различаются, поэтому для промышленности требуются специально разработанные объектно-ориентированные приложения.

В таблице 1 представлено сравнение объектно-ориентированных систем и систем, основанных на тегах.

Таблица 1 - Сравнение объектно-ориентированных систем и систем, основанных на тегах

Параметр сравне-	Объектно-ориентированная архитектура				Архитектура, основанная на тегах
ния	Разработка		Исполнение		Разработка		Исполнение
Структу-	Иерархиче-		Иерархическая		Иерархиче-		Плоская - монолитные экземпляры ПО исполняются на одной/нескольких машинах в качестве отдельных «приложений»
ра при-	ски - объек-		- компоненты		ская - графи-
ложений	ты создаются		соответствуют		ческий кон-
	с применени-		физическим		тент иногда
	ем объектно-		устройствам и		создается с
	ориентиро-		могут осу-		применением
	ванной мето-		ществлять ко-		объектно-
	дологии		ординацию с компонентами в различных компьютерах.		ориентированного подхода
Разра ботка графики	Осуществляется в последнюю очередь				Осуществляется в первую очередь
Внесение	Наследуются		Возможны рас-		На основе		Требуется пе-
измене-	из шаблонов		пределение, за-		графики или с		рекомпилиро-
ний в	объектов		мена или усо-		применением		вание прило-
приложе ния			вершенствова- ние		таких средств, как Excel		жения
Внесение	Наследуются		Возможны рас-		На основе		Требуется перекомпилирование приложения
измене-	из шаблонов		пределение, за-		графики или с
ний в	объектов		мена или усо-		применением
приложе ния			вершенствова- ние объектов		таких средств, как Excel
Скрипты		Разрабатываются в шаблонах объектов, затем внедряются в конкретное исполняемое приложение				Разрабатываются отдельно с последующей привязкой к графическому интерфейсу
Соответствие стандартам		Строгое				Нестрогое
Представление данных		Логические конструкции, такие как физические устройства (например клапаны и насосы) или логические устройства (например, петли PID или вычисления) представляются в виде объектов				С помощью тегов

Как видно из таблицы, объектно-ориентированная архитектура обладает рядом следующих преимуществ:

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

- упрощается внесение изменений в проект за счет распространения изменений шаблона объекта на все компоненты;

- текущая модификация и модернизация систем упрощается и удешевляется благодаря автоматизированному распространению изменений [2].

1.2 Архитектура разработки информационных систем и ее виды

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

- для разработки используется отдельный компьютер;

- для приложения создаются графические элементы и экраны операторских дисплеев

- определения тегов импортируются из ПЛК или настраиваются вручную;

- для каждого тега определяются скрипты аварийных сигналов и обнаружения событий;

- тегам и связанным с ними входам и выходам присваиваются ссылки на графические элементы;

- создаются графические скрипты или ссылки для анимации;

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

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

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

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

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

- создание списка сходных компонентов оборудования или физических ресурсов (при этом также проводится разграничение областей деятельности);

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

- при необходимости создания сложных элементов оборудования шаблоны объектов устройств или компонентов можно включать в состав друг друга;

- шаблоны объектов устройств имеют атрибуты, соответствующие реальным входам и выходам в ПЛК или в системе управления (эти атрибуты в дальнейшем связываются с входами и выходами с помощью объектов интеграции устройств);

- затем можно собрать приложение, просто перетаскивая объекты мышью;

- после этого прикладные объекты включаются в группы безопасности;

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

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

1.3 Объектно-ориентированный подход при построении автоматизированной системы

Стандарт имеет долгую историю, которая началась, когда Международная Электротехническая Комиссия получила рабочее предложение стандартизировать некоторые аспекты применения программных модулей, называемых «функциональные блоки», в промышленно-ориентированной распределенной измерительной и управляющей среде. Документ был условно разделен на четыре части. В проект были положены такие стандарты, как IEC-61131 и IECA61158.

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

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

Естественно, чтобы обеспечить такие возможности коммуникаций, должна быть проделана огромная работа. Как со стороны разработчиков программного обеспечения, так и со стороны поставщиков оборудования. Найти общий язык, наладить интерфейсы, призван стандарт IEC 61499.

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

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

Первая стадия предполагает применение так называемых P&ID (Process and Instrumentaion Diagrams) - структурных схем, отражающих в некотором роде суперпозицию физического процесса или объекта и применяемых в нем технических средств. На создаваемой схеме наносятся различные технологические установки, указывается расположение датчиков и т.д. Этот документ является своеобразной отправной точкой, началом проекта, и индикатором уровня профессионализма, причем не только разработчика системы, но и заказчика проекта. От того, насколько грамотно выполнена это стадия проекта, во многом определяется его конечный успех. В настоящий момент существует огромное количество программ разного уровня и ориентации, облегчающих создание P&ID, среди них AutoCAD, CADWorx, SmartPlant и многие другие.

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

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

Стандарт разделен на четыре части, доработка которых велась достаточно долго. Объяснить это можно глобальностью самой идеи, ведь стандарт рассчитан не только на производителей различных контроллеров и разработчиков программного обеспечения. Все положительные стороны этого стандарта проявятся только в случае, если будут выпускаться стандартные (с точки зрения производства) устройства, такие как котлы, печи, станки, насосы, обладающие определенным набором качеств, обеспечивающих совместимость с требованиями IECА61499. Производители промышленных систем управления, поставщики оборудования из США, Японии, Англии, Европы вошли в рабочую группу IEC, и появилась первая часть стандарта, описывающая архитектуру функциональных блоков, подходы к созданию и применению их на практике. Этот документ содержит описание следующих ключевых позиций:

- правила описания функциональных блоков;

- правила поведения событий в функциональных блоках;

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

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

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

- требования соответствия стандартам.

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

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

Extensible Markup Language (Расширяемый язык разметки) - средство, позволяющее структурно описать любой тип данных в текстовом виде для дальнейшего хранения и транспортировки. Основное преимущество - крос- сплатформенность. Данные, закодированные в XML, будут одинаково интерпретированы везде.

Для того, чтобы «функциональный блок» действительно стал функциональным, разработчик должен проделать работу по созданию алгоритмов или функций, которые придадут его объекту необходимые свойства. Для того чтобы задать эти свойства, можно будет воспользоваться языками стандарта IECA61131 (SFC, FB, LD, ST, IL), что, безусловно, очень удобно. Новый стандарт в своей основе будет иметь именно эти технологии программирования. Таким образом, обеспечивается преемственность решений, и тысячи разработчиков смогут легко перейти к созданию программ по объектноориентированной методологии [4].

OPC Unified Architecture (Унифицированная архитектура OPC) - спецификация, определяющая передачу данных в промышленных сетях и взаимодействие устройств в них.

Для упрощения и удешевления реализации информационных обменов в системах промышленной автоматизации была предложена технология OPC (OLE for Process Control), в системах промышленной автоматизации взаимодействие с «внешним миром» достигается за счет использования определенного шлюза, унифицирующего интерфейс взаимодействия с клиентом и скрывающего частный протокол отдельных средств автоматизации. Использование «классической» OPC ограничено платформой Windows, так как это не протокол передачи данных, а именно программная технология, основанная на механизме удаленного вызова процедур с использованием стека DCOM. Это накладывает свой негативный отпечаток на такие параметры процесса взаимодействия по OPC, как безопасность, надежность и резервирование.

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

Говоря о «классической» OPC, в первую очередь имеют в виду передачу данных согласно спецификациям OPC DA (Data Access - в масштабе реального времени), OPC HDA (Historical Data Access - архивов изменений параметров) и OPC A&E (Alarm and Events - тревог и событий).

Популярность спецификаций OPC HDA и OPC A&E существенно меньше, чем у OPC DA, потому, что передача данных архивов и аварийных событий требовала от производителя оборудования разработки еще двух отдельных программ, а от разработчика системы диспетчеризации - настройки еще одного или двух дополнительных информационных стыков c серверами OPC HDA и OPC A&E, имеющими независимые и не связанные с OPC DA адресные пространства. В OPC UA предусматривается объединение механизмов адресации и доступа к разным категориям данных.

Типовая схема использования OPC для доступа к данным ПЛК и SCADA- систем показана на рисунке 1.

Рисунок 1 - Схема применения «классической» OPC

Итак, первая особенность OPC UA - получение текущих и архивных значений параметров и событий происходит теперь единообразно от одного источника. При этом унифицированное адресное пространство еще и содержит больше семантических сведений, доступных при его просмотре. Для примера рассмотрим объект «бойлер», которым управляют через события «вклю- чен/выключен», по изменению температуры и давления, а также анализируют, как эти параметры влияют друг на друга. Логично, что данные свойства нужно группировать и анализировать все вместе. Семантика OPC UA позволяет это сделать. Один объект здесь представлен набором свойств (температура, давление), методов (включен/выключен) и событий (температура слишком высокая, давление слишком низкое).

Вторая особенность OPC UA - полностью переработанный механизм взаимодействия OPC-клиента и OPC-сервера. Произошел отказ от DCOM в пользу обмена бинарными или XML-сообщениями, то есть OPC UA - это именно протокол передачи данных; к такому механизму намного «дружественнее» относятся межсетевые экраны и прочие средства информационной безопасности; с другой стороны, отказ от DCOM вызван и ростом популярности решений под Linux. Также стандарт определяет гибкий механизм управления сетевыми и логическими соединениями OPC-серверов и OPC-клиентов для поддержки резервированных конфигураций и т.п. Более того, интерфейс OPC-сервера рассматривается как набор сервисов, а значит, данные систем автоматизации могут стать доступными другим приложениям в единой сервисной шине предприятия, построенной по технологии SOA.

Третья особенность OPC UA - отказ от использования механизмов контроля прав доступа Windows (основанных на проверке имени/пароля пользователя, от имени которого запускается OPC-клиент), разработчики OPC UA предложили более современный способ контроля с использованием сертификатов.

Также предусмотрена возможность шифрования передаваемых данных.

Естественно, уделено внимание и вопросу сохранения уже сделанных предприятиями инвестиций. Использование «классической» OPC возможно и в OPC UA-среде: специальная оболочка обеспечивает доступ к обычному OPC DA-серверу, а proxy-модуль позволяет OPC DA-клиенту взаимодействовать с новыми OPC UA-серверами [5].

Спецификация OPC UA является многоэлементной и состоит из следующих частей:

- концепция;

- модель безопасности;

- модель адресного пространства;

- службы;

- информационная модель;

- распределение служб;

- профили;

- доступ к данным;

- аварийная сигнализация и условия;

- программы;

- доступ к историческим данным.

В отличие от спецификаций основывающихся на COM, спецификации UA не являются чистыми определениями приложения. Обычно они описывают внутренние механизмы Унифицированной архитектуры, обрабатываемые коммуникационным стеком и нормально лежащие вне пределов интереса тех, кто портирует стек на специфическое устройство, или тех, кто хочет реализовать свой собственный стек UA. Разработчик приложений OPC UA разрабатывает код против OPC UA API и, следовательно, взамен будет в основном использовать документацию API [6].

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

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

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

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

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

Рассмотрен стандарт IEC 61499, а также спецификация OPC UA ориентированная на объектно-ориентированный подход.

Глава 2. Методология разработки информационной системы на основе объектно-ориентированного подхода

2.1 Онтология информационной системы и ее построение

Потребность в разработке онтологий возникает по некоторым причинам:

- для совместного использования людьми или программными агентами общего понимания структуры информации;

- для возможности повторного использования знаний в предметной области;

- для отделения знаний в предметной области от оперативных знаний;

- для анализа знаний в предметной области.

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

Обеспечение возможности использования знаний предметной области стало одной из движущих сил недавнего всплеска в изучении онтологий. Например, для моделей многих различных предметных областей необходимо сформулировать понятие времени. Это представление включает понятие временных интервалов, моментов времени, относительных мер времени и т.д. Если одна группа ученых детально разработает такую онтологию, то другие могут просто повторно использовать ее в своих предметных областях. Кроме того, если нам нужно создать большую онтологию, можно интегрировать несколько существующих онтологий, описывающих части большой предметной области. Отделение знаний предметной области от оперативных знаний - это еще один вариант общего применения онтологий. Можно написать задачу конфигурирования продукта из его компонентов в соответствии с требуемой спецификацией и внедрить программу, которая делает эту конфигурацию независимой от продукта и самих компонентов. Можно разработать онтологию компонентов и характеристик ЭВМ и применить этот алгоритм для конфигурирования нестандартных ЭВМ [8].

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

В общем виде формальная модель онтологии может быть описана следующим кортежем:

0 = {L,C,F, G,H,R,A},

где L = LC U LR - словарь онтологии, содержащий набор лексических единиц (знаков) для понятий LC и набор знаков для отношений LR;

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

F и G - функции ссылок такие, что F: FLC ^ 2C и П: FLR ^ 2R, то есть F и G связывают наборы лексических единиц {Lj} с L с наборами понятий и отношений, на которые они соответственно ссылаются в данной онтологии, при этом одна лексическая единица может ссылаться на несколько понятий или отношений и одно понятие или отношение может ссылаться на несколько лексических единиц;

H - фиксирует таксономический характер отношений (связей), при котором понятия онтологии связаны нерефлексивными, ациклическими, транзитивными отношениями H с C х C, выражение Н(Сг, C2) означает, что понятие C является подпонятием C2;

R - обозначает бинарный характер отношений между понятиями онтологии, фиксирующей пары области применения (domain)/области значений (range);

A - набор аксиом онтологии.

Более простая модель онтологии (без словаря и без определения типа отношений) приведена ниже. Под онтологией в этой работе понимается упорядоченная тройка вида [9 - 11]:

0 = (C,R,F),

где C - конечное множество концептов (понятий, терминов) предметной области, которую представляет онтология О;

R - конечное множество отношений между концептами заданной предметной области;

F - конечное множество функций интерпретации (аксиоматизации), заданных на концептах и/или отношениях онтологий О.

Естественным ограничением, налагаемым на множество С, является его конечность и не пустота.

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

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

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

Современные инструментальные средства для работы с онтологиями являются Protege, OntoEdit, OilEd. Их главным назначением является создание, редактирование и визуальное отображение онтологий.

На практике разработка онтологий включает:

- определение классов в онтологии;

- расположение классов в таксономическую иерархию (подкласс- надкласс);

- определение слотов и описание допускаемых значений слотов;

- связывание слотов с классами.

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

2.2. Структура программного обеспечения конфигурирования автоматизированной информационной системы как элемент объектно-ориентированного подхода

Диаграмма размещения программных средств состоит из следующих уровней:

- сервера базы данных;

- автоматизированной системы учета энергоресурсов;

- конфигуратора;

- OPC UA-клиента;

- OPC UA-сервера;

- приборов учета.

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

База данных содержит информацию о приборах учета.

Конфигуратор - позволяет создавать, удалять, выполнять резервное копирование баз данных. Конфигуратор позволяет: создавать дерево объектов учета и учитываемых энергоресурсов; добавлять приборы учета и их свойства; задавать параметры связи с приборами учета [13].

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

OPC-клиент получает информацию о конкретном приборе учета.

OPC-сервер получает данные о приборах учета энергоресурсов и передает эти данные автоматизированной системе учета энергоресурсов.

Структуре программных средств представлена на рисунке 2.

Рисунок 2 - Структура автоматизированной системы с использованием спецификации OPC UA

OPC UA разделяет несколько уровней взаимодействия OPC-клиентов и OPC-сервера. Во-первых, каждый из клиентов устанавливают с сервером свое защищенное сетевое соединение. При этом если в «классической» OPC право доступа клиента к серверу определялось, исходя из прав пользователей Windows, от чьего имени они запускались на соответствующих компьютерах, то в OPC UA клиент и сервер идентифицируют себя цифровыми сертификатами. Во-вторых, в рамках соединения создается сессия - логическое соединение клиента и сервера. Параметром сессии являются уже права отдельного пользователя, использующего OPC клиент, так как OPC-сервер может вводить ограничения на операции чтения/записи отдельных элементов для разных пользователей. Уже в рамках сессии производится собственно передача данных (выполнение запросов на чтение/запись), а также производится инициализация списка элементов, об изменениях значений которых сервер направляет клиенту уведомление.

На рисунке 3 - представлена сущность взаимодействия OPC-клиента и OPC-сервера

Рисунок 3 - Сущность взаимодействия OPC-клиента и OPC-сервера

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

Отдельно отметим изменения в концепции отправки OPC-сервером уведомлений об изменениях значений отдельных параметров клиентам. В OPC DA этот механизм был реализован через обратный вызов методов клиента, в OPC UA межпрограммное взаимодействие не используется, а отправляются сообщения. Важной особенностью их отправки является то, что сервер сам определяет момент отправки (по факту изменения значений отдельных параметров), но не создает новых сообщений, а выбирает их из очереди ранее полученных «заготовок» от данного клиента. То есть сначала клиент направляет серверу массив запросов об изменениях (с уникальными ID), сервер их кэширует и по мере появления изменений (или при прохождении заданного периода времени без изменений) отправляет клиенту; далее клиент подтверждает факт получения сообщения. Периодически клиент пополняет очередь на сервере сообщениями с новыми ID. Таким образом, исключается возможность неконтролируемого роста числа отправляемых сервером сообщений об изменениях.

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

OPC UA реализует важные изменения и в части организации данных сервера, то есть адресного пространства. В OPC DA теги были сгруппированы иерархически с помощью папок. У каждого тега были обязательные свойства: значение (скалярное или векторное, одного из предопределенных простых типов данных - Int16, Float, String и т.п.); признак достоверности (quality); метка времени. Разработчик OPC-сервера мог определять дополнительные свойства для тегов, такие как описание единиц измерения и т.п.; было желательным, чтобы OPC-клиент мог считывать значения этих дополнительных свойств наряду с обязательными свойствами. В OPC UA адресное пространство организовано иерархически за счет введения объектов (в терминах объектноориентированного программирования), то есть экземпляров классов. Класс (и объект) может содержать переменные, ссылки на другие объекты и даже методы - функции, доступные для вызова OPC-клиентом. При этом тип переменной может быть сложным, аналогично понятию структуры из языка программирования, объединяя поля разных типов, включая таблицы (массивы) и т.д.

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

В адресном пространстве OPC UA-сервера может быть реализована явная типизация объектов, то есть сопоставление однотипных групп технологических параметров шаблону (классу). Благодаря этому появляется возможность в приложении-клиенте контролировать полноту получаемой информации и в случае изменения ее объемов в сервере автоматически на это реагировать.

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

Заключение

Объектно-ориентированное проектирование - это конструирование программных систем как структурных коллекций, реализующих абстрактные типы данных.

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

Преимущества объектно-ориентированного метода:

- работают на более высоком уровне абстракции;

- нет «прыжков» между фазами;

- поддерживают данные, которые имеют тенденцию, к большей стабильности, чем функции;

- поощряют и поддерживают классические достоинства хорошего программирования и проектирования;

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

Объектно-ориентированный подход имеет два аспекта:

- объектно-ориентированная разработка программного обеспечения;

- объектно-ориентированная реализация программного обеспечения.

Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных моделей при разработке программных систем и их компонентов. К объектно-ориентированной разработке относятся:

- объектно-ориентированные технологии разработки программных систем;

- инструментальные средства, поддерживающие эти технологии.

Объектно-ориентированная разработка может начаться на самом первом этапе жизненного цикла; она не связана с языком программирования, на котором предполагается реализовать разрабатываемую программную систему: этот язык может и не быть объектно-ориентированным.

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

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

- RUP (Rational Unified Process);

- OMT (Object Modeling Technique);

- SA/SD (Structured Analysis/Structured Design);

- JSD (Jackson Structured Development);

- OSA (Object-Oriented System Analysis)

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

Список использованной литературы

1. Гурьянов, Л. В. Платформа «Энергокруг»: эффективный инструмент комплексного учета энергоресурсов / В. Д. Слета, Л. В. Гурьянов // Control Engineering Россия. - 2015. - №6. - С. 42 - 46.

2. Гуськов, М. Ю. Принципы объектного подхода в разработке систем промышленной автоматизации / М. Ю. Гуськов, Л. В. Гурьянов // Новые информационные технологии и системы: материалы XIII Международной научно-технической конференции - Пенза: Издательство Пензенского государственного университета, 2016. - С. 117 - 118.

3. Гарбрехт, С. Преимущества объектно-ориентированных архитектур для SCADA и систем диспетчерского управления / С. Г арбрехт // Информатизация и системы управления в промышленности. - 2013. - №2. - С. 93 - 100.

4. Гулько, С. В. Обзор стандарта IEC 61499 / С. В. Гулько, Н. Джоврей // Передовые технологии и технические решения. - 2005. - №4. - С. 8 - 12.

5. Богданов, Н. OPC Unified Architecture: изменения в популярной технологии информационных обменов с точки зрения инженера / Н. Богданов, О. Киселева // Современные технологии автоматизации. - 2010. - №3. - С. 82 - 87.

6. OPC UA // Википедия: свободная энцикл. [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/OPC_UA

7. Гурьянов, Л. В. От измерения и обработки тегов к объектам и быстрой разработке автоматизированных систем / В. Д. Слета, Л. В. Гурьянов // Control Engineering Россия. - 2015. - №6. - С. 20 - 23.

8. Ной Н. Ф., МакГиннесс Д.Л. Разработка онтологий 101. Руководство по созданию вашей первой онтологии // International Forum of Educational Technology &Society [Электронный ресурс]. URL: http://ifets.ieee.org/russian/depository/ontology101_rus.doc

9. Башмаков, А. И. Интеллектуальные информационные технологии / А. И. Башмаков, И. А. Башмаков. - М.: МГТУ им. Н.Э.Баумана, 2005. - 304 с.

10. Тузовский, А. Ф. Системы управления знаниями / А. Ф. Тузовский, С. В. Чириков, В. З. Ямпольский. - Томск: НТЛ, 2005. - 260 с.

11. Скобелев, П. О. Онтологии деятельности для ситуационного управления предприятиями в реальном времени / П.О. Скобелев // Онтология проектирования. - 2012. - №1. - С. 6 - 38.

12. Муромцев, Д. И. Онтологический инжиниринг знаний в системе Protege / Д. И. Муромцев. - СПб.: СПб ГУ ИТМО, 2007. - 62 с.

13. Арлоу, Д. UML 2 и унифицированный процесс. Практический объектно-ориентированный анализ и проектирование / Д. Арлоу, А. Нейштадт. - Спб.: Символ-Плюс, 2007. - 624с.

14. Бойко, В. В. Проектирование баз данных информационных систем / В. В. Бойко, В. М. Савинков. - М.: Финансы и статистика, 1989. - 351 с.

15. Орлов, С. А. Технологии разработки программного обеспечения / С. А. Орлов. - СПб.: Питер, 2004. - 608 с.

16. Диго, С. М. Базы данных. Проектирование и создание / С. М. Диго. - М.: Изд. центр ЕАОИ. 2008. - 171 с.

17. Дадян, Э. Г. Проектирование современных баз данных / Э. Г. Дадян. - М.: Финакадемия, 2007. - 117 с

18. Постолит, А. В. Visual Studio .NET: Разработка приложений баз данных / А. В Постолит - СПб.: БХВ-Петербург, 2003. - 538 с.