Технология Sapiens

ОБЩИЕ ЗАМЕЧАНИЯ

    Каноническая схема разработки прикладных систем, если рассматривать ее <в чистом виде>, предполагает ряд последовательных этапов:
    определение требований к системе, разработка спецификации в рамках проекти-рования программного обеспечения (это наиболее трудоемкий, длительный и ответственный этап), программирование модулей, тестирование системы. Различные модификации канонической модели достаточно подробно разработаны. Предложены оптимальные, по тем или иным параметрам, подходы к проектированию программного обеспечения, разработаны формальные языки спецификаций, методики тестирования и т.д. Наиболее значимым <всплеском> в этой области стал, вероятно, структурный подход к проектированию, разработке и тестированию программных систем, который, что бы ни говорили его сторонники, представлял собой оптимизированную форму канонического подхода.
    <Родовая> черта канонического подхода к разработке прикладного программного обеспечения состоит, по нашему мнению, в известной отстраненности создания для организации программной системы от содержательной деятельности самой организации.
    RAD-метод, помимо всего прочего, представляет собой попытку ликвидации этой отстраненности. При создании системы для каждой итерации в рамках отведенного для нее промежутка времени устанавливаются требования к системе. Разработка спецификаций в чистом виде не выполняется. Вместо этого к работе активно подключается пользователь, который вместе с разработчиком обсуждает природу возникшей задачи и способ ее решения на содержательном уровне в понятиях задачи, а не программной системы. Поэтому собственно процесса проектирования программного обеспечения нет. Взамен создается некоторый прототип будущей системы, который в дальнейшем может быть доработан до конечного продукта или забракован, а выбранный инструментарий заменен другими средствами разработки.
    При каждой итерации в разработке прикладной системы предусматривается ее тестирование и сдача в эксплуатацию, поскольку основная цель RAD-метода - скорейшее достижение функциональности даже для не полностью завершенной системы. При подобном подходе, если в системе работает только часть функций, позволяющих использовать ее, например, половине потенциальных пользователей, она уже может рассматриваться как законченный продукт. Открываются новые перспективы и темы для обсуждения с пользователями. Итерационный процесс длится до тех пор, пока система не будет удовлетворять интересам пользователя полностью.
    Первое, что приходит в голову, когда речь заходит о создании автоматизированной или информационной системы с активным участием пользователя и подключением прогрессивных средств разработки - это CASE-технологии. Ключевое отличие CASE-технологии от RAD-метода заключается в том, что она предоставляет разработчику способ итеративной разработки, которому следует достаточно строго следовать до конечной точки разработки. При использовании же RAD-метода после каждой итерации пользователь имеет фактически законченную систему с ограниченным набором функций. В зависимости от инструментария, используемого в разработке, можно указать и ряд других отличий, главное и наиболее общее из которых, вероятно, заключается в том, что RAD-метод позволяет <двигаться> по процессу разработки в обе стороны, как от начала к концу, так и от конца к началу.
    RAD-метод обладает рядом отличительных особенностей, среди которых можно выделить следующие:

основная цель метода состоит в максимально полном удовлетворении бизнес-требований;

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

разработка ведется пошагово, и для каждого шага (итерации) определен фиксированный интервал времени;

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

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

разработка строго организована, каждая итерация четко планируется и оценивается;

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

реализация метода предполагает использование очень мощных средств разработки.
    В конце разработки получается полностью работоспособная система, имеющая подготовленных пользователей и оснащенная всеми средствами поддержки. Можно привести и еще ряд свойств метода, но сказанного вполне достаточно2.
    Если говорить о средствах разработки, пригодных для использования в RAD-методе, то сегодня на рынке его требованиям в той или иной мере удовлетворяют следующие средства: Cactus (Informations Builders), CA-OpenRoad (Computer Asso-ciates), Composer (Texas Instruments Software), Designer и Developer/2000 (Oracle Corporation), INPHASE/EIS (INPHASE Software Ltd), Magic (Magic Software Interprises), NatStar (Nat Sys-tems), Natural (Software AG), ObjectPool (Sapiens), Object Star (Antares Alliance Corp.), SAS System (SAS Institute), SNAP (Template Software), серия Usoft Deve-lopment (Usoft), Visual Age (IBM).
    Любое из средств, пригодных для RAD-метода, должно основываться на соответствующей базе. Оно должно позволять строить бизнес-модели, выполнять определение и структурирование данных, вывод и отображение информации, моделировать процессы, поддерживать работу в интерактивном режиме, осуществлять поддержку разработки и готовой системы, поддерживать конфигурирование системы, давать ее оценку и документирование. Перечисленные выше программные продукты (среды) обладают всеми приведенными особенностями, но, вероятно, наиболее оригинальный подход реализован в ObjectPool фирмы Sapiens.

