«ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ И ПРОГРАММНЫЕ СРЕДСТВА: ПРОЕКТИРОВАНИЕ, РАЗРАБОТКА И ПРИМЕНЕНИЕ Сборник научных статей Гродно 2011 УДК 004 005.951(082) ББК 32.81я43 И38 Редакционнаяколлегия: кандидат физико-математических ...»

Очевидно, что отношение определяет систему ФЗ на R, которая называется тривиальной системой ФЗ, а входящие в нее ФЗ – тривиальными ФЗ. Для задания системы ФЗ, отличающейся от тривиальной, требуется постулировать конечное множество ФЗ G { X i Yi | X i R, Yi R, i 1, n}, которое в [7] было названо системой образующих структуры ФЗ на R, однако более точно его называть образующим множеством системы ФЗ. Систему ФЗ, заданную образующим множеством G, будем обозначать F (G).

Определение 2. Замыканием множества X R относительно системы ФЗ F (G) называется множество X (G) R, такое, что для любого A R из X A следует A X (G).

Алгоритм построения множества X (G) состоит из следующих шагов.

2. Положить P 0 и для каждого i 1, n выполнить действия шага 3.

4. Если P 1, то перейти к шагу 2, иначе закончить работу.

ответственно называются эквивалентными, если для любого X R имеет место равенство Необходимые и достаточные условия эквивалентности систем ФЗ F (G1 ) и F (G 2 ) дает следующая теорема, доказанная в работе [2].

Теорема 1. Системы ФЗ F (G1 ) и F (G 2 ) на множестве R эквивалентны тогда и только Определение 4. Образующее множество E {H i Ti | H i R, Ti R, i 1, m} системы ФЗ F (E ) на множестве R называется базисом, если образующее множество E, полученное из E путем удаления любой ФЗ, задает систему ФЗ F (E), не эквивалентную системе ФЗ F (E ).

множестве R называется элементарным, если выполняются следующие условия:

1) для любого i 1, m и любого A Ti образующее множество E, полученное из E путем замены ФЗ H i Ti на ФЗ H i Ti \ A, задает систему ФЗ F (E), не эквивалентную системе ФЗ F (E ) ;

2) для любого i 1, m и любого B H i образующее множество E, полученное из E путем замены ФЗ H i Ti на ФЗ H i \ B Ti, задает систему ФЗ F (E), не эквивалентную системе ФЗ F (E ).

Определения базиса и элементарного базиса системы ФЗ были введены в работе [7]. В англоязычной литературе базис системы ФЗ называют неизбыточным покрытием, а элементарный базис– минимальным покрытием системы ФЗ. В некоторых источниках [5, 6] требуется, чтобы в минимальном покрытии каждое из состояло из единственного элемента множества R, что легко достигается применением правила декомпозиции к каждой ФЗ H i Ti. В монографии [3] элементарный базис называется редуцированным покрытием.

Определение 6. Элементарный базис E {H i Ti | H i R,Ti R, i 1, m} системы ФЗ F (E ) на множестве R называется минимальным, если не существует другого элементарного базиса системы ФЗ F (E ) с числом ФЗ, меньшим m.

Определение 7. Минимальный элементарный базис E {H i Ti | H i R, Ti R, i 1, m} системы ФЗ F (E ) на множестве R называется оптимальным, если не существует другого минимального элементарного базиса системы ФЗ F (E ) с меньшим числом вхождений элементов множества R.

В работе [3] минимальный и оптимальный элементарный базисы системы ФЗ называются минимальным и оптимальным покрытием.

Построение элементарного базиса системы ФЗ Элементарный базис системы ФЗ на множестве R с образующим множеством G {X i Yi | X i R, Yi R, i 1, n} можно легко построить по алгоритму, состоящему из следующих шагов [3].

1. Удалить «посторонние» элементы из левых частей ФЗ из G. Элемент A X i называется «посторонним» в X i, если A ( X i \ A) (G), где через G обозначено образующее множество системы ФЗ, полученное из G путем замены ФЗ X i Yi на ( X i \ A) Yi.

2. Если в G имеется две или более ФЗ с одинаковыми левыми частями, то объединить их в одну ФЗ.

3. Удалить «посторонние» элементы из правых частей ФЗ из G. Элемент B Yi называется «посторонним» в Yi, если B X i (G), где через G обозначено образующее множество системы ФЗ, полученное из G путем замены ФЗ X i Yi на X i (Yi \ A).

4. Удалить из G ФЗ с пустыми правыми частями.

Определение 8. Пусть E {H i Ti | H i R, Ti R, i 1, m} – элементарный базис системы ФЗ F (E ) на множестве R. Будем говорить, что в ФЗ ( H s Ts ) E существует P – зависимость непустого Ts Ts от H s, если существует P H s (E ), P H s, такое что Ts [ P ( E ) \ P] и никакое подмножество P этими свойствами не обладает. Через E обозначим образующее множество ФЗ, полученное из E путем замены ФЗ H s Ts на H s (Ts \ Ts).

Будем различать три типа P – зависимости: P1 – зависимость имеет место, если P H s (E ), P2 – зависимость – если одновременно P H s (E) и Ts [ P ( E) \ P], P3 – зависимость – если одновременно P H s (E ) и Ts [ P ( E) \ P].

Можно показать, что для P – зависимости выполняются условия Ts P (E ) и H s P (E), а для P2 – зависимости выполняется условие H s P (E ), следовательно, для P и P2 – зависимостей системе ФЗ F (E ) принадлежит биекция H s P. Легко убедиться, что при наличии P – зависимости не существует H s H s, такого что P H s (E ). Действительно, в противном случае P – зависимость может быть только P – зависимостью, но тогда имеем H s H s (E ), т. е. в левой части ФЗ H s Ts имеются «посторонние» элементы.

Основные свойства P – зависимостей сформулируем в виде теорем 2 – 4, доказательство которых проводится путем проверки выполнения достаточных условий эквивалентности систем ФЗ.

Теорема 2. Если в ФЗ ( H s Ts ) E существует P – зависимость Ts Ts от H s и образующее множество ФЗ Q получено из E путем замены ФЗ H s Ts на H s Ts \ Ts и добавления к E ФЗ P Ts, то системы ФЗ, задаваемые образующими множествами E и Q, эквивалентны.

Теорема 3. Если в ФЗ ( H s Ts ) E существует P2 – зависимость Ts Ts от H s и обраH s Ts H s [(Ts \ Ts) ( P \ H s ( E))] и добавления к E ФЗ P Ts, то системы ФЗ, задаваемые образующими множествами E и Q, эквивалентны.

Теорема 4. Если в ФЗ ( H s Ts ) E существует P3 – зависимость Ts Ts от H s и обрапутем замены ФЗ H s Ts на зующее множество ФЗ Q получено из E H s [(Ts \ Ts) ( P \ H s ( E))], то системы ФЗ, задаваемые образующими множествами E и Q, эквивалентны.

Приведенные свойства P – зависимостей позволяют переходить от одного элементарного базиса системы ФЗ к другим элементарным базисам. Заметим, что в общем случае образующее множество ФЗ Q не является элементарным базисом, поскольку может содержать транзитивные ФЗ, и к нему следует применить алгоритм построения элементарного базиса системы ФЗ.

Рассмотрим пример использования P – зависимостей для построения минимального и оптимального базисов системы ФЗ. Пусть система ФЗ на множестве атрибутов R { A, B, C, D, K} задана образующим множеством E1 { AB D, C D, D A, BD C, BC K}, которое является элементарным базисом. В элементарном базисе E1 имеем следующие P – зависимости: P – зависимость K от BC для P AB ; P – зависимость K от BC для P BD ; P – зависимость C от BD для P AB ; P3 – зависимость D от AB для P C. Применяя к первым трем P– зависимостям теорему 2, получим элементарные базисы E4 {AB C, C D, D A, BC K}. Применяя к последней P3 – зависимости теорему 4, также получим элементарный базис E4.

В элементарном базисе E2 имеем P – зависимость K от AB для P BD (приводит к E3 ); P – зависимость K от AB для P BC (приводит к E1 ); P – зависимость C от BD для P AB (приводит к элементарному базису E5 {AB CK, C D, D A} ); P3 – зависимость D от AB для P C (также приводит к E5 ). В элементарном базисе E3 имеем P – зависимость K от BD для P AB (приводит к E2 ); P – зависимость K от BD для P BC E6 { AB C, C D, D A, BD K} ); P3 – зависимость D от AB для P C (также приводит к E6 ). В элементарном базисе E4 имеем P – зависимость K от BC для P AB (приводит к E5 ); P – зависимость K от BC для P BD (приводит к E6 ); P2 – зависимость C от AB для P BD (приводит к E1 ). В элементарном базисе E5 имеем P – зависимость K от AB для P BD (приводит к E6 ); P – зависимость K от AB для P BC (приводит к E4 );

P2 – зависимость C от AB для P BD (приводит к E2 ). В элементарном базисе E6 имеем P – зависимость K от BD для P AB (приводит к E5 ); P – зависимость K от BD для P BC (приводит к E4 ); P2 – зависимость C от AB для P BD (приводит к E3 ). Для рассмотренного примера минимальным и оптимальным элементарным базисом является E5.

Armstrong, W.W. Dependency structure of data base relationships / W.W. Armstrong // Proc. IFIP Congress. – Geneva, Switzerland, 1974. – P. 580–583.

Карпук, А.А. Выбор элементарного базиса структуры функциональных зависимостей при проектировании базы данных / А.А. Карпук // Вопросы радиоэлектроники. Сер. ОВР. – 1983. – № 6. – С. 38–41.

Мейер, Д. Теория реляционных баз данных: пер. с англ. / Д. Мейер. – М.: Мир, 1987. – 608 с.

Копейкин, М.В. Базы данных. Концепция баз данных: учеб. пособие / М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова. – СПб.: СЗТУ, 2004. – 116 с.

Кузнецов, С. Базы данных. Вводный курс / С. Кузнецов // [Электронный ресурс]. – Режим доступа:

http://www.citforum.ru/database/advanced_intro. – Дата доступа: 19.02.2010.

Дейт, К.Дж. Введение в системы баз данных / К.Дж. Дейт; пер. с англ. – 8-е изд. – М.: Издательский дом «Вильямс», 2005. – 1328 с.

Неклюдова, Е.А. Синтез логической схемы реляционной базы данных / Е.А. Неклюдова, М.Ш. Цаленко // Программирование. – 1979. – № 6. – С. 58–68.

Карпук Анатолий Алексеевич, начальник управления развития и сопровождения клиринговой и взаимодействующих систем Расчетного центра Национального банка Республики Беларусь, кандидат технических наук, доцент, [email protected].

УДК 681.3.

ОБ ОБЩИХ ПОДХОДАХ К РАЗРАБОТКЕ СРЕДЫ

