CC BY
56
Нетрудно показать, что
РМ _ ОТ2 R
_ 21ттЛг
ПР - 21ИаПР ■
Проведенный на основании полученных зависимостей анализ показал, что коэффициент полезного действия резонансных источников питания (а значит и мощность рассеивания) существенно не отличаются от аналогичных значений для традиционных импульсных схем. Преимуществом резонансных ИП является существенное уменьшение размеров реактивностей в связи с ростом рабочей частоты ШИМ -контроллера, что приводит к относительному уменьшению геометрического объема. Это позволяет с уверенностью утверждать, что для трех известных схем [4] тепловой объем превышает геометрический. Но в то же самое время для каждого нового типа схем следует производить хотя бы качественную оценку соотношения объемов. Для этого желательно для всех основных схем резонансных ИП иметь формулы по расчету рассеиваемой мощности, аналогичные тем, которые были получены для обычных импульсных ИП.
ЛИТЕРАТУРА
1. Полянский ЕМ. Исследование многомерного алгоритма выбора состава ряда модулей средств электропитания. Известия ТРТУ. Тематический выпуск. Интеллектуальные САПР. Таганрог : Издательство ТРТУ, №4 (22) 2001. С. 274-280.
2. Ли Ф. К. Высокочастотные квазирезонансные преобразователи. ТИИЭР. т. 76. №4. 1988. С. 83 - 97.
3. Кассакян Д.Г., Шлехт М.Ф. Высокочастотные преобразователи высокой удельной объемной мощности для распределенных систем электропитания.
4. ТИИЭР. Т. 76. №4, 1988. С. 67 - 83.
5. Источники вторичного электропитания/В. А. Головацкий, Г. Н. Гуликович, Ю. И. Конев
и др.; Под редакцией Ю. И. Конева. - 2-е изд., переработанное и доп. М.: Радио и связь, 1990. 280 с.: ил.
Е.Г. Хаблов, С.А. Литвиненко, А.Н. Литвиненко РАЗРАБОТКА WWW-ИНТЕРФЕЙСОВ К БАЗАМ ДАННЫХ
В связи с ростом числа прикладных баз данных в Internet возникает проблема их удобного и доступного отображения в Web среде. Как правило, такие БД не имеют сложной структуры данных и связей. При этом интерфейс пользователя обладает практически одной и той же функциональностью. При создании таких WWW-интерфейсов и систем их администрирования часто приходится повторять уже проделанную ранее работу. Нашей целью являлось создание программного инструментария для автоматизации этого процесса.
На этапе проектирования приложения происходит разбиение системы на модули, чтобы их разработка была эффективной, а сами модули можно было использовать повторно в других проектах. Модуль, реализующий интерфейс пользователя, включает HTML-шаблоны для форм, PHP- или JavaScript-функции для построения элементов управления и отображения данных.
Модуль, реализующий «бизнес-логику» приложения, осуществляет обработку запросов пользователя. Модуль взаимодействия с источником информации представляет собой объект с набором свойств, характеризующих параметры дос-
тупа к БД или другим ресурсам, и методами для получения различных наборов данных.
Такое разбиение хорошо тем, что позволяет разрабатывать системы нескольким людям независимо друг от друга. Ведь для реализации первого модуля больше требуется верстальщик страниц HTML, для второго - программист, а третьего - специалист по СУБД. Для согласования работ на начальном этапе выполняется проектирование системы и принимаются соглашения о программных интерфейсах функций.
Любая прикладная система, вне зависимости от выбранной модели взаимодействия, требует такого инструментария, который смог бы существенно ускорить сам процесс создания системы и, одновременно с этим, обеспечить прозрачность и расширяемость кода.
Данное приложение представляет собой инструмент для создания Web-интерфейса к БД. Его реализация основана на однородном описании всех структур данных и их универсальной обработке. Так, HTML-формы, отчеты, служебная информация составляют однородное пространство данных. Пространство операций однородно относительно клиентских и серверных операций. Клиентские операции, написанные на JavaScript или XML, представляют собой набор действий, которые создают дополнительные удобства при работе с интерфейсом. Базовый набор операций с данными (такие как создание, просмотр, редактирование, удаление), дополнительные функции по обработке данных и действий составляют множество серверных операций. Анализ применимости операции к данным и ее исполнение производится с помощью «универсального исполнителя».
Предусмотрена возможность ограничивать доступ к реальным данным без уменьшения функциональности, за счет чего администратор получает возможность моделировать запросы пользователя на изменение данных.
Для унификации работы с записями и таблицами, а также для создания гибких интерфейсов функций используются ассоциативные массивы, при этом средним звеном между интерфейсом приложения и БД служит объект для доступа к БД. Это следование тенденции использования объектно-ориентированных компонентных средств разработки.
Гибкость достигается использованием механизма динамического подключения специальным образом регистрируемых программных вставок. Этот механизм известен как реализация однородного набора с помощью наборных гнезд [1].
Для динамического формирования интерфейса используется CGI-модули на языке РНР[2]. Для хранения данных была выбрана СУБД PostgreSQL.
Следуя стандарту, в качестве всевозможных метаданных, служебной информации, и самих данных эффективным решением является использование XML. В этом случае вся информация из различных БД и источников данных предварительно преобразуется в формат XML и обрабатывается дополнительными средствами на сервере или на клиенте. С помощью XML описываются формы и данные для обработки и отображения, что позволяет на клиенте вести поиск, организовать сортировки и «интеллектуальные» подсветки. На основе XML планируется создание генератора отчетов и заготовленных шаблонов просмотра содержимого таблиц. Использование генератора отчетов в сочетании с развитой системой поиска позволяет быстро создавать готовые документы с интересующей информацией.
В конечном итоге разработка нового интерфейса к БД состоит в использовании готовых шаблонов, модулей и отдельных вспомогательных функций, из
которых собирается приложение. Использование данного инструментария предполагает знание технологий РНР, 1ауа8спр1:, так как очевидна необходимость доработки шаблонов, написания дополнительных функций. Работа по настройке и запуску сводится уже не к написанию «с нуля» кода приложения, а к внесению в БД соответствующих таблиц, разработке и созданию шаблонов интерфейсной части, написанию дополнительных функций для интерфейса и обработки данных.
На основе разработанных авторами инструментальных программных средств была создана информационно-справочная система, содержащая информацию о преподавателях, студентах, предметах, факультетах и кафедрах РГУ.
ЛИТЕРАТУРА
1. Горбунов-ПосадовММ. Расширяемые программы. - М.: Полиптех, 1999.
2. Кастаньетто Дж., Рават Х., Шуман С., Сколло К., Велиаф Д. Профессиональное РНР программирование.- Пер.с англ. - СПб: Символ-Плюс, 2001.
Е.Н. Коробко, А.Н. Литвиненко КОМПОНЕНТНОЕ ПРОГРАММИРОВАНИЕ
В данной работе предлагается архитектура программной системы, создаваемой на основе набора компонентов. Компоненты - это программные модули, разработанные на базе СОМ-технологий, которые легко можно повторно использовать в различных комбинациях в различных контекстах.
Предлагаемую архитектуру можно реализовать с помощью существующего инструментария, если использовать соответствующую дисциплину организации компонентов.
Компонентное программирование - это концепция программирования, в основу которой положено объектное программирование, совместное использование модулей бинарного стандарта и минимизация межмодульных связей [1,2].
Цель компонентного программирования - отказ от реализации новых примитивов в пользу уже существующих программных элементов. Эта цель не достигается, главным образом, из-за того, что задача объединения независимо разработанных компонент в единое целое часто оказывается сложнее, чем самостоятельная разработка нужных модулей. Причина такой ситуации в том, что прямой перенос методов объектно-ориентированного программирования для создания повторно используемых компонент невозможен. Главная причина заключается в том, что компонент должен быть контекстно-независимым. Объектноориентированная декомпозиция очень часто приводит к контекстной зависимости объектов [3,4].
Для узких областей компонент контекстная независимость достигается либо созданием пассивных компонент (т.е. компонент, не влияющих на поведение общей системы, например, для доступа к данным или видеосистеме), либо стандартизацией интерфейса контекста (АсйуеХ).
Стандартизация интерфейса контекста представляется единственно возможным решением создания контекстно-независимых объектов. Стандарт, применяемый для использования АС:^еХ, для этой роли не подходит, т.к. он очень
