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

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

Главные особенности платформы интеграции

1. Архитектура системы

1. ИнСис – это в первую очередь платформа для создания региональных систем, автоматизирующих деятельность системы управления регионами – от организаций уровня Администрации Губернатора, Правительства, министерств и ведомств — вплоть до администраций муниципальных образований с их учреждениями.

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

3. Модульная иерархическая архитектура системы ориентирована на создание больших информационных систем, объединяющих программные компоненты различных территориальных уровней в единый комплекс. Например, в рамках единой системы могут функционировать как компоненты ведения реестров муниципального имущества, доступные сотрудникам муниципалитетов, так и модули многомерного анализа сводных данных о недвижимом имуществе уровня региона (Правительство субъекта Федерации, министерства, Администрация Губернатора), хотя, конечно же, на региональном уровне могут быть размещены и приложения учетного плана. В качестве первых примеров систем уровня региона на базе ИнСис компанией ЦСИ «Интегро» сегодня реализуется «Система учета сделок с недвижимым имуществом на территории региона» (например, в Министерстве земельно-имущественных отношений), а также АИС ОГД муниципалитетов и региона в целом (т.е. сразу два уровня систем обеспечения градостроительной деятельности в единстве «в связке» с имущественной задачей).

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

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

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

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

8. Работа ИнСис базируется на гетерогенной модульной (важно!) БД, где различные группы взаимосвязанных данных могут храниться в модулях БД разного формата с использованием СУБД разных производителей, а также предоставляет возможность подключения и использования данных из различных удаленных источников. Например, данные о договорах аренды земельных участков могут размещаться или в реляционной, или NoSQL БД, хоть под управлением Microsoft SQL Server хоть Oracle, а данные адресных справочников подкачиваться из удаленной базы данных ФИАС в формате DBF, размещенных на интернет — сервисах ФНС. Т.е. каждый модуль БД в плане реализации структур БД или используемых СУБД независим от других модулей БД. Между модулями БД не поддерживается ссылочная целостность и не требуется нормализация. Внутри отдельного модуля БД ссылочная целостность автоматически обеспечивается.

2. Интерфейсы пользователя

1. Типовой Web-интерфейс пользователя ИнСис поддерживается большинством современных браузеров и работает в том числе и на мобильных устройствах.

2. Помимо этого, система дополнительно допускает разработку различных пользовательских интерфейсов, в числе которых могут быть как интерфейсы настольных ПК под управлением Windows, Linux и др., так и смартфонов и планшетов (Android, iOS, Windows Phone и т.д.). Причем, как в рамках разных, так и в рамках одного предметного приложения на базе ИнСис можно использовать различные интерфейсы одновременно.

3. Подсистема ведения автоматизированных технологических процессов является составной частью ядра ИнСис (организована в виде одного из архитектурных слоев).Техпроцессы позволяют организовать действия пользователей в рамках регламентов, создаваемых в соответствии с законодательством или внутренними правилами взаимодействия организаций.

4. Пространственная модель региона и ГИС-компонента являются неотъемлемой частью ИнСис. Более того, пространственные данные являются составной частью системы прав доступа пользователей к базам данных системы, определенных в узлах иерархической системы пространственных данных (административного деления территории). Естественно, что пространственные данные хранятся в БД системы и могут использоваться программной логикой (в т.ч. и в рамках автоматизированных техпроцессов), а также отображаться на пользовательском интерфейсе. Пространственный аспект является принципиально «родным» для системы, а не «подключается» к системе в качестве внешней компоненты. Но другие ГИС-системы могут подключаться к системе в качестве внешних источников данных при разработке соответствующего адаптера.

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

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

3. Особенности для разработчиков

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

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

3. Покрытие кода ИнСис модульными тестами доводится до 75-80%. Это существенно повышает качество программного продукта и резко сокращает сроки разработки системы, а также позволяет нам без серьезных затрат проводить развитие и рефакторинг системы, эффективно исправлять возможные ошибки проектирования без опасения появления побочных эффектов в других местах обширного программного кода. В настоящий момент разработку системы «контролируют» порядка 200 модульных тестов системных компонент. В целом же без модульных предметных тестов, номенклатура системных тестов будет доведена до примерно 400 тестов, контролирующих рефакторинг всех важнейших компонент системы.

