Размещено на http://www.allbest.ru/

Промышленные технологии проектирования программного обеспечения

1. Методология DATARUN

Одной из наиболее распространенных в мире электронных методологий является методология DATARUN. В соответствии с методологией DATARUN ЖЦ ПО разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каждую стадию кроме ее результатов должен завершать план работ на следующую стадию.

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

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

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

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

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

Методология DATARUN опирается на две модели или на два представления:

· модель организации;

· модель ИС.

Методология DATARUN базируется на системном подходе к описанию деятельности организации. Построение моделей начинается с описания процессов, из которых затем извлекаются первичные данные (стабильное подмножество данных, которые организация должна использовать для своей деятельности). Первичные данные описывают продукты или услуги организации, выполняемые операции (транзакции) и потребляемые ресурсы. К первичным относятся данные, которые описывают внешние и внутренние сущности, такие как служащие, клиенты или агентства, а также данные, полученные в результате принятия решений, как например, графики работ, цены на продукты. Основной принцип DATARUN заключается в том, что первичные данные, если они должным образом организованы в модель данных, становятся основой для проектирования архитектуры ИС. Архитектура ИС будет более стабильной, если она основана на первичных данных, тесно связанных с основными деловыми операциями, определяющими природу бизнеса, а не на традиционной функциональной модели. Любая ИС (рисунок 3.1) представляет собой набор модулей, исполняемых процессорами и взаимодействующих с базами данных. Базы данных и процессоры могут располагаться централизованно или быть распределенными.

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

Рис. Модель ИС

Подход DATARUN преследует две цели:

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

· спроектировать ИС на основании модели данных.

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

На рисунке 3.3 определены модели, создаваемые в процессе разработки ИС. Для их создания используется CASE-средство Silverrun, описанное в подразделе 5.1. Silverrun обеспечивает автоматизацию проведения проектных работ в соответствии с методологией DATARUN. Предоставляемая этими средствами среда проектирования дает возможность руководителю проекта контролировать проведение работ, отслеживать выполнение работ, вовремя замечать отклонения от графика. Каждый участник проекта, подключившись к этой среде, может выяснить содержание и сроки выполнения порученной ему работы, детально изучить технику ее выполнения в гипертексте по технологиям, и вызвать инструмент (модуль Silverrun) для реального выполнения работы.

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

Рис. Последовательность шагов проектирования системы

BPM (Business Process Model) - модель бизнес-процессов.

PDS (Primary Data Structure) - структура первичных данных.

CDM (Conceptual Data Model) - концептуальная модель данных.

SPM (System Process Model) - модель процессов системы.

ISA (Information System Architecture) - архитектура информационной системы.

ADM (Application Data Model) - модель данных приложения.

IPM (Interface Presentation Model) - модель представления интерфейса.

ISM (Interface Specification Model) - модель спецификации интерфейса.

Рис. 3.3. Модели, создаваемые с помощью подхода DATARUN

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

В процессе обследования работы организации выявляются и документируются структуры первичных данных. Эти структуры заносятся в репозиторий модуля BPM при описании циркулирующих в организации документов, сообщений, данных. В модели бизнес-процессов первичные структуры данных связаны с потоками и хранилищами информации.

На основе структур первичных данных в модуле Silverrun ERX создается концептуальная модель данных (ER-модель). От структур первичных данных концептуальная модель отличается удалением избыточности, стандартизацией наименований понятий и нормализацией. Эти операции в модуле ERX выполняются при помощи встроенной экспертной системы. Цель концептуальной модели данных - описать используемую информацию без деталей возможной реализации в базе данных, но в хорошо структурированном нормализованном виде.

На основе модели бизнес-процессов и концептуальной модели данных проектируется архитектура ИС. Определяются входящие в систему приложения, для каждого приложения специфицируются используемые данные и реализуемые функции. Архитектура ИС создается в модуле Silverrun BPM с использованием специальной нотации ISA. Основное содержание этой модели - структурные компоненты системы и навигация между ними. Концептуальная модель данных разбивается на части, соответствующие входящим в состав системы приложениям.

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

