Методологические основы CASE-технологий — КиберПедия 

Автоматическое растормаживание колес: Тормозные устройства колес предназначены для уменьше­ния длины пробега и улучшения маневрирования ВС при...

История развития хранилищ для нефти: Первые склады нефти появились в XVII веке. Они представляли собой землянные ямы-амбара глубиной 4…5 м...

Методологические основы CASE-технологий

2017-11-17 498
Методологические основы CASE-технологий 0.00 из 5.00 0 оценок
Заказать работу

 

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

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

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

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

CASE-средствам присущи следующие основные особенности:

• наличие мощных графических средств;

• интеграция отдельных компонентов CASE-средств с IDE;

• использование хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

• графические средства анализа и проектирования, обеспечивающие создание и редактирование комплекса взаимосвязанных диаграмм;

• средства разработки приложений, включая языки 4GL (Fourth Generation Language - язык 4-го поколения) и генераторы кодов;

• средства управления требованиями;

• средства управления конфигурацией ПО;

• средства документирования;

• средства тестирования;

• средства управления проектом;

• средства реверсного инжиниринга ПО и баз данных (восстановления исходников из конечного продукта).

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

В CASE-средствах обычно реализуются следующие виды контроля:

• контроль синтаксиса диаграмм и типов их элементов;

• контроль полноты и состоятельности диаграмм: все элементы диаграмм должны быть идентифицированы и отражены в репозитории. Например, для DFD контролируются неименованные или несвязанные потоки данных, процессы и хранилища данных;

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

Можно привести много примеров различных классификаций CASE- средств, встречающихся в литературе. CASE-средства можно классифицировать по применяемым структурным или объектно-ориентированным методам анализа и проектирования ПО. Также есть классификация по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ.

 

 

Внедрение CASE-средств

 

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

• определение потребностей в CASE-средствах;

• оценка и выбор CASE-средств;

• выполнение пилотного проекта;

• практическое внедрение CASE-средств.

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

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

Несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате чего эти средства становятся “полочным” ПО (shelfware). В связи с этим необходимо отметить следующее:

• CASE-средства не обязательно дают немедленный эффект;

• затраты на внедрение CASE намного превышают затраты на приобретение;

• существенная выгодапоявляется только после завершения внедрения.

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

• широкое разнообразие качества и возможностей CASE-средств;

• недостаток опыта их применения;

• разнообразие практики внедрения CASE-средств в различных организациях;

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

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

• различная степень интеграции CASE-средств в различных проектах.

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

Ключом к успешному внедрению CASE-средств является готовность организации, которая включает следующие аспекты:

• технология — понимание ограниченности существующих возможностей и способность принять новую технологию;

• культура — способность воспринять новые процессы и взаимоотношения между разработчиками и пользователями;

• управление - четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

Чтобы принять взвешенное решение относительно инвестиций в CASE-технологию, пользователи вынуждены производить оценку отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных “подводных камней” использования CASE- средств. Среди наиболее важных проблем выделяются следующие:

• достоверная оценка отдачи от инвестиций в CASE-средства затруднительна;

• внедрение CASE-средств может представлять собой достаточно длительный процесс. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение;

• отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации;

• CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами, что объясняется как различными парадигмами, так и проблемами передачи данных и управления от одного средства к другому;

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

• негативное отношение персонала к внедрению новой CASE-технологии

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

Особенности конкретных проектов также накладывают отпечаток на процесс внедрения CASE-средств. Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE- средств позволяет преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить:

• высокий уровень технологической поддержки;

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

• приемлемый уровень отдачи от инвестиций в CASE-средства.

Рассмотрим этапы внедрения CASE-средств.

 

4.2.2. ОПРЕДЕЛЕНИЕ ПОТРЕБНОСТЕЙ В САБЕ-СРЕДСТВАХ

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

Анализ возможностей организации

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

