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

Можно выделить несколько подходов к проектированию ИС [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 предусматривается объединение механизмов адресации и доступа к разным категориям данных.

---