CC BY
32
P. 130-143. 2. Zorian Yervant. What is Infrastructure IP? // IEEE Design & Test of Computers.- May-June 2002. P. 5-7. 3. Zorian Yervant. Advances in Infrastructure IP // IEEE Design & Test of Computers. - May-June 2003. 49 p. 4. Novak O., Gramatova E., Ubar R., and collective. Handbook of testing electronic systems. Czech Technical University Publishing House.2005. 395 p. 5. Abramovisi, M.,BreyerM.A. andFriedman A.D. Digital systems testing and testable design. Computer Science Press 1998.652p. 6. Хаханов В.И., Хаханова И.В. VHDL + Verilog=CTHre3 за минуты. Харьков. ХНУРЭ. 2006. 264 с. 7. Автоматизация диагностирования электронных устройств/ Ю.В. Малышенко и др./Под ред.В.П.Чипулиса. М.: Энергоатомиздат, 1986. 216 с. 8. УбарР.Р. Анализ диагностических тестов для комбинационных цифровых схем методом обратного прослеживания неисправностей // Автоматика и телемеханика. 1977. №8. C.168-176. 9. Hahanov V.I., Babich АУ., Hyduke S.M. Test Generation and Fault Simulation Methods on the Basis of Cubic Algebra for Digital Devices. Proceedings of the Euromicro Symposium on Digital Systems Design DSD 2001. Warsaw, Poland. September, 4-6, 2001. P. 228-235. 10. Хаханов В.И., ХакХ.М. Джахирул, Масуд М.Д. Мехеди. Модели анализа неисправностей цифровых систем на основе FPGA, CPLD // Технология и конструирование в электронной аппаратуре. 2001. № 2. С. 3-11. 11. Levendel Y.H., MenonP.R. Comparison offault simulation methods - Treatment ofunknown signal values // Journal of digital systems. Vol. 4. 1980. P. 443-459. 12.ХахановВ.И., Сысенко И.Ю., КолесниковК.В. Дедуктивно-параллельный метод моделирования неисправностей на реконфигурируемых моделях цифровых систем // Радиоэлектроника и информатика. 2002. № 1. С. 98-105.
Поступила в редколлегию 05.03.2008
Хаханов Владимир Иванович, декан факультета КИУ ХНУРЭ, д-р техн. наук, профессор кафедры АПВТ ХНУРЭ. Научные интересы: техническая диагностика цифровых систем, сетей и программных продуктов. Увлечения: баскетбол, футбол, горные лыжи. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 70-21-326. E-mail: hahanov@kture.kharkov.ua. Сушанов Алексей Владимирович, студент факультета компьютерной инженерии и управления ХНУРЭ. Научные интересы: диагностика цифровых устройств, программирование. Увлечения: музыка. Адрес: Украина, 61000, Харьков, ул. Ощепкова, 16/2, кв.7, тел. +380933251277, e-mail: sushanov_aleksey@mail.ru.
УДК 681.326:719.513
С.В. МИХТОНЮК, Р.С. ХВАН, В.И. ОБРИЗАН
АРХИТЕКТУРНАЯ МОДЕЛЬ МАСШТАБИРУЕМОЙ СИСТЕМЫ АСИНХРОННОЙ ОБРАБОТКИ БОЛЬШИХ ОБЪЕМОВ ДАННЫХ
Предлагается типовое масштабируемое архитектурное решение для систем визуализации и модификации больших объемов данных с использованием метода асинхронного выполнения программируемых команд и рефлексивного подхода к построению структуры объектов.
1. Введение
В последнее время количество информации, необходимой человеку для работы, стремительно растет. Это влечет за собой повышение спроса на программы, которые позволяют представлять эту информацию в удобном для пользователя виде, легко ее анализировать и модифицировать. Источником данных может выступать локальная база данных, либо база на корпоративном сервере, или же информация может собираться из сети Интернет. Несмотря на схожесть таких приложений, нельзя создать единое программное решение для всех из них, ведь каждая предметная область имеет свою специфику и правила обработки данных. Идя по пути единого решения, разработчик рискует получить продукт, перегруженный различными настройками и параметрами, предназначенными для его адаптации к конкретной задаче, а также сложный со стороны реализации и поддержки.
Лучшим подходом в данном случае будет создание единого типового решения для построения программ такого вида, придерживаясь которого программисты смогут легко создавать эффективные продукты, специализированные на решении конкретной задачи. Специализация каждого программного продукта обеспечит минимальные затраты на его реализацию и интеграцию.
Объект исследования: архитектурная модель приложения визуализации и обработки информации, асинхронно работающего с большими хранилищами данных.
Цель исследования: повышение надежности и скорости реализации программных продуктов за счет введения единообразного подхода к взаимодействию с большими источниками данных.
Задачи: 1. Анализ общих недостатков приложений рассматриваемого типа. 2. Разработка обобщенного представления информации, построение объектной модели данных предметной области. 3. Разработка способа изоляции кода программы, зависящего от структуры хранилища, в пределах одного из архитектурных слоев. 4. Разработка алгоритма доступа к данным, компенсирующего недостатки хранилища. 5. Разработка эффективного способа разделения данных и их представления, механизма их синхронизации.
2. Анализ требований к системе
Главным требованием к архитектурному шаблону [1] является его обобщенность, чтобы он подходил для решения как можно большего спектра задач. Определим общие проблемы приложений рассматриваемого типа:
1. Изменение структуры источника влечет за собой серьезные изменения во всех слоях приложения (далее под источником или хранилищем будут пониматься любые виды баз данных и Интернет, общей чертой которых является низкая скорость доступа к данным). Даже при использовании подхода с трехслойной архитектурой [2] (рис. 1) изменения в структуре базы данных часто могут повлечь сквозную модификацию кода вплоть до слоя интерфейса.
Database
Рис. 1. Трехслойная архитектура приложения
2. Неудобство работы с данными, представленными в реляционной базе данных. Программисту и пользователю удобнее работать с объектно-ориентированным представлением данных, когда нет нужды заботиться о таких особенностях реляционного представления как, например, реализация отношения «многие ко многим» (в реляционной базе данных требует создания дополнительной таблицы связей).
3. При обращении к источнику из одного потока возможно замирание пользовательского интерфейса программы. Даже при работе с высокоскоростными локальными базами данных возможна ситуация, когда выполнение сложного запроса потребует заметного для пользователя времени. При выполнении такого запроса синхронно в потоке интерфейса GUI не будет реагировать на действия пользователя.
Исходя из перечисленных проблем, сформулируем требования к системе:
1. Поддержка асинхронного выполнения запросов к хранилищу.
2. Масштабируемое число потоков выполнения.
3. Возможность задать синхронный режим работы для упрощения отладки приложения.
4. Большинство изменений в структуре хранилища не должны затрагивать более одного архитектурного слоя программы.
5. Независимость от числа и типов источников данных.
Далее представлен проект системы, отвечающей всем описанным выше требованиям.
3. Рефлексивная модель представления данных
В разрабатываемой системе принята графовая модель представления информации (рис. 2). Таким образом, каждая сущность из предметной области может как хранить коллекции относящихся к ней дочерних сущностей, так и сама быть дочерней по отношению к нескольким другим сущностям.
а б в
Рис. 2. Пример древовидной(а) и графовой(б,в) модели представления данных для отображения
объектов базы данных издательства
Далее объект, представляющий некую сущность из предметной области, будет именоваться артефактом (Artifact).
Чтобы оградить структуру артефакта от его представления в базе данных, был использован «рефлексивный» (от англ. Reflection - отражение) подход к его структуре [3,4]. Reflection - это механизм метапрограммирования, позволяющий получить информацию о структуре класса во время выполнения программы, иначе она теряется во время компиляции. В представленной системе происходит динамическое «отражение» структуры артефакта в базе на класс артефакта в программе. Количество свойств и их значения определяются в момент создания каждого из артефактов в соответствии с возвращенной базой информацией. На рис. 3 представлена UML-диаграмма артефактов для рассматриваемого случая с базой данных издательства.
Рис. 3. Диаграмма классов артефактов для примера БД издательства Каждый артефакт содержит в себе ассоциативный массив, где ключом выступает имя свойства, а значением - значение свойства, полученное из источника. Такой подход позволяет максимально оградить слой данных и доменной логики от реальной структуры артефакта. Единственными завязанными на истинную структуру являются слой отображения и алгоритмы по модификации данных.
Чтобы еще сильнее абстрагироваться от структуры артефакта, были введены классы итераторов [1] свойств. Благодаря итераторам, в случае, когда приложению нужно отобразить таблицу из имени и свойств артефакта, слою представления не нужно знать имена каждого свойства, чтобы его извлечь. Ему достаточно будет только проитерировать все свойства, отображая их имена как столбец в таблице, а в ячейках - их значение.
4. Система асинхронного взаимодействия с источниками данных
На рис. 4 представлена диаграмма ключевых классов и интерфейсов системы.
Рис. 4. Диаграмма основных классов системы
Центральным классом системы является Core, он отвечает за инициализацию всех подсистем и за взаимодействие со слоем GUI через интерфейс IArtifactView. Реализовав этот интерфейс и зарегистрировав себя в ядре, объект будет оповещаться обо всех изменениях данных. При инициализации класс Core конструирует необходимый экземпляр реализации ICommandQueue. Классы из этой иерархии реализуют очередь команд, помещенные в нее команды будут выполняться асинхронно в фоновом потоке.
Таким образом, при инициализации одного из классов IArtifactView он может поставить на загрузку необходимые ему артефакты. Этот запрос будет обрабатываться асинхронно, и по его завершении все IArtifactView будут уведомлены об обновлении данных. Такой подход позволяет устранить замирание интерфейса при обработке запроса и визуализировать сам процесс загрузки.
Класс команды значительно расширяет возможности очереди. Команда может инкапсулировать в себе любые действия, требующие значительного времени на выполнение. О процессе выполнения либо о завершении обновления данных команда сообщает всем IArtifactView посредством Core. Большинство систем построения пользовательского интерфейса ограничивают доступ к своим объектам только до главного потока, это потребовало реализации системы диспетчеризации, которая переводит выполнение нотификации на поток GUI.
В рассматриваемой реализации команды существуют в единственном экземпляре и ставятся в очередь через объекты Executionltem, кроме команды они содержат необходимые для выполнения аргументы. Так как одна команда может одновременно выполняться в нескольких потоках, то они реализуются как объекты без состояния (stateless) и работают лишь с данными, переданными с параметрами.
Кэш артефактов призван обеспечить однозначность между артефактом в хранилище данных и артефактом в программе. Для уникальной идентификации артефакта вводится URI (Unique Resource Identifier). Если обнаруживается, что загружаемый артефакт уже находится в кэше, то загрузка прерывается и возвращается ссылка на уже существующий экземпляр.
Рассмотренная модель, помимо плюсов асинхронного выполнения, предлагает широкий набор модификаций. Так, на базе существующего проекта можно реализовать: парсинг команд и их параметров для работы из командной строки; добавить выполнение команд в любом количестве командных потоков, что в случае работы с Интернетом даст многократный прирост производительности; поддержку неограниченного числа объектов визуализации данных, синхронизированных как с базой, так и между собой.
5. Заключение
Научная новизна: разработано типовое решение для архитектуры приложений, взаимодействующих с низкоскоростными источниками данных, рассмотрены инновационные методы доступа к данным с помощью рефлексивной модели построения объектов, позволяющие снизить степень связанности программного кода со структурой источника данных.
1. Представлен инновационный подход динамической инициализации структуры объектов данных. 2. Разработана гибкая система асинхронного взаимодействия с источниками данных. 3. Разработан гибкий и расширяемый подход к взаимодействию слоев доменной логики и пользовательского интерфейса.
Практическая значимость предложенного проекта заключается в повышении надежности и скорости реализации программных продуктов за счет введения единообразного подхода к взаимодействию с большими источниками данных.
Список литературы: 1.Gamma, Helm, Johnson, Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1995. 2. Martin Fauler. Patterns of Enterprise Application Architecture. Addison Wesley, 2002. 3. Arthur H. Lee, Joseph L. Zachary. Reflections on Metaprogramming. IEEE Transactions on Software Engineering, Vol. 21, №11, November 1995. 4. Manuel Clavel. Reflection in Rewriting Logic: Metalogical Foundations and Metaprogramming Applications. Cambridge University Press, 2000.
Поступила в редколлегию 22.02.2008
Михтонюк Сергей Владимирович, студент 3-го курса ХНУРЭ, специальность - специализированные компьютерные системы, разработчик программного обеспечения компании ИП «Интспеи-Украина». Научные интересы: параллельное программирование, высокопроизводительные вычисления, компьютерная 3D графика. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 7021326. E-mail: mikhtonyuk@gmail.com.
Хван Роман Сергеевич, студент 4-курса ХНУРЭ, специальность - системное программирование, разработчик программного обеспечения компании ИП «Интспеи-Украина». Научные интересы: проектирование и разработка программного обеспечения, трехмерная графика. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 7021326. E-mail: hwang.roman@gmail.com.
Обризан Владимир Игоревич, аспират кафедры АПВТ ХНУРЭ, менеджгр проектов компании ИП «Интспеи-Украина». Научные интересы: параллельное программирование, высокопроизводительные вычисления, проектирование цифровых систем на кристалле. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 7021326. E-mail: obrizan@intspei.com.
УДК 004.421: 548.55
А.П. ОКСАНИЧ, В.Р. ПЕТРЕНКО
АВТОМАТИЗИРОВАННАЯ СИСТЕМА УПРАВЛЕНИЯ КОМПОНОВКОЙ ЗАГРУЗОК ПРИ ВЫРАЩИВАНИИ МОНОКРИСТАЛЛОВ КРЕМНИЯ ДЛЯ СОЛНЕЧНЫХ ФЭП
Рассматривается функциональная структура и алгоритмы решения задач автоматизированной системы управления компоновкой загрузок при выращивании монокристаллов кремния для солнечных ФЭП. Приводится формализованное описание алгоритма управления процессом формирования смешанных загрузок (оборотный материал + поликристаллический кремний), оптимизирующего использование оборотного материала.
1. Введение
Высокочистый монокристаллический кремний является основным полупроводниковым материалом, используемым в современной электронной промышленности. Мировое производство полупроводникового кремния постоянно увеличивается. Ежегодный прирост объемов производства составляет более 2 тысяч тонн. Это является следствием уникальности свойств этого материала, неограниченности природных запасов исходного сырья, коммерческой доступности, технологичности процессов изготовления электронных приборов на основе полупроводникового кремния.
Дополнительный интерес к монокристаллическому кремнию появился в связи с решением проблем альтернативных источников энергии. Научные разработки возобновляемых источников энергии в последние десятилетия достигли практической реализации и стали активно внедряться в мировую экономику. Среди таких разработок особое место принадлежит солнечной энергетике, базирующейся на использовании полупроводниковых фотоэлектрических преобразователей (ФЭП).
