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

Содержание:

Введение

Реализация любого программного обеспечения, в том числе информационных систем, предполагает по умолчанию совместное использование соответствующих языков программирования. Однако, в случае недооценки значения моделирования, предваряющего реализацию конечного программного изделия, программист невольно приходит к методу «собачьей конуры», который может быть оправдан лишь при создании небольших программ. При грамотном подходе к разработке различных систем (технических, экономических, информационных и др.) следует выполнить обследование целевой деятельности предприятия заказчика с построением модели бизнес-процесса AS-IS для последующей реорганизации с созданием бизнес-процесса TO-BE. Для этого можно воспользоваться диаграммными техниками IDEF0, DFD, и IDEF3 пакета BPwin либо UML-диаграммами (вариантов использования, состояний и др.) пакета Rational Rose. В данном случае, пожалуй, первый подход предпочтительней.

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

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

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

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

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

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

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

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

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

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

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

1.1 Общая характеристика подходов при построении и внедрении информационных систем

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

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

Для системы управления предприятием основными аспектами являются следующие факторы:

-цель деятельности организации;

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

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

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

-наличие органа управления предприятием;

-обязательная обратная связь между элементами системы - наличие функции контроля [2].

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

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

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

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

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

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

-ориентация системы на автоматизацию обработки информации;

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

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

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

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

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

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

Объектно-ориентированная архитектура обладает рядом следующих преимуществ [9]:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Классическое определение архитектуры в строительстве сформировалось и стало использоваться при рассмотрении технических систем, как сложных объектов. На сайте SEI (Software Engineering Institute) приведено более ста трактовок понятия «архитектура информационной системы», представляющих эту дефиницию как:

- организационную структуру системы;

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

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

- набор ключевых решений, неизменных при изменении бизнес -технологий.

Архитектура информационной системы - это концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы [14].

Архитектура ИС это её модель, определяющая стоимость её использования через имеющуюся в системе архитектуру.

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

Основанием выбора архитектуры ИС являются плановые затраты на её использование и стоимость рисков.

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

К типам рисков при разработке архитектуры ИС относятся:

- ошибки разработки, недостаточная оптимизация;

- технические риски (простои системы, утрата данных, отказы);

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

Рациональный способ разработки архитектуры ИС предполагает необходимость выяснения ряда вопросов:

- В чём состоит назначение системы (что она делает?);

- Каковы компоненты этой системы?;

- Как взаимодействуют эти компоненты?;

- Территориальное размещение этих компонентов.

Для крупных компаний архитектура представляет собой т.н. «корпоративную архитектуру» как совокупность нескольких типов архитектур.

Можно выделить несколько подходов к проектированию ИС [15]:

- календарный подход на основе графика предстоящих работ с выделением этапов его исполнения;

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

- формирование пакета документов;

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

- архитектурный подход [13].

Архитектурный подход своим ключевым аспектом имеет создание фрэймворка, т.е. некого каркаса, который может быть адаптирован под требования конкретной системы. Другими словами, фрэймворк представляет собой общее решение сложной задачи. Одним из фрэймворков является фрэймворк разработанный сотрудником компании УВН Джоном Захманом (John Zachman) на основе классификации артефактов систем. При использовании таксономии Захмана разработчик отвечает на вопросы:

- какие данные используются в системе (что?);

- какие процессы и функции характеризуют систему (как?);

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

- участники процесса (организация и люди) (кто?);

- управляющее событие (когда?);

- цели и ограничения, определяющие работу системы (почему?).

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

- уровень контекста (для аналитиков);

- уровень бизнес-описаний (топ менеджеры);

- системный уровень (архитекторы);

- технологический уровень (разработчики);

- технический уровень (администраторы);

- уровень реальной системы (пользователи).

Использование фреймворка Захмана не позволяет описать динамику поведения системы, что яв-ляется его главным недостатком. Фреймворк TOGAF (The open Group Architecture Framework) представ-ляет собой совокупность модулей: бизнес-архитектура [16]; архитектура приложений; архитектура данных; технологическая архитектура. Фреймворк TOGAF может использоваться в совокупности с другими фреймворками, в том числе и с фреймворком Захмана.

Фреймворк министерства обороны США DoDaf (Departmentof Desense Architecture Framwork) состоит из трех компонентов: модели (modeles), виды (views) и точки зрения (viewpoints). Несмотря на военные назначения DoDaf является свободным распространяемым продуктом. При помощи этого фреймворка проектируются системы сбора, хранения и анализа данных для поддержки принятия решений (таблицы, графические изображения структурных аспектов архитектурного решения, взаимосвязи между типами информации, онтологии, картинки в свободном формате, временные диаграммы).

Наиболее полной методологии является архитектура федеральной организации (Federal Enterprise Atchitecture - FEA), включающая 5 эталонных моделей: модель бизнеса; модель обслуживания; модель компонентов; технологическую модель; модель данных. Фреймворк FEA включает модель Захмана и Фреймворк TOGAF.

Методология Cartner определяет два самых важных вопроса: «куда организация стремится?» и «как она туда попадает?». Процесс проектирования архитектуры в методологии Cartner представляется следующими этапами [17]:

1. Изложить стратегические представления о будущем компании на языке бизнеса;

2. Составить перечень необходимых решений задач;

3. Выбрать для реализации задачу из сформированного перечня;

4. Составить список требований к решению выбранной задачи;

5. Сформировать команду;

6. Разработать целевую архитектуру бизнеса для выбранной задачи;

7. Создать специализации будущей системы;

8. Изучить существующую архитектуру и определить какие изменения необходимо внести;

9. Разработать технологическую архитектуру для ИТ - систем, которые будут поддерживать новую архитектуру бизнеса;

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

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

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

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

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

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

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

Естественно, чтобы обеспечить такие возможности коммуникаций, должна быть проделана огромная работа. Как со стороны разработчиков программного обеспечения, так и со стороны поставщиков оборудования. Найти общий язык, наладить интерфейсы, призван стандарт 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. Структура программного обеспечения конфигурирования автоматизированной информационной системы как элемент объектно-ориентированного подхода

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

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

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

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

- 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 с.