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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


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

Информация:

Тип работы: курсовая работа. Добавлен: 22.09.2012. Сдан: 2011. Страниц: 9. Уникальность по antiplagiat.ru: < 30%

Описание (план):


НОУ ВПО «МОСКОВСКИЙ ТЕХНОЛОГИЧЕСКИЙ ИНСТИТУТ «ВТУ»»
    ФАКУЛЬТЕТ ТЕХНИКИ И СОВРЕМЕННЫХ ТЕХНОЛОГИЙ 

                                              Кафедра Информатики и автоматизации 
     
     
     

 
 
 
 
    Курсовая  работа по дисциплине «Базы данных» на тему:
    Разработка  диаграмм классов  с помощью CASE-средства Rational Rose
    Уровень образования бакалавриат
    Направление 230100 «Информатика и вычислительная техника»
    Профиль (бакалавриат) «Сети ЭВМ и телекоммуникации» 
     
     
     
     
     
     
     
     

   
Выполнил: студент 5 курса заочной формы обучения
 
 
 
 
 
 
 
 
 
 
 
Москва  2011 
 

      Содержание 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

      Введение 

      Современные RAD-средства программирования используют библиотеки компонентов, позволяющих повторно применять отлаженный программный код, что значительно облегчает сборку программных приложений. Такое «сборочное программирование» стало возможным за счет объектного подхода и привело к изменению организации жизненного цикла разрабатываемой информационной системы. Новые модели жизненного цикла предполагают минимальное время кодирования, больше времени уделяя моделированию системы.
      Визуальные  модели широко используются в существующих технологиях управления проектированием  систем, сложность, масштабы и функциональность которых постоянно возрастают. В практике эксплуатации ИС все время приходится решать такие задачи, как физическое перераспределение вычислений и данных, обеспечение параллелизма вычислений, безопасности доступа к ИС и устойчивости к сбоям, репликация БД, оптимизация балансировки нагрузки ИС и т. п.
      Модели  позволяют свести высокую сложность  информационной системы до уровня, понимаемого человеком. Достигается  это за счет иерархического принципа их построения и применения наглядной графической нотации. Иерархия уровней описания системы дает возможность резко сократить количество элементов, которые должен анализировать человек. Каждая модель может быть выражена с разными уровнями детализации. При этом на верхних уровнях иерархии опускаются детали реализации, которые проявляются на более низких уровнях.
      Построенные модели могут модифицироваться в  течение всего жизненного цикла. Причин тому может быть много - изменения  требований к системе, устранение ошибок, развитие системы, нахождение более удачных решений и т. д. При этом обязательно соблюдение соответствия между моделями и программными кодами. Для этого современные средства визуального моделирования оснащаются возможностью генерации программного кода для RAD-систем разработки. Выполняется также обратное проектирование: преобразование готового кода в визуальные модели.
      Актуальность  выбранной темы, обусловлена тем, что с помощью этих диаграмм можно показать статическую структуру, определяющую логические связи в системе, динамику работы отдельных компонент (классов), взаимодействие объектов в процессе функционирования системы, физическую структуру и т. д.
     Цель Разработка диаграмм классов с помощью CASE-средства Rational Rose.
     Объект – Проектирование автоматизированных информационных систем.
     Предметом – информационные технологии.
     Основные задачи:
      - Изучить среду проектирования программного обеспечения Rational Rose, основанную на унифицированном языке моделирования UML.
     Методологическая  основа исследования изучение средств и технологии обработки графической информации занимались следующие ученые Зайце Е.Г., Анатольев Е.Ф., Мальцев А.Н., Агашков А.Н., Третьяков Н.Н. и другие.
     Методы  исследования –  при написании данной курсовой работы были использованы научные и учебные издания по проектированию автоматизированных информационных систем.  
 
 
 
 
 

      Глава I CASE-средства Rational Rose 

      1.1 Задачи моделирования  предметной области  с помощью UML rational rose borland delphi система 

     Традиционно, при проектировании автоматизированной информационной системы в среде Rational Rose, необходимо построить ряд диаграмм, отражающих разные стороны проекта. В частности, для описания динамики работы проектируемой системы надо построить набор диаграмм деятельностей разной степени детализации. На таких диаграммах изображаются виды деятельности, связанные с решением задачи, подлежащей автоматизации, входные и выходные документы или данные, связанные с конкретной деятельностью, исполнители деятельности и подразделения, в которых она выполняется. На основе этого требуется определить и зафиксировать функциональные требования к системе и отразить их в диаграммах Use-Case1.
     При использовании инструментария, предоставляемого фирмой Rational для проектирования систем с помощью UML, разработчики могут оговорить ряд соглашений по построению диаграмм разных видов. Эти соглашения позволят создать корпоративный стандарт моделирования. Этот стандарт обеспечит:
    Возможность выдержать единый стиль диаграмм;
    Возможность автоматизации преобразования и обработки диаграмм;
    Возможность внедрения формальных способов контроля;
    Повышение качества конечного продукта за счет своевременного выявления ошибок на ранних стадиях проекта.
 
 


      1.2 Описание нотаций  диаграмм 

     Модель  разрабатываемой системы являет собой совокупность взаимосвязанных подмоделей, каждая из которых описывается набором диаграмм, описанных с помощью определенной в UML графической нотации.
     Моделирование проводится как «поуровневый спуск» от концептуальной модели к логической, а затем к компонентной модели программной системы. Концептуальная модель выражается в виде «диаграмм прецедентов» (use case diagram). Этот тип диаграмм служит для проведения итерационного цикла общей постановки задачи вместе с заказчиком.
     Техника Прецедентов Использования (Use-case) - была впервые предложена Айваром Якобсоном в 1992 и быстро завоевала всеобщее признание за счет простоты и легкости восприятия и применения. Суть ее состоит в следующем: проектируемая система представляется в виде наборов Актеров, взаимодействующих с системой с помощью так называемых use-case. Актером является любая сущность, взаимодействующая с системой извне. Им может быть человек, оборудование, другая система, то есть мы определяем, что взаимодействует с системой. Графическое обозначение актера представляет собой схематичное изображение человека и название (рис.1.1)2.
     В свою очередь Use-case описывает, что система предоставляет актеру, то есть определяет некоторый набор транзакций, совершаемый актером при диалоге с системой, при этом ничего не говориться о том, каким образом будет реализовано взаимодействие. Графическое изображение Use Case представляет собой горизонтальный овал с названием внизу. На рисунке 1 представлен пример диаграммы Use Case.

     Рисунок 1.1 - Диаграмма UseCase3 

     Детальное описание - удел других техник моделирования UML, диаграмма Use-case несет в себе высокий уровень абстракции, что позволяет еще на ранних этапах проекта определить и зафиксировать функциональные требования к системе и обеспечить гибкий и эффективный механизм взаимодействия между разработчиком и заказчиком проекта. Внутри каждого прецедента могут быть определены:
    Вложенная диаграмма прецедентов (диаграмма функций, use case diagram);
    Диаграмма взаимодействия объектов (Collaboration diagram);
    Диаграмма последовательности взаимодействий (Sequence diagram);
    Диаграмма классов (Class diagram);
    Диаграмма перехода состояний (State diagram).
     Далее будут рассмотрены некоторые  виды диаграмм, необходимые для понимания  проблематики данного проекта.
     Диаграмма классов показывает статическую  структуру части системы. Таким образом, составляющими данного типа диаграмм являются классы, объекты и отношения между ними. Нотация классов и объектов проста и интуитивно понятна всем, кто когда-либо имел опыт работы с разного рода CASE-инструментариями. Класс представлен прямоугольником с тремя разделами, в которых соответственно помещаются имя класса, атрибуты и операции. Схожая нотация применяется и для объектов - экземпляров класса, с тем различием, что к имени класса добавляется имя объекта и вся надпись подчеркивается. Нотация UML предоставляет широкие возможности для отображения дополнительной (и зачастую очень важной) информации (абстрактные операции и классы, стереотипы, общие и частные методы, интерфейсы, параметризованные классы и т.д.), но в рамках данной работы невозможно охватить абсолютно все, поэтому несколько слов о представлении отношений между классами объектов. Ассоциации, то есть статические связи между классами, изображаются в виде связующей линии, на которой может указываться мощность ассоциации, ее направление, название и возможное ограничение, реализующее механизм расширения UML. Существует возможность отразить специфические свойства ассоциации, например: отношение агрегации, когда составными частями класса могут выступать другие классы. Такое отношение изображается в виде ромба, расположенного рядом с агрегирующим классом. Отношение обобщения также имеет собственную графическую нотацию в виде треугольника и связующей линии, позволяя представить иерархию наследования: от суперкласса к подклассам. 

     

     Рисунок 1.2 - Пример диаграммы  классов4 

     Диаграммы деятельностей (Activity diagram) занимают особое место при проектировании. Они отражают динамику работы проектируемой системы. Основным направлением использования Диаграммы Деятельностей является описание операций классов, когда необходимо представить алгоритм реализации, при этом каждый шаг является выполнением операции некоторого класса. По сути, эти диаграммы – дальнейшее развитие классических блок-схем алгоритма с учетом современных требований.
     Диаграммы деятельностей устраняют следующие недостатки блок-схем:
    Невозможно отобразить операции, выполняющиеся параллельно;
    Нельзя явно задать область ответственности для классов системы;
    Невозможно правильно и наглядно отобразить работу в событийно-ориентированной среде5.
     Графическая нотация включает:
    Дорожка (Swim lane) – делит диаграмму вертикальными линиями на поименованные области, задавая ответственность класса, указанного в названии.
    Деятельность (Activity) – обозначает выполнение операции класса, указанного в соответствующей дорожке. Изображается овалом, внутри которого указано название операции.
    Состояние (State)
    Линейка синхронизации (Synchronization) – показывает момент синхронизации параллельно выполняющихся процессов. Изображается утолщенной горизонтальной или вертикальной линией.
    Принятие решения (Decision) – условный переход. В отличие от классического блока перехода имеется возможность более гибко варьировать условия перехода, задавая более двух направлений. Главная особенность в том, что обязательно должно выполнится одно из условий. Изображается ромбом.
    Переход (Transition) – отношение между двумя состояниями или деятельностями. С его помощью организуется связь по управлению между элементами диаграммы. Обозначается стрелкой.
     Кроме диаграмм действий и состояний, в разделе диаграмм поведения предусмотрено два типа диаграмм, отвечающих за описание взаимодействия объектов системы:
    Диаграмма Следования;
    Диаграмма Кооперации6.
     Диаграмма Следования делает упор на временную  последовательность передаваемых сообщений, важен порядок, вид и имя сообщения, на диаграмме изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии, и не показываются возможные статические ассоциации с другими объектами. Таким образом, для диаграмм следования ключевым моментом является динамика взаимодействия. Диаграмма имеет два измерения, первое - слева направо, в виде вертикальных линий, изображающих объекты, участвующие во взаимодействии. Верхняя часть линий дополняется прямоугольником, содержащим имя класса объекта или имя экземпляра объекта. Второе измерение - вертикальная временная ось. Сообщения, посылаемые одним объектом другому, изображаются в виде стрелок с именем сообщения и упорядочены по времени возникновения.
     Для Диаграмм Кооперации главным является возможность отобразить не столько последовательность взаимодействия, сколько все окружение объектов, участвующих в нем. То есть, показаны не только посылаемые и принимаемые сообщения, но и косвенные связи между ассоциированными объектами. Говорят, что Диаграммы Кооперации описывают полный контекст взаимодействия и представляет собой своеобразный временной "срез" конфигурации сети объектов, взаимодействующих для выполнения определенной бизнес-цели программной системы. Диаграмма кооперации изображает объекты, участвующие во взаимодействии, в виде прямоугольников, содержащих имя объекта, его класс и, возможно, значение атрибутов. Ассоциации между объектами, как и на диаграммах классов, изображаются в виде соединительных линий. Возможно указание имени ассоциации и ролей, которые играют объекты в данной ассоциации. Динамические связи - потоки сообщений, представляются также в виде соединительных линий между объектами, сверху которых располагается стрелка с указанием направления и имени сообщения. Отдельно используются диаграммы, призванные осветить вопросы, связанные с физической реализацией системы:
    Диаграмма Компонент;
    Диаграмма Размещения7.
     Диаграммы Компонентов и Размещения, в отличие  от ранее рассмотренных диаграмм Прецедентов, Классов, Деятельностей и Следования, являющихся логическим представлением системы в процессе ее разработки, описывают физическое представление системы. Диаграмма Компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль (или компонента) соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости (аналогичные тем, которые имеют место при компиляции). Диаграммы размещения используются для представления конфигурации компонент, процессов и объектов, присутствующих в системе на этапе выполнения. Кроме того, Диаграммы размещения показывают физическую зависимость аппаратных устройств, задействованных в реализации системы, а также соединений между ними - маршрутов передачи информации.
     Таким образом, язык UML предоставляет нам полный набор инструментов, необходимый нам для описания предметной области и моделирования автоматизированной системы.
     Порядок работ на этапе бизнес моделирования  включает следующие виды технологических  работ:
    Формулировка задач, подлежащих автоматизации;
    Описание бизнес процессов по каждой сформулированной задаче. Описание бизнес процессов должно производиться с использованием диаграмм деятельности (activity diagram);
    На основе бизнес процессов определение бизнес требований по автоматизации предприятия, т.е. определение видов деятельности предприятия, подлежащих автоматизации;
    На основе бизнес требований описание структуры автоматизируемого предприятия с использованием диаграммы функций (use case diagram). На диаграмме функций (use case diagram) должно быть замоделировано:
          - действующие лица и их бизнес функции, подлежащие автоматизации с использованием элементов бизнес актер (business actor), бизнес работник (business worker), бизнес функция (business use case);
          - документы с использованием элементов бизнес сущностей (business entity);
          - сценарии функций с использованием диаграмм последовательностей (sequence diagram) или диаграмм деятельности (activity diagram);
          - состояния документов с использованием диаграмм деятельности (activity diagram);
          - бизнес правила, включая алгоритмы, с использованием диаграмм деятельности (activity diagram) и элементов бизнес сущностей (business entity)8.
     Модели  и документы на этапе бизнес моделирования  должны быть разработаны после неоднократных  встреч аналитиков, проектировщиков  с заинтересованными в разработке автоматизированной системы лицами. В рамках данной работы необходимо подробно рассмотреть описание бизнес процессов с использованием диаграмм деятельности. Ниже перечисляется ряд соглашений, формализующих такое описание:
    Диаграмма деятельностей должна иметь начало и конец.
    На одной диаграмме следует отображать не более 8-10 видов деятельности. Для этого необходимо декомпозировать отдельные виды деятельности. На декомпозирующей диаграмме должны быть отражены разделительные линии.
    Название декомпозирующей диаграммы должно быть следующим – «Декомпозиция деятельности «Название деятельности, которая декомпозируется»».
    Начальная точка должна именоваться аналогично.
    Конечная точка должна иметь название деятельности, следующее за декомпозированной.
    Нельзя в одном элементе Activity указывать несколько видов деятельности, например, «формирует товарный отчет и проводки, получает и передает акт о недостаче».
    Условия на переходах, соединяющих деятельности и состояния, должны указываться строчными буквами.
      Выполнение  этих соглашений позволит значительно  повысить качество и позволит избежать множество ошибок на ранних стадиях проектирования 

      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.
      Use case diagram (диаграммы  прецедентов)
      Этот  вид диаграмм позволяет создать  список операций, которые выполняет  система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.
      Каждая  такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors). 
      Данный  тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты как системы, так  и предметной области и задачи, ими выполняемые.
      Deployment diagram (диаграммы  топологии)
      Этот  вид диаграмм предназначен для анализа  аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм.
      Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения.   
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.