OBJECTPOOL ФИРМЫ SAPIENS

    Sapiens ObjectPool - комплексная среда разработки собственно сетевых и клиент/сервер приложений. Она использует объектно-ориентированную технологию, построенную на правилах. Основой Object-Pool является база знаний (knowledge-base). Разработка прикладной системы в среде ObjectPool не требует традиционного программирования, прикладная система представляет собой, по сути дела, совокупность определений, хранящихся в базе знаний. База знаний в среде Sapiens поддерживается средствами системы управления базами данных (СУБД). В качестве собственно СУБД прикладной системы могут использоваться как встроенная объектно-ориентированная СУБД Sapiens DB1, так и различные СУБД, такие как DB/2, IMS, Adabas, ORACLE, а также различные файловые структуры.
    Среди объектов среды Sapiens можно выделить базовые (basic), обладающие уже заложенной в них функциональностью, такой как управление базами данных, рестарт/восстановление, обработка ошибок и исключительных состояний. Базовые объекты могут использоваться в качестве образцов (template) для дальнейшей модификации и создания других объектов. Вторым типом объектов является совокупность или линия бизнес-объектов (line of business object), которые создаются на уровне графического представления изменением <поведения> базовых объектов. Для бизнес-объектов определяются связанные с ними данные и описываются бизнес-правила обработки этих данных. Создание линии бизнес-объектов, по существу, и является разработкой конкретного приложения в среде Sapiens.
    Для каждого класса объектов определяется совокупность атрибутов, однозначно их характеризующих. Описание атрибутов и классов объектов хранится в базе знаний, а значения атрибутов конкретных объектов - в базе данных. Определение атрибута содержит некоторый набор метахарактеристик, позволяющий отразить семантику предметной области, не прибегая к программированию. Например, можно определить область допустимых значений, задать значение <по умолчанию>, задать автоматическую генерацию значений для объектов типа <дата> и т.п. Один и тот же атрибут может относиться к различным классам объектов, при этом его описание в базе знаний не дублируется. Можно задавать иерархическую подчиненность объектов. При этом каждый подчиненный уровень объектов рассматривается системой как самостоятельный класс, хотя вне иерархии подчиненные объекты лишены смысла в предметной области.
    Формально правила в среде Sapiens можно описать на специализированном языке TOL, где доступны пять типов правил: check, local, fetch, derivation, call.
    Правило типа check проверяет некоторое условие и при отрицательном результате посылает пользователю сообщение об ошибке. Например:
    QUANTITY MUST BE GE 100 (количество должно быть > 100).
    Сообщение об ошибке:
    введите количество заново (минимум -100).
    Правило типа local используется для вычисления атрибутов внутри объекта. Например:
    COST IS STORED AS QUANTITY х
    х PRICE (стоимость определяется как количество единичную цену).
    Правило типа fetch служит для извлечения значения атрибута из одного объекта в контекст другого. Например:
    ITEM IS TARGET OBJECT (изделие является целевым объектом).
    PRICE IS FETCHED (цена выбирается).
    В соответствии с этим правилом значение атрибута PRICE извлекается из объекта ITEM в контекст другого объекта.
    Правило типа derivation посылает сообщение другому объекту. Например:
    ITEM IS TARGET OBJECT (изделие является целевым объектом).
    QUANTITY IS SUBTRACTED FROM QUANTITY-ON-HAND (количество вычитается из количества на складе).
    В соответствии с этим правилом объекту ITEM будет посылаться сообщение об изменении атрибута QUANTITY-ON-HAND.
    Правило типа call позволяет из одного правила инициировать выполнение других правил. Например:
    IF QUANTITY-ON-HAND LE 1000 CALL PURCHASING (если количество на складе > 1000, вызвать процесс закупки).
    Это правило позволяет строить разветвленную логику обработки.
    Одно из важнейших свойств среды Sapiens заключается в наличии оригинального механизма <позитивного мышления>, который автоматически генерирует импликации правил. Когда задается правило, определяющее поведение объекта для какой-либо ситуации, среда Sapiens автоматически генерирует импликации этого правила для всех возможных ситуаций. В приведенном выше примере использования правила типа derivation за-дана реакция системы на заказ нового продукта. При этом импликации этого правила будут автоматически сгенерированы на изменение заказанного количества, исключение продукта из заказа, замену продукта другим продуктом, аннулирование заказа. Механизм <позитивного мышления> позволяет существенно сократить время разработки прикладной системы. Согласно статистическим данным импликацией правил можно покрыть до 80% возможных ситуаций, которые при традиционных подходах должны быть реализованы в виде отдельных ветвей программ.
    Уникальным типом объектов для среды Sapiens являются объектные конгломераты (object frameworks). Они представляют собой совокупность объектов, связанных в рамках конкретного специфического приложения. Это позволяет начать конкретную разработку не <с нуля>, а с некоторой предварительно определенной и отлаженной базовой платформы.
    Важнейшую роль в среде Sapiens играют сообщения. Приложение обрабатывает различные типы сообщений: входные, выходные, сообщения об ошибках, производные (внутренние) сообщения. Входные - это сообщения, инициированные конечным пользователем с терминала. Ответом на входное сообщение может стать выходное сообщение или сообщение об ошибке, которое объект посылает на экран конечного пользователя. Кроме того, входное сообщение может инициировать совокупность внутренних сообщений, которые объекты посылают друг другу.
    По сути дела, пересылка внутренних сообщений - основа функционирования прикладной системы. Например, если конечный пользователь торговой системы посылает сообщение некоторому объекту с целью увеличить заказ определенного продукта, этот объект автоматически перешлет сообщение другому объекту, определяющему общее количество продукта на складе (для изменения соответствующего значения). Затем будет проверено граничное значение и в случае необходимости послано сообщение объекту, инициирующему заказ новой партии.
    В теле каждого входного сообщения содержится код соответствующей операции (например, Insert, Change, Delete, Extract), идентификатор объекта, которому предназначено данное сообщение и совокупность новых значений атрибутов. Существует возможность группировать входные сообщения, посылаемые с терминала, в трансакции. Если одно из сообщений трансакции завершится аварийно, все остальные сообщения трансакции будут проигнорированы.
    Язык запросов прикладной системы строится разработчиком или конечным пользователем посредством простого многофункционального языка описания запросов QUIX среды Sapiens. Результаты запроса можно представить в виде форматированного экрана или в виде отчета.
    Конечные пользователи и разработчики взаимодействуют с прикладной системой через графический интерфейс (форматированные экраны). Когда определяется новый класс объектов, среда автоматически генерирует его описание, описания атрибутов, описания экранов для работы с объектами этого класса и описания входных сообщений, обеспечивающих взаимодействие экранов с базой данных. Описания экранов хранятся в базе знаний и доступны пользователю и разработчику для корректировки.
    Существуют два типа экранов - экраны обработки данных и экраны меню. Экран обработки данных позволяет отображать данные из базы данных, вносить и редактировать информацию об объектах. На экран может быть выведено несколько блоков, каждый из которых связан с одним классом объектов. Описание экрана содержит количество объектов в блоке, параметры позиционирования атрибутов на экране, заголовки блоков и атрибутов, начальные их значения и т.д. Экран меню - это стандартный набор вариантов для диалога с системой, как и в любой другой системе. За каждой строкой меню может стоять обращение к объекту, вызов процедуры, подключение следующего экрана и т.п.
    Таким образом, использование инструментальной среды разработки Sapiens ObjectPool обеспечивает:

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

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

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

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

* * *

Материалы подготовлены независимой экспертно-консультационной компанией <КомпьюЛог>.
http://www.compulog.ru.