ДЛЯ ПОСТРОЕНИЯ ВЕБ-ПРИЛОЖЕНИЙ

В предлагаемой статье излагаются общие подходы к созданию веб-приложений на основе некоторой универсальной среды. Особое внимание уделяется выделению уровней в вебприложениях, а также даются рекомендации по их реализации с целью сокращения времени разработки пользовательских Интернет-приложений.

Введение Расширение мировых информационных ресурсов и развитие Интернет-пространства привело к масштабному использованию всемирной сети, например, для коммуникационных, информационных, аналитических целей [2, 3]. Следует отметить, что с развитием веб-технологий повышаются требования и к соответствующим приложениям, позволяющим быстро и качественно создавать готовые решения, предназначенные для размещения в сети Интернет.

В настоящее время многие фирмы и разработчики предлагают собственные программные продукты, которые поддерживают некоторый класс готовых решений для создания Интернетприложений. Однако если речь идет о проектном решении для поддержки класса задач, функциональность которых требует не только размещения определенной информации в сети, но также включает достаточно сложную бизнес-логику, аналитическую обработку данных и персонифицированный доступ к ресурсам, готовые решения, охватывающие некоторую предметную область, практически отсутствуют.

В связи с этим возникает необходимость разработки некоторой универсальной интегрированной среды, поддерживающей создание Интернет-приложений требуемой предметной области, например, электронная коммерция, телекоммуникации, он-лайн страхование и т.д. Интегрированная универсальная среда должна обеспечивать удобную работу с базами данных; быструю разработку как статических, так и динамических веб-страниц; понятный абстрактный интерфейс для вывода информации клиенту; быструю обработку полученной информации сервером и визуализацию аналитических данных; быстрое внедрение базового решения на различные типовые проекты предметной области; быструю расширяемость базовой части проекта под специфику задачи; легкую переносимость базовой и расширенной части на новые проекты.

Определение многоуровневой архитектуры для универсальной среды разработки веб-приложений Определим основные уровни в архитектуре универсальной среды, позволяющей разрабатывать веб-приложения (рис. 1).

Первый уровень назовем уровнем хранилища данных. Как правило, этот уровень связан с данными, которые необходимо сохранять, накапливать и поддерживать. Для реализации данного уровня выбираются различные СУБД (MySQL, Oracle, SQLite и др.) в зависимости от ресурсов и рассматриваемой задачи предметной области.

Второй уровень связан с технологией доступа к данным (технология DAO – DataAccessObjects). Он предназначен для отправки запросов в хранилища и обработки их результатов. Как правило, данный уровень чаще всего поддерживается различными фреймворками, которые предоставляют удобный интерфейс для работы с базами данных.

Третий уровень – уровень сервисов. Он выполняет операции с данными в одной транзакции. Здесь создаются также различные бизнес-объекты, над которыми уже оперирует DAOуровень, и если нужно возвращается результат.

Четвертый уровень – уровень менеджеров, представляющих собой определенную «прослойку» между веб-сервисами (или – непосредственными обработчиками пользовательских запросов) и сервисами, для создания промежуточного кэша данных. Кроме того, данный уровень позволяет избегать повторения кода при расширении веб-приложений до функциональности вебсервиса, и тем самым избегать новых ошибок.

Пятый уровень связан с веб-сервисами и непосредственными обработчиками пользовательских запросов (MVC). На этом уровне могут находиться и веб-сервисы, необходимые для открытой работы с приложением другим клиентом и/или непосредственные обработчики пользовательских запросов, т.е. серверная часть, которая принимает на себя запросы пользователей.

И, наконец, последний, шестой уровень – это клиенты веб-сервиса и/или клиенты непосредственных запросов. Клиентами веб-сервисов могут быть различные приложения с совершенно непохожими интерфейсами и работающими под различными операционными системами, или даже из самого браузера, т.к. веб-сервис предоставляет открытый API для работы с самим приложением. Клиентом же непосредственных запросов, как правило, является браузер: он предоставляет интерфейс пользователю для работы с приложением.

О подходах к реализации универсальной среды для построения веб-приложений Для реализации описанной архитектуры универсальной среды выбран объектноориентированный язык Java, наилучшим образом подходящий для серверной имплементации.

Фреймворк Hibernate [1] позволяет организовать работу с СУБД. Так, Hibernate дает возможность описывать сущности баз данных с помощью аннотаций именно в бизнес-объектах, а по ним фреймворк сам в случае необходимости создает соответствующие таблицы и атрибуты. Кроме этого, в Hibernate присутствуют готовые решения для выполнения запросов к базе данных.

Для упрощения создания сервисов и менеджеров использован SpringFramework. Он позволяет написать интерфейс и его реализацию в виде абстрактного класса-шаблона, который обладает методами доступа к данным (выборка, вставка, удаление, обновление). Таким образом, простой генерирующий класс DAO уровня (рис. 2) в качестве параметра будет принимать бизнес-объект, описанный с помощью аннотаций фреймворка Hibernate и контекста Spring. Описав реализацию таких классов в конфигурации фреймворка Spring, получаем удобные классы для работы с любыми таблицами базы данных.

По аналогии с генерирующим классом можно создать абстрактный шаблонный сервис (рис. 3), который будет выполнять стандартные операции с данными. В случае необходимости можно расширить класс недостающих методов, используя наследование. С помощью фреймворка Spring задается маска на название методов сервисов и соответствующие для них транзакции. Это позволяет автоматически выполнять метод в рамках заданной транзакции. В случае ошибки Spring сам будет отменять совершенные действия над базой данных.

Для непосредственной обработки пользовательских запросов через браузер удобно использовать фреймворк Struts. Struts – представляет собой мощную реализацию шаблона MVC. Для обработки запросов созданы специальные Action-классы (рис. 4). Кроме того, Struts сам инициализирует поля форм, данными из которых менеджеры будут оперировать и передавать в необходимые сервисы, а также возвращать результаты в формы.

Используя Action, можно обобщить Form-классы фреймворка Struts для обработки обычных запросов пользователя: вывод таблицы, добавление, удаление, редактирование бизнесобъектов. Для этого опять же удобно использовать шаблонные классы, которые в качестве параметра будут принимать бизнес-объект. Так, для вывода таблиц в общем классе формы можно реализовать стандартную пагинацию для просмотра бизнес-объектов. Для удаления/редактирования/добавления в общем классе формы можно также реализовать методы для генерации сообщений, проверки прав (рис. 5). В итоге, разработчик реализует только то, что нужно для реализации специфического функционала веб-приложения и не предусмотрено в общем шаблонном классе формы или метода.

Реализация методов веб-сервисов будет заключаться также в вызове методов менеджеров, чтобы избежать повторения кода, дублирования объектов, общего доступа к кэшу. Таким образом, для любого веб-приложения можно в кратчайшие сроки реализовать открытый интерфейс программирования приложения. Отметим, что между прямыми методами веб-сервиса и методами менеджеров создается «прослойка»: в случае необходимости расширения или добавления нового функционала исключительно в веб-сервисы разработчики не будут испытывать сложностей.

Для разработки клиентских приложений для веб-сервисов используется любой язык, наиболее близкий разработчикам. По WSDL можно сгенерировать клиента, дописать необходимый функционал, и приложение будет функционировать либо в другом оформлении, либо на другой ОС.

Также для удобного доступа к функционалу приложения используется JSON: создан механизм, который по аннотациям над методами класса формы генерирует ответ сервера в JSONобъектах. Такой механизм позволяет минимизировать объем трафика между клиентской и серверной части, т.к. клиент принимает исключительно данные, а все, что касается интерфейса работы с этими данными, реализует локально. Таким образом, разработчики такого вида клиентов смогут использовать все ресурсы устройства, для которого написан клиент, для визуального оформления и других операций.

Для создания клиентского приложения для браузера можно применять обычные JSPстраницы. Так, например, jQuery (библиотека javascript) позволяет реализовать оконный интерфейс для веб-приложения. Тем самым пользователь не заметит разницы между локально установленной программой и работой в веб.

Основные выводы Итак, универсальная среда для разработки веб-приложений позволяет создавать в кратчайшие сроки Интернет-приложения. Рабочая библиотека такой среды с базовым функционалом основана на генерирующих и абстрактных классах. Ее расширение основано на наследовании и имплементации новых классов и интерфейсом с использованием функционала библиотеки. Разработанные на основе такой архитектуры приложения и веб-сервисы смогут легко интегрироваться друг с другом. Например, можно будет реализовать веб-приложение, которое хранит и отображает различных клиентов к веб-сервисам. Создав веб-сервис к такому приложению, можно будет импортировать в него клиента написанного на этом веб-приложении, а также – различных других клиентов к веб-сервисам.

http://docs.jboss.org/hibernate/stable/annotations/reference/en/html/. – Date of access: 28.10.2010.

MySpace [Electronic resource]. – Mode of access: http://m.myspace.com/login.wap. – Date of access:

22.10.2010.

LiveJournal [Electronic resource]. – Mode of access: http://www.livejournal.com/. – Date of access:

22.10.2010.

Клышевич Владимир Сергеевич, студент 5 курса специальности «Программное обеспечение информационных технологий» факультета математики и информатики Гродненского государственного университета имени Янки Купалы [email protected].

Рудикова Лада Владимировна, доцент кафедры программного обеспечения интеллектуальных и компьютерных систем факультета математики и информатики Гродненского государственного университета имени Янки Купалы, кандидат физико-математических наук, доцент, [email protected].

УДК 621.3.049. А.И. КОСТРОВ, В.В. НЕЛАЕВ, В.Р. СТЕМПИЦКИЙ, Ф.Л. ЦИБУЛИН

БАЗА ДАННЫХ ДЛЯ ПРОЕКТИРОВАНИЯ ИМС

В СРЕДЕ ПРОГРАММНОГО КОМПЛЕКСА CADENCE

На примере моделирования триггера Шмитта представлены возможности использования программного комплекса компании Cadence при подготовке студентов по техническим специальностям, связанным с проектированием схемотехники интегральных микросхем. Описанный подход реализован на кафедре микро- и наноэлектроники Белорусского государственного университета информатики и радиоэлектроники (БГУИР).

Введение Важнейшим этапом создания и вывода на рынок современных изделий электронной промышленности является проведение всестороннего, высокоточного моделирования технологии, проектирования прибора, схемы и системы. По оценкам экспертов более 90% временных и финансовых затрат от общей стоимости изделия следует отнести на этап проектирования. Кроме того, увеличение степени интеграции интегральных микросхем (ИМС) влечет постоянное развитие технологии производства, что не может не сказаться на архитектуре устройств и появлении новых функциональных узлов. В связи с этим для современного специалиста-разработчика в области микроэлектроники необходимы глубокие теоретические знания, а главное, практические навыки работы в среде современных профессиональных комплексов автоматизированного проектирования (САПР).

В Белорусском государственном университете информатики и радиоэлектроники студентам специальностей «Микро- и наноэлектронные технологии и системы» и «Квантовые информационные системы» преподается дисциплина «Информационные технологии в проектировании ИМС» и «САПР ИМС» в рамках которых проводятся лабораторные и практические занятия, целью которых является получение студентами базовых знаний и навыков по использованию программного комплекса компании Cadence [1].

Программный комплекс компании Cadence Ведущим разработчиком программного обеспечения (ПО) для проектирования аналоговых и цифровых ИМС является компания Cadence. Комплекс ПО состоит из множества программных модулей, которые могут использоваться на всех основных этапах проектирования ИМС, включая разработку и моделирование схемотехники и топологии, функционально-логическое моделирование системы, оптимизация параметров создаваемого изделия с точки зрения быстродействия и энергопотребления.

Базовым инструментом, применяемым для проектирования схемотехники аналоговых ИМС является модуль Virtuoso, в состав которого входят программа-редактор схем Virtuoso Schematic Composer, система моделирования Analog Design Environment, программа для вывода графической информации WaveScan, а также другие. В качестве программы моделирования (симулятора) схемы используется Spectre, который не является SPICE-совместимым по архитектуре, но использует подобную идеологию при описании и расчете электрических параметров исследуемой схемы. Основными характеристиками, которые исследуются инженером-проектировщиком в процессе работы со схемой и моделируются с помощью соответствующего типа анализа являются:

временная (TRAN-анализ), амплитудно-частотная (AC-анализ), переходная, или режим работы по постоянному току (DC-анализ). Кроме того, важно подобрать оптимальные номиналы и параметры компонентов схемы, используя параметрический анализ (PARAMETRIC), а также изучить влияние флуктуаций параметров (номиналов компонентов) на ее выходные характеристики посредством проведения статистического анализа в цикле Монте-Карло (MC).

В качестве набора доступных разработчику компонентов (резисторы, конденсаторы, транзисторы и т.п.) в программном комплексе Cadence используются библиотеки проектирования (в англоязычной литературе – Process Design Kit, PDK), включающие в свой состав не только электрические характеристики приборов и графическое представление символа, но и их топологическое представление, правила расположения на кристалле и верификации топологии.

Благодаря сотрудничеству с консорциумом EUROPRACTICE [2] в рамках проекта REASON Европейской комиссии [3] кафедра микро- и наноэлектроники БГУИР получила в свое распоряжение академические лицензии на использование профессиональных программных комплексов компаний Cadence, Synopsys, Silvaco и Mentor Graphics в учебном процессе и научных исследованиях.

Моделирование аналоговых схем в среде программного комплекса Cadence Типичные аналоговые (формирователи прямоугольных импульсов, мультивибраторы, сумматоры синусоидальных сигналов, формирователи коротких импульсов) и цифровые (сумматоры, счетчики, делители) схемы, анализируемые в процессе выполнения компьютерных лабораторных работ с использованием пакета Cadence, приведены в [4].

В качестве базовой библиотеки проектирования студенты и магистранты используют входящую в стандартную поставку комплекса Cadence библиотеку General Process Design Kit (GPDK), которая ориентирована на разработку ИМС с проектными нормами 0,18 мкм.

Основные этапы моделирования аналоговой схемы формирователя прямоугольных импульсов (см. рис. 1) включают графический ввод элементов схемы (компоновка), проведение основных видов анализа с выводом на экран полученных зависимостей, определение значимых характеристик и их оптимизация.

Типичная схема для исследования – формирователь прямоугольных импульсов, построенный на базе триггера Шмитта. Триггер Шмитта – электронное устройство, предназначенное для преобразования непрерывно меняющегося во времени сигнала в прямоугольные импульсы.

Рис. 1. Графический образ схемы формирователя прямоугольных импульсов Отличительной особенностью триггера Шмитта является наличие гистерезиса в передаточной характеристике, что обуславливает его применение. Ниже (см. рис. 2) представлен результат проведения анализа по постоянному току (DC).

Зависимость амплитуды сигнала от времени может быть получена посредством проведения анализа временных характеристик (TRAN-анализ) (см. рис. 3).

C помощью анализа по переменному току (AC) рассчитывается амплитудно-частотная характеристика (см. рис. 4) по которой определяется предельная рабочая частота исследуемой схемы – 300 кГц.

Рис.2. Передаточная характеристика формирователя прямоугольных импульсов в виде гистерезиса Рис. 3. TRAN-анализ формирователя прямоугольных импульсов Рис. 4. AC-анализ формирователя прямоугольных импульсов Посредством параметрического анализа можно исследовать изменение амплитуды и формы выходного сигнала в зависимости от параметров компонентов схемы, в частности вариация номинала резистора R3 в диапазоне 1-100 КОм приводит к вырождению прямоугольного импульса в синусоиду (см. рис. 5).

Рис. 5. Результат параметрического анализа формирователя импульсов в Cadence Главная страница компании Сadence [Электронный ресурс]. – Режим доступа: www.cadence.com.

Главная страница консорциума EUROPRACTICE [Электронный ресурс]. – Режим доступа:

www.europractice-ic.com.

www.reason.imio.pw.edu.pl.

Шевкун, И.М. Методические указания к лабораторной работе «Схемотехническое моделирование» / И.М. Шевкун. – Минск: БГУ, 2000. – 26 с.

Костров Александр Иванович, аспирант кафедры микро- и наноэлектроники Белоруского государственного университета информатики.

Нелаев Владислав Викторович, профессор кафедры микро- и наноэлектроники Белоруского государственного университета информатики, [email protected].

Стемпицкий Виктор Романович, доцент кафедры микро- и наноэлектроники Белоруского государственного университета информатики, [email protected].

Цибулин Федор Леонидович, студент 4-го курса факультета радиоэлектроники Белоруского государственного университета информатики, [email protected].

УДК 004.932 + 519.

РАЗРАБОТКА ВИДЕОДЕТЕКТОРА ДВИЖУЩИХСЯ ОБЪЕКТОВ

С ИСПОЛЬЗОВАНИЕМ БИБЛИОТЕКИ INTEL OPENCV

В работе выполняется разработка математической модели видеодетектора движущихся объектов, работающего для статических видеокамер и его программного обеспечения с использованием библиотеки Intel OpenCV. По результатам исследования отмечается высокое качество видеодетекции и быстродействие разработанной программы, а также простота ее реализации.

Введение В современных мультимедиа приложениях работающих с изображениями и видео все чаще используются сложные математические алгоритмы обработки изображений и распознавания образов. Многие разработчики таких приложений заинтересованы в использовании программных модулей, которые помогали бы им решать типовые задачи компьютерного зрения. Одним из таких средств является Intel OpenCV – библиотека алгоритмов компьютерного зрения, обработки изображений и численных алгоритмов с открытым исходным кодом. Она реализована на языке C/C++ и призвана стандартизировать разработку приложений в данной области. Множество функций библиотеки позволяют выполнять базовые операции обработки числовых массивов и изображений. В частности выполнять: фильтрацию изображений, нахождение отличительных признаков изображений, анализ движения, сравнение изображений, обнаружение объектов, например лиц, восстановление изображений, морфологический анализ и многое другое.

Использование данной библиотеки позволяет упростить решение задач обработки изображений, а также добиться ускорения программ за счет подключения низкоуровневой библиотеки Intel Performance Libraries (IPP). Таким образом, в данном исследовании ставится задача разработки математической модели видеодетектора движущихся объектов, его программного обеспечения, для статических видеокамер в режиме реального времени с использованием библиотеки OpenCV.

Математическая модель детектора и его реализация В предлагаемой модели видеодетектора, являющейся уточнением модели, описанной в [1], можно выделить три стадии: сегментация движения, определение связанных областей бинарного изображения, выделение движущегося объекта и определение его параметров. Каждая из стадий на программном уровне реализует алгоритмы цифровой обработки видеоизображений, поступающих с видеокамеры в режиме реального времени. Проанализируем каждый из этапов.

Для сегментации движения предлагается использовать метод, ставший классическим и основанный на моделировании фонового изображения (Running Gaussian average) [2]. Суть метода заключается в последовательном вычислении отклонения значений пикселей каждого изображения от фоновой модели, обновляемой с течением времени. Предполагается, что каждый пиксель фонового изображения описывается случайным процессом, который описывается средним значением (математическим ожиданием) и дисперсией. Как правило, распределение вероятности случайного процесса заранее неизвестно, но многие процессы со случайными величинами можно описать с помощью распределения вероятности Гаусса. Математическое ожидание и дисперсию можно определить, не зная распределения вероятности, путем усреднения конечного числа измерений:

где X t i, j – случайный процесс в пикселе i, j изображения. Именно так в течение n первых кадров происходит инициализация фоновой модели в программе и для каждого пикселя фона вычисляется математическое ожидание и среднеквадратичное отклонение за n кадров. Принадлежность пикселя к движущемуся объекту выполняется в случае, когда разность среднеквадратичного отклонения фонового пикселя и отклонения текущего превышает определенное пороговое значение:

где p 10. Данные выражения вычисляются с помощью базовых арифметических операций языка С++, либо специализированных функций OpenCV – cvSub(), cvAdd(), cvPow(), cvInRange() и др. [3].

Для обновления фоновой модели с течением времени используется авторегрессионная модель первого порядка (выражающая зависимость некоторого состояния случайного процесса от предшествующего). Параметры и распределений Гаусса, обновляются следующим образом:

где 0,02 – для пикселей, принадлежащих фону, и 0,005 – для пикселей, принадлежащих движущемуся объекту. Для выполнения данной операции используется функция библиотеки OpenCV – cvRunningAvg() [3]. Результатом сегментации при этом является бинарное изображение, определяющее наличие или отсутствие движения в пикселе изображения. Полученная маска движения, с целью удаления посторонних шумов, может обрабатываться медианным фильтром, а также выполняться морфологическая операция закрытия (эрозия + дилатация с большим структурообразующим элементом, размером 5-7 ед.) – cvErode(), cvDilate().

На втором этапе маска движения анализируется на предмет обнаружения пространственно разделенных объектов, а также их характеристик: координат, площади и др. Для решения этой задачи, используется так называемый метод «маркирования связанных компонент» изображения.

Данный алгоритм приводит к получению массива связанных компонент, соответствующих каждому объекту (выделяемых по принципу взаимной пространственной расположенности составляющих их пикселей) в формате CvConnectedComp, с помощью функций cvSegmentMotion() [3]. После этого может проводиться их фильтрация по размеру, площади, степени заполнения.

Для вычисления таких характеристик изображения, как площадь, центр тяжести, ориентация удобно использовать моментные характеристики изображения, а также рассчитываемые на основе них моментные инварианты [4]. Моментные характеристики представляют собой некоторые взвешенные суммы пикселей изображения, характеризующие многие свойства объектов на изображении:

Например, координаты центра тяжести объекта в бинарном изображении вычисляются по следующей формуле:

где M 00 – площадь объекта.

Данные моменты вычисляются с помощью функции cvMoments(). По окончании, движущиеся объекты могут выделяться прямоугольными рамками, и выводится дополнительная информация о них.

Заключение В результате данного исследования получена математическая модель видеодетектора, а также ее программная реализация с помощью функций библиотеки OpenCV. Проведенная оценка времени работы программы на тестовых видеопоследовательностях на компьютере с процессором AMD Athlon X2 4400+, с объемом ОЗУ 2Гб, (среда разработки – Bloodshed Dev-C++ 4.9.9.2, захват видео реализован с помощью OpenCV), показывает, что даже для изображений с разрешением 800х600 время обработки одного кадра составляет – 35 мс.

На рис. 1 и рис. 2 приведен результат работы программы, а также результат сегментации движения тестовой видеопоследовательности. Определены и выведены координаты центров объектов, площадь, а также описанные вокруг них прямоугольники. По результатам исследования отмечается высокое качество видеодетекции и быстродействие разработанной программы, а также простота ее разработки с использованием OpenCV.

Рис. 1. Изображения видеопоследовательности с выделением движущихся объектов Рис. 2. Изображения видеопоследовательности с выделением движущихся объектов Краснобаев, Е.А. Моделирование оптических систем автоматического сопровождения и целеуказания / Е.А. Краснобаев // 4-я Международная научная конференция по военно-техническим проблемам, проблемам обороны и безопасности, использованию технологий двойного применения, MILEX 2009:

материалы Междунар. науч. конф., Минск, 20–21 мая 2009 г. / ГУ «БелИСА»; редкол.: В.Е. Кратенок [и др.]. – Минск, 2009 – С. 102–104.

Краснобаев, Е.А. Адаптивная модель фона в задачах сегментации движущихся объектов в видеоизображениях / Е.А. Краснобаев, А.Ю. Халанский // Молодежь и наука в XXI веке: сб. ст.

молодых ученых. Вып. 3 / Вит. гос. тех. ун-т; под ред. В.М. Мироненко [и др.]. – Витебск, 2008. – Bradski, G. Learning OpenCV / G. Bradski, A. Kaehler, – O'Reilly, 2008 – 576 p.

4. Flusser J., Suk T. Rotation Moment Invariants for Recognition of Symmetric Objects, IEEE Trans. Image Proc.

– 2006. – Vol. 15. – P. 3784–3790.

Краснобаев Евгений Алексеевич, преподаватель, аспирант кафедры инженерной физики Витебского государственного университета имени П.М. Машерова, [email protected].

УДК 004.

УПРАВЛЕНИЕ ЭФФЕКТИВНОСТЬЮ РАБОТЫ

РАСПРЕДЕЛЕННЫХ SCRUM-КОМАНД

В данной статье рассматриваются особенности распределенных команд, работающих по методологии SCRUM через призму итеративного процесса разработки. Предлагаются показатели эффективности, основанные на временных метриках и предназначенные для оценки организации работ на всем протяжении итерации, а также подходы, направленные на минимизацию рисков, которые связаны с неэффективной занятостью членов команды в течение итерации.

Введение C целью повышения конкурентоспособности программной продукции, когда необходимо не только выпустить качественное программное средство, но и сделать это раньше конкурентов, все больше компаний рассматривают целесообразность перехода на новые гибкие методологии разработки ПО, а многие уже адаптировали и практикуют их в реальных проектах. Специальное исследование [1], проведенное компанией Forrester в 2009 году, показало, что 35% опрошенных специалистов ведущих ИТ компаний на постоянной основе и успешно применяют гибкие методологии.

При этом, в компании Yahoo! к 2008 году гибкие методологии разработки ПО и SCRUM были адаптированы и применялись в более чем 150 командах в США, Европе и АзиатскоТихоокеанском регионе [2]. Компания IBM сообщала [3] об успешном ведении 25% своих внутренних проектов в соответствии с тем или иным видом гибкой методологии разработки ПО.

Несмотря на многообразие существующих гибких методологий, широкое распространение получила методология SCRUM, которая, специализируясь на управлении и организации процессом разработки, сочетается [4] с методологиями, ориентированными на инженерные практики, например, XP и TDD. Жесткие двух-шестинедельные рамки [4] итераций, на протяжении которых реализуется работы процесса разработки, вынуждает SCRUM-команду ориентироваться на реализацию только полезных и важных заказчику требований (историй) и, снижая сложность ПО, выпускать его работоспособные версии на регулярной основе.

SCRUM, благодаря своей относительной простоте и адаптируемости, используется также в компаниях, предоставляющих услуги по разработке и тестированию ПО. Результатом является создание распределенных SCRUM-команд, для которых нередко характерны проблемы географической удаленности, разности часовых поясов, различия культур и применяемых практик. Кроме того, декомпозиция требований (историй) на задачи, назначаемые как минимум двум различным членам команды, всячески стимулирует их к сотрудничеству, постоянному отслеживанию зависимости своих задач от результатов работы других.

Термины и определения L – число историй, выбранных для реализации в рамках текущей итерации.

USk – одна из L историй.

TAk,i – одна из задач, формирующих историю USk.

AM k,i – исполнитель, член команды, назначенный для выполнения конкретной задачи TAk,i. Несмотря на то, что в рамках USk выполнения истории два исполнителя AM k,i и AM k, j могут являться одним и тем же действительным членом команды, подобное формальное разделение является удобным при рассмотрении зависимости задач.

Взаимоотношения истории, задач и исполнителей в рамках одной итерации, как «история USk, состоящая из задач TAk,i | i 1, N k, каждая из которых назначена одному из исполнителей | i 1, N k », могут быть представлены следующим двумерным массивом, количество элеk,i ментов в каждой строке которого может быть различным и определяется исключительно декомпозицией истории:

Поскольку объем работ для каждого члена команды выражается в единицах времени (часах, днях), то показатель времени, требующегося исполнителю для завершения задачи, будет отражать риски, связанные с несвоевременным выполнением запланированных работ.

Подобным показателем является временная функция ToDo TAk,i, AM k,i, которая рассчитывает время, необходимое исполнителю AM k,i для завершения задачи TAk,i, если бы он приступил к ее выполнению в данный момент времени. Как правило, для хорошо оцененных исполнителем задач функцию ToDo можно рассматривать как невозрастающую в рамках итерации.

Формализация рисков Определим функцию D TA TAk,i как такое подмножество задач истории US k, что начало работ над задачей TAk,i непосредственно зависит от результатов их выполнения в порядке логического следования. Для каждой задачи TAk,i следует проанализировать на наличие зависимостей множество следующего вида: TAk,1, TAk, 2,, TAk,i 1. Подобный анализ содействует построению очередности выполнения задач.

Наибольшую угрозу выполнению планов итерации в жесткие временные рамки представляет неэффективное использование рабочего времени члена команды в результате незапланированных простоев. Так, время ожидания можно определить как целевое значение, оцениваемое для конкретного исполнителя AM k,i, приступающего к выполнению задачи TAk,i :

Очевидно, что эффективная последовательность выполнения задач имеет место, когда функция TWait принимает минимальное значение для исполнителя AM i в рамках всех L историй:

Рассчитанное оптимальное значение TOptWait позволяет определить историю и задачу, на выполнение которой следует переключиться исполнителю AM i.

Оптимальное значение Значение TOptWait можно применять как статический показатель после сессии планирования итерации, когда заданы ToDo-оценки, для того чтобы сформировать первоначальную последовательность выполнения задач.

Функция TOptWait динамична по своей природе, поскольку основана на функции ToDo. Поэтому следует проводить ежедневный анализ значения TOptWait, чувствительного ко времени, которое осталось до завершения работ над задачей, с целью возможной корректировки последовательности выполнения задач.

Подходы к минимизации рисков С целью минимизации рисков, связанных с неэффективной занятостью члена команды в течение итерации, следует выполнять ряд мероприятий.

На этапе планирования итерации необходимо решение задачи, значение TOptWait для которой минимально.

На этапе работы над историями и задачами итерации следует:

осуществлять пересчет значений TOptWait. Определить иерархию зависимости задач для каждой конкретной задачи в рамках истории, основываясь на предварительной информации о задаче. На данном шаге определяется подмножество задач DTA TAk,i ;

рассчитать начальные значения TOptWait для каждого члена команды. Данные значения должны равняться нулю. В противном случае, необходимо пересмотреть назначенные исполнителям задачи;

осуществить выбор каждым членом команды Частота пересчета значений зависит от динамики функции ToDo. На ежедневно проводимых SCRUM-совещаниях предполагается, что каждый член команды отразит изменение объема работ для своих задач. Таким образом, оптимальная частота пересчета значений – ежедневно;

по завершении задачи членом команды осуществить переход к выполнению следующей задачи, руководствуясь одним из алгоритмов.

Алгоритмы выбора очередной задачи для выполнения:

алгоритм невытесняющей работы над задачей. Член команды приступает к выполнению очередной задачи, как только завершены все работы над текущей;

алгоритм свободного переключения между задачами. Член команды может начать работу над новой задачей из списка назначенных ему в рамках итерации, когда это становится необходимым. В случае незавершения, работы над текущей задачей приостанавливаются на некоторое время.

В отличие от предыдущего, данный подход достаточно гибок, поскольку чувствителен и позволяет адаптироваться к возможной динамике приоритетов задач. Тем не менее, имеют место задачи, прерывание выполнения которых может впоследствии оказать негативное воздействие на качество их выполнения;

смешанный подход. Переключение на выполнение новой задачи происходит только в том случае, если целевая задача принадлежит истории более высокой важности.

Заключение Таким образом, предложенный в данной статье формальный подход к оценке рисков, связанных с неэффективной организацией выполнения работ в распределенных SCRUM-командах, позволяет сформировать эффективную последовательность выполнения задач для каждого члена команды, а также проводить корректировку такой последовательности в течение всей итерации.

Grant, T. From Agile Development To Agile Engagement [Электронный ресурс] / T. Grant // Forrester from_agile_development_to_agile_engagement/q/id/53565/t/2. – Дата доступа: 28.03.2010. – Режим доступа: http://www.slideshare.net/rsrivastava91/forrester-agile. – Дата доступа: 28.03.2010.

2. Benefield, G. Rolling out Agile in a Large Enterprise / G. Benefield // Proceedings of the 41st Hawaii International Conference on System Sciences, 7-10 January 2008. – IEEE Computer Society – 2008. – 461 p.

Kanaracus, C. IBM employs 'agile' methodology [Электронный ресурс] / C. Kanaracus // ComputerworldUK, – Режим доступа: http://www.computerworlduk.com/management/infrastructure/applications/news/ index.cfm?newsid=6286. – Дата доступа: 28.03.2010.

Kniberg, H. Scrum and XP from the Trenches / H. Kniberg. – C4Media, 2007. – 140 p.

Кузиков Александр Александрович, аспирант Белорусского государственного университета информатики и радиоэлектроники, магистр технических наук, [email protected].

УДК 004. А.И. КУЧЕРОВ, В.Н. КУЛИНЧЕНКО, С.А. БАРСУКОВ, С.В. ДРОБЫШЕВСКИЙ, М. ГУЛЕВИЧ

МОНИТОРИНГ ПОЛЬЗОВАТЕЛЬСКОЙ РАБОЧЕЙ НАГРУЗКИ

НА УЗЛАХ КОРПОРАТИВНОЙ СЕТИ

Статья посвящена проблеме идентификации личности пользователей в корпоративных сетях на основе мониторинга пользовательской рабочей нагрузки.

Введение Человек в своей повседневной деятельности все чаще и чаще использует компьютерную технику и коммуникационное оборудование. В настоящее время все больше и больше оборудования объединяется в сетевые структуры различных стандартов и типов. Будь то локальные, корпоративные, городские или глобальные сети. В процессе своей деятельности человек – пользователь использует различные сетевые ресурсы и в свою очередь создает различные компьютерные продукты: документы, чертежи, программы, мультимедиа и др. Каждый сетевой ресурс и программный продукт, является собственностью определенного человека или группы лиц и в конечном итоге может быть собственностью предприятия. Поэтому возникает необходимость обеспечения сохранности создаваемых программных продуктов. Для этих целей используется огромное множество программных и аппаратных продуктов. Но основной и первоначальной задачей, является обеспечение достоверной идентификации пользователя. Для этих целей операционная система предоставляет большие возможности, но их не достаточно, так как они широко известны злоумышленнику.

Разграничение прав доступа пользователей Каждый пользователь или группа пользователей в операционной системе обладают определенными правами. Действия, которые пользователь может выполнять в операционной системе, строго определены и описаны. В общем случае возможностей у пользователя много. Пользователь может выполнять большое количество различных операций, на которые он может иметь или не иметь прав. Эти операции связаны как с работой на локальном компьютере, так и при работе в сетевой среде.

Чем выше привилегии пользователя, тем выше у него права и соответственно возможности. Всеми правами в операционной системе обладают только администраторы системы. Для управления правами пользователей в операционной системе в настройках имеется возможность администрирования, где можно назначить права пользователя.

Пользователь может выполнять большое количество действий. Но не все из них пользователь имеет право и должен выполнять. А информация может быть как общего, личного, так и служебного использования.

Для повышения дисциплины руководство организаций и предприятий должно иметь возможность управлять правами пользователей локальной вычислительной сети и следить за выполнением их служебных обязанностей. Обеспечить эти возможности предназначено, как встроенное в операционную систему, так и другое системное программное обеспечение.

Разработка программного комплекса На первом этапе разработки программного обеспечения создан программный продукт, позволяющий автоматизировать действия администратора корпоративной сети по регистрации пользователей на контроллере домена.

Для предоставления доступа к ресурсам сети необходимо использовать средства операционной системы, которые позволяют разграничить права пользователей на используемые данные.

Операционная система является связующим звеном между электронными средствами и пользователем. Вся информация хранится в электронном виде на компьютерах.

Разграничением прав доступа пользователей к различной информации занимается администратор корпоративной сети. Для осуществления своей деятельности ему необходимо обрабатывать большие объемы информации, содержащей сведения о компьютерах и пользователях корпоративной сети. На рисунке 1 представлена схема традиционной работы администратора корпоративной сети.

Рис. 1. Структура неавтоматизированной работы администратора сети средствами операционной Для усовершенствования работы администратора сети по разграничению прав доступа пользователей к информационным ресурсам сети используется автоматизированная система, которая позволит уменьшить ошибки, сбои и дублирование служебной информации в работе администратора и операционной системы. На рисунке 2 представлена схема работы администратора сети посредством автоматизированной системы.

Автоматизированная системой реализуются следующие задачи:

ввод первичной информации в БД Active Directory;

модификация, удаление устаревшей информации;

ввод вторичной информации;

репликация БД Active Directory;

поисковые запросы в БД Active Directory;

вывод результатов поиска по запросам;

создание личных папок пользователей корпоративной сети;

разграничение прав доступа к вычислительным ресурсам корпоративной сети;

ведение аудита входа и выхода на рабочей станции;

ведение аудита использования сетевых ресурсов;

автоматизация ввода вторичной информации;

автоматизация модификации и удаления устаревшей информации.

информация Служебная информация

ДОСТУП

администратора Рис. 2. Структура автоматизированной работы администратора сети На втором этапе разработки программного обеспечения предполагается создать программный комплекс дополнительной идентификации пользователей корпоративной сети, через сбор информации о них на узлах сети и формирование идентификационного портрета пользователя.

В качестве узлов сети принимаем персональные компьютеры, соединенные по средствам сетевой среды, выполненной по одной из топологий. Рабочая нагрузка на узлах сети состоит из рабочей нагрузки, создаваемой операционной системой, и рабочей нагрузки, создаваемой пользователями вычислительной системы. В процессе функционирования операционной системы на узле сети порождается рабочая нагрузка по средствам системных процессов. Кроме этого пользователь вычислительной системы по роду своей деятельности выполняет различные задачи, которые в операционной системе представляются как пользовательские процессы. Пользователь может использовать следующие программные приложения:

офисные пакеты;

бухгалтерские пакеты;

интернет;

графические пакеты;

мультимедиа;

языки программирования;

специализированные и т.д.

Программный комплекс дополнительной идентификации пользователей корпоративной сети будет строиться на основе модульного принципа разработки приложений. Каждый модуль будет выполнять одну определенную функцию, что позволит уменьшить влияние одного программного модуля на другой. Это позволит создать более гибкий и легко расширяемый по функциям программный модуль. Программные модули будут собирать информацию о действиях пользователей, например:

скорость набора на клавиатуре (количество символов в единицу времени);

скорость кликов на каждой кнопке манипулятора типа «мышь»;

запускаемые приложения;

время входа в узел сети;

время выхода из узла сети;

время блокировки пользователем узла сети;

время простоя узла сети и т.д.

Исходя из собранной информации, создается идентификационный портрет пользователя корпоративной сети. Идентификационные портреты пользователей будут храниться в базе данных, и сравниваться с текущей информацией о пользователе. Если сохраненный идентификационный портрет пользователя существенно не совпадает с текущей информацией о пользователе, то с определенной долей вероятности система дополнительной идентификации пользователей корпоративной сети принимает решение, что на узле сети работает пользователь, выдающий себя за другого пользователя. Санкции, применяемые к таким нарушителям, определяет администрация организации, которая будет использовать создаваемый программный комплекс.

Перспективы дальнейшей разработки Кроме того из собранной информации можно делать и другие выводы. Например, сколько каждый узел сети работает в течении дня, недели, месяца и т.д. От этого будет зависеть, как часто необходимо проводить профилактические работы с тем или иным узлом.

При дальнейшей разработке программного комплекса будут уточняться цели и задачи создаваемой системы.

Дробышевский, С.В. Функциональные возможности приложения для анализа работы пользователей в сетевой среде / С.В. Дробышевский, Д.Б. Винглевский, А.И. Кучеров // Материалы XII Республиканской научной конференции студентов и аспирантов «Новые математические методы и компьютерные технологии в проектировании, производстве и научных исследованиях» / ГГУ им. Ф. Скорины. – Гомель, 2009. – С. 195–196.

Шуман, Е.А. Проверка идентифицированного пользователя на предмет соответствия личности / Е.А. Шуман, А.И. Кучеров / Материалы XII Республиканской научной конференции студентов и аспирантов «Новые математические методы и компьютерные технологии в проектировании, производстве и научных исследованиях» / ГГУ им. Ф. Скорины. – Гомель, 2009. – С. 259–260.

Воруев, А.В. Удаленный контроль и управление процессами в локальных сетях / А.В. Воруев, О.М. Демиденко, А.И. Кучеров // Известия Гомельского государственного университета им. Ф. Скорины. – Гомель. – 2007. – № 5 (44). – С. 98–100.

Кучеров Александр Иванович, магистрант кафедры автоматизированных систем обработки информации физического факультета Гомельского государственного университета имени Франциска Скорины, [email protected].

Кулинченко Владимир Николаевич, аспирант кафедры автоматизированных систем обработки информации физического факультета Гомельского государственного университета имени Франциска Скорины, [email protected].

Борсуков Сергей Александрович, магистрант кафедры автоматизированных систем обработки информации физического факультета Гомельского государственного университета имени Франциска Скорины.

Дробышевский Станислав Витальевич, магистрант кафедры автоматизированных систем обработки информации физического факультета Гомельского государственного университета имени Франциска Скорины.

Гулевич Михаил Сергеевич, магистрант кафедры автоматизированных систем обработки информации физического факультета Гомельского государственного университета имени Франциска Скорины.

УДК 004.

ЗАДАЧИ УПРАВЛЕНИЯ ПРОЕКТОМ

НА ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ

Статья посвящена технологическим аспектам использования системы моделирования MICIC4 при реализации проектов на имитационное моделирование сложных дискретных систем. Обсуждаются достоинства многоуровневой структуры программы модели. Предложены формы интеграции моделей в информационную систему заказчика.

Введение Имитационные модели (ИМ) по своей природе не являются самодостаточными программными продуктами. Они могут идеально дополнять программное обеспечение заказчика блоком решения задач исследования функционирования сложной системы или даже ее управления. Следовательно, разрабатываемые ИМ должны обеспечивать гибкий интерфейс с базой данных предметной области, вызываться на выполнение из внешней программной среды, импортировать результаты имитационного эксперимента в информационную систему заказчика, ориентированную на автоматизацию принятия управленческих решений. Необходимость решения данных задач учитывалась при проектировании системы моделирования MICIC4 [1]. Ключевая проблема заключается в том, что существующие информационные системы отличаются большим разнообразием возможностей по способам взаимодействия с ними.

Достоинства многоуровневой структуры имитационной модели Функционирование сложной дискретной системы необходимо рассматривать на нескольких уровнях. Для каждого уровня специалистам следует разрабатывать соответствующую модель.

MICIC4 автоматизирует решение следующих задач при реализации проекта на моделирование:

создание концептуальной модели, отражающей, в первую очередь, взгляд на объект моделирования со стороны коллектива заказчика;

преобразование концептуальной модели в формальное описание системы, соответствующее представлениям аналитика и служащее исходным заданием для программиста;

кодирование и отладка механизмов информационного взаимодействия отдельных элементов ИМ;

описание вариантов использования ИМ, т.е. схемы постановки, реализации и обработки результатов имитационного эксперимента;

