С.А. Панащук

РосНИИ ИТ и АП, тел.: (095) 288-27-97


1. Контекст использования системы SILVERRUN
2. Архитектура системы SILVERRUN
3. Подход к представлению проектной информации
4. Моделирование процессов
5. Моделирование данных
6. Развитие системы

Американская фирма Computer Systems Advisers, Inc. (CSA) является поставщиком средств проектирования и создания информационных систем архитектуры "клиент-сервер", а также занимается консалтингом в области информационных технологий. Статья знакомит читателя с основным продуктом фирмы - CASE-системой SILVERRUN.

1. Контекст использования системы SILVERRUN



Рисунок 1.

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

1.1. Методология

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

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

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

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

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

1.2. Средства управления проектом

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

1.3. CASE-система верхнего уровня

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

1.4. Средства поддержки проектирования систем

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

1.5. Средства управления разработкой приложений

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

1.6. Языки разработки приложений четвертого поколения

Для массового создания информационных систем критична эффективность и относительная простота средств разработки приложений. Этим требованиям удовлетворяют языки четвертого поколения (4GL). Высокая скорость разработки, возможность повторного использования и хорошая переносимость созданных на этих языках приложений сделали языки четвертого поколения наиболее используемыми средствами разработки систем бизнес-класса.

SILVERRUN имеет возможность передать информацию в репозитории (или словари данных) наиболее распространенных средств создания приложений. При этом экономятся значительные трудозатраты разработчиков. Например, генератор приложений SILVERRUN для PowerBuilder может генерировать из модели данных до 75% кода приложения.

1.7. Реляционные СУБД

Среди используемых СУБД в настоящее время наиболее распространены реляционные системы, основанные на хорошо разработанной математической теории, представляющие удобный стандартизированный интерфейс, переносимые и хорошо приспособленные для параллельной обработки больших объемов информации.

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

1.8. Средства управления распределенной обработкой информации

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

1.9. Масштабируемость

Использование сразу всех компонентов, изображенных на рис.1, не обязательно. Среда может наращиваться по мере необходимости. Минимальная конфигурация - модуль реляционного моделирования SILVERRUN + язык четвертого поколения + РСУБД.

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

SILVERRUN состоит из трех основных подсистем: модуля построения диаграмм потоков данных (Data Flow Diagrammer) и двух модулей построения диаграмм "сущность-связь": концептуальных моделей - модуль ERX (Entity Relationship eXpert) и реляционных моделей - модуль RDM (Relational Data Modeler). Каждый модуль является самостоятельным продуктом и может приобретаться и использоваться отдельно. Для интеграции подсистем в единое целое служит менеджер репозитория WRM (Workgroup Repository Manager).

Встроенный в модуль RDM генератор схем баз данных позволяет получить операторы определения данных (DDL) для 15 СУБД. Но для полного использования специфики каждой СУБД следует использовать отдельно приобретаемые мосты, позволяющие как получить схему базы данных из модели, так и построить модель существующей базы данных.

Для обмена данными с языками разработки приложений также используются соответствующие мосты. Полный перечень существующих в настоящее время мостов включен в Рис.1. Таким образом, из модулей можно собрать систему требуемого масштаба: от диаграммера до среды разработки приложений для конкретного языка программирования и СУБД. Заменяемость мостов позволяет использовать единые бизнес-модели в ситуациях, когда разные подразделения или филиалы организации используют разные СУБД и средства разработки приложений.

Сама система SILVERRUN функционирует на четырех платформах: Windows, OS/2, Macintosh, Solaris. Коллективная разработка в стандартной версии поддерживается разделением и слиянием моделей. В версии SILVERRUN Enterprise поддерживается одновременный коллективный доступ к репозиторию (в настоящее время на базе СУБД ORACLE, к концу 1995 года - также на базе СУБД Sybase и Informix). Между версиями разных платформ обеспечен обмен данными, что обеспечивает одновременную разработку в разнородной среде, как в сетевом, так и в одиночном режимах.

3. Подход к представлению проектной информации

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

Один и тот же элемент данных может в разных представлениях иметь разные названия и форматы. В SILVERRUN обеспечена возможность связывать элементы данных различных представлений с общим элементом (common item), выражающим смысл информации, представленной этими элементами данных. Этот общий элемент может стать столбцом таблицы базы данных в новой системе или просто использоваться как универсальный термин для связи разных представлений.

4. Моделирование процессов

Диаграммы потоков данных, создаваемые в SILVERRUN, соответствуют современному развитию принципов структурного анализа. В системе имеется возможность изменять внешний вид символов диаграмм и выбирать отображаемые в них дескрипторы, включая определяемые пользователем. На рис.2 показан экран определения нотации модуля DFD. Также можно выбирать набор правил, проверяемых процедурой анализа корректности модели. В SILVERRUN встроено несколько предопределенных нотаций и наборов правил, соответствующих наиболее известным методам построения DFD: Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor.

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

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