С помощью модели системных процессов детально документируется поведение каждого приложения. В модуле BPM создается модель системных процессов, определяющая, каким образом реализуются бизнес-процессы. Эта модель создается отдельно для каждого приложения и тесно связана с моделью данных приложения.

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

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

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

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

2. Rational Unified Process

· Обширные руководства для всех членов коллектива разработчиков, для каждого временного интервала жизненного цикла ПО. Руководства представлены в двух видах: для осмысления процесса на верхнем уровне, и в виде подробных наставлений по повседневной деятельности. Руководства опубликованы в HTML формате.

· Наставления по пользованию инструментальными средствами, которые автоматизируют большие разделы процесса создания ПО. Наставления опубликованы в HTML формате.

· Примеры и шаблоны для Rational Rose, которые служат руководствами по тому, как структурировать информацию в Rational Rose при следовании указаниям RUP.

· Шаблоны для SoDa - более десятка шаблонов для SoDa, которые помогают автоматизировать документирование ПО.

· Microsoft Word шаблоны - более 30 шаблонов, которые предназначены для поддержки документации по всем последовательностям действий и интервалам жизненного цикла ПО.

· Планы в формате Microsoft Project - для тех, кому трудно сразу перейти к созданию планов - отражают итерационную разработку. Данные документы помогают произвести такой переход.

· Development Kit - описывает то, каким образом можно конфигурировать и расширить RUP для специфических нужд проекта, и обеспечивает инструменты и шаблоны, помогающие это выполнить.

· Доступ к Resource Center, который содержит последние публикации, обновления, подсказки, методики, а также ссылки на add-on и сервисы.

· Книги Ph. Kruchten - Rational Unified Process-An Introduction. Книга содержит 277 страниц и является хорошим вступлением и обзором к процессу и базе знаний.

Ниже представлен список продуктов, которые поддерживают Rational Unified Process:

· Rational Requisite Pro - поддерживает обновления и отслеживает изменения в требованиях для всего коллектива разработчиков, представляя их в удобном виде для чтения, обсуждения и изменений.

· Rational ClearQuest - Windows и Web-размещаемый продукт, который помогает коллективу разработчиков отслеживать и управлять всеми действиями по изменению ПО в течение его жизненного цикла.

· Rational Rose 98 - мировой лидер среди средств визуального моделирования для бизнес процессов, анализа требований, и проектирования на основе архитектуры компонентов.

· Rational SoDA - автоматизирует создание документации для всего процесса разработки ПО, значительно сокращая стоимость документации и время на ее создание.

· Rational Purify - средство поиска ошибок на run-time для разработчиков приложений и компонентов, программирующих на C/C++; помогает находить ошибки утечки памяти.

· Rational Visual Quantify - средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО.

· Rational Visual PureCoverage - автоматически определяет области кода, которые не подвергаются тестированию; разработчики могут учесть это и более тщательно выполнять проверку.

· SQA TeamTest - создает, обслуживает и выполняет автоматизированные функциональные тесты, позволяя тщательно протестировать код и проверить, соответствует ли ПО предъявляемым к нему требованиям.

· Rational PerformanceStudio - простое в использовании, точное и масштабируемое средство, которое измеряет и предсказывает характеристики клиент/серверных и Web систем.

· Rational ClearCase - лидирующее на рынке средство конфигурационного управления, позволяющее менеджерам проекта отслеживать эволюцию каждого разрабатываемого проекта.

Циклы разработки ПО

В методологии RUP определяется цикл разработки ПО, который всегда состоит из последовательности четырех фаз4:

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

· Фаза проработки проекта: планирование необходимых работ и требуемых ресурсов; определение возможностей, проектирование и создание базовой версии архитектуры.

· Фаза построения системы: создание продукта, дальнейшее развитие его концепции, архитектуры и планов работ до тех пор, пока продукт,имея законченную концепцию,не будет готов для первоначальной поставки заинтересованным лицам.

· Фаза передачи в эксплуатацию: завершение передачи продукта в эксплуатацию своим пользователям, что включает такие процессы, как производство, поставку, обучение, поддержку и сопровождение продукта с целью полного удовлетворения потребностей конечных пользователей.

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