демонстрация результатов моделирования и их следствий заказчикам проекта на моделирование.

Центральное место в данной иерархии задач занимает этап программирования ИМ. Языки имитационного моделирования включают в себя конструкции, соответствующие определенной базовой схеме формализации, и по синтаксической основе подразделяются на три категории: 1) с собственным синтаксисом (поставляются компилятор и средства отладки программ-имитаторов);

2) препроцессоры к языку моделирования или универсальному языку программирования;

3) вложенные в универсальный язык программирования (строятся на основе средств проблемной ориентации базового языка, представляя собой библиотечный модуль).

Поскольку в настоящее время существуют развитые технологии программирования, последняя категория языков моделирования широко распространена. В этом случае от программиста не требуется дополнительно изучать новый язык моделирования, детально вникать в синтаксические конструкции, приобретать опыт отладки и верификации программ ИМ. Он будет использовать привычный ему полнофункциональный инструментарий интегрированной среды разработки приложений на универсальном языке программирования.

Данная группа языков моделирования по форме является библиотекой функций, объектов, шаблонов и т.п. Язык моделирования MICIC4 также принадлежит этой группе и «его интерфейс реализован» системным модулем на объектно-ориентированном языке программирования С++.

Системный модуль можно оттранслировать независимо от других модулей, описывающих взаимодействие составных элементов сложной дискретной системы и постановку имитационного эксперимента, а затем включать в проект любой ИМ.

Таким образом, для написания программ ИМ с помощью MICIC4 разработчик модели должен владеть универсальным языком программирования С++, а также изучить программный интерфейс, являющийся отображением базовой схемы формализации MICIC4.

В процессе написания программы ИМ участвуют три класса специалистов. Аналитик занимается постановкой экспериментов с некоторым семейством моделей, которое в обобщенном виде создает программист, и обработкой результатов моделирования. Все множество ИМ соответствует концептуальному описанию исходной системы. Программист использует тот интерфейс, который предоставляет ему разработчик MICIC4. То есть именно программист, активно использующий язык моделирования для определения структуры ИМ и описания информационного взаимодействия элементов в общем виде, должен владеть технологией объектно-ориентированного программирования. Программный интерфейс является постоянным и функционально полным в рамках базовой схемы формализации MICIC4, что позволяет создавать ИМ различных по своей природе объектов моделирования.

В силу того, что разработчик МICIC4 всегда один и тот же, системный модуль является уникальным и неизменным для всех ИМ, написанных на языке моделирования MICIC4. Так как в любом эксперименте независимо от конкретной структуры ИМ ее элементы взаимодействуют по фиксированным алгоритмам, то информационный модуль, создаваемый программистом, соответствует определенной концептуальной модели. Наконец, с одной и той же ИМ можно решить различные задачи, поставив произвольное количество экспериментов. Поэтому аналитик наиболее подходящим образом формирует способы постановки планов экспериментов и обработки результатов моделирования, определяя функциональные модули ИМ на основе одного и того же информационного модуля. Таким образом, в соответствии с поставленными задачами в языке моделирования MICIC4 предлагается трехмодульная структура программы ИМ. Назначение каждого модуля представлено в таблице.

Таблица – Назначение модулей в программе на языке MICIC Функциональный Определение и реализа- – Определение глобальных данных ция эксперимента с моИнициализация параметров модели Информационный Описание информаци- – Определение иерархической структуры ИМ Системный Предоставление интер- – Реализация базовых классов для компонентов модели, статистики, откликов, постановки эксперимента и стохастических потоков Предложенная структура обеспечивает гибкий механизм интеграции ИМ и информационной системы заказчика путем прямого импорта функционального модуля или реализации программного интерфейса к нему. Прямой импорт возможен при совместимости инструментальных средств разработки информационной системы с языком программирования С++. Открытый код MICIC4 предоставляет неограниченные возможности по адаптации ИМ под решение поставленных задач. Объектные модули программы ИМ компактны и, как следствие, им достаточно ресурсов компьютера (в том числе для учета взаимодействия элементов системы на высоком уровне детализации).

При отсутствии совместимости информационной системы с языком С++ следует задействовать возможности MICIC4 по экспорту/импорту данных. В ней реализованы множества классов для генерации стандартных и пользовательских отчетов, предоставляются надстройки для обработки и отображения результатов моделирования.

Интеграция имитационных моделей Одним из возможных путей реализации ИМ для упрощения ее интеграции в информационную систему заказчика является построение программы модели в виде информационного модуля, который импортируется в различные контейнеры, реализованные по правилам построения функционального модуля [2]. В качестве контейнеров для имитационной модели могут выступать консольное приложение, web-приложение, приложение с графическим интерфейсом пользователя, АСУ заказчика.

Реализация программы ИМ с использованием в качестве контейнера консольного приложения является простейшим и одновременно эффективным способом. Обмен данными обеспечивается через текстовые файлы. Их структура адаптируется для непосредственного открытия в требуемых приложениях. Примером такой реализации может выступать текстовый файл входных параметров, настроенный на открытие в табличном процессоре Excel.

Вторым примером возможной реализации контейнера программы ИМ является Win приложение с графическим пользовательским интерфейсом. В таком случае пользователь получает оконное приложение, в элементы управления которого заносятся значения параметров и переменных ИМ. Нажатие кнопки приводит к запуску процесса моделирования, по окончании которого результаты помещаются на отдельной вкладке. Использование такого контейнера позволяет несколько упростить интерактивное взаимодействие пользователя с моделью, позволяя оперативно вручную изменять входные данные и анализировать поведение модели.

Третьим примером возможной реализации ИМ является использование web-технологий. В этом случае в web-сервер встраивается функциональный модуль ИМ, а взаимодействие с моделью происходит через сеть.

Визуализация на этапах реализации проекта Общеизвестно, что большую часть информации человек воспринимает через зрительные органы. Не удивительно поэтому, что визуализация стала частью имитационного моделирования с самого начала зарождения данного научного направления. Более того, известно множество специализированных средств, где написание программы модели существенно облегчается при представлении функционирования объекта либо его подсистем в форме некоторой графической схемы. Это замечание справедливо также для MICIC4. В ее основе находится базовая схема формализации сложной дискретной системы, где большинство положений имеет наглядную графическую интерпретацию.

Так, статическая структура объекта моделирования представляет собой дерево. Горизонтальные связи между вершинами дерева (обслуживающими устройствами) соответствуют некоторым маршрутам следования динамических единиц – транзактов. Механизм обслуживания транзакта на устройстве есть множество активностей, которое также удобно представить графом. Естественно, для повышения уровня автоматизации имитационного моделирования в среде MICIC4 апробируются следующие идеи:

отображения в графическом приложении процессов первичного изучения, формализации и будущей презентации сложной системы и результатов ее моделирования;

объединения формального описания с созданием программы модели путем преобразования графических образов в соответствующие языковые конструкции языка моделирования MICIC4;

отображения динамики функционирования ИМ в рамках разработанной формальной модели для ее наглядной верификации.

Следует, однако, отметить, что стремление использовать богатые функциональные возможности мощных графических продуктов может легко привести к зависимости от этих систем и нерациональным затратам времени. Поставив задачу использования графического материала, например, для отображения структуры ИМ, необходимо найти эффективный путь ее решения знакомыми и несложными средствами, обеспечив при этом доступ к созданным образам. Это особенно важно, поскольку, как показывает практический опыт, процесс подготовки уникальной в некотором смысле презентации, демонстрации и внедрения моделирующего комплекса у заказчика в итоге занимает большую часть работы в целом. Поэтому для реализации проекта в системе моделирования MICIC4 разработаны на основе языка UML специализированные средства, обеспечивающие необходимую для имитационного моделирования функциональность и позволяющие избежать указанные выше трудности.

Заключение Рассмотрение имитационной модели как части информационной системы заказчика создает предпосылки для успешного внедрения проекта на имитационное моделирование. Управление данным проектом обеспечивается при разделении программы имитационной модели на уровни, соответствующие ролям исполнителей проекта. Реализованная под руководством автора статьи система моделирования MICIC4 позволяет эффективно решать задачи управления проектом на имитационное моделирование.

Левчук, В.Д. Базовая схема формализации системы моделирования MICIC4 / В.Д. Левчук // Проблеми програмування. – 2005. – №1. – С. 85–96.

Левчук, В.Д. Постановка имитационных экспериментов средствами системы моделирования MICIC4 / В.Д. Левчук // Известия ГГУ им. Ф. Скорины. – 2005. – №5. – С. 18–21.

Левчук Виктор Дмитриевич, зав. кафедрой автоматизированных систем обработки информации Гомельского государственного университета имени Франциска Скорины, кандидат технических наук, доцент, [email protected].

УДК 004.

РАСШИРЕНИЕ КОМАНДЫ РАЗРАБОТЧИКОВ ПРОГРАММНЫХ СРЕДСТВ

В статье предлагается механизм расширения команды разработчиков программных средств путем выстраивания горизонтальной или вертикальной иерархии. Данных механизм описан формально на основе теории графов. Приведены критерии для выбора оптимальной в заданных условиях модели ролей команды разработчиков.

Эффективная разработка программных средств (ПС) предполагает четкое определение ролей команды разработчиков и связей между ними. Когда с конкретным членом команды ассоциирована определенная роль, его персональная ответственность растет [1]. Наиболее распространенными моделями ролей команды разработчиков на сегодняшний день являются такие, как модель MSFT (Microsoft Solutions Framework Team Model – модель команды каркаса решений Майкрософт) [2], модель OPEN (Object-oriented Process, Environment and Notation – объектно-ориентированный процесс, среда и нотация) [3], модель команды XP (Extreme Programming – экстремальное программирование) [4].

Как правило, существующие модели команд разработчиков выделяют следующие уровни ролей:

управляющие роли (например, менеджер продукта или менеджер проекта);

исполняющие роли (например, тестировщик или программист).

Члены управляющих ролей уполномочены принимать решения. Именно они определяют дальнейшую стратегию развития проекта. Безусловно, они несут и большую ответственность, чем представители других ролей.

Однако существующие модели команд разработчиков – статические, то есть содержат фиксированный набор ролей, на основании которого и строится команда разработчиков в зависимости от условий проекта. В отличие от такого подхода, в данной работе предлагается механизм расширения ролей команды. Предлагается два пути расширения:

расширение по горизонтали;

расширение по вертикали.

Расширение по горизонтали означает добавление новых равноправных ролей. Например, на рисунке 1 приведен пример добавления новой роли бизнес-аналитика Vb, смежной с вершиной менеджера проекта Vm.

