WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 11 |

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

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

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

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

К вспомогательным объектам системы учёта можно отнести «Регистр сведений», «Регистр накопления», «Журнал документов», формы ввода/вывода данных, запроса и анализа информации, зарегистрированной в системе.

Вариантов практической реализации систем учёта множество. В части научного подхода к организации хранения данных мы использовали работы д. т. н. О. О. Варламова. В вопросах, относящихся к организации представления и хранения данных объектов в таблицах сервера реляционной БД (статьи, диссертация «Системный анализ и синтез моделей данных и методы обработки информации в самоорганизующихся комплексах оперативной диагностики», Москва, 2003), модели Чена («сущность—связь», ER-модель). При выборе подхода к созданию системы учёта мы сделали ставку на расширяемость и многоплатформенность.

Следствием этого стал выбор инструментария разработки: QT, MySQL и Postgresql, GNU/Linux.

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

В результате начала вырисовываться структура платформы «Ананас». В настоящее время платформа состоит из следующих приложений:

Designer (инструмент разработки прикладной системы учёта), GUIengine («исполнитель» созданных в Designer приложений), WEB-engine (исполнитель web-приложений).

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

10:50–11:Юрий Хныкин Ижевск, ITK CLIP team Андрей Черепанов Москва, EAS team Проект: CLIP, R2D2, EAS Разработка систем автоматизации бизнеса Аннотация:

1. CLIP — средство разработки 2. r2d2 — веб-платформа автоматизации бизнеса 3. E/AS — клиент серверная платформа 4. Перспективы развития систем автоматизации бизнеса.

CLIP — средство разработки CLIP — это не только компилятор популярного языка Clipper на платформах Unix, это полноценная среда для разработки прикладных программ, включающая компилятор, препроцессор, библиотеки, почти полностью соответствующие проверенному годами Clipper, а также около 2000 функций из популярных библиотек и виджетсетов. Кроме того CLIP обеспечивает доступ к большинству распространённых SQLсерверов, поддерживает объектный стиль программирования, позволяет использовать динамические библиотеки и модули на байт-коде.

Основные проблемы при переносе унаследованных приложений с Clipper‘а на CLIP связаны с различиями и особенностями операционных систем.

Дальнейшее развитие CLIP происходит в сторону использования современных технологий таких как:

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

• объектный сервер приложений COBRA (CLIP Object Broker and Application Server), позволяющий исполнять бизнес-логику на серверной стороне, динамически подключать новые методы классов и бизнес-процессов без остановки работы сервера.

• пользовательский интерфейс, одинаково удобный для разработчиков, инженеров бизнес-процессов и, конечно, пользователей.

На основе этих возможностей CLIP строятся два проекта, имеющие в основе разные пути реализации пользовательского интерфейса и бизнес-процедур: r2d2 и E/AS.

r2d2 — web-ориентированная платформа для создания корпоративных информационных систем Использует Mozilla как основу пользовательского интерфейса. Проект ориентирован на решение задач различного рода учёта, планирования и анализа: бухгалтерского, управленческого, финансового и т. д..

В качестве объектов учёта и анализа могут выступать любые объекты, имеющие структурированный набор атрибутов, а также различного рода процессы, протекающие с участием объектов учёта. Основное отличие r2d2 от аналогичных учётных программ в том, что всё это реализовано на ОБД и практически не имеет никаких ограничений по количеству классов данных или по количеству атрибутов в объектах.

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

Для организации полноценного пользовательского интерфейса r2dразработан специальный модуль к Mozilla на базе форматов XUL, CSS, JS с набором библиотек для построения пользовательских или создания собственных расширений.

3. E/AS — клиент-серверная платформа Ещё одним примером развивающегося проекта с открытым исходным кодом является проект E/AS (Enterprise automation system — система автоматизации предприятия). Платформой для реализации этого проекта был выбран CLIP. В рамках проекта реализованы следующие решения:

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

• создан язык описания интерфейсов и печатных форм на базе XML и UIML;

• предусмотрена возможность автогенерации форм на основании метаданных базы;

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

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

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

В этих условиях весьма вероятно появление новой мощной силы.

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

11:15–11:Михаил Шигорин Киев, TYPO3: консистентная модульная система управления веб-контентом Аннотация:

• Краткий обзор основных концепций и возможностей TYPO3 с точки зрения веб-разработчика;

• разделение обязанностей: логика, контент, дизайн;

• разделение привилегий: пользователи «оболочки» и «изнанки» сайта;

• наращивание возможностей: модули на основе общей БД;

• в реальности: открытый код, решения «под ключ»;

• сравнение с более поздними технологиями разделения контента и представления (например, XML/XSLT); возможности интеграции.

11:45–12:00: Кофе Дневное заседание 12:00–14:Секция (Председатель — Станислав Иевлев) 12:00–12:Алексей Воинов Москва, ALT Linux Проект: WindowMaker Состояние разработки проекта WindowMaker Аннотация:

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

WindowMaker — популярный менеджер окон для X11. Проект был начат Альфредо Койма в 1997 году сразу после выхода AfterStep 1.0, и предлагался в качестве одного из путей развития AfterStep. Однако, остальные разработчики не поддержали Альфредо.

К 2001 году вокруг проекта сложилась любопытная ситуация. В проекте выделилось «узкое» место — Дэн Паску. Из-за того, что он не доверял ничьему коду, он переписывал все присылаемые ему патчи, используя оригинал только как идею. Со временем он просто перестал успевать обрабатывать весь присылаемый ему материал. Если учесть возросшую занятость в «реальной жизни» у обоих программистов проекта, становится понятно, что развитие проекта начало замедлятся уже давно. Стороннему наблюдателю это стало заметно значительно позже.

