Кафедра информационных технологий

Сочинский государственный университет

Факультет информационных технологий и математики

Кафедра информационных технологий

Лабораторная работа №1
по дисциплине
Программная инженерия

Тема: Универсальный язык моделирования UML и средство моделирования Rational Rose – первое знакомство

Выполнил студент гр. 14-ПИ

Рябцев В.В.

Сочи

2016

Оглавление

1.Понятие Rational Rose 3

2.Понятие UML. 5

3.Виды диаграмм.. 6

3.1.Диаграмма классов. 6

3.2.Диаграмма компонентов. 7

3.3Диаграмма композитной/составной структуры.. 7

3.4.Диаграмма развёртывания. 7

3.5.Диаграмма объектов. 7

3.6.Диаграмма пакетов. 7

3.7.Диаграмма деятельности. 8

3.8.Диаграмма автомата. 8

3.9.Диаграмма сценариев использования. 8

3.10.Диаграммы коммуникации и последовательности. 8

3.11.Диаграмма обзора взаимодействия. 9

3.12.Диаграмма синхронизации. 9

4.ПРЕИМУЩЕСТВА RATIONAL ROSE. 10

5.Главное окно Rational Rose. 11

Заключение. 13

Используемые источники. 14

1.Понятие Rational Rose [1]

Rational Rose — мощный инструмент анализа и проектирования объектно-ориентированных програм­мных систем. Он позволяет моделировать системы до написания кода, так что вы можете с самого на­чала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат.

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

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

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

Естественно ожидать различие в стилях программирования; получив одинаковый набор требова­ний, 20 разработчиков создадут 20 различных систем. Таким образом, без подробного обсуждения ра­боты с каждым участником проекта будет трудно понять, какие решения по проекту приняты, из каких элементов состоит система и что представляет собой ее общая структура. Не имея документи­рованного проекта, трудно даже быть уверенным, что созданное приложение — это именно то, чего хотели пользователи.

Традиционно процесс, которому мы следуем, выглядит следующим образом:

Хотя требования и были документированы, весь проект находится в голове Боба, и никто, кроме Боба, не понимает достаточно хорошо архитектуру системы. Когда Боб оставляет команду, информа­ция уходит вместе с ним. Если вы оказывались в подобной ситуации, то согласитесь, как трудно быва­ет понять плохо документированную систему.

Модель Rose предлагает совершенно другой подход:

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

Однако модели используют не только разработчики:

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

С помощью диаграмм Вариантов Использования и документации менеджеры проекта смогут разделить проект на отдельные управляемые задачи.

Из документации по вариантам использования аналитики и потребители смогут понять, что будет делать готовая система.

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

Из диаграмм Последовательности и Кооперативных диаграмм аналитики и разработчики уяснят, насколько логично работает система, поймут ее объекты и сообщения между ними.

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

С помощью диаграмм Классов я Состояний разработчики получат представление о фрагмен­тах системы и их взаимодействии друг с другом.

Из диаграмм Компонентов и Размещения эксплуатационный персонал сможет узнать, какие .ЕХЕ и .DLL файлы и другие компоненты будут созданы, а также где в сети они должны быть размещены.

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

В настоящее время доступны три различных варианта Rose:

Rose Modeler, позволяющий разрабатывать модели системы, но не поддерживающий возмож­ности генерации кода и обратного проектирования.

Rose Professional, позволяющий генерировать код на каком-либо одном языке.

Rose Enterprise, позволяющий генерировать код на C++, Java, Visual Basic и схемы QracleS.

Более того, в последней версии Rose 98i уделяется особое внимание ее интеграции с такими инст­рументами, как Rational RequisitePro, TeamTest, Visual C++ и другими. Rose 98i обеспечивает публика­цию вантах моделей на Web-страницах. Как и предшествующая версия, она доступна в вариантах Modeler, Professional и Enterprise. Все упражнения этой книги записаны для обеих версий: Rose 98 и Rose98i.

2.Понятие UML[2]

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

3.Виды диаграмм[2]

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

Структуру диаграмм UML 3.1 можно представить на диаграмме классов UML:

Диаграмма классов

Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.

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

· концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

· точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

· точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

Диаграмма компонентов

Диаграмма компонентов (Component diagram) — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

Не нашли, что искали? Воспользуйтесь поиском по сайту: