Исследование возможностей CASE-технологии при создании интеллектуальных систем управления

Предыдущая часть

(c) 2000 Семизельникова О.А.

Эта статья была размещена на сайте www.inftech.webservis.ru/

1.3.2. Rational Rose

Rational Rose 98 - это инструментальное средство визуального моделирования для создания сложных коммерческих приложений (или КИС - корпоративных информационных систем), ориентированное на разработчиков архитектуры информационных систем и программистов.

Rational Rose доминирует на рынке продуктов для объектно-ориентированного анализа, моделирования, проектирования и инструментальных средств разработки. International Data Corporation (IDC) - независимая фирма, лидирующая на рынке исследования технологий, в мае 1998 опубликовала отчет, в котором подтверждается, что доля Rational Rose в данном секторе рынка превышает суммарную долю продуктов следующих трех поставщиков вместе взятых и превышает более чем в три раза долю самого близкого конкурента.

Достоинства продукта состоят в следующем:

• отлично реализованная поддержка множества языков программирования,

• широкие возможности моделирования;

• возможность одновременного ведения нескольких проектов,

• возможность совместной разработки несколькими отделами.

• поддержка стандарта визуальной нотации - языка UML.

Rose 98 занимает уникальное место в этом ряду CASE-средств и имеет стратегическое преимущество в плане развития продукта, поскольку:

1. Поддерживает генерацию кода и обратное проектирование (т.е. построение модели по программному коду) для нескольких языков, включая:

• Visual Basic,
• C++,
• Java,
• PowerBuilder,
• CORBA Interface Definition Language(IDL),
• Data Definition Language для большинства СУБД,

• ERwin модели.

2. Поддерживает визуальное моделирование, полностью совместимое с UML (Unified Modeling Language), который с 1997 года определен как стандарт языка для этой быстро развивающейся области инструментальных средств.

3. Имеет утилиты-"переходники" (Links), создаваемые многочисленными независимыми разработчиками инструментальных средств в рамках программы Rational Rose Link Partner Program.

Этапы проведения моделирования в Rational Rose 98

Проектирование в Rational Rose 98 реализуется как дисциплинированный и упорядоченный подход, который используется для итерационного "изобретения" решения заданной проблемы. Это обеспечивает "движение модели" от требований заказчика к программной реализации. Цель проектирования состоит в том, чтобы полученная система:

1. Удовлетворяла заданным (возможно неформальным) спецификациям.

2.Соответствовала ограничениям целевой вычислительной аппаратуры.

3.Удовлетворяла (явным и/или неявным) требованиям на производительность и используемые ресурсы.

4.При ее разработке были выполнены ограничения на сам процесс проектирования по цене, времени, и т.п.

При построении общей модели в Rational Rose 98 используются принципы:

• декомпозиции и абстрагирования,

• иерархии на концептуальном, логическом и физическом уровнях,

• повторного использования элементов моделей/программных компонент,

• разработки различных типов моделей для различных аспектов системы,

• согласованности статических и динамических моделей системы,

• пошаговое и итеративное моделирования/программирования,

• поддержки коллективной разработки/использования компонент.

Моделирование проводится как "поуровневый спуск" от концептуальной модели к логической, а затем к физической модели программной системы. Концептуальная модель выражается в виде "диаграмм прецедентов" (use case diagram). Внутри каждого прецедента могут быть определены:

• вложенная диаграмма прецедентов (use case diagram),

• диаграмма взаимодействия объектов (Collaboration diagram),

• диаграмма последовательности взаимодействий (Sequence diagram),

• диаграмма классов (Class diagram),

• диаграмма состояний (Statechart diagram) .

Логическая модель позволяет определять два различных взгляда на системы: статический и динамический. Статическая модель выражается Диаграммами классов (Class diagram). Именно диаграммы классов служат основой для генерации программного кода на целевом языке программирования. Возможна очень гибкая настройка генерации кода, позволяющая учитывать конкретные соглашения (например, по префиксам имен идентификаторов), принятые в команде разработчиков проекта.

Динамически модели задаются двумя типами диаграмм:

• диаграммами взаимодействия объектов (Collaboration diagram),

• диаграммами последовательности взаимодействий (Sequence diagram).

