Добавить комментарий

Пример создания прототипа учетной системы

Игорь Паньшин, октябрь 2006

Погружаясь в предметную область новой учетной системы, всегда возникает вопрос на базе чего ты понимаешь? Можно просто рисовать схемы на бумаге. Можно пользоваться Enterprize Architect. Можно разрабатывать метаданные. В общем кто к чему привык. Основное требование в этом деле, чтобы был результат, который бы можно было реализовать. У меня не возникает желания что-то с чем-то сравнивать по эффективности, поскольку это более маркетинговый крючок. Я просто готов описать один мой рабочий день (4 октября 2006) по разработке прототипа информационной системы доступа к информационным ресурсам.

Background. Что я мог в рамках NEXUS-технологии?

1. Генерация любых классов объектов в виде скрипта для таблиц и SQL-обработчиков класса. В папке классы/автопорожденные классы с гридом есть документы прародители желаемого класса.

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

Если правильно понята предметная область, то для создания нового класса требуется

  • заполнить документ “Создание класса с гридом”
  • выполнить свойство класса “Создать класс”, после которого в каталоге c:commandfromsql появятся автоматически сгенерированные скрипты по созданию класса, его таблиц и обработчиков класса.

  • Все это хозяйство скриптов компилируешь в базу данных.

И все, можно работать с новым классом.

2. Второй важный пункт - это создание новых свойств класса. Для этого существует класс объектов “Код”, который позволяет выполнять средствами динамического SQL небольшой (8000 символов) текст Transact SQL, который пишется прямо в тело объекта “Код”. Например,

Новые свойства класса могут быть сразу отлажены. Сам контекст SQL-скрипта может быть отлажен отдельно в рамках SQL query analizer. Хочу напомнить, что выполнение хранимой процедуры может спокойно запускать процесс в рамках операционной системы сервера , а также (при небольшой хитрости) и на клиенте. Также существуют нехитрые возможности сохранения информации в файл или в html по определенному образцу, или в xml. Также можно написать отдельный DLL модуль, организовав его в виде хранимой процедуры. Поэтому детальную проработку операционных свойств класса можно оставить на потом.

3. Третий важный аспект разработки прототипа, это оперативное соединение свойств с классом. Я говорю о дополнительных свойствах отличных от стандартных edit, view, print. Обычно свойства вносятся путем внесения условных свойств в контекст хранимых процедур обработчиков и это, в принципе, правильно. Хотя, это можно выделить в отдельную независимую часть, назвав его “управляющим контекстом” (context handler), как это предлагается делать в PMI (privilege management infrastructure). Моя упрощенная процедура привязки свойств выглядит следующим образом

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

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

Я хочу сказать, что 30 минут я тратил на корректировку своих собственных огрехов, поскольку где-то опустил в определении null, где-то надо родительский класс заменить, что не не было продумано ранее. Если бы golds (утилита для работы с SQL-скриптами, используемая в NEXUS1, в NEXUS2 используются только инструментарий самого SQL Server, прим.ред.) корректно работал с таблицами, то можно автоматизировать эту процедуру полностью. Все равно скорость 1 класс за 15 минут достигнута на простой Windows XP с процессором Pentium 3 (честно скажу у меня дома машина лучше).

Foreground. Какова была постановка задачи.

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

Здравствуйте, Игорь.
Набор документов по атрибутным сертификатам (AC) и инфраструктуре управления привелегиями (PMI):
509_overview
rfc3281
X509_4thEditionDraftV8

Читаю документ X509_2005, из которого следует что атрибутный сертификат есть следующая структура данных:

AttributeCertificate ::= SIGNED { AttributeCertificateInfo } 
-------------------------------------------------------------------------
AttributeCertificateInfo ::= SEQUENCE
{ 
    version                  
AttCertVersion, -- version is v2 
    holder                   
Holder, 
    issuer                   
AttCertIssuer, 
    signature                
AlgorithmIdentifier, 
    serialNumber             
CertificateSerialNumber, 
    attrCertValidityPeriod   AttCertValidityPeriod, 
    attributes               SEQUENCE OF Attribute,
 
    issuerUniqueID           
UniqueIdentifier OPTIONAL, 
    extensions               
Extensions OPTIONAL 
} 
 
AttCertVersion ::= INTEGER { v2(1) } 
Holder ::= SEQUENCE 
{ 
    baseCertificateID [0]     IssuerSerial       OPTIONAL, 
    -- the issuer and serial number of the holder's Public Key Certificate
 
    entityName [1]              GeneralNames OPTIONAL,               
 
    -- the name of the entity or role 
    objectDigestInfo [2]       ObjectDigestInfo OPTIONAL 
    -- used to directly authenticate the holder, e.g., an executable 
    -- at least one of baseCertificateID, entityName or objectDigestInfo 
shall be present 
} 
 
ObjectDigestInfo ::= SEQUENCE 
{ 
    digestedObjectType       ENUMERATED 
    {publicKey (0),publicKeyCert (1),otherObjectTypes (2) }, 
    otherObjectTypeID       OBJECT IDENTIFIER OPTIONAL, 
    digestAlgorithm             AlgorithmIdentifier, 
    objectDigest                  BIT STRING 
}
 
AttCertIssuer ::= [0] SEQUENCE 
{
    issuerName                   GeneralNames OPTIONAL, 
    baseCertificateID [0]     IssuerSerial       OPTIONAL, 
    objectDigestInfo [1]       ObjectDigestInfo OPTIONAL 
}
-- At least one component shall be present 
( WITH COMPONENTS { ..., issuerName PRESENT } | 
WITH COMPONENTS { ..., baseCertificateID PRESENT } | 
WITH COMPONENTS { ..., objectDigestInfo PRESENT } ) 
 
IssuerSerial ::= SEQUENCE 
{ 
    issuer                GeneralNames, 
    serial                CertificateSerialNumber, 
    issuerUID         UniqueIdentifier            OPTIONAL 
}
 
AttCertValidityPeriod ::= SEQUENCE 
{
    notBeforeTime GeneralizedTime, 
    notAfterTime    GeneralizedTime 
}

Конечно, лучший вариант, это убедить заказчика в том, что его приложения (информационные ресурсу) не готовы к раздельному выполнению процессов аутентификации и авторизации, для которых и предназначен атрибутный сертификат, на основе которого выдаются привилегии в момент доступа пользователя к защищаемому ресурсу. Но можно пойти и по другому эволюционному пути разработки информационной системы, который, по моему мнению, более прогрессивен. Ведь в рамках заказа можно создать все, удовлетворяющие заказчика структуры данных, без особого обсуждения (ну хочет он x509 ). Нет проблем, я создам эти структуры, но работать они будут только тогда, когда он построит свою собственную PKI (public key infrastructure) и обеспечит механизм динамической авторизации на базе контента приложений.

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

Где

,

,

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