Затем, уже в пределах каждой фазы, разработка ПО идет итеративно, путем повторения сходных наборов работ и последовательного улучшения создаваемой системы вплоть до момента, когда продукт может быть поставлен заказчику. прикладной серверный приложение интерфейс

Эти фазы являются обязательными и через них нельзя перешагнуть; хотя в некоторых случаях проводимые в них работы можно сократить до минимума, но практически никогда невозможно сократить до нуля. Не заблуждайтесь относительно "узловой диаграммы" методологии RUP (рис. 1); эта диаграмма не учитывает факта, что вы уже затратили определенное количество времени и денег на то, чтобы выполнить часть работ. Вот один из ключевых принципов RUP: “Не делайте ничего, не имея перед собой цели.”

Давайте, например, предположим, что вы только что вышли из фазы обследования, и поняли, что имеются все предпосылки для выхода из фазы проработки проекта:

· Требования понимаются однозначным образом.

· В дальнейшем архитектура не будет изменяться.

· Имеется план первой итерации фазы построения системы.

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

Рис. "Узловая диаграмма" методологии RUP

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

Рис. 2. Версия 1.0: цикл начальной разработки

Циклы развития

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

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

3. Oracle Designer

Целостность и Качество

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

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

Oracle Designer один раз определяет и много раз использует правила, управляющие надлежащим поведением и формой отображения данных. Эти стандартные правила можно переопределить во время проектирования для каких-либо конкретных целей, но в любом случае характеристики, используемые по умолчанию в остальных приложениях, сохраняются. Oracle Designer позволяет разработчикам встраивать руководства по стилю пользовательского интерфейса непосредственно в набор инструментальных средств генерации программного кода, используя для этого мощную комбинацию настроек (Preferences) и шаблонов (Templates). Настройки для элементов UI устанавливаются для всей прикладной системы и многократно генерируются для всех модулей, гарантируя их единообразие.

Задачи, решаемые Oracle Designer

Графика на всех этапах жизненного цикла

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

Гибкое бизнес-моделирование

За счет предоставления инструментальных средств поддержки как объектно-ориентированных (OO) моделей моделирования, так и моделей типа "сущность-связь" (ER) Oracle обеспечивает гибкий метод бизнес-моделирования. Оба построителя диаграмм (diagrammers) поддерживают стандартные соглашения для соответствующих стилей моделирования: Унифицированный Язык Моделирования (Unified Modeling Language - UML) поддерживается разработчиком моделей (modeler) объектно-ориентированного типа, а моделирование ER - разработчиком моделей "сущность-связь".

Генерация для сред Web и клиент/сервер

На основе определений, хранящихся в репозитории , генерируются приложения, которые затем развертываются в средах клиент/сервер или Web. Используя Oracle Developer , на основе определения модуля или даже целого приложения можно получить систему, которая развертывается в обеих средах, без изменения каких бы то ни было частей определения. Это чрезвычайно продуктивный путь повторного использования определения приложений.

Реинжениринг проекта

Проектирование серверной части

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

Проектирование приложений

Аналогично, мы можем сделать реинжениринг проекта приложений, построенных на языке Visual Basic или Developer Reports и Forms Developer, включая логику приложения.

Циклическое (круговое) проектирование

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

Эта способность изменять приложение вне рамок Oracle Designer, определять изменения и повторно генерировать (сохраняя изменения) известна под названием "циклическое проектирование" (Round-Trip Engineering) и является основным элементом продуктивной среды проектирования и разработки. Если мы принимаем, что приложение изменяется в течение своего жизненного цикла, то способность поддерживать такое высокопродуктивное циклическое проектирование является одним из основных преимуществ использования Oracle Designer.

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

В Oracle Designer включены средства для управления содержимым репозитория и доступом к нему пользователя. Утилита Администрирования Репозитория (Repository Administration Utility) предназначена АБД репозитория.

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

