РАДЖА
   
  О проекте в целом 
   
  Прикладная архитектура 
   



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


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



   
  Независимость скорости работы от количества документов в базе данных 
   

Изначально "Раджа" разрабатывалась как программа, которая может работать с очень большими объемами данных. Достигнуто главное требование - скорость работы не должна падать с ростом размера базы данных. Этому подчинено все. Во время разработки и тестирования всегда, когда появлялась зависимость между скоростью работы и объемом базы данных, это рассматривалось как дефект и ошибка разработки. Даже при использовании находящегося в дистрибутивном наборе бесплатного SQL-сервера FireBird вполне реальна работа с базой данных, содержащей миллионы документов при подключении десятков клиентских рабочих мест. Конечно, в этом есть большая заслуга правильной организации работы ядра системы. Но и прикладные программы были устроены так, чтобы реально были достижимы объемные показатели вроде 300 тысяч записей в справочнике номенклатуры товаров и количество входящих-исходящих накладных в день порядка 500-2000.



   
  Возможность работы с большим количеством клиентских подключений 
   

Не менее важный показатель. Реально достижимое число одновременно работающих клиентских компьютеров исчисляется десятками. И это без применения варианта установки, показанного на рис. 1-6. Тут требуется небольшое пояснение. Дело в том, что архитектура с несколькими серверами приложений на самом деле несколько сложнее показанного на рис. 1-6
примера.
Реально требуется еще один сервер. Так называемый "сервер синхронизации" см. рис. 3-1.

Рис. 3-1

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



   
  Полная ликвидация эффекта "текущего момента" 
   

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



   
  Мощные инвентаризационные функции 
   

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



   
  Подсчет остатков 
   

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



   
  Работа с документами - основа интерфейса 
   

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