Формальные подходы определяются моделью оценки зрелости технологических процессов в организации СММ (Capability Maturity Model), разработанной SE1 (Software Engineering Institute), а также стандартами ISO 9001: 1994, ISO 9003-3: 1991 и ISO 9004-2:1991. Главное в этих подходах - анализ различных аспектов происходящих в организации процессов.

Рис. 4.1. Определение потребностей в CASE-средствах

 

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

 

 


 

Характеристики CASEсредств

 

SilverRun

CASE-средство Silverrun американской фирмы Silverrun Technologies, Inc. используется для анализа и проектирования ЭИС и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любого метода, основанного на структурном подходе к проектированию ПО. Настройка на конкретный метод обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных ме-тодов: DATARUN (основной метод, поддерживаемый Silverrun), Гейна - Сэрсона, Йордана, Уорда — Меллора, Мартина и др. Для каждого понятия, введенного в проект, имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (ВРМ — Business Process Modeler) позволяет моделировать деятельность обследуемой организации или проектируемую ЭИС. В модуле ВРМ обеспечена возможность работы с моделями большой сложности: автоматическая перенумерация процессов, работа с деревом процессов (включая визуальное перетаскивание ветвей), отсоединение и присоединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая нотации Йордана и Гейна - Сэрсона. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля. В версии Silverrun 2.7 добавлена поддержка некоторых диаграмм UML (вариантов использования, последовательности, сотрудничества и состояний).

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

Модуль реляционного моделирования {RDM- Relational Data Modeler) позволяет создавать детализированные ERD, предназначенные для последующей генерации описания реляционной базы данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т.д. Изменяемая нотация и расширяемость репозитория позволяют работать по любому методу. Возможность создавать подсхемы соответствует подходу ANSI (American National Standards Institute — Американский национальный институт стандартов) SPARC к представлению схемы базы данных. На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представления. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.

Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.

Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля между компонентами различных моделей (например, возможности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, однако, отметить, что этот недостаток может иметь существенное значение только в случае использования каскадной модели ЖЦ ПО.

Взаимодействие с другими средствами. Для автоматической генерации схем баз данных у Silverrun существуют интерфейсы (мосты) для наиболее распространенных СУБД: Oracle, Informix, DB2, MS SQL Server, Sybase, MS Access. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL. Это дает возможность документировать, перепроектировать или переносить на новые платформы уже находящиеся в эксплуатации базы данных и прикладные системы. При использовании моста Silverrun расширяет свой внутренний репозиторий специфичными для целевой системы атрибутами. После определения значений этих атрибутов генератор приложений переносит их во внутренний каталог среды разработки или использует при генерации кода на языке SQL. Таким образом, можно полностью определить ядро базы данных с использованием всех возможностей конкретной СУБД: триггеров, хранимых процедур, ограничений ссылочной целостности. При создании приложения на языке 4GL данные, перенесенные из репозитория Silverrun, используются либо для автоматической генерации интерфейсных объектов, либо для быстрого их создания вручную.

Для объектно-реляционной СУБД Informix-Universal Server разработано специальное средство объектно-реляционного моделирования Silverrun-Universal Modeler, поддерживающее нотацию Unified Modeling Language (UML), позволяющее проектировать и генерировать БД, а также выполнять реинжиниринг объектных компонентов DataBlade, формируя при этом собственные графические объектные модели (SilverBlade), используемые в дальнейшем для поддержки DataBlade.

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

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

• система экспорта/импорта. Для более полного контроля над структурой файлов в системе экспорта/импорта имеется возможность определять не только содержимое экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца текстовых полей. Файлы с указанной структурой можно не только формировать, но и загружать в репозиторий. Это позволяет обмениваться данными с различными системами: другими CASE-средствами, СУБД, текстовыми редакторами и электронными таблицами;

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

Одним из примеров практической реализации взаимосвязи между структурным и объектно-ориентированным подходом является программный интерфейс (мост) между CASE-средствами Silverrun и RationalRose, разработанный компанией “Аргуссофт”. Этот мост создает диаграммы классов RationalRose на основе RDM-модели Silverrun. Главная трудность при разработке подобных мостов связана с тем, что средства описания моделей в одной системе содержат конструкции, не имеющие аналогов в другой. Однако между RDM- моделью Silverrun и объектной моделью RationalRose существует прямая и обратная аналогия (рис. 4.5 а, б).

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

 

Рис. 4.5. Прямая (а) и обратная (б) аналогия между RDM-моделью Silverrun и объектной моделью RationalRose

 

Групповая работа. Групповая работа поддерживается в системе Silverrun двумя способами. В стандартной однопользовательской версии (Silverrun Professional) имеется механизм контролируемого разделения и слияния моделей. Разделив модель на части, можно раздать их нескольким разработчикам. После детальной доработки модели объединяются в единые спецификации. Сетевая версия Silverrun Enterprise позволяет осуществлять одновременную групповую работу с моделями, хранящимися в сетевом репозитории на базе СУБД Oracle, Sybase, MS SQL Server или Informix. При этом несколько разработчиков могут работать с одной и той же моделью, так как блокировка объектов происходит на уровне отдельных элементов модели.

Среда функционирования. Текущая версия Silverrun 2.7 реализована на платформах Windows 95/98/NT.

 

 

ORACLEDESIGNER

CASE-средствоOracleDesignerфирмыOracleявляетсяинтегрированнымCASE-средством, обеспечивающимвсовокупностисосредствамиразработкиприложенийOracleDeveloperиOracle

Application Server поддержку полного ЖЦ ПО для систем, использующих СУБД Oracle.

Структура и функции. Oracle Designer представляет собой семейство методов и поддерживающих их программных продуктов. Базовый метод Oracle Designer (CASE*Method Баркера) — структурный метод проектирования систем, охватывающий полностью все стадии ЖЦ ПО. в настоящее время данный метод продолжает развиваться и поставляется корпорацией Oracle как самостоятельный продукт под названием Custom Development Method (CDM) в совокупности с методами и средствами управления проектом Project Management method (PJM).

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

• Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);