Средства выделения, загрузки и слияния данных репозитория поддерживают распределенную разработку, при которой могут использоваться многочисленные репозитории Oracle Designer. Определения из одного репозитория загружаются в другие и согласовываются, гарантируя, что разработчики, не имеющие возможности работать в команде, могут все-таки извлечь пользу из плодов работы других разработчиков. Так же репозиторий служит опорой понятия "мобильная разработка". В рамках этого понятия аналитики или дизайнеры системы могут дистанционно (то есть, не покидая своих постоянных рабочих мест) работать с пользователями или клиентами, чтобы совместно определить требования, или прототипы, прежде чем вернуться к повторной загрузке новых определений проекта в центральный репозиторий.

Утилита Администрирования Репозитория обеспечивает очень эффективные, но, тем не менее простые в использовании характеристики, которые гарантируют, что полномасштабная разработка систем может проходить гладко, расширяя преимущества разработчиков, которые вместе трудятся в единой контролируемой среде.

Мощная база данных предварительных настроек и преобразователи проектов приложений

Отталкиваясь от созданной модели связи сущностей (ER), преобразователь проектов БД (Database Design Transformer) может автоматически выполнить эскизный проект базы данных со всеми таблицами, столбцами, индексами, и ограничениями ссылочной целостности.

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

Гибкость репозитория и открытые интерфейсы

Репозиторий Oracle Designer сконфигурирован таким образом, что он имеет возможность управлять объектами, используя собственный программный интерфейс. Описание нового объекта можно ввести в репозиторий с помощью диалогового интерфейса и без потребности в программировании. Доступ к новым объектам можно получать из имеющихся инструментальных средств и легко манипулировать ими, используя для этого Матричный Диаграммер (Matrix Diagram) или Навигатор Объектов Репозитория (Repository Object Navigator).

Разработчики или другие поставщики инструментальных средств имеют доступ к содержимому репозитория непосредственно из программ, написанных на языках 3GL или 4GL, используя полный API моделирования. С помощью этого API существенно упрощается процесс интеграции с репозиторием продуктов третьих фирм и облегчается их поддержка. Используя гибкость и открытые интерфейсы, доступные при работе с Oracle Designer, разработчики могут, не прибегая к сложному программированию, приспособить репозиторий к своим специфическим потребностям и использовать Oracle Designer в гетерогенной среде разработки, куда включены и инструментальные средства от других поставщиков.

Интеграция с настольными системами

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

Инструментарий моделирования Oracle Designer тесно интегрирован с известными приложениями. OLE интерфейс обеспечивает в средствах моделирования работу механизмов cut-and-paste и drag-and-drop. Можно привести примеры включения диаграмм в документы текстовых процессоров или использование текстового процессора для снабжения примечаниями самих моделей. Там где это необходимо, диаграммы могут даже содержать изображения, видео и звук. Такая интеграция позволяет разработчикам и пользователям вместе использовать знакомый комплект инструментальных средств в процессе определения бизнес-моделей и моделей систем, способствуя групповой работе, увеличению производительности и эффективности взаимодействия.

Управление диаграммами и синхронизация

Бизнес-моделирование и моделирование систем - это сложные, многозадачные процессы, для проведения которых требуются соответствующие средства поддержки. Инструментарий моделирования использует для управления и синхронизации сессий построения диаграмм (diagramming sessions) метод Интерфейса Множественных Документов (Multiple Document Interface - MDI), общеупотребительный во многих Windows-приложениях.

Основным требованием при построении графических бизнес-моделей и моделей систем является поддержка гибкой групповой работы и исправления моделей в многопользовательской среде. Это всегда было сильной стороной продуктов Oracle для моделирования.

Механизм широкого оповещения

Механизм широкого оповещения Oracle Designer делает возможным оповещение пользователей об изменениях объектов репозитория текущей прикладной системы, как только такие изменения сделаны. Если объект репозитория, который в настоящий момент отображается в одном инструментальном средстве, изменяется в другом средстве, (даже в тех случаях, если это средство используется другим пользователем и на другой машине), срабатывает индикатор широкого оповещения, так что устаревшие объекты корректируются для требующегося отражения изменений.

Размещено на Allbest.ru