НТВ плюс 

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

Введение

В процессе разработки программного обеспечения используется большое количество самого разностороннего программного обеспечения (ПО). Данный курс лекций рассматривает когда и что используется на протяжении всего этапа разработки приложений.

Чтобы дать более полное представление о роли каждой утилиты или срезы разработки в процессе создания ПО, все рассмотренные в данном курсе лекций инструментальные средства будут рассмотрены на примере разработки приложений с использованием одного их высокоуровневых языков. Для простоты, все используемые инструментальные средства можно разделить на 4 группы. Рассмотрим подробнее каждую из групп.

Необходимые

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

§ редакторы текстов;

§ компиляторы и ассемблеры;

§ компоновщики или редакторы связей (linkers);

Часто используемые

Это средства, использования которых, в отличие от необходимых, можно избежать. Но без них процесс разработки весьма затрудняется и удлиняется; Из часто используемых средств стоит назвать:

§ утилиты автоматической сборки проекта;

§ отладчики;

§ программы создания инсталляторов;

§ редакторы ресурсов;

§ профилировщики;

§ программы поддержки версий;

§ программы создания файлов помощи (документации).

Специализированные

Эти инструментальные средства используются в исключительных случаях, решают довольно специфичные задачи:

§ программы отслеживания зависимостей;

§ дизассемблеры;

§ декомпиляторы;

§ hex-редакторы;

§ программы отслеживания активности системы и изменений, происходящих в системе;

§ программы-вериферы и контейнеры (создают виртуальную среду для отдельных классов программ, в которой можно исследовать поведение программы);

Интегрированные среды разработки

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

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

КЛАССИФИКАЦИЯ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ

ТЕМА 1 ПОНЯТИЕ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ.

КЛАССИФИКАЦИЯ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ.

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

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

· репозиторий,

· инструментарий,

· интерфейсы.

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

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

Самая общая архитектура инструментальных систем технологии программирования представлена на рис.

Рис. Общая архитектура инструментальных систем технологии программирования.

Различают два класса инструментальных систем технологии программирования: инструментальные системы поддержки проекта и языково-зависимые инструментальные системы.

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

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

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

1. Терминология

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

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

С учетом данного определения термин «Разработка программ» будет звучать следующим образом:

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

2. Основные средства, используемые на разных этапах разработки программ

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

  1. Проектирование приложения.
  2. Реализация программного кода приложения.
  3. Тестирование приложения.

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

2.1 Средства проектирования приложений

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

  1. Анализ требований.
  2. Разработка архитектуры будущего программного обеспечения.
  3. Разработка устройств основных компонент программного обеспечения.
  4. Разработка макетов Пользовательских интерфейсов.

Результатом проектирования обычно является «Эскизный проект» (Software Design Document) или «Технический проект» (Software Architecture Document). Задача «Анализ требований» обычно выполняется с использованием методов системологии (анализа и синтеза) с учетом экспертного опыта проектировщика. Результатом анализа обычно является содержательная или формализованная модель процесса функционирования программы. В зависимости от сложности процесса для построения данных моделей могут быть применены различные методы и вспомогательные средства. В общем случае для описания моделей обычно применяются следующие нотации (в скобках приведены программные средства, которые могут быть использованы для получения моделей):

  • BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
  • Блок-схемы (Vision 2003 и многие другие).
  • ER-диаграмы (Visio 2003, ERWin, Sybase Power Designer и многие другие).
  • UML-диаграмы (Sybase Power Designer, Rational Rose и многие другие).
  • макеты, мат-модели и т.д.

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

Целью второй и третьей задачи из приведенного списка задач является разработка модели (описания) будущей системы, понятной для кодировщика – человека, который пишет код программы. Здесь огромное значение имеет то, какую парадигму программирования (парадигму программирования также необходимо рассматривать как средство разработки) необходимо использовать при написании программы. В качестве примера основных парадигм необходимо привести следующее:

  • Функциональное программирование;
  • Структурное программирование;
  • Императивное программирование;
  • Логическое программирование;
  • Объектно-ориентированное программирование (прототипирование; использование классов; субъективно-ориентированное программирование).

Выбор её во многом зависит от сложившихся привычек, опыта, традиций, инструментальных средств, которыми располагает коллектив разработчиков. Иногда разрабатываемый программный продукт настолько сложен, что для решения ряда задач в разных компонентах системы используются разные парадигмы. Необходимо отметить, что выбор того или иного подхода накладывает ограничения на средства, которые будут применены на этапе реализации программного кода. Результатом решения данной задачи в зависимости от подхода могут быть (в скобках приведены программные средства, которые могут быть использованы для их получения):

  • диаграмма классов и т.д (Ration Rose, Sybase PowerDisigner и многие другие).
  • описание модулей структур и их программного интерфейса (например, Sybase PowerDisigner и многие другие).

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

2.2 Средства реализации программного кода

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

  • языки программирования (C++,Си, Java, C#, php и многие другие);
  • средства создания пользовательского интерфейса (MFC, WPF, QT, GTK+ и т.д.)
  • средства управления версиями программного кода (cvs, svn, VSS).
  • средства получения исполняемого кода (MS Visual Studio, gcc и многие другие).
  • средства управления базами данных (Оracle, MS SQL, FireBird, MySQL и многие другие).
  • отладчики (MS Visual Studio, gdb и т.д.).

2.3 Средства тестирования программ

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

  • Тестирование на отказ и восстановление.
  • Функциональное тестирование.
  • Тестирование безопасности.
  • Тестирование взаимодействия.
  • Тестирование процесса установки.
  • Тестирование удобства пользования.
  • Конфигурационное тестирование.
  • Нагрузочное тестирование.

Среди основных видов средств, которые могут быть применены для выполнения поставленных работ можно привести следующие:

  • средства анализа кода, профилирования (Code Wizard – ParaSoft, Purify – Rational Softawre. Test Coverage – Semantic и т.д.);
  • средства для тестирования функциональности (TEST – Parasoft, QACenter – Compuware, Borland SilkTest и т.д.);
  • средства для тестирования производительности (QACenter Performance – Compuware и т.д).

3. Заключение

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

Также смотрите :

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

К ним относятся:

Внутрисхемные эмулятры;

Программные симуляторы;

Отладочные мониторы;

Платы развития (оценочные платы);

Эмуляторы ПЗУ;

Интегрированные среды разработки.

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

Функционально внутрисхемные эмуляторы делятся на стыкуемые с внешней ЭВМ и функционирующие автономно.

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

Основные функциональные блоки эмулятора:

Отладчик;

Узел эмуляции микроконтроллера;

Эмуляционная память;

Подсистема точек останова.

Дополнительные блоки:

Процессор точек останова;

Трассировщик;

Профилировщик (анализатор эффективности программного кода);

Таймер реального времени;

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

Программно-аппаратные средства, обеспечивающие синхронное управление, необходимое для эмуляции в мультипроцессорных системах.

Отладчик осуществляет:

Управление процессом эмуляции (моделирования);

Вывод на монитор состояния и содержимого всех регистров и памяти и, при необходимости, их модификации (изменение их содержимого).

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

Эмуляционная память может применяться вместо ПЗУ отлаживаемой системы, а также дает возможность отлаживать программу без реальной системы или ее макета. (Нет необходимости в перепрограммировании ПЗУ.) Эмулирование возможно целиком или поблочно.

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

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

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

Количество обращений к различным участкам программы;

Время, затраченное на выполнение различных участков программы.

Анализ статистической информации, поставляемой профилировщиком, позволяет легко выявлять «мертвые» или перенапряженные участки программ и в результате оптимизировать структуру отлаживаемой программы.

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

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

Существуют эмуляторы, предназначенные для эмуляции микроконтроллеров семейств Intel MCS 8051, MCS-196, Microchip PIC.

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

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

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

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

Загрузку прикладных кодов в свободную от монитора память;

Установку точек останова;

Запуск и останов загруженной программы в реальном времени;

Проход программы пользователя по шагам;

Просмотр, редактирование содержимого памяти и управляющих регистров.

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

Основное достоинство использования монитора – это малые затраты при сохранении возможности вести отладку в реальном времени на микроконтроллере, стоящем на плате. Недостатком является отвлечение ресурсов микроконтроллера на отладочные и связные процедуры (память, прерывания, последовательный канал).

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

Для удобства отладки платы развития комплектуются простейшими средствами отладки на базе монитора отладки для микроконтроллеров с внешней шиной и без нее.

В первом случае отладочный монитор поставляется в виде микросхемы ПЗУ, которая устанавливается в разъем (кроватку) на плате. На плате также имеется ОЗУ для программ пользователя и канал связи с компьютером. Пример – плата фирмы “INTEL” для микроконтроллера 8051.

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

Готовая программа получается путем удаления монитора и всех вызовов мониторных функций. Примерами могут служить платы развития фирмы “MICROCHIP” для своих PIC-контроллеров, а также платы развития для отладки своих контроллеров 80С750 Philips и 89С2051 Atmel.

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

Эмуляторы ПЗУ – это программно-аппаратные средства, позволяющие замещать ПЗУ на отлаживаемой плате и подставляющие вместо него ОЗУ, куда загружается программа с компьютера через один из стандартных каналов связи. В данном случае стараются избежать многократных циклов перепрограммирования ПЗУ. Метод пригоден для микроконтроллеров, которые в состоянии обращаться к внешней памяти программ. По сложности и стоимости метод сравним с использованием плат развития, но более универсален, так как может применяться с любыми типами микроконтроллеров.

В настоящее время имеются модели «интеллектуальных» эмуляторов ПЗУ, позволяющие заглядывать внутрь микроконтроллера, т. е. работающие почти как внутрисхемный эмулятор за счет быстрого переключения шины. Создается эффект, будто бы монитор отладки установлен на плате пользователя и при этом не занимает у микроконтроллера никаких аппаратных ресурсов, кроме небольшой зоны программных шагов, примерно 4К. Такое устройство разработала фирма «ФИТОН» для всех существующих и будущих микроконтроллеров с ядром МК 8051, но дополнительно насыщенных различными устройствами ввода/вывода. Оно поддерживает множество микроконтроллеров фирм “PHILIPS”, “SIEMENS”,”OKI”.

Интегрированные среды разработки (Integrated Development Environment, IDE) позволяет программисту:

Использовать встроенный файловый текстовый редактор, специально ориентированный на работу с исходными текстами программ;

Общая характеристика инструментальных средств разработки программ

    Общая характеристика инструментальных средств разработки программ

    Инструментальные системы технологии программирования

    CASE-средства. Характеристика современных CASE-средств

Обзор объектно-ориентированных инструментальных средств

Объектно-ориентированное программирование возникло раньше объектно-ориентированного анализа и проектирования, поэтому на сегодняшний день существует достаточно большое количество языков, поддерживающих данную технологию. Первым из них, по дате возникновения, считается язык Smalltalk , хотя многие элементы объектно-ориентированного подхода были использованы еще в языке Simula в 1967г. Наиболее мощным инструментом создания объектно-ориентированных программ на сегодня является язык C++ , созданный на базе языка структурного программирования C . Успешно развивается язык Java , который изначально разрабатывался как объектно-ориентированный.

Разработка крупных программных систем в современных условиях невозможна без использования средств автоматизации разработки программного обеспечения (CASE средств). CASE, поддерживающих объектно-ориентированный подход, не так много. Наиболее известное средство в этом направлении – система Rational Rose , которая поддерживает, в том числе, этапы объектно-ориентированного анализа и проектирования.

Объектно-ориентированное CASE средство Rational Rose

Разработчик Rational Rose - фирма Rational Software Corp., известная своими наработками в области объектно-ориентированных технологий, главной из которых является язык UML. Именно на поддержку UML, как основного языка проектирования ПО, и ориентированна данная CASE система.

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

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

Из основных возможностей можно перечислить следующие:

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

    Удобная навигация между элементами модели при помощи "инспектора проекта".

    Хранение результатов проектирования в виде единой модели.

    Поддержка работы над проектом группы разработчиков.

    Мощная система подготовки отчетов и документации о проекте.

    Возможности синтеза программ практически на всех современных объектно-ориентированных языках, в том числе и на межплатформенном языке Java.

    Поддержка компонентных технологий построения программных систем.

    Широкие возможности по проектированию ПО различной архитектуры, от простых программ, до крупных "клиент-серверных" систем и Интернет-приложений.

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

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

Принципы разработки программных систем в Rational Rose

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

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

На всех этапах предоставляется возможность применять специализированные графические редакторы элементов модели и использовать инспектор модели для навигации среди ее компонентов. Вся проектная информация сохраняется в едином файле модели (*.mdl).

Работа начинается с построения диаграммы использования (Use Case Diagram), характеризующей основные задачи и окружение проектируемой системы. Далее, для каждого блока использования (Use Case), представленного на диаграмме использования, разрабатываются диаграммы последовательностей (Sequence Diagram), идентифицирующие объекты в системе и описывающие последовательности событий, возникающих в процессе общения объектов. Rational Rose позволяет автоматически связывать диаграммы последовательностей с блоками использования.

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

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

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

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

Проектирование программных средств

Моделирование предметной области . Создание проекта начинается с формирования принципов использования системы. В рамках Rational Rose это этап именуется "Use Case View". Реализация этого этапа позволяет идентифицировать внешних пользователей, блоки использования, объекты системы и связи между ними.

Составляется диаграмма использования, отражающая внешнее функционирование создаваемой системы. Эта модель во многом аналогична диаграмме потоков данных в структурном анализ. Основными ее составляющими являются внешние пользователи (actors), блоки использования (use case) и связи между компонентами. Для создания диаграммы в Rational Rose используется специализированный графический редактор.

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

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

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

Разработка логической структуры. После завершения формирования принципов использования системы, наступает этап разработки ее логической структуры. В Rational Rose он именуется "Logical View". Результатом данного этапа должна стать главная диаграмма, и детализирующие диаграммы для ее элементов.

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

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

Встроенный в Rational Rose редактор диаграмм классов представляет удобные средства для таких операций, а инспектор модели облегчает перемещение по иерархии диаграмм.

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

Наличие шаблонов позволяет легко создавать классы различной структуры.

Классы могут импортироваться в систему извне. Rational Rose поддерживает компонентную структуру программного обеспечения и позволяет использовать в модели двоичные компоненты, такие как COM и ActiveX. Их представление в модели выполняется с помощью классов, основанных на интерфейсах данных компонентов.

Кроме диаграмм классов, для описания логики системы применяются на данном этапе применяются диаграммы состояний, диаграммы сценариев и другие элементы языка UML

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

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

Для визуализации компонентов проектируемой системы используются диаграммы компонент. Этап построения диаграмм компонент в Rose именуется "Component View". Он состоит из построения общей диаграммы и, при необходимости, детализации отдельных компонентов на вложенных диаграммах.

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

Построение диаграмм выполняется в специализированном редакторе. Для компонента задаются составляющие его классы.

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

Последним этапом в проектировании программного обеспечения является подготовка диаграммы развертывания. В Rose этот этап именуется "Deployment View". Диаграммы развертывания показывает конфигурацию исполняемой программной системы. Она состоит из узлов и отношений взаимодействия между узлами и компонентами. Узлы могут включать компоненты и объекты. Узлы являются физическими элементами времени выполнения.

Построение и сопровождение системы

Генерация исходных текстов . После того, как определены конкретные компоненты разрабатываемой системы, наступает время генерации программного кода для каждого компонента.

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

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

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

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

Rational Rose 98 Enterprise Edition позволяет генерировать исходный текст на Visual Basic, C++, Java, а также получать описание интерфейсов компонент на языке IDL и создавать проекты для системы Oracle 8.

Реинжиниринг модели на основе исходных текстов . Возможность реинжиниринга, или, как его еще называют, "обратного проектирования", модели по исходным программным текстам представляется одной из важных и, безусловно, полезных функций Rose . Потребность в такой операции часто возникает при выполнении модификации и модернизации проекта. Сгенерированные по модели шаблоны программы, после их передачи программистам, могут быть модифицированы и необходимо учитывать эти изменения в модели. Кроме того, поскольку Rational Rose поддерживает импорт двоичных компонентов (COM объекты в среде Win32), то поддержка построения классов на основе описания интерфейсов двоичного компонента просто необходима.

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

После успешного завершения операции, на диаграмме компонентов (этап "Component View") появится новый элемент, имеющий имя, совпадающее с каталогом исходных файлов. Переход на этап "Logical View" покажет, что все классы и пакеты, составляющие новый компонент, также появились на диаграммах классов.

Теперь становится возможным внести в модель изменения, определяемые добавленными компонентами, и вновь генерировать исходные тексты.

Поддержка этапов разработки

Компоненты и шаблоны. Одной из возможностей Rose является моделирование двоичных компонентов, поддерживающих спецификацию COM. В модели подобные компоненты представляются интерфейсными классами, созданными на основе IDL файлов, сопровождающих COM объект. Это позволяет включать в модель различные готовые компоненты.

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

Рабочие среды. Логичным развитием идеи использования шаблонов и внешних двоичных компонентов в Rational Rose стало появление рабочей среды (Framework).

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

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

    Среда проектирования распределенных приложений (Application Performance Explorer)

    Стандартная среда (Standard). Ориентированна на создание приложений на Visual Basic. Включает объявление многих стандартных объектов VB.

    Среда проектирования приложений для Интернет (Internet). Включает определение различных компонентов ActiveX и библиотек VB.

    Среда проектирования приложений для работы с локальными базами данных (Local Database). Содержит объявление объектов системы DAO

    Среда проектирования приложений с использованием RDO (Remote Data Object). Позволяет использовать объекты RDO для создания клиент-серверных приложений.

    Среда проектирования приложений для доступа к SQL-серверами (SQL Server Distributed Management Object (SQL-DMO)), поддерживающая доступ к SQL через объекты OLE-Automation.

    Среда поддержки Microsoft Transaction Server

    Среда поддержки Microsoft Outlook

    Среды проектирования приложений на Java (Java JDK 114 Full и Java JDK 114 Quick). Включают модели классов и интерфейсов Java полученные путем реинжиниринга.

    Среда поддержки Oracle8

Среда разработки назначается при создании модели. Хранятся среды разработки в виде файлов модели (*.mdl) предназначенных только для чтения (Read only). В процессе создания новой модели необходимые элементы загружаются из выбранной среды разработки, после чего новую модель.

Среды разработки представляют собой замечательный механизм для настройки Rose на конкретный проект. Можно создать собственную среду разработки, которая будет включать необходимые вам элементы из различных стандартных сред. В состав Rational Rose входит "мастер" по созданию рабочих сред.

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

Наряду с удобным средством инспектирования модели, облегчающим переключение между этапами, в Rational Rose определены механизмы поддержки группы разработчиков.

Создаются различные рабочие области для разработчиков и рабочая область всего проекта. Каждый разработчик производит изменения в своей части (подмодели), и эти изменения становятся глобальными (переносятся в общую модель) только после их утверждения системой управления проектом. В качестве контроллеров проекта в Rose могут использоваться внешние системы, такие как ClearCase и Microsoft SourceSafe .

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

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

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

Для управления расширениями в Rose существует менеджер расширений. С его помощью можно активизировать и де активизировать различные модули расширений.

Достоинства и недостатки Rational Rose

Данное CASE средство может быть применено для создания разнообразного объектно-ориентированного программного обеспечения, в первую очередь для платформы Windows, а так же на межплатформенном языке Java.

На всех этапах разработки применяется язык UML, и проект программного средства представляет собой единую модель.

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

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