4. Модель предметной области ИнСис является полностью объектно-ориентированной. Разработчикам не нужно работать с нетипизированными полями реляционных таблиц и других подобных им структур, поскольку все объекты и их свойства представлены соответствующими конструкциями языка C#, а сохранением и загрузкой этих объектов занимается системная инфраструктура, выполняя как объектно-реляционное (ORM), так и другие виды преобразований программных объектов в хранимые структуры данных различных модулей БД. Фактически, предметный разработчик не подозревает какая СУБД и какая структура данных используется в том или ином используемом модуле БД. Работать с множествами объектов он в своем коде сразу может в том числе и используя всё богатство операторов LINQ.

5. Модель предметной области ИнСис состоит из набора слабо связанных модулей (программных компонент в смысле UML), для каждого из которых может выбираться свой формат, место и способ хранения данных, более удобный для реализации той или иной функции. Разрабатываемая в соответствии с принципами Domain-Driven Design (DDD) модель предметной области состоит из набора модулей, включающих в себя кластеры тесно-связанных объектов, называемых агрегатами. Внутренние элементы агрегатов принципиально сохраняют ссылочную целостность, тогда как сами агрегаты слабо связаны друг с другом и на уровне данных прямых адресных ссылок друг на друга не имеют. Поэтому агрегированные данные могут храниться в отдельных модулях баз данных, которые в свою очередь могут быть размещены на разных аппаратных серверах, иметь разный формат и средства хранения и даже, выглядя для программиста как местная БД, быть размещены на удаленных вэб-службах других учреждений (ФНС, Росреестр) и т.д. Таким образом, предметные программисты среды ИнСис в большой степени избавлены от проблем организации получения данных из различных БД, – для этих программистов в памяти системы просто появляются нужные программные объекты и всё.

6. Преимущественное (но необязательное) использование NoSQL-подхода для хранения данных на Microsoft SQL Server в XML-формате позволяет существенно увеличить скорость работы ИнСис. При этом предоставляются все преимущества обработки Xml структур (например, XPath-запросы). Отсутствие необходимости при каждом программном запросе объединять реляционные таблицы существенно ускоряет загрузку связанных данных (агрегатов) в память с одновременным преобразованием их «на лету» в связную объектную кластерную модель (ORM), в то время как использование XML в качестве формата представления данных позволяет использовать для хранения такие зарекомендовавшие себя СУБД, как Microsoft SQL Server или Oracle, а для запросов – язык XQuery.

7. Презентационная модель отделена от модели предметной области. Структуры данных, передаваемые на презентационный уровень, независимы от структур данных используемых модулей БД. Перед отправкой на интерфейс пользователя данные ИнСис преобразуются в презентационные объекты, которые декорируют объекты модели предметной области, добавляя к ним особенности, необходимые исключительно для целей отображения. Например, презентационный объект может немного изменить структуру исходного объекта, добавить к нему вычислимые поля и методы, объединить несколько объектов в один, — как это удобно для пользовательского интерфейса. Кроме того, для одного объекта модели предметной области можно создать несколько презентационных объектов, которые будут по-разному представлять его в соответствующих задачах.

8. Текущая версия Web-интерфейса пользователя ИнСис построена на базе платформы Sencha ExtJs и, возможно, будет поставляться с открытым исходным кодом, что предполагает самостоятельное внесение сторонними разработчиками изменений в развиваемый GUI.

9. Разработчики могут самостоятельно разрабатывать интерфейсы пользователя для ИнСис, используя открытое API презентационного уровня. Пользовательский интерфейс в ИнСис построен на основе шаблона Модель – Представление – Презентационная Модель (Model-View-ViewModel), причем Представление (View) отвечает исключительно за отображение данных, а вся экранная логика содержится на сервере и не зависит от технологии отображения, что позволяет использовать одну и ту же логику в целом наборе различных интерфейсов, в том числе и в тех, что написаны внешними разработчиками. Интерфейс должен лишь корректно обращаться к API сервера ИнСис и отображать полученные Презентационные модели (View Model), выдаваемые сервером в форматах JSON и XML.

10. ИнСис автоматически генерирует унифицированные представления (View) для презентационных объектов, после чего их можно дополнительно настроить вручную, если требуется внести детали. Для входящего в состав ИнСис Web-интерфейса на базе Sencha ExtJs-представления – это JavaScript-файлы, модификация которых может быть выполнена в любом подходящем редакторе в соответствии с правилами работы в ExtJs. Кроме того, для визуальной модификации представлений может быть использована среда Sencha Architect.