Роль бизнес-аналитика равноправна с ролями программиста и тестировщика, поэтому речь идет о выстраивании горизонтальной иерархии. Формальным признаком расширения по горизонтали является подчинение общей управляющей роли. Такое расширение является локальным, так как оно определяет связь родственных ролей (или групп ролей). Например, при добавлении новых ролей к роли бизнес-аналитика Vb нельзя говорить о расширении по горизонтали, так как роли программиста и тестировщика не имеют общих прямых связей с данными ролями. Другими словами, роли будут находиться на одном уровне по горизонтали тогда и только тогда, когда подчинены одной и той же управляющей роли и длина маршрута между любыми двумя вершинами, представляющими такие роли, равна 2.

Расширение модели по вертикали означает определение новых управляющих ролей. На рисунке 2 приведен пример расширения предлагаемой в данной работе модели новой управляющей ролью ведущего программиста.

Для графа на рисунке 2 вершина Vd соответствует новой управляющей роли ведущего программиста. Этой роли подчиняются роли Vd1 и Vd2. На практике это может означать, например, существование отдела разработки клиентской части ПС (Vd1) и отдела разработки серверной части ПС (Vd2), которые подчиняются ведущему программисту (Vd), выполняющему интеграцию компонентов ПС. Формальным признаком расширения по вертикали является добавление вершин со степенью 1 (для графа на рисунке 2 deg(Vd1 ) deg(Vd 2 ) 1).

Для выбора оптимальной в заданных условиях модели ролей команды разработчиков в данной работе предлагается использовать диаметр графа d (для графа на рисунке 2 d=4) и степень вершин deg(V1 ), deg(V2 ),..., deg(VN ), где N – количество вершин графа (для графа на рисунке N=6). Диаметр d графа определяет оперативность работы команды. Чем больше диаметр, тем больше звеньев в модели, и, следовательно, тем больше времени требуется на обмен информацией между членами команды. Степень i-й вершины deg(Vi ), i 1, N определяет ее нагрузку. При чрезмерном увеличении степени вершины эффективность работы звена снижается.

Подводя итог вышесказанному, в данной работе предложен механизм расширения модели ролей команды разработчиков. Суть его состоит в выстраивании вертикальной или горизонтальной иерархии. Приведены критерии выбора оптимальной в заданных условиях модели ролей команды разработчиков. Применение на практике предложенного механизма позволит обеспечить более высокое качество разрабатываемых ПС.

1. Dubinsky, Y. and Hazzan, O. Roles in Agile Software Development Teams, Fifth International Conference on Extreme Programming and Agile Processes in Software Engineering, Garmisch-Partenkirchen, Germany, 2004. – 57-165 pp.

Анализ требований и создание архитектуры решений на основе Microsoft.NET. Учебный курс MCSD. / пер. с англ. – М.: Издательско-торговый дом «Русская Редакция», 2004 – 416 с.

Firesmith, D. The OPEN Process Framework. An Introduction. / D. Firesmith, B.Henderson-Sellers. – Addison-Wesley, 2001. – 272 pp.

Hunt, J. Agile Software Construction / J. Hunt –Springer-Verlag London Limited, 2006, – 254 pp.

Неборский Сергей Николаевич, аспирант Белорусского государственного университета информатики и радиоэлектроники, магистр технических наук, [email protected].

УДК 681.3.06+347.78.

О РАЗРАБОТКЕ ПРИЛОЖЕНИЙ СРЕДСТВАМИ MICROSOFT OFFICE EXCEL

В статье описываются рекомендации и примеры по профессиональной разработке пользовательских приложений в Microsoft Office Excel (версий 12 и 14) с использованием VBA. Особое внимание уделяется возможностям нового формата Microsoft Office Open XML., рекомендациям по настройке пользовательского интерфейса с использованием RibbonX-кода.

Введение Многие задачи, связанные с экономической деятельностью, физическим экспериментом, обработкой числовых и не только данных требуют быстрой и наглядной интерпретации. Как известно, компания Microsoft предоставляет целый пакет офисных приложений, которые ориентированы, практически, на все задачи современного офиса или, например, научной лаборатории. Новая версия Microsoft Office 2010 объединяет не только приложения, направленные на обработку информации конкретного рода, но также и специальные средства, позволяющие систематизировать и совместно использовать файлы различного типа, а также изменять некоторые параметры используемых приложений.

Основной особенностью приложений, входящих в состав пакета Microsoft Office 2010, является направленность на поддержку коллективной и сетевой работы, интеграцию, анализ и обработку данных. В частности, Microsoft Office Excel, интегрированное решение корпорации Microsoft, считается лучшим на рынке современного прикладного программного обеспечения, предназначенного для обработки табличной информации.

Новые возможности Microsoft Office Excel Можно отметить следующие новые возможности, которые появились в версии Microsoft Office Excel 2007 и развиваются в Excel 2010 [1, 2].

1. Новые требования к системе.

2. Новый более простой и удобный дизайн пользовательского интерфейса.

3. Новые средства для обработки данных (инфокривые, срезы, новая надстройка «Поиск решения», анализ многомерных данных средствами OLAP и др.).

4. Более эффективные возможности форматирования данных и объектов рабочей книги.

5. Более эффективная интеграция всех компонентов Microsoft Office.

6. Улучшенные возможности совместной обработки данных.

7. Возможность работы с рабочими книгами независимо от используемого устройства и месторасположения.

8. Усовершенствованная система защиты.

9. Новые возможности для разработчика.

Рассмотрим общие подходы к разработке приложений средствами Microsoft Office Excel и примеры прикладных задач автоматизации данных.

Основные требования к разработке приложений Итак, определим основные требования к разработке приложений, которые можно реализовать в среде Microsoft Excel.

1. Определение цели разработки приложения. Прежде всего, выясняется, с какой целью создается приложение, кем и как оно будет использоваться.

2. Требования к данным – какого рода информация будет обрабатываться вашим приложением, какого формата данные будут являться входными величинами, и в каком формате будут выводиться обработанные данные.

3. Требования бизнес-логики. Определяется функциональность разрабатываемого приложения, основные требования относительно свойств приложения для реализации правил и ограничений автоматизируемых операций. Здесь требуется уточнить, например, какие алгоритмы будут составлять основу приложения, какие формулы для обработки данных будут использованы в приложении, какова последовательность для определенного рода данных в их обработке, будут ли выводиться промежуточные результаты обработки данных, необходима ли их визуализация и т.д.

4. Требования к пользовательскому интерфейсу включают требования пользовательским экранным формам разрабатываемого приложения и требования непосредственно к интерфейсу Microsoft Office Excel. Так, при создании экранных форм приложения следует учесть необходимость создания пользовательских окон, предназначенных для ввода и редактирования информации, окон, выводящих результаты обработки данных, а также необходимость создания модальных окон, отвечающих за корректность работы приложения. Что же касается интерфейсу Microsoft Excel, то здесь требуется реорганизация самой ленты, контекстного меню и всплывающих окон приложения.

5. Определение пользователей и общей политики безопасности. Здесь стоит отметить, что в последних версиях пакета Microsoft Office используется новая модель безопасности данных, которая направлена на защиту и поддержку надежных издателей, защищенных сертификатов, цифровых подписей и надежных паролей.

В общем случае, для автоматизации многих задач обработки информации достаточно использовать встроенные возможности Excel и макросы. Однако для полной автоматизации решения конкретной задачи или обработки информации определенного рода следует использовать встроенный язык VBA и возможности формата Microsoft Office Open XML.

С помощью VBA реализуется:

последовательности повторяющихся команд и условия их реализации;

комплексный анализ данных;

нестандартный диалог с пользователем, использующий необходимые диалоговые формы и обрабатывающий реакцию пользователя на события в приложении;

отдельные элементы интерфейса приложения Microsoft Excel (контекстное меню, всплывающие окна);

приложения, которые одновременно используют различные компоненты нескольких приложений;

приложения, поддерживающие коллективную работу и интеграцию с другими приложениями пакета Microsoft Office.

Настройка основного элемента пользовательского интерфейса приложения Microsoft Office Excel (версии 12 и версии 14) осуществляется непосредственно с использованием XML.

Особенности нового формата. Объектная модель Как указывалось выше, начиная с пакета Microsoft Office 2007, введен новый формат файлов – формат Microsoft Office Open XML. Наиболее отличительной его особенностью является использование новой концепции интерфейса – Ленты (Ribbon), которая заменила традиционные меню и панели инструментов и направлена на наиболее эффективное и удобное достижение намеченной цели. Кроме того, изменен стандартный формат хранения рабочей книги из двоичного формата, принятого в прежних версиях, на формат, основанный на XML. И еще одной важной характеристикой новых версий Microsoft Office Excel является существенное расширение многих системных ограничений, таких как количество строк (1048576 вместо 65536) и столбцов (16384 вместо 256) рабочего листа, неограниченно выросло количество допустимых ссылок на ячейки и количество способов форматирования ячеек.

Объектная модель Microsoft Office Excel 2010 представляет собой иерархию объектов, подчиненных одному объекту Application, который соответствует самому приложению MS Excel.

Многие из этих объектов собраны в библиотеке объектов Microsoft Excel 14.0 Object Library, однако некоторые из них, например объект Language Settings, входят в библиотеку объектов Microsoft Office 14.0 Object Library, которая является общей для всех офисных приложений.

По умолчанию, в Microsoft Office Excel 2010 доступны следующие объектные модели, реализованные в нескольких библиотеках:

библиотека объектов Microsoft Excel 14.0 Object Library – основная библиотека документов Excel, в которой хранится класс, задающий корневой объект Application, а также все вложенные классы объектов;

библиотека объектов Microsoft Office 14.0 Object Library – библиотека объектов, общих для всех приложений Microsoft Office 2010;

библиотека объектов OLE Automation (Stdole) – библиотека классов, позволяющая работать с OLE-объектами и реализовать связь и внедрение объектов;

библиотека Visual Basic for Applications – библиотека классов языка VBA, включающая все стандартные функции и константы, встроенные в язык, классы Collection и Object Browser;

проект VBAProject – проект, связанный с документом, в котором доступны созданные классы, методы, свойства, а также объекты классов стандартных библиотек.

Кроме этого, в Microsoft Office Excel 2010 используются при необходимости также и другие библиотеки. Следует отметить, что каждый объект из библиотеки Excel имеет в качестве свойства объект Application (в том числе и сам объект Application имеет свойство Application), который ссылается на активное приложение Microsoft Office Excel. Конечно же, по сравнению с предыдущими версиями, многие объекты в Microsoft Office Excel (версия 12 и версия 14) оказались скрытыми (например, FileSearch, Assistant, RoutingSlip и др.), с другой стороны появилось много новых объектов (Slicers, SparklineGroups, PivotCaches и др.), позволяющих реализовывать полнофункциональные и наглядные приложения.

Настройка пользовательского интерфейса Итак, в версии Excel 2010 существует возможность настраивать Ленту (Ribbon), используя прямое редактирование XML-файлов рабочей книги Excel и процедуры VBA. Как правило, для настройки Ленты, нам необходимо создать XML-файл, задающий конкретные параметры настройки, поместить его внутрь как часть xlsx-архива (или xlsm-архива) и добавить в текст базового XML-файла _rels/.rel ссылку с указанием расположения добавленного файла (части) в архиве.

