Содержание к диссертации
Введение
ГЛАВА 1. Анализ технологических процессов хранения и обработки информации в диспетчерских пунктах АСУТП 10
1.1. Анализ моделей данных, используемых современными СУБД 10
1.2. Анализ методов объектной декомпозиции предметной области 17
1.3. Механизмы программного взаимодействия с объектно-ориентированными базами данных 27
1.4. Типы информационных потоков ДП АСУТП 36
1.5. Адресные пространства источников данных 42
Выводы по главе 1 44
ГЛАВА 2. Разработка информационных моделей непрерывного технологического процесса 46
2.1. Задача адаптации современных методологий проектирования для создания модели непрерывного технологического процесса диспетчерского управления 46
2.2. Разработка информационной модели с использованием объектно-ориентированных методов ..53
2.3. Разработка информационной модели с использованием субъектно-ориентированных методов 59
2.4. Разработка информационной модели с использованием аспектно-ориентированных методов 64
Выводы по главе 2 76
ГЛАВА 3. Синтез и оптимизация структуры сети передачи данных в распределнной системе диспетчерского управления 78-
3.1. Исходные данные, постановка и схема решения задачи 78
3.2. Оценка интенсивности потоков данных распределенной АСУТП 82
3.3. Генерация начальной структуры сети передачи данных 85
3.4. Оптимизация структуры сети передачи данных 89
Выводы по главе 3 92
ГЛАВА 4. Реализация и экспериментальное исследование методов автоматизации проектирования и управления информационными потоками дп АСУТП 93
4.1. Описание методов автоматизации проектирования 93
4.2. Описание типа автоматизируемого производства 98
4.3. Методика синтеза структуры БД ДП АСУТП 100
4.4. Методика объектно-ориентированного описания информационных связей 104
Выводы по главе 4 106
Заключение 108
Литература 110
- Механизмы программного взаимодействия с объектно-ориентированными базами данных
- Разработка информационной модели с использованием объектно-ориентированных методов
- Разработка информационной модели с использованием аспектно-ориентированных методов
- Оптимизация структуры сети передачи данных
Введение к работе
В настоящее время на многих производственных предприятиях, в частности в нефтегазовой промышленности, проводится внедрение новых комплексов автоматизированных систем управления технологическими процессами (АСУТП). Это связано с необходимостью повышения управляемости и эффективности производства, его безопасности, в т.ч. экологической, а также моральным устареванием установленных на предприятиях систем автоматизации. При этом характер производства приводит к необходимости создания многоуровневой системы управления, обеспечивающей информационные обмены между производственно связанными локальными пунктами управления, а также объединяющей в центральной диспетчерской всю информацию о состоянии территориально распределенного технологического процесса.
К концу 90-х гг. произошел полный переход от заказных, часто создаваемых "с нуля" программно-аппаратных комплексов автоматизации производства к использованию типовых программных решений и серийных средств телемеханики [20]. В частности, внедрение диспетчерского пункта (ДП) АСУТП требует проведения логического и физического проектирования базы данных (БД), входящей в состав некоторого тиражируемого универсального программного комплекса. Проведенный автором сравнительный анализ систем управления базами данных (СУБД), использующих различные модели данных [8] показал, что наиболее эффективно при автоматизации промышленных предприятий использовать базы данных, совмещающие объектно-ориентированный и иерархический подходы. Программные комплексы ДП АСУТП, использующие именно такие базы данных, широко внедряются в производственных подразделениях ОАО «Газпром» и ряда нефтяных компаний. Однако системы автоматизированного проектирования таких баз данных отсутствуют, современные теоретические работы также затрагивают в основном методологии программирования (предлагая расширения объектно-ориентированного подхода) или развивают реляционную, постреляционную, объектную модели данных.
5 Анализ работ, в которых рассматривались бы информационные потоки
распределенных систем управления, а также вопросы теории проектирования объектно-иерархических баз данных, при их широком практическом применении во многих отраслях промышленности, обосновывает выбор темы диссертации и обуславливает ее актуальность.
Предметом исследования являются информационные потоки, рассматриваемые с двух точек зрения. Во-первых, рассматриваются потоки данных в БД ДП АСУТП, реализующей функции хранения оперативных, нормативно-справочных данных и маршрутизации информационных потоков. Во-вторых, рассматривается распределенная сеть передачи данных (РСПД), объединяющая территориально распределенные диспетчерские пункты, и специфика информационных потоков в ней.
Целью исследования является адаптация современных методов проектирования к области разработки структуры объектно-иерархической базы данных ДП АСУТП, управления внешними и внутренними по отношению к ней информационными потоками, а также исследование методов синтеза топологической структуры и оптимизации параметров сети передачи данных распределенной АСУТП. Исходя из этого, основными задачами исследования являются:
Проведение анализа существующих способов хранения оперативных технологических данных в базах данных ДП АСУТП, методов организации логической структуры этих баз данных, средств и языков доступа к данным в объектно-ориентированных базах данных (ООБД).
Разработка шаблонов и методики объектно-ориентированного проектирования структур баз данных ДП АСУТП.
Применение достижений субъектно- и аспектно-ориентированного программирования для автоматизации и управления процессами передачи информации в распределенных системах диспетчерского управления.
Исследование и систематизация реализуемых различными протоколами передачи данных алгоритмов информационного обмена.
Исследование методов синтеза структуры и оптимизации топологической структуры магистральных сетей передачи данных и их применимости при создании распределенной системы диспетчерского управления, с учетом требований к надежности и вероятностно-временным характеристикам сети.
Разработка методик автоматизации проектирования объектно-иерархической БД с учетом правил и ограничений взаимосвязей проектных вариантов предметной области (ПрО) транспорта нефти и газа.
Теоретическая значимость диссертации заключается в выполнении синтеза результатов современных исследований в области методологий программирования и логического проектирования, в частности субъектно- и аспектно-ориентированного, и их применении к области автоматизации непрерывных технологических процессов. Проектирование структуры объектно-иерархической базы данных в соответствии с результатами анализа предметной области описано в специальном руководстве разработчика [89], но в нем не рассмотрены информационные потоки и не анализируется возможное повышение эффективности за счет распределения хранимых данных, описывающих различные аспекты технологического процесса и автоматизируемого производства. Данная работа является попыткой применения комплексного подхода при рассмотрении информационных потоков в распределенных системах диспетчерского управления.
В практическом плане ценность диссертации заключается в проработке и апробировании методик формализации структуры объектно-иерархической БД; синтеза и оптимизации структуры сети передачи данных распределенной системы диспетчерского управления, разработке практической методики организации информационного обмена в программных комплексах систем диспетчерского управления.
Основные результаты работы, выносимые на защиту, состоят в следующем:
1. По результатам анализа методов логической организации информации
и доступа к ней в базах данных диспетчерских пунктов АСУТП и низовых систем установлено, что наиболее эффективно использование объектно-иерархической модели данных. Такие БД, подобно ООБД, поддерживают иерархию классов, реализуют механизмы наследования, инкапсуляции данных. Введение независимой иерархии объектов, где каждый из элементов - специфический экземпляр определенного класса, позволяет отразить результаты анализа предметной области и представить сложную систему - автоматизируемое производство - в канонической форме [10]. Также, в частности, использование подобных БД устраняет логическое несоответствие между информационной моделью и множеством понятий предметной области. В диссертационной работе предлагается использовать как существующие шаблоны анализа [74,75] и проектирования [28,65,76] общего назначения, так и специализированные для систем реального времени [12]. Это множество типовых решений, а также методы рефакторинга программного обеспечения (ПО) [49] составляют базовый набор правил формализации требований к системе и выявления взаимосвязей предметной области в терминах объектной модели.
2. Использование встроенной программной среды подобных СУБД по
зволяет расширить поведенческую модель объектов-контейнеров операциями
обработки состояний их элементов. Также, поскольку объект автоматизации,
особенно в нефтегазовой отрасли, энергетике, на транспорте, часто содержит
несколько типовых производственных участков, эксплуатационных зон и т.п.,
возможно тиражирование их информационных моделей в структуре ООБД.
При этом проявляется дополнительное преимущество объектно-иерархических
БД: возможность использования относительной адресации между ее объектами,
В диссертации предложено использовать методы субъектно-ориентированного
и аспектно-ориентированного программирования и проектирования, что позво
ляет упростить структуру классов за счет разделения общей информационной
модели предметной области, реализуемой в базе данных ДП АСУТП, на не
сколько соответствующих различным требованиям пользователей подмоделей,
8 и выделения из классов атрибутов и методов, необходимых для согласованной
поддержки какого-либо требования или реализации некоторой функциональности, не связанной с описываемой классом абстракцией, за счет чего достигается лучшее структурирование программного комплекса в целом. Особенно эффективно применение аспектно-ориентированныых методов тогда, когда требуется согласованная поддержка некоторого требования в различных классах (в частности, операции управления информационными потоками и обеспечения целостности данных в ООБД, что, вследствие инкапсуляции данных в раздельных объектах, является более насущной проблемой, чем в реляционных базах данных). В диссертации предлагаются модели выделенных аспектов - сервисных процессов ООСУБД, управляемых событиями изменения состояния объектов БД и обеспечивающих контроль и управление информационными потоками.
Исследован характер информационных потоков распределенной АСУТП, зависимость режима поступления информации в РСПД от алгоритма информационного обмена. Рассмотрены составляющие информационного потока и структура пакетов, произведена экспертная вероятностная оценка объема данных, поступающих в РСПД при периодическом опросе изменений и их спонтанной передаче. Для решения задачи синтеза структуры РСПД в работе предложено два эвристических алгоритма, учитывающих специфику направлений информационных потоков в распределенных системах диспетчерского управления предприятий нефтегазового комплекса. Первый из них генерирует начальную структуру сети, исходя из матрицы расстояний между узлами. Второй алгоритм предназначен для итерационной оптимизации полученной структуры с использованием оценок интенсивностей потоков технологических данных в РСПД. Оба алгоритма учитывают ограничение по максимальному количеству транзитных узлов коммутации и требования к обязательному резервированию каналов связи.
При разработке базы данных ДП АСУТП в нефтегазовой промышленности, вследствие типизации производственных участков и схожих характеристик производственного оборудования различных производителей, целесооб-
разно применение методов комбинаторного синтеза. При этом проектирование
информационных потоков и их реализация в отношениях как между объектами БД, так и между БД и внешними системами является трудоемким и требующим автоматизации процессом. Разработаны группы проектных вариантов (ПВ) для каждого из этапов комбинаторного синтеза; также рассмотрено использование ПВ операций над данными. Предложены методы записи правил и ограничений связывания ПВ' и групп сигналов ввода/вывода, которые могут применяться проектировщиками БД ДП АСУТП на этапе структурно-параметрического синтеза.
Новизна исследования заключается в следующем. Во-первых, впервые в российской практике разработки баз данных диспетчерских пунктов были адаптированы и применены методы аспектно-ориентированного программирования для управления информационными потоками и обеспечения целостности данных, что позволило повысить эффективность организации информационного и программного обеспечения ДП АСУТП. Во-вторых, для выполнения задачи комбинаторного синтеза структуры БД ДП АСУТП были разработаны не только проектные варианты сущностей БД, но и проектные варианты операций над данными; также были введены правила их комбинирования. В-третьих, был предложен оригинальный эвристический алгоритм оптимизации начальной структуры РСПД, учитывающий требования по обязательному резервированию каналов связи.
Комплексное рассмотрение процессов передачи информации между распределенными ДП АСУТП, между программными подсистемами одного ДП и между объектами внутри БД ДП позволило выявить универсальность известных алгоритмов взаимодействия клиента и сервера в протоколах передачи данных и предложить эффективную программную реализацию этих алгоритмов для взаимодействия субъектов объектно-иерархических баз данных ДП АСУТП.
Механизмы программного взаимодействия с объектно-ориентированными базами данных
База данных любого элемента АСУТП, и, в частности, диспетчерского пункта, предназначена для хранения информации о состоянии сущностей предметной области. Использование объектно-ориентированной БД (ООБД) дает разработчику преимущества при проектировании: во-первых, возможность инкапсулировать данные о состоянии некоторой сущности ПрО и методы их изменения в объекте-элементе модели данных СУБД; во-вторых, используя систему классов и механизм наследования, можно явно определить метамодель для выражения результатов анализа ПрО и абстрагирования ее понятий в самой структуре данных. Вообще, объектно-ориентированный подход позволяет избежать разнесения информации по множеству отношений, структура которых (особенно при нормализации высоких уровней) мало соответствует структуре предметной области и требует от разработчика программного обеспечения, обрабатывающего данные из этих таблиц, «проектировать свою задачу не в терминах предметной области (самой по себе достаточно сложной), а в терминах огромного числа плоских реляционных таблиц (что может быть на порядок более сложно)» [25]. Рассматривая задачи доступа к БД, выделим две основных: выборка (чтение/запись) данных из существующих структур их хранения и изменение самих этих структур (изменение схемы данных, в терминах РСУБД). Обе эти операции возможно выполнить двумя способами: написав программу, использующую интерфейс прикладного программирования СУБД для манипулирования группами данных и получения их значений (процедурный подход), и используя декларативный язык запросов — написать предложение, которое будет интерпретировано процессором СУБД и на основании которого будет сформирован результат. С одной стороны, для разработчика ИС, использующего объектно-ориентированный язык программирования третьего или четвертого поколения, при первом подходе проявляется достоинство ООБД: возможность непосредственного манипулирования объектами БД средствами используемого языка («Для разработчика, использующего ООСУБД, отсутствует так называемая "проблема импеданса", проявляющаяся в неудобстве перевода описания объекта с языка объектной модели на язык реляционной модели и обратно». [25]) С другой стороны, составление запроса при процедурном подходе фактически означает написание отдельной программы, что приводит к таким отрицательным последствиям, как усиление зависимости алгоритма приложений от заданной структуры данных, необходимость оптимизировать запрос на уровне программного кода (практическая невозможность оптимизации запроса самой СУБД), сложность каждого запроса, его слабая пригодность к автоматической верификации.
Использование декларативного языка запросов позволяет переложить задачи выбора алгоритмов его выполнения и оптимизации на СУБД (что особенно необходимо в системах реального времени), сам запрос записывается с использованием некоторой алгебры, соответствующей модели данных БД. Однако декларативный язык более ограничен, чем универсальный язык программирования, поэтому сейчас вводится требование вычислительной полноты к ООСУБД (см. ниже), что означает поддержку возможности реализовать любую вычислимую функцию с помощью языка манипулирования данными. У задач информационных обменов АСУТП существует своя специфика, влияющая на требования при выборе ООБД для применения в качестве хранилища оперативных данных ДП АСУТП. Мы рассмотрим набор обязательных свойств, которым, согласно «Манифесту систем объектно-ориентированных баз данных» [3] должна удовлетворять ООБД, и настоятельность их поддержки в базах данных систем реального времени.
1. Поддержка сложных объектов: списков, множеств. Для удобства обработки и представления сложных понятий ПрО, помимо указанных конструкций, в АСУТП эффективно использовать древовидные структуры.
2. Идентифицируемость объектов: каждый объект должен иметь свой уникальный идентификатор. Это позволяет проводить упорядочивание объектов методами наименования. Помимо абсолютной адресации, желательна поддержка относительной адресации в иерархических структурах.
3. Инкапсуляция: необходима инкапсуляция и свойств и методов, однако сокрытие значений, за исключением ограничения доступа по категориям поль зователей, не является настоятельным.
4. Типы и классы: необходимы. Тип объекта — это его классификатор. Понятие класса используется для определения множества объектов определенного типа. (Далее в настоящей работе понятие класса используется также и как синоним типа, по принятым соглашениям объектно-ориентированного анализа, проектирования и программирования).
5. Иерархии классов или типов. Иерархия типов отражает результатов анализа и абстрагирования сущностей предметной области. Иерархия (решетка) классов предназначена для упорядочивания множеств объектов. Иерархии типов и иерархии классов не совпадают между собой, но можно говорить о типе класса, т.к. все объекты одного класса имеют один и тот же тип.
6. Перекрытие, перегрузка и позднее связывание: необходимы.
7. Вычислительная полнота. Не является необходимой для специализированных ООСУБД, особенно используемых на "нижнем уровне" АСУТП (в контроллерах и встраиваемых системах).
8. Расширяемость: возможность введения новых типов данных важна при адаптации системы к новой ПрО, не используется при тиражировании.
Разработка информационной модели с использованием объектно-ориентированных методов
При анализе предметной области автоматизированного производства мы выделяем два абстрактных базовых класса: Object и Signal; Объект — это или реальное средство производства, автоматизации и т.п., или сущность условного технологического и прочих способов деления автоматизируемого производства. Сигнал - абстрактная группа данных, предназначенная для хранения значения измеряемой величины и связанных с ней атрибутов. Мы не рассматриваем в качестве самостоятельного класса "ячейку хранения данных" или "число", которое могло бы являться базовым классом с производными "целое число", "число с плавающей точкой" и т.п., поскольку это стандартные типы данных, предоставляемые любой СУБД или языком программирования, так же как и такие элементы, как массивы, строки и прочее
Отношения между классами Object и Signal показаны на диаграмме.
Объект может включать произвольное количество сигналов или других объектов, при этом мы задаем ограничение на то, что сигнал или объект могут быть включены только в один объект. Это обеспечивает иерархическую струк 54 туру и исключает возможность создания сетевых структур. В ассоциации между классами Object и Signal используется композиция - агрегирование по значению, т.е. Object включает в себя один или несколько объектов - экземпляров класса Signal или производных от него. При связывании двух объектов используется агрегирование по ссылке. Т.о. структура базы данных образуется множеством экземпляров класса Object и производных от него, независимо размещаемых в памяти. Производные классы используют отношение «специализация/обобщение»; наследуя структуру и поведение базовых, они специфически расширяют их сообразно своей роли в системе. Мы выделяем три производных от Object класса: Область (Field), Устройство (Facility), ЛинияСвязи (CommLine). Первый вводится для описания некоторого участка производства, второй - для представления в БД моделей: технологического или контрольно-измерительного оборудования, конструктивно содержащего в себе датчики, третий - для линий связи всех типов, которые не содержат в себе средств самодиагностики, но для которых вводится понятие состояния, рассчитываемого по показаниям других устройств. Производные от Signal классы могут уточнять тип сигнала, например можно создать классы AnalogSignal, DigitalSignal, LogicalSignal и др. или вводить поддержку дополнительных свойств: так, TimestampSignal - класс, добавляющий атрибут - метку времени произошедшего события и связанные методы.
При использовании абстракций поведения требуется выделить типовые элементарные действия. Мы выделяем два таких действия, выполняемые над данными, несводимые к более примитивным; классифицирующим признаком является количество входных и выходных значений. Это — Multiplexer (по нескольким входным значениям формирует несколько выходных) и Demultiplexer (обратно, по одному входному значению вычисляет несколько выходных). Вычислительные модули, преобразующие один входной сигнал по формуле в выходной, мы рассматриваем как производные от Multiplexer (рассматривая коэффициенты формул как род входных значений).
На диаграмме эти классы отображаются как классы-ассоциации. Моделировать связь между входным и выходным сигналами с помощью двух ассоциаций (напр., пары Signal-Multiplexer и Multiplexer-Signal) было бы неправильно, поскольку таким образом нельзя передать связь конкретного экземпляра объекта Multiplexer с конкретной парой множеств входных и выходных классов Signal (ассоциация показывает количество и роль сигналов).
Еще один класс, реализующий простейшее оригинальное действие — это таймер (Timer). Он содержит методы запуска/останова и атрибут — интервал срабатывания. Таймер реализует механизм «обратного вызова» и также содержит в себе указатель на метод какого-либо класса, вызов которого происходит при «срабатывании».
Одно из основных преимуществ применения объектно-ориентированных методов анализа и проектирования заключается в возможности повторного использования проектных решений [10,72], т.е. поддержке их типизации и обобщения. Тогда, средством записи типового проектного решения будет являться шаблон или образец проектирования (в русскоязычной литературе одинаково широко используются оба термина - перевода англ. pattern). Согласно определению, «шаблон - типичное решение типичной проблемы в данном контексте» [11]. П. Коуд также вводит понятие стратегии: «плана действий, предназначенного для достижения конкретной цели» [28]. В 90-е годы разработка универ 56 сальных шаблонов является одной из наиболее важных областей развития объектно-ориентированного анализа и проектирования, по результатам исследований предложены цельные системы шаблонов [28,32,53,65,74,75].
Разработка информационной модели с использованием аспектно-ориентированных методов
Как отмечают авторы [92], в то время как существует поддерживающий АО-концепции язык программирования AspectJ, отсутствует реализованный (язык моделирования, поддерживающий проектирование AspectJ-программ. Предложениям по разработке подобного языка посвящено большое количество работ, представленных на различных конференциях в 1998-2002 гг. Подавляющее большинство исследователей предлагают основываться на существующем стандарте UML [11] и применить существующие в нем механизмы расширения графической нотации сущностей и отношений (стереотипы, ограничения, помеченные значения) для описания дополнительных концепций АО-проектирования.
Так, в работе [88] предлагается ввести три новых концепции: группы (для целей классификации гетерогенных и распределенных сущностей), пересекающие отношения (позволяющие программисту определить "точки пересечения" аспекта с функциональной программой), аспектные классы (реализующие расширения программы в точках пересечения). Графически это предполагает использование имеющихся в UML элементов: классов и ассоциаций с добавлением стереотипов «group», «pointcut», «aspect». Для методов аспектного класса вводятся стереотипы «before», «after», «around», описывающие момент их вызова по отношению к вызову "пересекаемых" функций, а также предлагается набор правил определения и интерпретации семантики ролей и кратностей для пересекающих отношений,
В [81] рассматривается выделение аспектов в программной системе. Примеры диаграмм в этой работе похожи на приводимые в [88]: аспект рассматривается как диспетчер взаимодействия двух взаимозависимых классов и других, предоставляющих некоторую функциональность. Но, в отличие от [88], в модель явно вводится понятие "точки пересечения", которую предлагается моделировать как вариант класса, а не как вариант ассоциации, более подробно рас 65 смотрены "точки соединения" - места взаимодействия с аспектом, прерывания/возобновления выполнения основной программы. «Точки соединения могут быть объединены для построения интерфейса аспекта, также как множество интерфейсов в UML могут быть объединены в форму интерфейса класса». Вводится понятие парных (conjugated) точек соединения, в которых происходит вызов методов с одинаковыми сигнатурами, но направления потока управления противоположны (в которых управление передается аспекту и возвращается им).
С. Кларк и Р. Уолкер предлагают свой вариант нотации [69] для описания аспектов средствами UML. Они предлагают использовать параметризируемые пакеты (что само по себе является непредусмотренным расширением UML) со стереотипом «subject», поскольку в принципе рассматривают аспекты как элементы субъектно-ориентированного проекта. Внутри пакета могут быть размещены диаграммы классов и взаимодействия, что позволяет графически показать поведение программы после связывания. Такой пакет является в терминологии авторов "композиционным шаблоном". При этом, «параметризируя проектный субъект и обеспечивая механизм для привязки этих параметров к элементам модели в других проектных субъектах, мы можем определить композицию пересекающего поведения с основным проектом способом, допускающим повторное использование». Предлагаемая семантика (отношение композиции, расширяемое строкой bind) оперирует классами и методами связываемых субъектов.
В [92] авторы рассматривают моделирование «пересекающих эффектов» отдельно в структуре типов и в поведении некоторой системы. Оригинальность их подхода заключается в предложении использовать параметризируемые, помеченные стереотипом «introduction» кооперации для определении свойств (атрибутов, операций) и отношений каждого из "пересечений" аспектных и обычных классов. Параметр кооперации используется для определения правил связывания (фактически - инстанцирования кооперации и ее встраивания в существующую систему классов). Помимо этих коопераций, в аспектных классах вводятся, независимо от методов, элементы со стереотипами «pointcut» и «advice»: "точки пересечения" и "извещения", определяющие пересечение логики аспекта и программной системы, и вводящие механизм перехвата управления. Предложенная нотация базируется на концепциях языка AspectJ, но является излишне усложненной.
Разработчики UML указывают, что «На практике для именования класса используют одно или несколько коротких существительных, взятых из словаря моделируемой системы» [11]. Аналогично, в большинстве рассмотренных работ имя аспектного класса является наречием и показывает выполняемую операцию.
Помимо рассмотренных выше четырех работ, предлагающих проработанные, готовые к практическому применению графические нотации, доступно большое количество статей теоретической направленности. Так, в [59] делается попытка формализовать использование средств расширений UML для специфицирования понятий АО-методологии. Для этого используется понятие "профиля" UML - механизма, позволяющего описать правила использования средств расширения языка в некоторой предметной области. Расширяя метамо-дель UML, авторы определяют набор стереотипов и их приложение к таким элементам метамодели, как класс и ассоциация. Авторы [93] также предлагают расширить метамодель UML для описания аспектных классов и отношений, но основной акцент сделан на предложении основанного на правилах XML языка разметки для описания проектных моделей, в частности, содержащих аспекты. Выгоды его введения обосновываются необходимостью наличия «нейтрального по отношению к приложениям формата» для коммуникации между разработчиками, облегчением повторного использования описаний аспектов, а также их разделением между различными средствами проектирования, связывания, кодо генерации. Комплексным подходом отличается статья известных разработчиков из IBM У. Харрисона, П. Терра и Г. Оссхера [78], в которой они рассматривают способы, какими информация об аспектах может быть отражена на различных диаграммах UML. Здесь же следует упомянуть работы С. Кларк [67,68], в которых она «представляет подход к разработке систем, базирующийся на объектно-ориентированной модели, но расширяющий ее добавлением новых возможностей декомпозиции». В докладе [79] представлен прототип автоматизированного средства для преобразования высокоуровневых моделей UML, поддерживающих абстракции АОП, к низкоуровневым детализированным моделям, по которым может быть сгенерирован программный код, т.е. предложено проводить связывание на уровне моделей.
Далее при составлении диаграмм мы будем придерживаться нотации, предложенной в [88].
Простейший случай использования аспекта — реализация некоторого функционального требования, необходимого разным (не имеющим общего базового) классам. В этом случае аспект становится похож на статический класс-утилиту (utility class), с более четко формализованным в проекте правилом его использования.
Оптимизация структуры сети передачи данных
Вторым этапом синтеза топологической структуры РСПД является проведение оптимизации полученной начальной структуры. Мы предлагаем эвристический алгоритм, относящийся к классу "жадных" алгоритмов, в котором «глобальная оптимизация целевой функции заменяется оптимизацией на каждом шаге алгоритма» [44]. Подобные алгоритмы широко используются при решении различных задач дискретного программирования (размещения [6], коммивояжера и др.), вследствие их существенно меньших требований к вычислительным ресурсам и трудоемкости реализации, чем алгоритмы нахождения точного решения, и достаточной эффективности при учете специфики условий каждой конкретной задачи.
В построенной начальной структуре РСПД для каждого потока сообщений, задаваемого матрицей [Я], существует минимум два маршрута доставки сообщений, каждый из которых при этом проходит не более чем через один промежуточный УК. Мы предлагаем алгоритм (см. рис. 22), в котором циклически, за N-2 повторения (блоки 3-11) рассматриваем группы из трех узлов РСПД: двух соседних локальных ДП щ и я)+/, / = 2,.„,N-l и ЦДЛ (а/), и определяем, безотносительно к остальной части РСПД, наиболее целесообразную конфигурацию КСв между ними, проводя операции замены и исключения КСв, с сохранением заданных выше ограничений.
Так, изначально эти три узла соединены КСв как показано на рис. 23а. Существует три других варианта их соединения с сохранением ограничений (см. рис. 236, 23в, 23г). На первом шаге алгоритма (блоки 4,5) мы включаем в множество допустимых вариантов (МДВ) эти четыре варианта.
МДВ может быть сужен: в случае, если узел or,- связан не только с а} и ai+I, то мы исключаем из рассмотрения вариант (в), т.к. при нем число промежуточных УК между а І и другими связанными с ним узлами будет больше одного (блоки 7,8).
После формирования МДВ для оценки сравнительной эффективности этих вариантов необходимо, используя оценку интенсивности информационных потоков, рассчитать значения функции (3.1) для каждого из вариантов соединения рассматриваемых трех УК каналами связи и выбрать оптимальный (блоки 9,10).
На каждой из итераций алгоритма, кроме первой, в зависимости от количества введенных на предыдущем шаге КСв между УК а/ и я/+; (который становится УК аг) мы включаем в МДВ модифицированные варианты (см. рис. 24) вместо первоначальных по правилу, изложенному в табл. 3. (Если на предыдущей итерации не было введено ни одного КСв между а\ и я,+/, то в МДВ включаются исходные варианты (а), (б), (в), (г)). Вариант (в) всегда включается в неизменном виде и также может быть исключен (блоки 7,8).
Выполняемая оптимизация объема передаваемых от локального ЛП в ЦДЛ технологических данных за счет алгоритмов периодической и спонтанной передачи изменений, а также оптимизация структуры РСПД - физических путей передачи этих данных - являются необходимыми этапами при строительстве РСПД территориально распределенных многоуровневых систем диспетчерского управления в составе АСУТП промышленных предприятий нефтегазовой промышленности. За счет их выполнения сокращаются капитальные затраты на систему в целом, в т.ч. за счет снижения требований к производительности вычислительного и сетевого оборудования. Также становится возможным развертывание современной системы диспетчерского управления при сохранении существующих низкоскоростных аналоговых линий связи тональной частоты.
