Основные сведения о Rational Rose.

Понятие варианта использования или прецедента (UseCase) является основным элементом разработки и планирования проекта. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Прецедент описывает типичное взаимодействие между пользователем и системой. На диаграммах обозначаются в виде овалов. Действующее лицо (Actor) – это роль, которую пользователь играет по отношению к системе. Обратите внимание: несмотря на то, что действующие лица обозначаются на диаграммах в виде человечков, на самом деле действующим лицом может выступать не только пользователь, но также другая система, взаимодействующая с данной, и время. Время становится действующим лицом, если от него зависит запуск какого-либо события в системе. Для наглядного представления вариантов использования как основных элементов процесса разработки ПО применяются диаграммы вариантов использования. Рассмотрим распространённый пример такой диаграммы, иллюстрирующий работу банкомата (рис.1). Действующими лицами в данной системе являются Клиент и Банковская система. Проектируемая система «Банкомат» должна выполнять следующие действия: перевести деньги, сделать вклад, снять деньги со счёта, изменить код, показать баланс, осуществить оплату. На диаграмме показано взаимодействие между вариантами использования и действующими лицами, отражены требования к системе с точки зрения пользователя. Можно сказать, что варианты использования – это функции, выполняемые системой, а актёры – заинтересованные лица (stakeholders), инициирующие варианты использования, либо получающие от него информацию. Таким образом, диаграмма вариантов использования иллюстрирует требования к системе. Варианты использования всегда нужно анализировать вместе с действующими лицами системы, определяя при этом реальные задачи пользователей и рассматривая альтернативные способы решения этих задач. Конкретная цель диаграммы вариантов использования – документирование вариантов использования (всё, входящее в сферу применения системы), действующих лиц (всё вне этой сферы) и связей между ними. Рис. 1. Диаграмма вариантов использования для системы «Банкомат» При разработке диаграмм вариантов использования желательно придерживаться следующих правил: 1. Действующие лица находятся вне сферы действия проектируемой системы, а значит и связи между ними моделировать не стоит. 2. Не желательно соединять коммуникационной связью два варианта использования, так как диаграмма должна описывать доступные системе варианты использования, а не порядок их следования. 3. Вариант использования должен быть инициирован действующим лицом (должна быть сплошная стрелка идущая от актёра к прецеденту). Начинать строить диаграмму лучше всего с перечисления всех событий внешнего мира, на которые система должна реагировать. Более конкретные детали вариантов использования описываются в специальном документе, называемом поток событий (FlowofEvents). Его целью является документирование процесса обработки данных в рамках варианта использования. Поток событий обычно включает: – краткое описание; – предусловия (pre-conditions); – основной поток событий; – альтернативный поток событий (один или несколько); – постусловия (post-conditions). Краткое описание.Каждый прецедент должен иметь связанное с ним короткое описание того, что он будет делать. Например:Вариант использования «Перевести деньги» позволяет клиенту или служащему банка переводить с одного счёта на другой.Предусловия.Предусловия прецедента – это такие условия, которые должны быть выполнены, прежде чем прецедент начнёт выполняться сам. Например, выполнение другого варианта использования, наличие у пользователя прав доступа и т.д. Основной и альтернативный потоки событий.Поток событий поэтапно описывает, что должно выполняться в варианте использования: – способ запуска варианта использования; – различные пути выполнения варианта использования; – нормальный поток событий; – отклонения от нормального потока (альтернативные потоки); – потоки ошибок; – способ завершения варианта использования. Пример: Поток событий для прецедента «Снять деньги со счёта»Основной поток:

Вариант использования начинается, когда клиент вставляет карточку в банкомат.
Банкомат выводит приветствие и предлагает пользователю ввести пин-код.
Клиент вводит пин-код.
Банкомат подтверждает введённый пин-код. Если код не подтверждается, выполняется альтернативный поток А1.
Банкомат выводит список доступных действий: положить деньги, снять деньги, перевести деньги.
Клиент выбирает пункт «Снять деньги».
Банкомат запрашивает сумму.
Клиент вводит сумму.
Банкомат проверяет наличие введённой суммы на счёте. Если денег на счёте недостаточно, выполняется альтернативный поток А2. При возникновении ошибки выполняется поток ошибки Е1.
Банкомат вычитает сумму из счёта.
Банкомат выдаёт требуемую сумму.
Банкомат возвращает клиенту карточку.
Банкомат печатает чек.
Вариант использования завершается.

Читайте также: Mmc что за программа

Подумайте: Попробуйте аналогично самостоятельно описать альтернативные потоки А1 и А2, а также поток ошибки Е1. Постусловия.Условия, которые должны быть выполнены после завершения прецедента (пометка флажком переключателя, выполнение другого варианта использования). В языке UMLна диаграммах прецедентов поддерживается несколько типов связей между элементами: – коммуникация (communication) – обозначается сплошной линией со стрелкой – связь между актёром и прецедентом, направление позволяет понять, кто инициирует коммуникацию; – включение (include) – линия с соответствующим стереотипом – применяется в тех ситуациях, когда фрагмент поведения системы, повторяющийся в нескольких вариантах использования (например, аутентификация клиента требуется в системе «Банкомат» требуется как в прецеденте «Снять деньги со счёта», так и «Сделать вклад» и т.д.); – расширение (extend) – аналогично включению – применяется при описании изменений в нормальном поведении системы, что позволяет прецеденту использовать функциональные возможности другого прецедента только при необходимости; – обобщение (generalization) – не закрашенная стрелка – показывает, что у нескольких актёров имеются общие черты, такие связи необходимы, только если поведение действующего лица одного типа отличается от поведения актёра другого типа, в противном случаем, показывать обобщение действующего лица (как уже было сказано выше) не следует. Пример вышеописанных связей показан на рис. 2. Рис. 2. Связи коммуникации, включения, расширения и обобщения Практическая часть

Сведения о системе Rational Rose: функциональные возможности, принципы проектирования (ооп), ограничения и условия применения

Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Структура и функции

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

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

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

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

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

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

— заготовки текстов программ;

— модель разрабатываемой программной системы.

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

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

Взаимодействие с другими средствами и организация групповой работы

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA — для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

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

Для управляемой подмодели предусмотрены операции:

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

выгрузка подмодели из памяти;

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

установка защиты от модификации;

замена подмодели в памяти на новую.

Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании «чужих» подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными.

Среда функционирования

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

Для работы системы необходимо выполнение следующих требований:

Платформа Windows — процессор 80386SX или выше (рекомендуется 80486), память8Mб (рекомендуется 12Mб), пространство на диске 8Mб + 1-3Mб для одной модели.

Платформа UNIX — память 32+(16*число пользователей)Mб, пространство на диске 30Mб + 20 при инсталляции + 1-3Mб для одной модели.

Совместимость по версиям обеспечивается на уровне моделей.

Rational rose что за программа

Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [21]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Структура и функции

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

Взаимодействие с другими средствами и организация групповой работы

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

Платформа Windows — процессор 80386SX или выше (рекомендуется 80486), память8Mб (рекомендуется 12Mб), пространство на диске 8Mб + 1-3Mб для одной модели.
Платформа UNIX — память 32+(16*число пользователей)Mб, пространство на диске 30Mб + 20 при инсталляции + 1-3Mб для одной модели.

Совместимость по версиям обеспечивается на уровне моделей.

При подготовке материала использовались источники:
https://studfile.net/preview/3675069/page:2/
https://studfile.net/preview/9926045/page:3/
http://citforum.ru/database/case/glava5_5.shtml