В общем случае можно привести следующие рекомендации по настройке Ленты (Ribbon).

1. Продумайте, какой именно Ленту (Ribbon) вы хотите видеть в своем приложении: какие у вас будут вкладки – какие из имеющихся хотите скрыть, какие новые вкладки необходимо добавить; все ли группы команд на вкладках необходимы в приложении, возможно, вам следует добавить собственную группу на стандартной вкладке; какие элементы управления и команды необходимы вам в ваших создаваемых группах и вкладках.

2. Определите, какие стандартные действия будут выполнять элементы управления на ваших вкладках. Возможно, вам необходимо также написать процедуры на языке VBA, выполняющие действия, отличные от стандартных, или производящие некоторые специфические расчеты.

Заранее продумайте логику процедур и их реализацию на языке VBA.

3. Опишите пользовательский интерфейс, т.е. вашу Ленту, с использованием языка XML, например, используя программу блокнот и сохраняя этот файл соответственно с именем и расширением: customUI.xml в отдельной папке CustomUI (см., например, листинг 1).

Листинг 1. Пример описания Ленты (Ribbon) с использованием языка XML 4. Откройте рабочую книгу Microsoft Excel 2010 и в окне редактора VBA введите (при необходимости) на листе модуля требуемый код для выполнения действий тех элементов управления, которые вы размещаете на вкладках Ленты (Ribbon). Сохраните ваш файл с расширением *.xlsm. Если вы добавляете стандартные элементы управления и вам не требуется писать процедуры на VBA, достаточно просто сохранить рабочую книгу с расширением *.xlsx.

5. Измените расширение вашей рабочей книги на *.zip и добавьте в структуру архива папку CustomUI.

6. Откройте в архиве базовый XML-файл (часть) _rels/.rel и добавьте перед последним тегом ссылку с указанием расположения CustomUI.xml-файла (части) в архиве, т.е.

нижеследующий тег (см. листинг 2).

Листинг 2. Тег, содержащий ссылку с указанием расположения CustomUI.xml-файла (части) в архиве 7. Сохраните изменения в файле и а архиве. Закройте архив. Замените расширение архива *.zip на первоначальное, т.е. на *.xlsx или *.xlsm. Откройте файл измененной рабочей книги и убедитесь в изменениях, которые произошли на Ленте (Ribbon).

При настройке Ленты (Ribbon) следует также помнить:

скрывать можно стандартные вкладки и группы команд, скрыть конкретный элемент управления, расположенные в некоторой группе команд, нельзя;

теги, связанные с настройкой Ленты (RibbonX-код) вводятся с учетом регистра;

все уникальные идентификаторы (ID) элементов управления прописываются на английском языке, поэтому модификация Ленты (Ribbon) не зависит от языковой версии Excel;

все модификации Ленты (Ribbon) доступны лишь в той рабочей книге, для которой они создавались; если же нам необходимо, чтобы некоторые элементы управления были доступны для любой рабочей книги, их следует добавить на вкладку Надстройки (Add-Ins);

для элементов управления, помещаемых на вкладки Ленты (Ribbon) невозможно изменять размеры;

если мы хотим скрыть все стандартные вкладки Ленты (Ribbon) и оставить лишь собственные, достаточно установить для элемента ribbon свойство startFromScratch равным true;

можно назначить свой собственный макрос встроенному элементу управления (repurposing the control), а также отменить действие встроенного элемента управления.

Основные выводы В статье рассмотрены основные особенности Microsoft Office Excel версии 12 и версии 14.

Кроме того, определяются требования к разработке приложений средствами VBA и RibbonX-кода, а также даются рекомендации по настройке пользовательского интерфейса разрабатываемых приложений.

Walkenbach, J. Excel 2007: Power Programming with VBA / J. Walkenbach. – John Wiley and sons, 2007. – Microsoft Office Excel 2010 (Beta). Бета-версия Microsoft Office Excel 2010. – Microsoft®, 2009.

Рудикова Лада Владимировна, доцент кафедры программного обеспечения интеллектуальных и компьютерных систем факультета математики и информатики Гродненского государственного университета имени Янки Купалы, кандидат физико-математических наук, доцент, [email protected].

УДК 681.3.

РАЗРАБОТКА УНИВЕРСАЛЬНОЙ СИСТЕМЫ ДЛЯ СБОРА

И АНАЛИЗА ДАННЫХ ПРОФЕССИОНАЛЬНОЙ ДИАГНОСТИКИ

В статье обосновывается актуальность создания автоматизированной системы профессиональной диагностики, которая может использоваться в региональных центрах тестирования. Система предполагает наличие соответствующих модулей: тестирования и анализа диагностического профиля, выявления статистических зависимостей, составления прогнозов.

Определяются основные подходы к созданию универсальных систем такого рода.

Введение Профессиональная деятельность занимает в жизни человека одно из главных мест. Однако выбор профессии, особенно в молодом возрасте, не всегда очевиден и прост. В современном мире, когда появились новые направления и тенденции в сфере жизни, деятельности и творчества, молодой человек часто оказывается в затруднительной ситуации. В подобных случаях на помощь приходят различные профориентационные центры, в которых квалифицированные специалисты с помощью разработанных методик помогут рассмотреть какие качества индивида, навыки, умения и интеллектуальные способности требуются в той или иной профессии. И, соответственно, дадут ориентир в мире профессий, исходя из их индивидуальных качеств человека.

Соответствие между психологическими особенностями человека и соответствующими характеристиками профессии поможет проследить тестовая система, включающая вопросы на оценку интересов и личностных качеств, а также задания на оценку уровня развития способностей. Более того, такого рода система позволит совместить анализ интересов, способностей и личностных качеств тестируемых в рамках диагностики их профессиональных склонностей.

Работа по профессиональной диагностике огромна и многогранна, а на сегодняшний момент она просто невозможна без использования современных компьютерных технологий [1].

Основные аспекты системы профессиональной диагностики Понятие «профессиональная склонность» следует трактовать как интерес, подкрепленный соответствующими личностными качествами и развитием соответствующих способностей, то есть, как совпадение интересов, способностей и характера человека, требуемых для определенной профессии (группы профессий). Поэтому тестовые методики специалистов в области профессиональной ориентации молодежи сфокусированы на интересах и способностях, важных для приобретения образования в соответствующей профессиональной области. При подборе методик учитываются принципы оптимальности их числа и последовательности их предъявления для достоверности полученных результатов.

Рекомендации по выбору профессий даются в терминах круга специальностей, отражающих наиболее массовые профили подготовки современного специалиста с высшим и средним специальным образованием. Вместе с тем по результатам профессиональной диагностики специалисты имеют возможность увидеть закономерности в профориентационной работе, в изменении популярности профессий, в развитии рынка труда, востребованности высших и средних специальных учебных заведений и т.п., и, исходя из этого, делать соответствующие выводы, давать рекомендации и составлять прогнозы. Общую схему профессиональной диагностики и анализа можно представить следующим образом.

Результативность профессиональной диагностики напрямую зависит от объема и четкости выполняемой работы, разработки и применения самых современных и достаточно объемных методик. Так, структура профориентационного комплекса Гродненского регионального центра тестирования и профессиональной ориентации молодежи включает три составляющие: опросник, бланк ответов, алгоритм анализа, позволяющий выдать рекомендации и проследить закономерности результатов профессиональной диагностики.

В свою очередь, предлагаемые вопросы и задания разделяются на три раздела.

1. Оценка структуры интересов. Состоит из утверждений, диагностирующих интересы учащегося к различным сферам профессиональной деятельности.

2. Оценка интеллекта. Включает вопросы, представляющие собой задания на определение уровня развития способностей.

3. Оценка структуры личности. Содержит вопросы-утверждения, ориентированные на выявление личностных качеств.

Результаты тестирования включают: индивидуальный графический профиль с результатами по каждому измеряемому тестом качеству (шкале), списки наиболее подходящих профессий, развернутые текстовые интерпретации результатов.

Рис. 1. Общая блок-схема профессиональной диагностики и анализа С учетом общего подхода к профессиональной диагностике и анализу (рис. 1) разрабатываемая система предусматривает:

автоматизацию анкетирования и тестирования;

обработку данных диагностического профиля, статистический анализ, выявление зависимостей и закономерностей;

автоматическую выдачу данных как по конкретному случаю, так и в обобщенной и проанализированной форме.

Применение компьютерной системы для проведения профессиональной диагностики и обработки данных намного ускорит и упростит сбор информации и выдачу рекомендаций тестируемому:

какие профессии подходят тестируемому на основе анализа интересов, способностей и особенностей характера;

в каких учебных заведениях можно получить соответствующее образование;

как соотносятся индивидуально-личностные особенности тестируемого с требованиями той или иной профессии;

как скорректировать «слабые» стороны и какие способности следует развивать для профессиональной деятельности;

психологически настроить тестируемого на принятие ответственного решения в своей жизни.

В свою очередь, на данные, полученные в результате тестирования, смогут опираться психологическая и социологическая службы центра при разработке новых методик профессиональной диагностики, а также для определения возможных мест профориентационной работы, например, с учетом таких факторов, как проживание тестируемых, социальный статус, определяющие факторы выбора будущей профессии, уровень информированности городских и сельских школьников, профессиональных предпочтений молодежи, соотношении популярности профессий в молодежной среде и на рынке труда, популярности и авторитете вузов и ссузов области и республики и др.

Общие подходы к реализации универсальной системы профессиональной диагностики Универсальная система профессиональной диагностики разрабатывается с использованием трехуровневой архитектуры (см. рис. 2). Трехуровневая архитектура представляет систему в виде совокупности трех компонент:

клиентского приложения, предоставляющего интерфейс для конечного пользователя;

сервера приложений, отвечающего за выполнение бизнес-логики приложения и аналитической обработки данных;

сервера базы данных, который обеспечивает хранение данных.

Для создания системы используется программная технология.Net Framework компании Microsoft. Эта технология имеет следующие преимущества [1]: объектно-ориентированное программирование(.NET Framework и C# изначально полностью базируются на объектноориентированных принципах) [2], хороший дизайн, независимость от языка, лучшая поддержка Web-страниц(ASP.NET), эффективный доступ к данным (ADO.NET), разделение кода, повышенная безопасность, поддержка Web-служб.

Клиент разрабатывается двух типов:

1. Web-клиент. Используется фреймворк для создания веб-приложений ASP.NET MVC Framework, который реализует паттерн MVC (Model-View-Controller).

2. Desktop-клиент. Используется графическая подсистема в составе.NET Framework WPF (Windows Presentation Foundation), опирающаяся на использование XAML.