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

НОУ ВПО «МОСКОВСКИЙ ТЕХНОЛОГИЧЕСКИЙ ИНСТИТУТ «ВТУ»»

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

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

 
 
 
 

Курсовая  работа по дисциплине «Базы данных» на тему:

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

Уровень образования бакалавриат

Направление 230100 «Информатика и вычислительная техника»

Профиль (бакалавриат) «Сети ЭВМ и телекоммуникации» 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 

Москва  2011 
 

      Содержание 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

      Введение 

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

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

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

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

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

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

     Объект – Проектирование автоматизированных информационных систем.

     Предметом – информационные технологии.

     Основные задачи:

      - Изучить среду проектирования программного обеспечения Rational Rose, основанную на унифицированном языке моделирования UML.

     Методологическая  основа исследования изучение средств и технологии обработки графической информации занимались следующие ученые Зайце Е.Г., Анатольев Е.Ф., Мальцев А.Н., Агашков А.Н., Третьяков Н.Н. и другие.

     Методы  исследования –  при написании данной курсовой работы были использованы научные и учебные издания по проектированию автоматизированных информационных систем.  
 
 
 
 
 

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

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

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

     При использовании инструментария, предоставляемого фирмой Rational для проектирования систем с помощью UML, разработчики могут оговорить ряд соглашений по построению диаграмм разных видов. Эти соглашения позволят создать корпоративный стандарт моделирования. Этот стандарт обеспечит:

1. Возможность выдержать единый стиль диаграмм;
2. Возможность автоматизации преобразования и обработки диаграмм;
3. Возможность внедрения формальных способов контроля;
4. Повышение качества конечного продукта за счет своевременного выявления ошибок на ранних стадиях проекта.

 

 

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

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

     Моделирование проводится как «поуровневый спуск» от концептуальной модели к логической, а затем к компонентной модели программной системы. Концептуальная модель выражается в виде «диаграмм прецедентов» (use case diagram). Этот тип диаграмм служит для проведения итерационного цикла общей постановки задачи вместе с заказчиком.

     Техника Прецедентов Использования (Use-case) - была впервые предложена Айваром Якобсоном в 1992 и быстро завоевала всеобщее признание за счет простоты и легкости восприятия и применения. Суть ее состоит в следующем: проектируемая система представляется в виде наборов Актеров, взаимодействующих с системой с помощью так называемых use-case. Актером является любая сущность, взаимодействующая с системой извне. Им может быть человек, оборудование, другая система, то есть мы определяем, что взаимодействует с системой. Графическое обозначение актера представляет собой схематичное изображение человека и название (рис.1.1)².

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

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

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

• Вложенная диаграмма прецедентов (диаграмма функций, use case diagram);
• Диаграмма взаимодействия объектов (Collaboration diagram);
• Диаграмма последовательности взаимодействий (Sequence diagram);
• Диаграмма классов (Class diagram);
• Диаграмма перехода состояний (State diagram).

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

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

     

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

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

     Диаграммы деятельностей устраняют следующие недостатки блок-схем:

1. Невозможно отобразить операции, выполняющиеся параллельно;
2. Нельзя явно задать область ответственности для классов системы;
3. Невозможно правильно и наглядно отобразить работу в событийно-ориентированной среде⁵.

     Графическая нотация включает:

1. Дорожка (Swim lane) – делит диаграмму вертикальными линиями на поименованные области, задавая ответственность класса, указанного в названии.
2. Деятельность (Activity) – обозначает выполнение операции класса, указанного в соответствующей дорожке. Изображается овалом, внутри которого указано название операции.
3. Состояние (State)
4. Линейка синхронизации (Synchronization) – показывает момент синхронизации параллельно выполняющихся процессов. Изображается утолщенной горизонтальной или вертикальной линией.
5. Принятие решения (Decision) – условный переход. В отличие от классического блока перехода имеется возможность более гибко варьировать условия перехода, задавая более двух направлений. Главная особенность в том, что обязательно должно выполнится одно из условий. Изображается ромбом.
6. Переход (Transition) – отношение между двумя состояниями или деятельностями. С его помощью организуется связь по управлению между элементами диаграммы. Обозначается стрелкой.

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

• Диаграмма Следования;
• Диаграмма Кооперации⁶.