Рисунок 2.

5. Моделирование данных

5.1. Концептуальное моделирование

В процессе первичного анализа данных, собранных из разных источников, необходимо выявить основные информационные понятия (сущности) и их взаимосвязи. Эта деятельность поддерживается модулем ERX, в который встроена экспертная система, помогающая реструктурировать "сырую" информацию и привести ее к виду, допускающему реализацию в реляционной СУБД. На рис.3 показана структура данных, а на рис.4 - модель "сущность-связь" в третьей нормальной форме, автоматически построенная модулем ERX из этой структуры и нормализованная в процессе ответов пользователя на задаваемые системой вопросы.

Data structure

Name          :      Заказ
Composition     :
    Заказ Номер
    Заказ Дата
    Покупатель Имя
    Покупатель Адрес
    Продукт
        Продукт Название
        Продукт Цена
        Продукт Количество
        Продукт Стоимость
    Заказ Стоимость

Рисунок 3.
Структура данных, на основе которой будет строится ER-модель



Рисунок 4.

5.2. Реляционное моделирование

На рис.5 показана созданная в ERX модель, перенесенная в модуль реляционного моделирования RDM и доработанная для непосредственной реализации в реляционной базе данных. В нижней части символов таблиц показаны действия над записями. А три колонки справа от имен столбцов таблиц отражают действия, производимые над этими столбцами при операциях считывания, присваивания и модификации значений. В генерируемой мостом схеме базы данных этим действием будут соответствовать триггеры. Также можно определять глобальные действия на уровне всей модели (в схеме базы данных - хранимые процедуры).



Рисунок 5.

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

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

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



Рисунок 6.

Различные группы пользователей имеют доступ к разным подмножествам базы данных и к ограниченному набору операций над ними. Для моделирования пользовательских (внешних по терминологии ANSI SPARC) представлений в модуле RDM используется механизм подсхем. Подсхема - это подмножество модели данных, доступное конкретному приложению или группе пользователей. SILVERRUN позволяет управлять "прозрачностью" границы между схемой и подсхемой, а также по требованию интерактивно переносить изменения из схемы в подсхему и наоборот. Число уровней подсхем не ограничено: можно создавать подсхемы подсхем.

5.3. Генерация приложений и схем баз данных

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

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

Генерация схемы базы данных происходит путем создания файла с SQL-операторами, в которые переводятся конструкции модели данных. Этот файл используется для физического создания базы данных на сервере. На рис.7 приведен фрагмент схемы для СУБД Informix OnLine, полученной из модели, изображенной на Рис.5.

- ====================================
-    table: Order
- ====================================
create table Order
(
    OrderNum        INTEGER       not null,
    OrderDate       DATE          default TODAY not null,
    OrderCost       MONEY         not null,
    CustomerName    CHAR          not null,
    primary key (OrderNum)
)
;
- ================================================================
-    referential integrity triggers section
- ================================================================

-    =======================================
-    Procedure raise_exception for errors messages
-    =======================================
create procedure
    messages_errors(errno INTEGER, isam INTEGER, errmsg char(255))
    raise exception errno, isam, errmsg;
end procedure;
-  ===================================================
-   Controls the INSERT action on table Order.
-   Rule         : CHILD INSERT RESTRICT
-   Parent       : Customer
-   Child        : Order
-   Direction    : Order_Customer
-  ===================================================
create trigger tr_ins_Order insert on Order
    referencing NEW as inserted
    for each row
    when
    (
        (select count(*) from Customer
            where
                inserted.CustomerName = Customer.CustomerName
        ) = 0
    )
    (
        execute procedure messages_errors
        (
            -746,
            0,
            "Insert of "Order" denied: corresponding "Customer" does not exist."
        )
    )
;
-  ===================================================
-   Controls the DELETE action on table Customer.
-   Rule         : PARENT DELETE RESTRICT
-   Parent       : Customer
-   Child        : Order
-   Direction    : Customer_Order
-  ===================================================
create trigger tr_del_Customer delete on Customer
    referencing OLD as deleted
    for each row
    when
    (
        exists
        (
            select * from Order
            where
                Order.CustomerName = deleted.CustomerName
        )
    )
    (
        execute procedure messages_errors
        (
            -746,
            0,
            "Delete of "Customer" denied: referencing "Order" exists."
        )
    )
;

Рисунок 7.
Фрагмент схемы базы данных для СУБД Informix OnLine.

6. Развитие системы

SILVERRUN постоянно развивается. В начале 1995 г. выпущена версия под ОС Solaris для платформ Intel и Sparc. К концу года закончится реализация модулей реинжениринга бизнес-процессов и ERX для версии SILVERRUN Enterprise. Постоянно обновляющиеся мосты позволяют работать с последними версиями поддерживаемых продуктов.