• Repository Object Navigator - средство доступа к репозиторию, обеспечивающее многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;

• Process Modeler — средство анализа и моделирования деятельности организации, основывающееся на концепциях реинжиниринга бизнес-процессов (Business Process Reengineering) и глобальной системы управления качеством (Total Quality Management);

• Systems Modeler - набор средств построения функциональных и информационных моделей проектируемой ЭИС, включающий средства для построения диаграмм “сущность-связь” (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);

• Systems Designer - набор средств проектирования ПО, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);

• Server Generator - генератор описаний объектов БД Oracle (таблиц, индексов, ключей, последовательностей и т.д.). Помимо Oracle генерация и реверсный инжиниринг БД (с ограничениями) могут выполняться для СУБД DB2, MS SQL Server, Sybase, a также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;

• Forms Generator (генератор приложений для Oracle Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Oracle Developer;

• Repository Reports - генератор стандартных отчетов, интегрированный с Oracle Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

Репозиторий Oracle Designer представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория - база данных Oracle.

Генерация приложений, помимо Oracle Developer, выполняется также для Oracle №b Application Server, C++ и Visual Basic.

Взаимодействие с другими средствами. Oracle Designer можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство Oracle CASE Exchange для экспорта/ импорта объектов репозитория в целях обмена информацией с другими CASE-средствами.

OracleDeveloper обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений OracleDeveloper с другими средствами реализуется через механизм OLE (ObjectLinkingandEmbedding — технология связывания и встраивания объектов) и управляющие элементы VBX (VisualBasicextension). Взаимодействие приложений с другими СУБД реализуется с помощью средств OracleClientAdapter для ODBC, OracleOpenGateway и API.

СредафункционированияOracleDesigner - Windows 95/98/NT.

 

 

ERWIN, BPWIN

CASE-средстваERwinиBPwinбылиразработаныфирмойLogicWorks. После слияния в 1998 г. LogicWorks с PLATINUMtechnology (которая, в свою очередь, вошла в состав одной из крупнейших компаний — поставщиков программных продуктов ComputerAssociates) они выпускаются под логотипом PLATINUMtechnology и включены в состав комплекса продуктов и технологий разработки прикладного ПО PLATINUMADvantage.

Структура и функции. BPwin — средство моделирования бизнес- процессов, реализующее метод IDEF0 (см. разд. 2.2). Текущая версия BPwin поддерживает также диаграммы потоков данных и потоков работ (WorkflowDiagramm - метод IDEF3). В процессе моделирования BPwin позволяет переключиться с нотации IDEF0 на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель.

Семейство продуктов ERwin представляет собой набор средств концептуального моделирования данных, использующих метод IDEF1X (см. разд. 2.6). ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (Oracle, Informix, Sybase, DB2, MicrosoftSQLServer и др.) и реверсный инжиниринг существующей БД. Выпускается в нескольких конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Интегрируется с популярными средствами разработки клиентской части приложений PowerBuilder, VisualBasic, Delphi, что позволяет автоматически генерировать код приложений. Для разных сред разработки реализована различная техника генерации кода. Код для PowerBuilder генерируется непосредственно в среде ERwin, код для Visual Basic — с помощью addin-компонентов и библиотек, подключаемых в проект Visual Basic. Семейство ERwin не поддерживает непосредственно генерацию кода для Delphi. Код клиентского приложения для Delphi на основе модели данных ERwin можно сгенерировать с помощью продукта Meta BASE.

Для управления групповой разработкой используется средство Model Mart, обеспечивающее многопользовательский доступ к моделям, созданным с помощью ERwin и BPwin. Модели хранятся на центральном сервере и доступны для всех участников группы проектирования.

Model Mart удовлетворяет ряду требований, предъявляемых к средствам управления разработкой крупных ЭИС, а именно:

• Совместное моделирование. Каждый участник проекта имеет инструмент поиска и доступа к интересующей его модели в любое время. При совместной работе используются три режима: незащищенный, защищенный и режим просмотра. В режиме просмотра запрещается любое изменение моделей. В защищенном режиме модель, с которой работает один пользователь, не может быть изменена другими пользователями. В незащищенном режиме пользователи могут работать с общими моделями в реальном масштабе времени. Возникающие при этом конфликты разрешаются с помощью специального модуля - Intelligent Conflict Resolution (ICR). В дополнение к стандартным средствам организации совместной работы Model Mart позволяет сохранять множество версий, снабженных аннотациями, с последующим сравнением предыдущих и новых версий. При необходимости возможен возврат к предыдущим версиям.

• Создание библиотек решений. Model Mart позволяет формировать библиотеки стандартных решений, включающие наиболее удачные фрагменты реализованных проектов, накапливать и использовать типовые модели, объединяя их при необходимости “сборки” больших систем. На основе существующих баз данных с помощью ERwin возможно восстановление моделей (реверсный инжиниринг), которые в процессе анализа пригодности их для новой системы могут объединяться с типовыми моделями из библиотек моделей.

• Управление доступом. Для каждого участника проекта определяются права доступа, в соответствии с которыми они получают возможность работать только с определенными моделями. Права доступа могут быть определены как для групп, так и для отдельных участников проекта. Роль специалистов, участвующих в различных проектах, может меняться, поэтому в Model Mart можно определять и управлять правами доступа участников проекта к библиотекам, моделям и даже к специфическим областям модели.

Model Mart включает специальную утилиту - Model Mart Synchronizer, позволяющую проводить синхронизацию моделей процессов (BPwin) и данных (ERwin), хранящихся в библиотеках Model Mart.

Взаимодействие с другими средствами. ERwin поддерживает взаимодействие с Rational Rose: модуль ERwin Translation Wizard позволяет конвертировать объектную модель Rational Rose в модель данных ERwin (и обратно) и затем с помощью ERwin генерировать схему БД для любой из поддерживаемых в ERwin СУБД.

Для связывания объектной модели, созданной средствами Paradigm Plus, с моделью данных не требуется дополнительных утилит. Версия Paradigm Plus 3.6 полностью интегрирована с ERwin.

Существует также возможность импорта/экспорта данных из/в репозиторий ERwin из репозиториев BPwin и Oracle Designer.

Среда функционирования BPwin и ERwin - Windows 95/98/NT.

 

 

RATIONAL ROSE

Rational Rose — семейство объектно-ориентированных CASE- средств фирмы Rational Software Corporation - предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует метод объектно-ориентированного анализа и проектирования, основанный на языке моделирования UML. В настоящее время Rational Rose доминирует на рынке продуктов для объектно-ориентированного анализа, моделирования и проектирования. Rational Rose реализует генерацию кодов программ для C+ +, Smalltalk, Java, PowerBuilder, CORBA Interface Definition Language (IDL) и др., а также позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций. Кроме того, Rational Rose содержит средства реверсного инжиниринга программ, обеспечивающие повторное использование программных компонентов в новых проектах.

Структура и функции. В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций UML, определяющих архитектуру системы, ее статические и динамические аспекты. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор доку-ментов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для C++, обеспечивающий реверсный инжиниринг.

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

Средства автоматической генерации кодов программ на языке C++, используя информацию, содержащуюся в диаграммах классов и компонентов, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке C++. Анализатор кодов C++ реализован в виде отдельного программного модуля. Его назначение — создавать модули проектов Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на C++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/C++ обеспечивает возможность повторного использования программных компонентов.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

• диаграммы UML, в совокупности представляющие собой модель разрабатываемой программной системы;

• спецификации классов, объектов, атрибутов и операций;

• заготовки текстов программ.

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

Rational Rose существует в следующих вариантах: Modeler Edition (обеспечивает непосредственную поддержку языка UML), Enterprise Edition (представляет собой интеграционную платформу для разработки проектов масштаба предприятия), Professional Edition (включает все возможности Rational Rose Modeler Edition плюс генерация программного кода и реверсный инжиниринг) и Rose для UNIX.

Взаимодействие с другими средствами и организация групповой работы. Для поддержки командной работы над проектом на каждой стадии жизненного цикла ПО имеется интегрированный набор продуктов Rational Suite, существующий в следующих вариантах:

• Rational Suite AnalystStudio - предназначен для определения и управления полным набором требований к разрабатываемой сис-теме;

• Rational Suite DevelopmentStudio - служит для проектирования и реализации ПО;

• Rational Suite TestStudio - предназначен для автоматического тестирования приложений;

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

В состав Rational Suite кроме Rational Rose входят следующие компоненты:

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

• Rational ClearCase — средство управления конфигурацией ПО;

• Rational SoDA — средство автоматической генерации проектной документации;

• Rational ClearQuest — средство для управления изменениями и отслеживания дефектов в проекте на основе средств e-mail и Web;

• Rational TeamTest — средство автоматического обнаружения ошибок во время выполнения программы и генерации сценариев для проведения регрессионного тестирования;

• Rational Robot - средство для создания, модификации и автоматического запуска тестов;

• Rational Purify - средство для локализации трудно обнаруживаемых ошибок времени выполнения программы;

• Rational PureCoverage - средство идентификации участков кода, пропущенных при тестировании;

• Rational Quantify — средство количественного определения узких мест, влияющих на общую эффективность работы программы;

• Rational Suite PerformanceStudio — средство нагрузочного тестирования приложений “клиент-сервер” и Web-приложений.

Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема.

Среда функционирования. Rational Rose функционирует на различных платформах: IBM PC (Windows 95/98/NT), Sun SPARCstations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

 

 


 


Поделиться с друзьями:

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

Историки об Елизавете Петровне: Елизавета попала между двумя встречными культурными течениями, воспитывалась среди новых европейских веяний и преданий...

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

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



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.092 с.