CC BY
45
Результаты параметрической идентификации теплового потока и коэффициента теплопроводности для ПТП-1 при Дт =0,01 с представлены на рис. 2. Результаты расчетов для ПТП-2 при Дт =0,01 с и уровне шумов в измерениях а =0,05 °С представлены на рис. 3. Результаты для ПТП-3 при Дт =0,001 с представлены на рис. 4.
Как видно из рис. 2-4, во всех случаях наблюдалась устойчивая сходимость процедуры идентификации: в результате тепловые потоки и коэффициент теплопроводности хорошо уточняются уже на первом участке сплайн-аппроксимации (рис. 2), либо на третьем (рис. 3), либо на 30-м (рис. 4).
Заключение
В работе описаны математические модели (ММ) линейного и нелинейного тепло-переноса в ПТП на основе ДРМ. Предложен метод рекуррентной последовательной линеаризации для решения ПЗТ на основе таких ММ.
Составлена стратегия оценивания для одновременного восстановления теплового потока и теплопроводности на основе метода параметрической идентификации. Адаптирован и реализован в форме программы на языке БсПаЬ нелинейный ФК по искомым параметрам для получения вышеперечисленных оценок.
Математическим моделированием доказана эффективность разработанных алгоритмов параметрической идентификации и показана их практическая применимость при экспериментально-расчетном определении тепловых потоков и теплопроводности.
Литература
1. Пилипенко Н.В. Методы параметрической идентификации в нестационарной теп-лометрии (ч. 1) //Изв. вузов. Приборостроение. - 2003. - № 8. - С. 50-54.
2. Пилипенко Н.В. Методы параметрической идентификации в нестационарной теп-лометрии (ч. 2) //Изв. вузов. Приборостроение. - 2003. - № 10. - С. 67-71.
Кириллов Кирилл Валерьевич — Санкт-Петербургский государственный универ-
ситет информационных технологий, механики и оптики, аспирант, [email protected]
Пилипенко Николай Васильевич — Санкт-Петербургский государственный универ-
ситет информационных технологий, механики и оптики, кандидат технических наук, доцент, [email protected]
УДК 004.4'22
СИСТЕМА КОДОГЕНЕРАЦИИ ТНОЯ^БО И ЕЕ ИСПОЛЬЗОВАНИЕ ДЛЯ СОЗДАНИЯ БИЗНЕС-ПРИЛОЖЕНИЙ
Д.В. Деев, Ю.С. Окуловский, В.Ю. Попов, В.П. Часовских
Описана система порождающего программирования Thornado, основанная на использовании языков разметки, скриптовых языков и объектно-ориентированного программирования. Приведен пример использования этой системы для создания бизнес-приложений. Исследованы вопросы организации разработки программного обеспечения с применением этой системы.
Ключевые слова: разработка программного обеспечения, порождающее программирование, кодогенерация.
Введение
В теории информации традиционно выделяются два основных объекта - поток данных и поток команд. Исторически считалось, что поток команд является основным,
а поток данных - вспомогательным. С развитием технологий программирования взаимодействие между данными и командами становилось сложнее. Кроме того, появился новый объект - поток спецификации, описывающий команды и данные. Согласно современному взгляду на программирование, этот поток является основным.
Широко распространены три подхода к взаимодействию программы и спецификации: порождение спецификации для существующей программы; проверка соответствия программы спецификации (верификация, [1]); порождение программы по спецификации (порождающее программирование [2]). Третий подход является на сегодняшний день наиболее обсуждаемым и изучаемым.
В случае порождающего программирования система принимает спецификацию на некотором формальном языке и генерирует исходный код приложения, заранее удовлетворяющий спецификации. На сегодняшний день существует множество систем порождающего программирования. Например, это Windows Forms Designer [3], входящий в стандартную поставку Microsoft Visual Studio, который позволяет порождать исходный код графического интерфейса пользователя по визуальному описанию. Более сложным примером является IBM RAD [4], способный сгенерировать исходный код бизнес-приложения. Кроме того, существует множество небольших кодогенераторов, разрабатываемых внутри предприятий для отдельных проектов. Все эти решения обычно имеют некоторые общие недостатки. Так, кодогенераторы обычно созданы для генерирования конкретного типа кода. Вследствие этого идеи, применяемые для генерирования бизнес-приложений, не могут быть непосредственно перенесены на генерирование, например, синтаксических анализаторов. Архитектура генераторов часто не предполагает их расширения, вследствие чего генератор не может быть скорректирован для более полного соответствия разрабатываемому проекту. Далее, спецификация, используемая для генерирования кода, не может быть интерпретирована вне генератора. Из-за этого проблема документирования кода не решена, и вместе с формальной спецификацией для генератора приходится писать также спецификацию на естественном языке. Наконец, часто сгенерированный код не может быть исправлен вручную, так как изменения будут либо потеряны после повторной генерации, либо сделают генератор неработоспособным. Для больших и сложных систем возникает также проблема большой цены использования, связанная с высокой ценой продукта и высокими затратами на дополнительное обучение сотрудников.
В данной статье описывается разрабатываемая система Thornado. Эта система предполагается свободной от приведенных недостатков. Система основывается на хорошо известных технологиях языков разметок, скриптовых языков и объектно-ориентированных технологий. Поэтому работа с системой не требует существенного дополнительного обучения программистов. Система Thornado является расширяемой и может быть приспособлена для нужд конкретного проекта. Кроме того, разработана технология расширения функциональности сгенерированного кода, которая не конфликтует с кодогенератором. С помощью Thornado возможно генерирование кода приложения любого типа и на любом языке программирования. Наконец, документы, используемые системой для генерации кода, могут быть преобразованы в спецификацию кода на естественном языке. В первой части приводятся общие принципы работы этой системы. Во второй части описывается применение системы Thornado для генерирования бизнес-приложений.
Общие принципы
Система кодогенерации Thornado строится на использовании трех технологий программирования: языков разметки, скриптовых языков и объектно-ориентированного программирования. На языке разметки происходит составление спецификации про-
граммного кода, который должен быть сгенерирован. Затем при помощи скриптовых языков эта спецификация транслируется в исходный код программы. Использование принципов объектно-ориентированного программирования позволяет расширять функциональность сгенерированного кода и встраивать его в приложения.
Язык Thorn
В качестве специального языка разметки для порождающего программирования использован язык Thorn (ранее TH, [5, 6]). Документ Thorn состоит из команд, вложенных одна в другую. Общее представление о синтаксисе языка Thorn дает следующий пример.
\table[border=1 width=100%] { \tr{ \td{a11} \td{a12} }
\tr{ \td{a21} \td{a22} } }
Приведенный документ Thorn в некотором смысле эквивалентен следующему документу HTML:
<table border-'Г' width="100%"> <td> <td>a11</td> <td>a12</td> </tr> <td> <td>a21</td> <td>a22</td> </tr> </table>
В отличие от HTML, синтаксис Thorn может быть существенно сокращен при помощи нескольких правил. Для каждой команды определена последовательность параметров (параметрами являются border и width в примере), и, если значения параметров следуют этой последовательности, то имена параметров могут быть опущены. Кроме того, для команды можно определить естественное вложение: например, для команды tr естественно находиться внутри команды table, а для команды td - внутри tr. Если команды вложены в естественном порядке, то фигурные скобки также могут быть опущены. Используя эти возможности сокращения, документ из примера может быть представлен в следующем виде. \table[1 100%] \tr \td a11 \td a12 \tr \td a21 \td a22
Основное различие между языком Thorn и другими распространенными языками разметки обеспечивается компилятором. Каждая команда ассоциируется с некоторой программой, которая может быть написана на любом языке программирования (как правило, используется Perl). При разборе текста компилятор собирает все текстовые данные, связанные с командой. После этого он запускает ассоциированную программу, передавая ей текстовые данные как входные параметры. Программа возвращает строку, которая подставляется на место команды. После того, как все команды выполнены, трансляция документа завершается. Программы могут обмениваться между собой данными через глобальные переменные.
Программы, ассоциированные с командами, сохраняются в библиотеках, которые отделены от документа Thorn. Один и тот же документ Thorn может быть транслирован разными библиотеками, т.е. с различным значением команд. Например, различные библиотеки могут производить код для разных языков программирования. Кроме того, может быть создана специальная библиотека, транслирующая документ Thorn в спецификацию на естественном языке.
Также Thorn является расширяемым языком за счет независимости библиотек. Допустим, мы используем библиотеку A для генерирования кода, и команды из A работают с некоторыми глобальными переменными. Предположим, что требуется породить новый код, который невозможен для библиотеки А. Мы можем написать библиотеку В,
которая использует глобальные переменные, определяемые командами из А. Таким образом, нет необходимости переписывать эти переменные. Кроме того, библиотека А может по-прежнему работать без библиотеки В. Подобная идеология позволяет создавать «диалекты» имеющихся больших библиотек для каждого проекта.
Язык Thorn с набором библиотек можно рассматривать как domain-specific language (DSL) [7]. Фактически, мы создаем DSL для наиболее распространенных типов кода -пользовательских интерфейсов, сохранения данных в файлах и базах данных и т.д. В нашем случае все DSL основаны на одной и той же технологии, что позволяет объединять данные из документов, написанных на различных DSL.
Скрипты для создания кода
В этом параграфе мы опишем преобразование документа Thorn в программный код. Рассмотрим следующий документ Thorn. \property[int Count] {Count of elements}
Предположим, он должен быть трансформирован в следующий программный код: ///<summary>Count of elements</summary> int count;
///<summary>Count of elements</summary> public int Count
{ get { return count; } set { count=value; } }
В этом случае команда property принимает три параметра: тип свойства, его имя и описание. Скрипт, который преобразует эти данные в выходную строку, очевиден. Однако решение, когда каждая команда создает часть программного кода, не всегда удобно. К примеру, если несколько команд используют один и тот же параметр, он должен быть написан в каждой из команд. Эта проблема решается с помощью глобальных переменных. Другая проблема состоит в том, что при большом количестве параметров команды трудно запомнить их наизусть, и это замедляет набор документа с клавиатуры. В этом случае команду следует разложить в набор других команд.
Мы видим, что необходим выбор оптимальной архитектуры команд. По нашим наблюдениям, описание с помощью многомерных отношений наиболее подходит для порождающего программирования. Отношение в данном случае есть набор записей; в каждой записи определены некоторые поля. Отношение может задаваться матрицей, в которой строки соответствуют записям, а столбцы - полям. В большинстве случаев генератор, транслирующий описание отношения в программный код, представим в виде следующей функции:
' gl(fl( 4),f1(A2),..., fl( Am )) ^
, g2(f2(A1), f2 (A2 f2(Am ))
p( A) = h
V gn (fn (AX fn (ЛХ.- fn (Am )))
Здесь h производит программный код. При генерации объектно-ориентированных программ h производит один класс. Функции g1,..., gn производят
части кода, обычно методы внутри класса. Функции fl,... , fn производят части метода, соответствующие одной записи отношения. A1,...,Am являются строками матрицы отношения. Часто g1,.., gn являются функциями конкатенации, т.е. g(х1,..., xm) = x1 •... • xm, где точка обозначает конкатенацию строк. Функция h часто может быть представлена в следующем виде: h(x1,..., xm) = a0 • x1 • a1 •... • xn • an, где
a0,..., a - константы.
Генераторы, представимые таким образом, будем называть функциональными. Этот подход к генераторам реализован в специальном модуле Perl. Функции этого модуля позволяют транслировать документ Thorn в отношение, записанное в глобальных переменных, и затем определять функциональные генераторы для преобразования этого отношения в программный код. Этот модуль заметно облегчает разработку кодогенераторов.
Описанная архитектура кодогенератора часто оказывается достаточной, однако бывают случаи, когда необходима полная функциональность языков Thorn и Perl. Так, если одна запись может воздействовать на код, сгенерированный для другой записи, то функциональный генератор оказывается неспособным обработать эту ситуацию. Другой пример - описание пользовательских меню. Пользовательское меню является деревом, и естественно описывать его именно как дерево, а не отношение.
Расширение функциональности
Одной из главных проблем многих существующих систем порождающего программирования является расширение функциональности сгенерированного кода. Любая корректировка кода будет потеряна после повторной генерации, поэтому для расширения функциональности требуется использовать другие методы. В объектно-ориентированном программировании это возможно за счет использования цепочек наследования.
В цепочке наследования каждый класс наследует предыдущий. Типичная структура цепочки следующая. Первый класс является шаблоном, определяющим некоторые абстрактные и виртуальные методы. Второй класс генерируется автоматически, он перегружает эти методы и заполняет их основной функциональностью. Третий класс является классом доводки. Он пишется вручную и содержит всю функциональность, которую не может обеспечить генератор. Класс доводки также перегружает виртуальные методы, но вызывает их из базового класса для использования функциональности сгенерированного кода. Благодаря этой схеме сгенерированный код и код, написанный вручную, находятся в разных файлах и не влияют друг на друга.
В более сложных случаях возможны дополнительные классы в цепочках наследования. Пусть генератор A производит код, а генератор B производит класс доводки. Эти генераторы не могут быть объединены, потому что A может выполняться и без участия B. В этом случае B генерирует третий класс в цепочке наследования, а четвертый класс в этой цепочке содержит усовершенствования, которые не может обеспечить B.
Разработка бизнес-приложений
Под бизнес-приложением мы понимаем программу, которая:
- собирает данные о бизнес-процессе у сотрудников и хранит их в базе данных;
- обрабатывает данные из базы данных и производит отчеты и документы;
- выполняет расчеты для оптимизации бизнес-процесса.
Хорошо известны крупные бизнес-приложения, такие как 1С. Однако покупка и в особенности адаптация подобных приложений к конкретному бизнес-процессу могут оказаться слишком затратными. Поэтому часто выбирается путь написания бизнес-приложения под нужды конкретного предприятия. При этом бизнес-приложения имеют схожую структуру, что позволяет использовать для их написания порождающее программирование.
При разработке системы кодогенерации для создания бизнес-приложений мы руководствовались следующими принципами.
1) Система кодогенерации порождает не все приложение, но типовые, достаточно большие его части.
2) Система кодогенерации должна оставаться простой и компактной.
3) Разработка спецификаций для кодогенераторов не должна требовать квалификации программиста.
Первое условие связано с тем, что написание спецификации для, например, алгоритмов оптимизации бизнес-процесса требует существенной выразительной возможности языка спецификации. Это приводит к неоправданному усложнению кодогенератора, поскольку становится проще написать исходный код на существующем языке программирования, чем разработать и освоить фактически новый язык. Второе условие связано с тем, что желательно создание простого ядра кодогенератора, подходящего для типичной функциональности приложения. Для обеспечения специфической функциональности не следует усложнять базовый кодогенератор. Вместо этого лучше использовать расширение функциональности сгенерированного кода методом цепочек наследования или разработать диалект кодогенератора для конкретного программного продукта. Наконец, третье требование обусловлено тем, что составление спецификации происходит в процессе ознакомления с бизнес-процессами предприятия. Желательно, чтобы это ознакомление осуществлялось не программистом, а специалистом в области бизнес-процессов, который обычно не имеет квалификации программиста.
В качестве языка программирования был выбран язык C# [8]. Однако система ко-догенерации может быть переведена на любой другой язык программирования в случае необходимости.
В соответствии с приведенными принципами были разработаны кодогенераторы для трех типичных подсистем бизнес-приложений: подсистемы ввода и хранения данных, подсистемы вывода документов и подсистемы пользовательского меню.
Подсистема ввода данных
Для примера рассмотрим описание данных сотрудника некоторой фирмы. Это описание состоит из перечисления полей, для каждого поля определены некоторые свойства. Описание поля имеет следующий формат: \йеЫ[<тип поля> <имя поля>] \desc <описание> \default <значение по умолчанию> \io <объект ввода-вывода> \gui <тип GUI>
Соответственно, структура данных определяется последовательностью описания полей:
\dataSet \field[string FIO]
\desc Фамилия, Имя, Отчество \field[DateTime Birthdate]
\field[double Salary]
На основании такого описания генерируются структуры данных. Так, генерируется класс Employee, поля и свойства которого соответствуют полям описания данных следующим образом.
- Тип поля и свойства класса определяются значением <тип поля>.
- Имя поля класса является значением <имя поля>, переведенным в нижний регистр.
- Имя свойства совпадает с <имя поля>.
- В конструкторе класса полю присваивается <значение по умолчанию>.
- Комментарий к полю определяется значением <описание>.
Помимо этого, дополнительные команды Thorn позволяют настроить модификаторы доступа, наличие в свойстве геттера и сеттера и т.д.
Кроме класса Employee, может быть сгенерирован класс EmployeeArray, являющийся коллекцией объектов типа Employee. Возможны различные модификации этой коллекции: заполнение ее предопределенными объектами в конструкторе, ограничение доступа к методам добавления и удаления элементов и т. д.
После генерации структур данных можно обеспечить их методами ввода и вывода в источники данных - системный реестр, файлы или SQL-базы данных. Для этого в основном используется ассоциированный с полем объект ввода-вывода, который специфицирован в примере командой \io. Этот объект обеспечивает перевод поля в текстовый вид и восстановление поля из текстового вида.
В платформе .NET каждый класс определяет метод ToString, переводящий объект в строку, а большинство встроенных типов имеют статический метод Parse, восстанавливающий объект из строки. Поэтому во многих случаях функциональность объекта ввода-вывода тривиальна. Однако введение объекта ввода-вывода может обеспечить различное представление поля для, например, файлов и базы данных. Кроме того, с помощью объектов ввода-вывода можно сохранять массивы, объекты пользовательского интерфейса и другие объекты, приведение которых в строковый тип не обеспечено платформой.
Для сохранения объекта Employee создается класс EmployeeTextlO. Его статические методы принимают объект Employee и генерируют файл вида
[Employee]
ТЮ=Иванов Иван Иванович
Birthdate=01.01.1981
Аналогично генерируется класс EmployeeRegistrylO, который создает ветвь системного реестра Windows, ключи которого хранят информацию об объекте. Также может быть сгенерирован класс EmployeeSqllO. Этот класс обеспечивает получение списка EmployeeArray из базы данных, обновление строки, соответствующей некоторому объекту Employee, и т. д.
Рассмотрим генерирование пользовательского интерфейса для ввода и вывода сгенерированных структур данных. Под пользовательским интерфейсом мы понимаем форму, содержащую элементы управления, заполнение которых данными позволяет полностью описать объект структуры данных. В полной формулировке проблемы форма должна ассоциировать с полями стандартные элементы управления - текстовые поля, выпадающие списки, флажки и т.д. Эта задача не была решена полностью, хотя некоторые подходы рассмотрены в [9]. Нами была решена эта проблема в более узкой формулировке. Все интерфейсы ввода вывода имеют табличную форму. Так, может быть сгенерирована «вертикальная» таблица, позволяющая описать один объект. В этой таблице два столбца, в первом столбце перечислены описания полей, а во втором - значения. Определение <тип GUI> указывает, каким образом происходит ввод значения поля - например, вводом текста, выбором из выпадающего списка и т.д. Восстановление значения поля из строкового представления осуществляется с помощью объекта ввода-вывода.
Кроме «вертикальных», возможны также горизонтальные таблицы, где поля расположены в столбцах, а объекты - в строках. Такие таблицы позволяют редактировать массивы объектов.
Кроме простых интерфейсов пользователя, возможны также составные интерфейсы, например:
- переключающиеся вкладки, где на каждой из вкладок расположена таблица. Такой интерфейс позволяет одновременно определять несколько объектов. Это используется, например, при создании диалогового окна настроек;
- управляющий компонент списка, содержащий объекты. При выборе объекта его поля загружаются в таблицу с возможностью редактирования.
В составных интерфейсах используется интерфейс страниц данных. Страница данных - это управляющий компонент, который позволяет считывать значения полей из объекта, записывать введенные значения в структуру данных, проверять корректность введенных данных, проверять наличие изменений и т. д. Все генерируемые таблицы являются страницами данных, что позволяет объединять их в сложные интерфейсы. Более того, каждый сложный интерфейс сам является страницей данных, что позволяет, например, встроить переключающиеся вкладки в окно с компонентом списка.
Табличные интерфейсы также имеют преимущества перед обычными при создании автоматизированных рабочих мест. Пусть к данным одной и той же таблицы обращается несколько сотрудников, но одни сотрудники имеют доступ к полю Birthdate, а другие - к полю Salary. Поле FIO все могут просматривать, но не могут редактировать. Пусть EmployeeTable - класс сгенерированной таблицы для сотрудников. Из него выводятся дополнительные классы EmployeeTableForDate и EmployeeTableForSalary. В первой таблице скрывается строка, соответствующая Salary, во второй - строка, соответствующая Birthdate. Поле FIO запрещается для редактирования в обеих. Таким образом, коррекция кода с использованием цепочек наследования способна определить уровни доступа к данным.
Для объединения данных нескольких структур в одном интерфейсе используются структуры данных, которые описывают все необходимые поля. В случае SQL таблиц, такая структура загружает данные из представления SQL.
Подсистема вывода документов
Подсистема вывода документов обеспечивает создание приказов, договоров, приложений, актов и других документов сопровождения бизнес-процесса. Подсистема вывода документов имеет свои особенности. Так, формат документов часто меняется в связи с изменениями законодательства. Кроме того, документы обычно имеют достаточно громоздкий вид, если они оформлены, например, в формате HTML. Соответственно, такой же вид имеет исходный код подсистемы. Наконец, верстка требует скорее навыков верстальщика, чем программиста, поэтому необходимо обеспечить возможность совместной работы как минимум двух специалистов.
Поэтому код подсистемы желательно изолировать от других исходных кодов программы. Следует также запретить его ручную правку, но обеспечить возможность быстро заменять исходный код в случае изменение формата документов.
Подсистема вывода документов формируется непосредственно из образцов документа, предоставленных заказчиком. Подобные документы обычно содержат множество недостатков в форматировании: выполненное пробелами центрирование, различные начертания и размеры шрифтов и т.д. В первую очередь требуется обеспечить документам стандартное форматирование. Для оформления документов стандартом является ГОСТ Р6.30-2003 [10].
В качестве языка форматирования документов был выбран язык HTML 4.01 [11]. Все необходимые способы форматирования могут быть выражены на этом языке. Документы HTML 4.01 также открываются большинством современных текстовых редакторов - Microsoft Word, Open Office, и др. Для упрощения ввода документов HTML 4.01 используется язык Thorn. Для обеспечения стандартного форматирования создана библиотека CSS-стилей, а также набор шаблонных команд Thorn, вставляющих распространенные штампы - например, штамп даты.
После стандартизации форматирования документа он перерабатывается в шаблон. Все участки документа, которые являются переменными, заменяются специальными последовательностями символов, например:
- последовательность $Name$ обозначает, что на ее место будет подставлена строковая переменная Name;
- последовательность $!Name$<текст>$ обозначает, что на ее место будет подставлен <текст>, если булева переменная Name истинна.
Текстовая переменная может иметь сложную структуру. Пусть в документ вставляется таблица с переменным числом строк. Тогда вставляемая переменная (внутренность таблицы) должна быть конкатенацией строк таблицы, а каждая строка сама по себе является шаблоном. В этом случае создается один шаблон для документа, содержащего таблицу, и второй - для строки таблицы.
После создания шаблона создается описание всех используемых в шаблоне переменных. Это описание составляется на языке Thorn и определяет описания переменных на естественном языке, их допустимые значения и т. д. После этого специальная библиотека команд Thorn создает исходный код классов, статические методы которых производят документы. Эти классы добавляются в проект и вызываются из программы.
Такой подход позволяет распределить обязанности между всеми участниками разработки подсистемы вывода документов. Менеджер проекта анализирует документы заказчика, выделяет переменные и описывает их на языке Thorn. Верстальщик обеспечивает правильное форматирование документа. На основании их работы генерируются модули вывода документов, которые затем используются программистами.
Подсистема пользовательского меню
Третьей важной подсистемой бизнес-приложения является подсистема пользовательского меню. Эта система дублируется в приложении в следующих пользовательских интерфейсах:
- главное меню программы;
- контекстное меню окна;
- панель инструментов, содержащая графическую репрезентацию команд меню.
Разработанная нами система библиотек позволяет описать единую структуру меню в виде дерева или леса (набора непересекающихся деревьев). Для каждого пункта меню указывается название, заголовок, иконка, горячая клавиша и так далее. По этим описаниям для любого набора узлов может быть сгенерировано контекстное меню, панель инструментов, главное меню, а также вспомогательные интерфейсы, которые позволяют автоматически соединить меню с обработчиками команд.
Организация разработки бизнес-приложения
Использование системы Thornado позволяет внедрить профессиональную схему разработки бизнес-приложений даже при работе в небольших коллективах над небольшими проектами. В разработке приложений принимают участие следующие специалисты: программист шаблонов, программист приложения, верстальщик и менеджер по работе с заказчиком.
Программист шаблонов разрабатывает новые шаблоны и стереотипные библиотеки Thornado, не занимаясь отдельными приложениями. Он должен являться программистом высокой квалификации. Он может также выполнять функции программиста приложений в малой организации.
Программист приложений создает конкретное приложение на базе шаблонов и библиотек Thornado, используя спецификации. Он должен являться программистом, однако для его работы достаточно средней квалификации.
Верстальщик обеспечивает правильное форматирование документов. Он может не обладать квалификацией программиста, но должен владеть языком HTML или другим языком разметки текста.
Менеджер по работе с заказчиком собирает данные о бизнес-процессах организации-заказчика, составляет спецификацию продукта, описывает на естественном языке те части приложения, которые не могут быть сгенерированы автоматически. Он должен обладать представлением об используемых шаблонах, быть опытным пользователем приложений и разбираться в бизнес-процессах. Менеджер занимается составлением технического задания, тестированием, внедрением и технической поддержкой. Таким образом, основная нагрузка при разработке приложений переходит к менеджеру. При этом менеджер может не обладать квалификацией программиста.
При работе над приложением между участниками разработки приложений возникают следующие информационные потоки, представленные на рис. 1.
Рис. 1. Диаграмма информационных потоков между участниками разработки приложений
На рисунке приняты следующие цифровые обозначения: 1 - постановка задачи, все материалы для работы: документы, примеры данных и т.д.; 2 - документы для верстки с указанием переменных; 3 - сверстанные документы; 4 - описание данных, описания переменных документов, неформальные описания бизнес-процессов; 5 - запросы на добавление или изменение шаблонов или библиотек кодогенерации; 6 - шаблоны и библиотеки кодогенерации; 7 - программа; 8 - внедрение программы, тестирование и написание руководства пользователя.
Литература
1. Barnett M., Campbell C., Grieskamp W., Gurevich Y., Nachmanson L., Schulte W., Tillmann N., Veanes M. Specifications in the development process: An ASML demonstration // Specification and Verification of Component-Based Systems, 2006.
2. Czarnecki K., Eisenecker U.W. Generative Programming: Methods, Tools, and Applications. - Addison-Wesley, 2000.
3. Microsoft® Windows Forms Designer. - Режим доступа: http://msdn2.microsoft.com/enus/library/e06hs424(VS.80).aspx, своб.
4. IBM® Rational Application Developer for WebSphere Software. - Режим доступа: http://www-306.ibm.com/software/awdtools/developer/application/, своб.
5. Окуловский Ю.С. Язык TH. // Труды 37-й региональной конф. в Кунгурке. - Екатеринбург, 2006.
6. Окуловский Ю.С. Спецификация языка Thorn. - Режим доступа: http://cs.usu.edu.ru/langs/th, своб.
7. Van Deursen A., Klint P., Visserm J. Domain-Specific Languages: an annotated bibliography // ACM SIGPLAN Notices. - 2000. - V. 35. - № 6.
8. Microsoft® C# Language Specification. - Режим доступа: http://msdn2.microsoft.com/en-us/vcsharp/aa336809.aspx, своб.
9. Деев Д.В. Исследование структур распространенных графических интерфейсов пользователя // Международная конференция «Информационно-математические технологии в экономике, технике и образовании», тезисы конференции, Екатеринбург, 2007.
10. ГОСТ Р 6.30 - 2003. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов. - Введ. 03.03.2003. - М.: Госстандарт России : Изд-во стандартов, 2003.
11. World Wide Web Consortium. HTML 4.0 Specification. - Режим доступа: http://www.w3.org/TR/html401/, своб.
Деев Дмитрий Васильевич Окуловский Юрий Сергеевич Попов Владимир Юрьевич
Частовских Виктор Петрович
— Уральский государственный лесотехнический университет, аспирант, [email protected]
— Уральский государственный университет им. А.М. Горького, аспирант, [email protected]
Уральский государственный университет им. А.М. Горького, доктор технических наук, профессор, [email protected]
Уральский государственный лесотехнический университет, доктор технических наук, профессор, [email protected]
УДК 004.75
МНОГОАГЕНТНЫЕ СИСТЕМЫ ИДЕНТИФИКАЦИИ С ИСПОЛЬЗОВАНИЕМ СЕМАНТИЧЕСКОГО СПОСОБА РАСПРЕДЕЛЕНИЯ МОДЕЛИ ФУНКЦИОНИРОВАНИЯ ОБЪЕКТА
А.И. Кальянова, А.В. Демин
В статье рассмотрена архитектура многоагентного комплекса идентификации технических объектов и проведены исследования применения многоагентного подхода с семантическим способом распределения моделей функционирования объекта.
Ключевые слова: многоагентные системы, идентификация, модели функционирования.
Введение
Развитие технических объектов, таких как распределенные вычислительные системы, системы связи, специальная техника и т.п., происходит в направлении функционального и структурного усложнения, а также интеграции различных по типу устройств (механических, электрических, электронных и пр.), связанных друг с другом и оказывающих большое влияние на свое окружение, в один технический объект. В связи с этим возникает задача создания эффективной системы идентификации технических объектов на соответствие требуемым функциональным и параметрическим показателям.
Учитывая, что любой технический объект состоит из большого количества разнообразных элементов, связанных друг с другом и оказывающих большое влияние на свое окружение, необходимо разработать математическую модель объекта, рассматривающую объект как сложную систему, состоящую из элементов и связей между ними.
