2015-04-20
967
Программа постоянной оценки качества и продуктивности ПО преследует следующие цели:
• определение степени совершенствования процессов;
• упреждение возможных стратегических просчетов;
• своевременный отказ от использования устаревшей технологии. Чтобы определить, насколько эффективно новое CASE-средство
повышает продуктивность и/или качество, организация должна опираться на некоторые базовые данные. К сожалению, лишь немногие организации в настоящее время накапливают данные для реализации программы текущей количественной оценки и усовершенствования процессов. Для доказательства эффективности CASE-средств и их возможностей улучшать продуктивность необходимы следующие базовые метрические данные:
• использованное время;
• время, выделенное персонально для конкретных специалистов;
• размер, сложность и качество ПО;
• удобство сопровождения.
Метрическая оценка должна начинаться с реальной оценки текущего состояния среды еще до начала внедрения CASE-средств и поддерживать процедуры постоянного накопления данных.
Период времени, в течение которого выполняется количественная оценка воздействия, оказываемого внедрением CASE-средств, является весьма значимой величиной относительно определения степени успешности перехода. Некоторые организации, успешно внедрившие в конечном счете CASE-средства, столкнулись с кратковременными негативными эффектами в начале процесса. Другие, успешно начав, недооценили долговременнее затраты на сопровождение и обучение. Вследствие этого наиболее приемлемый временной интервал для оценки степени успешности внедрения должен быть достаточно большим, чтобы можно было преодолеть любые негативные эффекты на начальном этапе, а также смоделировать будущие долговременные затраты. С другой стороны, данный интервал должен соответствовать целям организации и ожидаемым результатам.
В конечном счете опыт, полученный при внедрении CASE-средств, может отчасти изменить цели организации и ожидания, возлагаемые на CASE-средства. Например, организация может сделать вывод, что средства целесообразно использовать для большего
или меньшего круга пользователей и процессов в цикле создания и сопровождения ПО. Такие изменения в ожиданиях зачастую могут дать положительные результаты, но могут также привести к внесению соответствующих корректив в определение степени успешного внедрения CASE-средств в данной организации. -
Результатом данного этапа является внедрение CASE-средств в повседневную практику организации. При этом больше не требуется какого-либо специального планирования. Кроме того, поддержка CASE-средств включается в план текущей поддержки ПО в данной организации.
4.3.
ХАРАКТЕРИСТИКИ CASE-СРЕДСТВ
4.3.1.
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 и Rational Rose, разработанный компанией "Аргуссофт". Этот мост создает диаграммы классов Rational Rose на основе RDM-модели Silverrun. Главная трудность при разработке подобных мостов связана с тем, что средства описания моделей в одной системе содержат конструкции, не имеющие аналогов в другой. Однако между RDM-моделью Silverrun и объектной моделью Rational Rose существует прямая и обратная аналогия (рис. 4.5 а, б).
Обратный мост формирует RDM-модель Silverrun на основе диаграммы классов Rational Rose. Он позволяет применить достаточно мощные средства проектирования реляционных БД, которыми располагает Silverrun, в объектно-ориентированных проектах. При этом могут быть использованы любые реляционные СУБД, поддерживаемые Silverrun.
Рис. 4.5. Прямая (а) и обратная (б) аналогия между RDM-моделью Silverrun и объектной моделью Rational Rose
Групповая работа. Групповая работа поддерживается в системе Silverrun двумя способами. В стандартной однопользовательской версии (Silverrun Professional) имеется механизм контролируемого разделения и слияния моделей. Разделив модель на части, можно раздать их нескольким разработчикам. После детальной доработки модели объединяются в единые спецификации. Сетевая версия Silverrun Enterprise позволяет осуществлять одновременную групповую работу с моделями, хранящимися в сетевом репозиторий на базе СУБД Oracle, Sybase, MS SQL Server или Informix. При этом несколько разработчиков могут работать с одной и той же моделью, так как блокировка объектов происходит на уровне отдельных элементов модели.
Среда функционирования. Текущая версия Silverrun 2.7 реализована на платформах Windows 95/98/NT.
4.3.2
ORACLE DESIGNER
CASE-средство Oracle Designer фирмы Oracle является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Oracle Developer и Oracle Application Server поддержку полного ЖЦ ПО для систем, использующих СУБД Oracle.
Структура и функции. Oracle Designer представляет собой семейство методов и поддерживающих их программных продуктов. Базовый метод Oracle Designer (CASE*Method Баркера) - структурный метод проектирования систем, охватывающий полностью все стадии ЖЦ ПО. В настоящее время данный метод продолжает развиваться и поставляется корпорацией Oracle как самостоятельный продукт под названием Custom Development Method (CDM) в совокупности с методами и средствами управления проектом Project Management method (PJM) (см. главу 5).
Версия 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 Web Application Server, C++ и Visual Basic!
Взаимодействие с другими средствами. Oracle Designer можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство Oracle CASE Exchange для экспорта/ импорта объектов репозитория в целях обмена информацией с другими CASE-средствами.
Oracle Developer обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Oracle Developer с другими средствами реализуется через механизм OLE (Object Linking and Embedding — технология связывания и встраивания объектов) и управляющие элементы VBX (Visual Basic extension). Взаимодействие приложений с другими СУБД реализуется с помощью средств Oracle Client Adapter для ODBC, Oracle Open Gateway и API.
Среда функционирования. Среда функционирования Oracle Designer - Windows 95/98/NT.
4.3.3.
ERWIN, BPWIN
CASE-средства ERwin и BPwin были разработаны фирмой Logic Works. После слияния в 1998 г. Logic Works с PLATINUM technology (которая, в свою очередь, вошла в состав одной из крупнейших компаний — поставщиков программных продуктов Computer Associates) они выпускаются под логотипом PLATINUM technology и включены в состав комплекса продуктов и технологий разработки прикладного ПО PLATINUM ADvantage.
Структура и функции. BPwin - средство моделирования бизнес-процессов, реализующее метод IDEF0 (см. разд. 2.2). Текущая версия BPwin поддерживает также диаграммы потоков данных и потоков работ (Workflow Diagramm - метод IDEF3). В процессе моделирования BPwin позволяет переключиться с нотации IDEF0 на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель.
Семейство продуктов ERwin представляет собой набор средств концептуального моделирования данных, использующих метод IDEF1X (см. разд. 2.6). ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (Oracle, Informix, Sybase, DB2, Microsoft SQL Server и др.) и реверсный инжиниринг существующей БД. Выпускается в нескольких конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Интегрируется с популярными средствами разработки клиентской части приложений PowerBuilder, Visual Basic, Delphi, что позволяет автоматически генерировать код приложений. Для разных сред разработки реализована различная техника генерации кода. Код для PowerBuilder генерируется непосредственно в среде ERwin, код для Visual Basic — с помощью add-in-компонентов и библиотек, подключаемых в проект Visual Basic. Семейство ERwin не поддерживает непосредственно генерацию кода для Delphi. Код клиентского приложения для Delphi на основе модели данных ERwin можно сгенерировать с помощью продукта MetaBASE.
Для управления групповой разработкой используется средство 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.
4.3.4
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).
Следует запомнить:
Под CASE-средством понимается программное средство, поддерживающее процессы жизненного цикла ПО ЭИС. CASE-средства вместе с системным ПО и техническими средствами образуют среду разработки ПО ЭИС.
Вопросы для самоконтроля
1. Какие компоненты входят в состав CASE-средств?
2. Какие существуют типы и категории CASE-средств?
3. Из каких стадий состоит процесс внедрения CASE-средств?
4. Каковы предпосылки успешного внедрения CASE-средств в организации?
ПРОМЫШЛЕННЫЕ ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Прочитав эту главу, вы узнаете:
• Что представляют собой промышленные технологии проектирования программного обеспечения.
• Каковы их основные особенности.
5.1
ТЕХНОЛОГИЯ DATARUN
Одной из наиболее распространенных в мире электронных технологий является технология DATARUN. В соответствии с этой технологией ЖЦ ПО разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO/IEC 12207..
Стадия формирования требований и планирования включает в себя действия по определению начальных оценок объема и стоимости проекта. Должны быть сформулированы требования и экономическое обоснование для разработки ЭИС, построены функциональные модели (модели деятельности организации) и исходная концептуальная модель данных, которые дают основу для оценки технической реализуемости проекта. Основными результатами этой стадии должны быть модели деятельности организации (исходные модели процессов и данных организации) и требования к системе, включая требования по сопряжению с существующими ЭИС. Каждую стадию должен завершать план работ на следующую стадию.
Стадия концептуального проектирования начинается с детального анализа первичных данных и уточнения концептуальной модели данных, после чего проектируется архитектура системы. Оценивается возможность использования существующего ПО и выбирается соответствующий метод его преобразования. После построения проекта уточняется исходный план. Результатами этой стадии являются концептуальная модель данных, модель архитектуры системы и уточненный план.
На стадии спецификации приложений продолжается процесс создания и детализации проекта. Концептуальная модель данных преобразуется в реляционную модель данных. Определяются структура приложения, необходимые интерфейсы приложения в виде экранов, отчетов и пакетных процессов вместе с логикой их вызова. Модель данных уточняется бизнес-правилами (ограничениями целостности) и методами для каждой таблицы. В конце этой стадии принимается окончательное решение о способе реализации приложений. По результатам стадии должен быть построен проект ЭИС, включающий модели архитектуры ПО ЭИС, данных, функций, интерфейсов (с внешними системами и с пользователями), требований к разрабатываемым приложениям (модели данных, интерфейсов и функций), требований к доработкам существующего ПО, требований к интеграции приложений, а также сформирован окончательный план создания ЭИС.
На стадии разработки, интеграции и тестирования должны быть созданы тестовая база данных, частные и комплексные тесты. Проводятся разработка, прототипирование и тестирование баз данных и приложений в соответствии с проектом. Отлаживаются интерфейсы с существующими системами. Описывается конфигурация текущей версии ПО. На основе результатов тестирования осуществляется оптимизация базы данных и приложений. Приложения интегрируются в систему, проводятся тестирование приложений в составе системы и испытания системы. Основными результатами стадии являются готовые приложения, проверенные в составе системы на комплексных тестах, текущее описание конфигурации ПО, скорректированная по результатам испытаний версия системы и эксплуатационная документация на систему.
Стадия внедрения охватывает действия по установке и внедрению баз данных и приложений. Основными результатами стадии должны быть готовая к эксплуатации и перенесенная на программно-аппаратную платформу заказчика версия системы, документация сопровождения и акт приемочных испытаний по результатам опытной эксплуатации.
Стадии сопровождения и развития включают процессы и операции, связанные с регистрацией, диагностикой и локализацией ошибок, внесением изменений и тестированием, проведением доработок, тиражированием и распространением новых версий ПО в места его эксплуатации, переносом приложений на новую платформу и масштабированием системы. Стадия развития фактически является повторной итерацией стадии разработки.
Технология DATARUN опирается на две модели или на два представления (см. главу 1):
• модель деятельности организации;
• модель проектируемой ЭИС.
Технология DATARUN базируется на системном подходе к описанию деятельности организации. Построение моделей начинается с описания процессов, из которых затем извлекаются первичные данные (стабильное подмножество данных, которые организация должна использовать для своей деятельности). Первичные данные описывают продукты или услуги организации, выполняемые операции (транзакции) и потребляемые ресурсы. К первичным относятся данные, которые описывают внешние и внутренние сущности, такие, как служащие, клиенты или агентства, а также данные, полученные в результате принятия решений, например графики работ, цены на продукты.
Основной принцип DATARUN заключается в том, что первичные данные, если они должным образом организованы в модель данных, становятся основой для проектирования архитектуры системы. Архитектура будет достаточно стабильной, если она основана на первичных данных, тесно связанных с основными бизнес-процессами.
Подход DATARUN преследует две цели:
• определить стабильную структуру, на основе которой будет строиться ЭИС. Такой структурой является модель данных, полученная на основе первичных данных, используемых фундаментальными процессами организации;
• спроектировать ЭИС на основе определенной структуры. Объекты, формируемые на основе модели данных, являются объектами базы данных, обычно размещаемыми на серверах в среде "клиент-сервер". Объекты интерфейса, определенные в архитектуре компьютерной системы, обычно размещаются на клиентской части.
Модель данных, являющаяся основой для спецификации совместно используемых объектов базы данных и различных объектов интерфейса, обеспечивает сопровождаемость ЭИС. На рис. 5.1 представлена последовательность шагов проектирования ЭИС.
Рис. 5.1. Последовательность шагов проектирования системы
На рис. 5.2 определен комплекс моделей, создаваемых в процессе разработки ЭИС. В его состав входят следующие модели:
• Business Process Model (BPM) — модель бизнес-процессов;
• Primary Data Structure (PDS) — структура первичных данных;
• Conceptual Data Model (CDM) — концептуальная модель данных;
• System Process Model (SPM) — модель процессов системы;
• Information System Architecture (ISA) — архитектура информационной системы;
• Application Data Model (ADM) — модель данных приложения;
• Interface Presentation Model (IPM) - модель представления интерфейса;
• Interface Specification Model (ISM) — модель спецификации интерфейса.
Рис. 5.2. Модели, создаваемые по технологии DATARUN
Для создания моделей используется CASE-средство Silverrun, описанное в подразд. 4.3.1. Silverrun обеспечивает автоматизацию проведения проектных работ в соответствии с технологией DATARUN. Предоставляемая этим средством среда проектирования дает возможность руководителю проекта контролировать проведение работ. Каждый участник проекта, подключившись к этой среде, может выяснить содержание и сроки выполнения порученной ему работы, детально изучить технику ее реализации в гипертексте по технологиям и вызвать инструмент (модуль Silverrun) для реального выполнения работы.
Информационная система создается последовательным построением ряда моделей, начиная с модели бизнес-процессов и заканчивая моделью ПО, автоматизирующего эти процессы.
Создаваемая ЭИС должна основываться на функциях, выполняемых организацией. Поэтому первая создаваемая модель — это модель бизнес-процессов, построение которой осуществляется с помощью модуля Silverrun BPM. Для этой модели используется специальная нотация. В процессе анализа и спецификации бизнес-функций выявляются основные информационные объекты, которые документируются как структуры данных, связанные с потоками и хранилищами модели. Источниками для создания структур служат используемые в организации документы, должностные инструкции, описания производственных операций. Эти данные вводятся в том виде, в каком они существуют в организации. Нормализация и удаление избыточности производятся позже при построении концептуальной модели данных в модуле Silverrun ERX. После создания модели бизнес-процессов информация сохраняется в репозитории проекта.
В процессе обследования работы организации выявляются и документируются структуры первичных данных. Эти структуры заносятся в репозитории модуля ВРМ при описании циркулирующих в организации документов, сообщений, данных. В модели бизнес-процессов первичные структуры данных связаны с потоками и хранилищами информации.
На основе структур первичных данных в модуле Silverrun ERX создается концептуальная модель данных. От структур первичных данных концептуальная модель отличается удалением избыточности, стандартизацией наименований понятий и нормализацией. Эти операции в модуле ERX выполняются с помощью встроенной экспертной системы. Цель концептуальной модели данных - описать используемую информацию без деталей возможной реализации в базе данных, но в хорошо структурированном нормализованном виде.
На основе модели бизнес-процессов и концептуальной модели данных проектируется архитектура ЭИС. Определяются входящие в систему приложения, для каждого приложения специфицируются используемые данные и реализуемые функции. Архитектура ЭИС создается в модуле Silverrun BPM с использованием специальной нотации ISA. Основное содержание этой модели — структурные компоненты системы и навигация между ними. Концептуальная модель данных разбивается на части, соответствующие входящим в состав системы приложениям.
Перед разработкой приложений должна быть спроектирована структура корпоративной базы данных. Технология DATARUN предполагает использование базы данных, основанной на реляционной модели. Концептуальная модель данных после нормализации переносится в модуль реляционного моделирования Silverrun RDM с помощью специального моста ERX-RDM. Преобразование модели из формата ERX в формат RDM происходит автоматически без вмешательства пользователя. После преобразования ERX-RDM получается модель реляционной базы данных. Эта модель детализируется в модуле Silverrun RDM определением физической реализации (типов данных СУБД, ключей, индексов, триггеров, ограничений ссылочной целостности). Правила обработки данных можно задавать как непосредственно на языке программирования СУБД, так и в декларативной форме, не привязанной к реализации. Мосты Silverrun к реляционным СУБД переводят эти декларативные правила на язык требуемой системы, что снижает трудоемкость программирования процедур сервера базы данных, а также позволяет из одной спецификации генерировать приложения для разных СУБД.
С помощью модели системных процессов детально документируется поведение каждого приложения. В модуле ВРМ создается модель системных процессов, определяющая, каким образом реализуются бизнес-процессы. Эта модель создается отдельно для каждого приложения и тесно связана с моделью данных приложения.
Приложение состоит из интерфейсных объектов (экранных форм, отчетов, процедур обработки данных). Каждый интерфейсный объект связан с некоторым подмножеством базы данных. В модели данных приложения формируется подсхема базы данных для каждого интерфейсного объекта этого приложения. Уточняются также правила обработки данных, специфичные для каждого интерфейса. Интерфейс работает с данными в ненормализованном виде, поэтому спецификация данных, как ее видит интерфейс, оформляется в виде отдельной подсхемы модели данных интерфейса.
Модель представления интерфейса — это описание внешнего вида интерфейса, как его видит конечный пользователь системы. Это может быть и документ, показывающий внешний вид экрана или
структуру отчета, и сам экран (отчет), созданный с помощью одного из средств визуальной разработки приложений — так называемых языков четвертого поколения (4GL — Fourth Generation Languages). Так как большинство языков 4GL позволяют быстро проектировать работающие прототипы приложений, пользователь имеет возможность увидеть работающий прототип системы на ранних стадиях проектирования.
После создания подсхем реляционной модели для приложений проектируется детальная структура каждого приложения в виде схемы навигации экранов, отчетов, процедур пакетной обработки. Эта структура детализируется до указания конкретных столбцов и таблиц базы данных, правил их обработки, вида экранных форм и отчетов. Полученная модель детально документирует приложение и непосредственно используется для программирования специфицированных интерфейсов.
Далее средствами разработки приложений происходит физическое создание системы: приложения программируются и интегрируются в информационную систему.
Электронный вариант технологии DATARUN реализован с помощью инструментального средства SE (Software Engineering) Companion. Оно позволяет:
• создать гипертекстовое описание технологии в виде иерархии описания стадий, этапов и операций разработки;
• создать гипертекстовое описание всех методов и методик реализации процессов ЖЦ ПО;
• выделить из гипертекстового описания иерархию процессов ЖЦ ПО для планирования и управления процессом создания ПО (иерархию работ);
• изменять гипертекстовые описания ЖЦ и методов так, как это необходимо разработчику, иными словами, производить авторизацию технологии и отслеживать эти изменения в иерархии работ, предназначенной для управления проектом;
• привязать к процессам ЖЦ инструментальные средства поддержки этих процессов и обеспечить вызов инструментальных средств из соответствующих экранов гипертекстового справочника;
• обеспечить просмотр гипертекстовых экранов описания используемых методов с помощью инструментальных средств;
• обеспечить поддержку процесса управления разработкой, в частности, за счет взаимодействия со средством планирования работ Microsoft Project, оценивания трудоемкости проекта, отслеживания хода работ, рисования графиков работ и др. Особенно важными являются возможность авторизации технологии и интерактивный доступ любого разработчика к описанию любого метода или процесса в нужный ему момент времени. В условиях быстрого изменения как программных и аппаратных средств, так и задач бизнеса технология создания, сопровождения и развития ПО не должна быть неизменной; она должна иметь возможность изменяться и настраиваться на новые методы и инструментальные средства. Таким образом, разработчики ПО приобретают одну или несколько технологий поставщика, а затем создают на их основе собственные технологии, адаптированные к конкретным условиям. Гипертекстовое описание технологии создания ПО строится из описания процессов жизненного цикла, методов и методик и представляет собой единый гипертекстовый документ в формате Microsoft Help. Итоговое гипертекстовое описание получается в результате трансляции исходного текстового документа. Все изменения и дополнения технологии производятся посредством корректировки исходного документа.
Описание технологии создания системы состоит из раздела описания процессов ЖЦ и разделов описания методов и методик. В свою очередь, раздел описаний процессов состоит из иерархии описаний стадий, этапов и операций жизненного цикла с обязательным описанием выходных компонентов каждого процесса. Компоненты ПО создаются с применением методов и методик, описываемых в соответствующих разделах.
5.2
ТЕХНОЛОГИЯ RUP
Технология RUP (Rational Unified Process) разработана компанией Rational Software. Она ориентирована на использование универсального языка объектно-ориентированного моделирования UML, являющегося фактическим стандартом в данной области (см. главу 3).
На рис. 5.3 показан общий вид процесса RUP в двух измерениях:
• горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как циклы, фазы, итерации и контрольные точки;
• вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как действия, результаты деятельности, исполнители и рабочие процессы.