В конце 2002 года была выпущена последняя версия WindowMaker. К середине 2003 изменения в cvs практически прекратились.

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

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

В декабре 2003 года я рассказывал о патчах для WindowMaker и об их создателях на виртуальной конференции Umeet. Я говорил, что наличие патчей — это очень хорошо, поскольку майнтейнер проекта может вовсе не желать поддерживать чей-то чужой код. Однако «простые» пользователи могут при желании получить нужную им функциональность, общаясь только с создателем патча. При этом все остаются довольны: майнтейнер проекта доволен, потому что ему не добавляется лишней работы, автор патча доволен, потому что его работа заметна и не тонет в тысячах строк основного проекта. В этом смысле, проект WindowMaker, пожалуй, уникален. Я не встречал больше нигде патчей, не вошедших в основную ветку, которые бы распространялись в официальном тарболе.

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

В начале 2004 года на irc-канале #windowmaker выделилась группа разработчиков, желающих нормального развития проекта. Был создан репозиторий, в котором началась работа по созданию нового оконного менеджера на базе существующего кода WindowMaker. Приблизительно через неделю после начала работы старая команда разработчиков WindowMaker была поставлена в известность о новом проекте. В результате длинного разговора было решено новый проект не создавать, а продолжить разработку WindowMaker силами обновлённой команды.

Разработка патчей, на самом деле, накладывает значительные ограничения на тех, кто их пишет. Мало кто будет озабочен прикладыванием к своей версии программы патча, который не добавляет какого-то заметного изменения. Это обстоятельство не способствует улучшению качества кода основной версии, если за этим не следит майнтейнер.

Именно поэтому первоочередной задачей новой команды стала чистка кода.

Другие (сформулированные) задачи включают:

• адаптацию и интеграцию уже разработанных патчей в основную ветвь проекта;

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

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

Адаптация патчей необходима, потому что многие из них разработаны так, чтобы вносить минимум исправлений в существующий исходный код, а это далеко не всегда приводит к лучшим решениям. Разделение на модули позволит сделать WindowMaker намного более гибким и позволит изменять набор возможностей во время работы без перекомпиляции. Сейчас, например, есть вариант компиляции lite, который отключает довольно много кода, но это невозможно изменить во время работы. У существующего интерфейса есть масса недостатков. Например, при запуске WindowMaker с переводом некоторые переведённые надписи не умещаются в отведённых им позициях.

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

Версии WindowMaker из новой ветви начнут выходить только после того, как будет выпущена версия 1.0.

12:25–12:Денис Слюсарев Москва, ainmarh lab Проект: QPLATFORM Основы QPLATFORM Аннотация:

QPLATFORM — это комплекс программных средств для разработки CGI(fastcgi)-приложений, рассчитанных на высокую нагрузку. Главными достоинствами проекта являются: язык разработки — C, встраиваемые в бинарный код программы html-шаблоны, динамическое кэширование контента (с вероятностью попадания в кэш около 90% при типичных задачах) и система управления пользовательскими сессиями.

В комплекс входят:

• FastCGI система организации работы CGI-приложений, как отдельных программ (демонов/сервисов), которые после запуска постоянно находятся в памяти и обрабатывают приходящие к ним от web-сервера запросы.

• QTP (или Q-Lang) препроцессор шаблонов, рассчитанных на высокую нагрузку и оптимизированных для встраивания непосредственно в код программы.

• CGIX — модифицированная версия CGIC, оптимизированная для работы с FastCGI и QTP (или Q-Lang).

• QCM — система динамического кэширования.

• QSM — система контроля пользовательских сессий.

• QDBC — система, унифицирующая работу с базами данных (в данный момент находится в стадии разработки).

Преимущества использования QPLATFORM:

• Высокая скорость работы приложений.

• Наличие необходимого инструментария для быстрого построения cgi-приложений.

• Возможность post-кэширования обработанных запросов.

• Возможность автоматического динамического кэширования (libqcm).

• Возможность получения «Content-Length» для результата работы, а, следовательно, возможность использования http-акселераторов на полную мощность.

• Система QSM (session manager) позволяет с помощью сессий решать проблемы безопасности.

Основной причиной появления проекта QPLATFORM является отсутствие на данный момент инструментария для создания в короткие сроки быстрых cgi-приложений на языке C. Существует достаточно большое количество шаблонных библиотек, XML/XSL-процессоров, которые являются очень громоздкими и непроизводительными. Так, при создании даже небольших проектов программисты сталкиваются со сложной дилеммой: если выбрать интерпретируемый язык как платформу для создания web-приложений, то при возрастании уровня посещаемости появятся проблемы с производительностью; при выборе же компилируемого языка разработка займёт очень много времени, которое, возможно, будет потрачено даром, если проект не будет иметь успеха.

Компромисса не существует, поэтому приходится жертвовать либо одним, либо другим. А QPLATFORM можно рассматривать как золотую середину: длительность разработки не больше, чем при разработке на PHP, однако скорость выше, чем при создании приложения с использованием большинства существующих библиотек для C.

Существует несколько причин низкой производительности современных web-приложений. Самое главное — это база данных (будь то MySQL, PostgreSQL, или даже Oracle), которая занимает большую часть ресурсов сервера. Вторая причина — использование интерпретируемого языка (PHP, Perl, Python и др.), И третья — низкая скорость работы самой системы, например, запуск приложения при каждом запросе (если мы избрали путь CGI).

Обойти все эти проблемы или свести их долю к минимуму можно следующим образом.

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 11 |






© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.