Разработка диаграмм классов с помощью CASE-средства Rational Rose

Автор работы: Пользователь скрыл имя, 16 Октября 2011 в 20:13, курсовая работа

Краткое описание

Цель – Разработка диаграмм классов с помощью CASE-средства Rational Rose.

Содержание работы

Введение 3
Глава I CASE-средства Rational Rose 5
1.1 Задачи моделирования предметной области с помощью UML rational rose borland delphi система 5
1.3 Объектно-ориентированные CASE-средства (Rational Rose) 15
Глава II UML диаграммы в Rational Rose 19
Глава III Структура и функции 26
Заключение 29
Список литературы 30

Содержимое работы - 1 файл

Разработка диаграмм классов с помощью CASE-средства Rational Rose.doc

— 217.00 Кб (Скачать файл)

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

     Для Диаграмм Кооперации главным является возможность отобразить не столько последовательность взаимодействия, сколько все окружение объектов, участвующих в нем. То есть, показаны не только посылаемые и принимаемые сообщения, но и косвенные связи между ассоциированными объектами. Говорят, что Диаграммы Кооперации описывают полный контекст взаимодействия и представляет собой своеобразный временной "срез" конфигурации сети объектов, взаимодействующих для выполнения определенной бизнес-цели программной системы. Диаграмма кооперации изображает объекты, участвующие во взаимодействии, в виде прямоугольников, содержащих имя объекта, его класс и, возможно, значение атрибутов. Ассоциации между объектами, как и на диаграммах классов, изображаются в виде соединительных линий. Возможно указание имени ассоциации и ролей, которые играют объекты в данной ассоциации. Динамические связи - потоки сообщений, представляются также в виде соединительных линий между объектами, сверху которых располагается стрелка с указанием направления и имени сообщения. Отдельно используются диаграммы, призванные осветить вопросы, связанные с физической реализацией системы:

  • Диаграмма Компонент;
  • Диаграмма Размещения7.

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

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

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

  1. Формулировка задач, подлежащих автоматизации;
  2. Описание бизнес процессов по каждой сформулированной задаче. Описание бизнес процессов должно производиться с использованием диаграмм деятельности (activity diagram);
  3. На основе бизнес процессов определение бизнес требований по автоматизации предприятия, т.е. определение видов деятельности предприятия, подлежащих автоматизации;
  4. На основе бизнес требований описание структуры автоматизируемого предприятия с использованием диаграммы функций (use case diagram). На диаграмме функций (use case diagram) должно быть замоделировано:
  5.      
  6. - действующие лица и их бизнес функции, подлежащие автоматизации с использованием элементов бизнес актер (business actor), бизнес работник (business worker), бизнес функция (business use case);
  7.      
  8. - документы с использованием элементов бизнес сущностей (business entity);
  9.      
  10. - сценарии функций с использованием диаграмм последовательностей (sequence diagram) или диаграмм деятельности (activity diagram);
  11.      
  12. - состояния документов с использованием диаграмм деятельности (activity diagram);
  13.      
  14. - бизнес правила, включая алгоритмы, с использованием диаграмм деятельности (activity diagram) и элементов бизнес сущностей (business entity)8.

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

  1. Диаграмма деятельностей должна иметь начало и конец.
  2. На одной диаграмме следует отображать не более 8-10 видов деятельности. Для этого необходимо декомпозировать отдельные виды деятельности. На декомпозирующей диаграмме должны быть отражены разделительные линии.
  3. Название декомпозирующей диаграммы должно быть следующим – «Декомпозиция деятельности «Название деятельности, которая декомпозируется»».
  4. Начальная точка должна именоваться аналогично.
  5. Конечная точка должна иметь название деятельности, следующее за декомпозированной.
  6. Нельзя в одном элементе Activity указывать несколько видов деятельности, например, «формирует товарный отчет и проводки, получает и передает акт о недостаче».
  7. Условия на переходах, соединяющих деятельности и состояния, должны указываться строчными буквами.

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

      1.3 Объектно-ориентированные CASE-средства (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 содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах9.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Глава II UML диаграммы в Rational Rose 

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

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

  • Use case diagram (диаграммы прецедентов);
  • Deployment diagram (диаграммы топологии);
  • Statechart diagram (диаграммы состояний);
  • Activity diagram (диаграммы активности);
  • Interaction diagram (диаграммы взаимодействия);
  • Sequence diagram (диаграммы последовательностей действий);
  • Collaboration diagram (диаграммы сотрудничества);
  • Class diagram (диаграммы классов);
  • Component diagram (диаграммы компонент)12.

Информация о работе Разработка диаграмм классов с помощью CASE-средства Rational Rose