В текущей версии Rational Rose 98 эти диаграммы не влияют на генерируемый код, однако, существуют приложения фирм-партнеров Rational Software, использующие эти диаграммы в своих приложениях. Так, последовательные диаграммы используются в пакете SQA Suite для автоматизированного проведения тестирования компонент, разработанных в Rational Rose 98. Классы, введенные на этих диаграммах, попадают в список классов модели и могут использоваться при конструировании диаграмм классов.

Физическая модель задается компонентной диаграммой (Component diagram), описывающей распределение классов по модулям, и диаграммой развертывания (Deployment diagram).

После построения "первого/последующего слоя" статической модели с использование диаграмм классов, можно провести генерацию кода на целевом языке программирования. На уровне кода можно ввести новые "уточняющие" классы, изменить атрибуты и методы классов модели и затем синхронизовать код и модель, выполнив "обратное проектирование". Т.е. по модифицированному коду Rational Rose 98 позволяет построить новую логическую модель взаимосвязи классов между собой! Повторение такой процедуры несколько раз называется итерационным моделированием (round-trip modeling), которое составляет основу мягкого и постепенного уточнения постановки задачи и согласования требований заказчика с имеющимися ресурсами (вычислительными, временными, финансовыми и т.п.).

Rational Rose 98 предназначен для генерации клиентской части приложения, но сгенерированный код не является готовым приложением. Здесь генерируются лишь заголовки методов, сами методы необходимо дописывать в ручную. Для генерации схемы БД нужно использовать другие системы. Например, объектную модель Rational Rose можно конвертировать, используя модуль ERwin Translation Wizard, в модель данных IDEF1X , поддерживаемую в ERwin. ERwin позволяет сгенерировать схему БД на любой из поддерживаемых СУБД.

2.1.Обоснование выбора среды разработки

2.1.1. Обзор возможностей современных СУБД

За исключением некоторых систем, иерархические СУБД почти полностью ушли с рыночной арены, а также и из сознания разработчиков приложений. Лидирующее положение два последних десятилетия занимает реляционная модель данных, представленная на рынке большими и маленькими коммерческими пакетами, такими как Oracle, Sybase, Access и др. Несмотря на полный коммерческий успех, многие эксперты ожидают изменений основополагающих принципов технологии БД в ближайшие пять лет.

В качестве недостатков реляционных СУБД отмечаются следующие:

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

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

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

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

Между тем кризис в сфере практического применения реляционных СУБД постепенно нарастает. По имеющимся в литературе сведениям до 80% созданных корпоративных хранилищ данных не решают полностью поставленных перед ними задач, а 40% являются проваленными проектами. Около 50% запросов Пользователей являются не предусмотренными в ходе их проектирования. По-видимому, можно считать, что использование реляционных СУБД неэффективно при количестве заложенных в них отношений (таблиц, информационных объектов) свыше 100-300.

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

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

Не смотря на все вышесказанные недостатки реляционной модели данных, всё же она является наиболее современной на сегодняшний день. По этому нет смысла использовать ранние модели ввиду их неконкурентноспособности по сравнению с реляционными и нет смысла использовать системы провозгласившие себя ОО, ввиду того, что под ними нет теоретической основы. Но и строить БД на основе чисто реляционной структуры было бы то же неуместно, ввиду её нереальности отображения семантики мира. Поэтому необходимо найти систему, которая основывалась на реляционном подходе и имела определённые разработки в объектно-ориентированных направлениях. При этом реляционный подход к организации БД должен быть наиболее популярным. И такой подход уже давно развит. Он основан на использование техники B-деревьев. С точки зрения внешнего логического представления B-дерево - это сбалансированное сильно ветвистое дерево во внешней памяти. Сбалансированность означает, что длина пути от корня дерева к любому его листу одна и та же. Ветвистость дерева - это свойство каждого узла дерева ссылаться на большое число узлов-потомков. Поиск в B-дереве - это прохождение от корня к листу в соответствии с заданным значением ключа. Заметим, что поскольку деревья сильно ветвистые и сбалансированные, то для выполнения поиска по любому значению ключа потребуется одно и то же (и обычно небольшое) число обменов с внешней памятью. Более точно, в сбалансированном дереве, где длины всех путей от корня к листу одни и те же, если во внутренней странице помещается n ключей, то при хранении m записей требуется дерево глубиной log_n(m), где log_n вычисляет логарифм по основанию n. Если n достаточно велико (обычный случай), то глубина дерева невелика, и производится быстрый поиск. Основной "изюминкой" B-деревьев является автоматическое поддержание свойства сбалансированности.

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

Продолжение статьи

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме