6.Назначение программного средства Rational xde. Основные окна и пункты меню Rational xde.
Rational XDE – это расширенная среда разработки (eXtended Development
Environment), полностью интегрируемая вMicrosoft Visual Studio.NET. Rational
XDE – это средство, позволяющее проектировать программную систему при помощи UML моделей. Среда позволяет создавать диаграммы и генерировать
по полученным моделям исходный код приложения, а также проводить обратное проектирование, то есть строить диаграммы по разработанному ранее исходному коду.
В результате интеграции вVisual Studio.NET Rational XDE разработчики
получили сразу несколько преимуществ. Модели и программный проект составляют единое целое, что позволяет проводить автоматическую синхронизацию модели и кода. В Rational XDE нет необходимости переключаться между различными программными продуктами, как это происходит при использовании Rational Rose и Microsoft Visual Studio, а можно работать в одной среде разработки.
Отличие Rational XDE от большинства других визуальных редакторов, таких как Microsoft Visio в том, что эта среда позволяет создавать исходный код или по готовому коду создавать его представление в виде диаграмм. При использовании Rational XDE диаграммы создают единую, связанную между собой модель, которая может быть подключена к программе контроля версий для отслеживания вносимых разными разработчиками изменений. В среде Rational XDE имеется возможность проводить обратное проектирование системы, для этого необходимо указать путь к проекту, а диаграмму классов построит XDE.
7.Сравнительный анализ программных продуктов Rational Rose и Rational xde
Главное отличие Rational XDE от своего предшественника Rational Rose –
это полная интеграция с платформой Microsoft Visual Studio.NET, позволяющая
в одной оболочке работать как с моделями создаваемой системы, так и непосредственно с кодом.
В то же время в Rational XDE сохранились принципы работы Rational Rose, относящиеся к созданию диаграмм.
В результате интеграции сMicrosoft Visual Studio.NET Rational XDE потеряла часть своей универсальности по сравнению с Rational Rose, касающуюся в основном возможности генерации программного кода практически для любых языков программирования. В Rational XDE для.NET возможна синхронизация модели и кода толькодля языков, которые поддерживаются Microsoft Visual Studio.NET. На данный момент этоVisual Basic, C#.
При этом кроме UML диаграмм XDE позволяет создавать Free Form (свободные формы), в которых не отслеживается нотация UML, и которые могут включать в себя значки из различных UML диаграмм, что не допускалась в Rational Rose.
В Rational XDE включены дополнительные фигуры и значки, которые позволяют аналитику нагляднее отображать в создаваемых моделях реальное положение дел.
8. Назначение, особенности и построение диаграммы Use Case.
Чаще всего моделирование системы начинается с построения диаграммы use case.
Case-среда типа Rational Rose представляет несколько способов создания новых элементов модели:
Контекстное меню
Tools -> создать
Строка инструментов
В первом случае элемент создается непосредственно в модели, но его значок не включены ни в одну из диаграмм, поэтому его необходимо поместить на выбранную диаграмму. Во втором и третьем случаях вместе с созданием элемента его значок помещается на диаграмму автоматически.
Построение диаграммы use case.
Согласно поставленной задаче существует некоторый план выращивания. Он должен быть введен в систему оператором. Поэтому создается актер и ему присваивается имя «оператор».
Создается элемент use case и ему присваивается имя «создать план выращивания».
Создается объект «контроллер». Этот актер также связывается с use case-ом «создать план выращивания».
Поскольку оператор должен иметь возможность просматривать протокол работы, создается use case «просмотреть протокол» и связывается с 2 актерами.
Для отражения процесса взаимодействия с исполнит устройствами создается use case «управлять устройствами», а также нов актер.
Необходимо еще одно действующее лицо «датчик» и use case «измерить показатели среды», который также связывается между собой и актером «контроллер».
Т.о. по диаграмме можно:
1. Оператор должен иметь возможность задать план выращивания
2. Он должен иметь возможность просматривать протокол работы
3. Система должна получать инф от датчика
4. Система должна иметь возможность управления внешними устройствами на основе показ датчика и введения плана выращивания.
Инструменты диаграммы.
Инструмент выбора – основной инструмент, позволяющий выбирать эл-ты диаграммы, позволяет выбирать инструменты для дальнейших действий.
Text – позволяет создать произвольную надпись на диаграмме не привязывая ее к какому либо элементу
Замечание – инструмент создает элемент «замечание», позволяет вписывать принят во время анализа решение. Обычно соединяется с другими аналогичными элементами посредствам «якоря».
Пакет – позволяет создавать пакеты, которые могут включать в себя группы элементов use case и в данной диаграмме м.б. использованы для определения более крупного сценариям с дальнейшей детализацией.
Use Case – позволяет создавать формы сценариев поведения объектов системы, т.е. представляет работы с позиции актера. Могут отображать:
А) Образцы поведения отдельных объектов системы
Б) Последовательные связи действий
В) Предоставление некоторой инф объектам.
Создание use case необходимо, чтобы:
Формализовать требования к системе
Организовать взаимодействие с пользователями и экспертами
Тестирование системы
Актер – используется для создания действующего лица в системе. Чаще всего польз системы. Также обозначает объект, который:
Взаимодействует с системой или использует ее
Передается или принимает инф в/из системы
Является внешним по отношению к системе.
Актер позволяет узнать:
Пользователя системы
Ответственен за сопровождение системы
Внешние устройства, взаимодействующие с системой
Однонаправленная ассоциации – позволяют обозначать связи между инструментами.
Рекомендации по построению диаграмм
Набор функций (прецедентов) создается, чтобы понять, чего актеры ждут от системы, а не как она должна это осуществлять. Ответ «как» получает позже, в ходе проектирования системы.
При анализе предметов прецедентов часто встреч след ошибка: создается use case высокого уровня абстракции, который затем разбивается на ряд use case’ов низкого уровня. И так до элементарных действий. Такой подход называется финальной декомпозицией и он считает ошибки в рамках ООП.
Выводы по диаграмме:
Модель прецедента без глубокой детализации всегда предпочтительнее той, где множество отношений include или extend
Удобно вынести общее поведение актеров в актера-родителя, т.е. выполнить обобщение актеров
Хорошим стилем является абстракция родит прецедента и актера.