- •1. Унифицированный язык моделирования uml 5
- •2. Использование case-средства rational rose для проектирования информационных систем 7
- •4.1. Представление Вариантов Использования 110
- •1. Унифицированный язык моделирования uml
- •2. Использование case-средства rational rose для проектирования информационных систем
- •2.1. Описание case-средства Rational Rose
- •2.2. Общие принципы работы в среде Rational Rose
- •2.3. Представления Rational Rose
- •2.3.1. Представление Вариантов использования
- •2.3.2. Логическое представление
- •2.3.3. Представление Компонентов
- •2.3.4. Представление Размещения
- •2.4. Диаграммы представления вариантов использования
- •2.4.1. Диаграммы Вариантов Использования
- •2.4.1.1. Работа с вариантами использования
- •2.4.1.2. Документирование потока событий
- •2.4.1.3. Работа с действующими лицами
- •2.4.1.4. Работа со связями
- •Р ис.4. Связь использования
- •Р ис.5. Связь расширения
- •2.4.1.5. Работа с пакетами
- •2.4.1.6. Работа с примечаниями
- •2.4.2. Диаграммы Взаимодействия
- •2.4.2.1. Идентификация объектов
- •2.4.2.2. Использование диаграмм Взаимодействия
- •2.4.2.3. Диаграммы Последовательности
- •2.4.2.4. Кооперативные диаграммы
- •2.4.2.5. Работа с действующими лицами на диаграмме Взаимодействия
- •2.4.2.6. Работа с объектами
- •2.4.2.6.1. Спецификации объекта
- •2.4.2.6.2. Именование объекта
- •2.4.2.6.3. Соотнесение объекта с классом
- •2.4.2.6.4. Определение устойчивости объекта
- •2.4.2.7. Работа с сообщениями
- •2.4.2.7.1. Работа с сообщениями на диаграмме Последовательности
- •2.4.2.7.2. Работа с сообщениями на Кооперативной диаграмме
- •2.4.2.7.2.1. Добавление потоков данных к Кооперативной диаграмме
- •2.4.2.7.3. Спецификации сообщений
- •2.4.2.7.3.1. Соотнесение сообщения с операцией
- •2.4.2.8. Работа с примечаниями и скриптами
- •2.4.3. Диаграммы деятельности.
- •Р ис. 9. Пример применения условия
- •2.4.3.1. Состояние действия
- •2.4.3.2. Переходы
- •2.4.3.3. Дорожки
- •2.4.3.4. Рекомендации по построению диаграмм деятельности
- •2.5. Диаграммы Логического представления
- •2.5.1. Диаграммы Классов
- •2.5.1.1. Выявление классов
- •2.5.1.2. Создание диаграмм Классов
- •2.5.1.3. Работа с классами
- •2.5.1.3.1. Спецификации классов
- •2.5.1.3.2. Именование классов
- •2.5.1.3.3. Назначение стереотипа для класса
- •Р ис.15. Место нахождения пограничного класса “Форма ввода поручения”
- •2.5.1.3.4. Задание видимости класса
- •2.5.1.3.5. Задание множественности класса
- •2.5.1.3.6. Задание устойчивости класса
- •2.5.1.3.7. Создание абстрактного класса
- •2.5.1.4. Работа с пакетами
- •2.5.1.5. Работа с атрибутами
- •2.5.1.5.1. Добавление и удаление атрибутов
- •2.5.1.6. Спецификации атрибута
- •2.5.1.6.1. Задание типа данных атрибута
- •2.5.1.6.2. Назначение стереотипа для атрибута
- •2.5.1.6.3. Задание видимости атрибута
- •2.5.1.6.4. Задание метода локализации атрибута
- •2.5.1.6.5. Определение статичного атрибута
- •2.5.1.6.6. Определение производного атрибута
- •2.5.1.7. Работа с операциями
- •2.5.1.7.1. Выявление операций
- •2) Операции управления (manager operations) управляют созданием и разрушением объектов. В эту категорию попадают конструкторы и деструкторы классов.
- •2.5.1.7.2. Добавление операций
- •2.5.1.8. Спецификации операции
- •2.5.1.8.1. Задание возвращаемого класса операции
- •2.5.1.8.2. Назначение стереотипа для операции
- •2.5.1.8.3. Задание видимости операций
- •2.5.1.8.4. Добавление аргументов к операции
- •2.5.1.9. Соотнесение операций с сообщениями
- •2.5.1.10. Связи
- •2.5.1.10.1. Ассоциации
- •2.5.1.10.2. Зависимости
- •2.5.1.10.2.1. Зависимости между пакетами
- •2.5.1.10.3. Агрегации
- •2.5.1.10.4. Обобщения
- •Р ис. 25. Связь обобщения
- •2.5.1.10.4.1. Создание обобщений
- •2.5.1.10.5. Выявление связей
- •2.5.1.10.6. Задание множественности
- •2.5.1.10.7. Использование имен связей
- •2.5.1.10.7.1. Использование ролей
- •2.5.1.10.8. Использование статичных связей
- •2.5.1.10.9. Использование дружественных связей
- •2.5.1.10.10. Задание метода включения
- •2.5.1.10.11. Элемент связи
- •2.5.2. Диаграммы Состояний
- •2.5.2.1. Создание диаграмм Состояний
- •2.5.2.1.1. Добавление состояний
- •2.5.2.1.2. Добавление переходов
- •2.5.2.2. Задание специальных состояний
- •2.5.2.2.1. Использование вложенных состояний
- •2.6. Диаграммы Представления Компонентов
- •2.6.1. Представление Компонентов
- •2.6.2.Типы компонентов
- •2.6.3. Диаграмма Компонентов
- •2.6.3.1. Добавление компонентов
- •2.6.3.2. Определение деталей компонентов
- •2.6.3.3. Добавление зависимостей между компонентами
- •2.7. Диаграммы Представления Размещений
- •2.7.1. Узел
- •Информацией в форме помеченного значения
- •С размещёнными на них компонентами
- •2.7.2. Соединения
- •2.7.3. Рекомендации по построению диаграммы Размещения
- •2.8. Дополнительные возможности Rational Rose
- •2.8.1. Генерация программного кода
- •2.8.1.1. Подготовка к генерации программного кода
- •6) Генерация программного кода.
- •2.8.1.2. Этап первый: проверка модели
- •2.8.1.2.1. Нарушения правил доступа
- •2.8.1.3. Этап второй: создание компонентов
- •2.8.1.4. Этап третий: отображение классов на компоненты
- •2.8.1.5. Этап четвертый: установка свойств генерации программного кода
- •2.8.1.6. Этап пятый: выбор класса, компонента или пакета
- •2.8.1.7. Этап шестой: генерация программного кода
- •2.8.1.8. Результаты генерации
- •2.8.1.8.1. Компоненты
- •2.8.2. Обратное проектирование
- •2.8.3. Проектирование бд с использованием Rational Rose
- •2.8.3.1. Использование стереотипов для представления схем бд
- •Р ис.39. Вид схемы в браузере Rational Rose (Data Modeler) р ис.40. Пакет со стереотипом «Schema» (Data Modeler)
- •Р ис.43. Отображение доменов в браузере Rational Rose
- •2.8.3.2. Прямая и обратная генерация схем бд
- •2.8.3.2.1. Формирование схем на основе диаграмм классов
- •Р ис.53. Преобразование связей-ассоциаций 1:1 и 1:n
- •Р ис.56. Преобразование связи-композиции
- •2.8.3.2.2. Отображение существующих бд в диаграммы Rational Rose
- •В окне браузера (слева) и на диаграмме компонентов (справа)
- •Р ис.62. Объектный просмотр, зависящий от объектного типа и реляционных таблиц
- •Пример проектирования информационной системы «стол заказов»
- •4.1. Представление Вариантов Использования
- •4.1.1. Диаграмма Вариантов Использования
- •4.1.2. Диаграммы Взаимодействия
- •4.1.2.1. Диаграммы Последовательности
- •4.1.2.2. Кооперативные диаграммы
- •4.2. Логическое представление
- •4.2.1. Диаграммы Классов
- •4.2.1.1. Выявление классов
- •4.2.1.2. Определение атрибутов и операций классов
- •4.2.1.3. Объединение классов в пакеты
- •Р ис.71. Диаграмма классов
- •Р ис.72. Пакет «Аутентификация»
- •4.2.2. Диаграммы Состояний
- •4.2.3. Диаграммы Деятельности
- •4.3. Представление Компонентов
- •4.4. Представление Размещения
- •Р ис.77 Диаграмма Размещения список литературы
- •Приложение а. «базовые сценарии вариантов использования»
- •Приложение б. «диаграммы последовательности»
- •2. «Изменить ассортимент»
- •3. «Изменить состояние заказа»
- •4. «Аутентификация»
- •5. «Просмотреть ассортимент»
- •6. «Управление заказом»
- •7. «Найти заказ»
- •8. «Копировать заказ»
- •9. «Учёт товаров на складе»
- •Приложение в. «пакеты»
- •1. «Работа с пользователями»
- •2. «Работа с заказами»
- •3. «Работа с товарами»
2.5.1.10.11. Элемент связи
Элементом связи (link element), известным также как класс Ассоциаций (Association class), называется место, где хранятся относящиеся к ассоциации атрибуты. Допустим, что у нас есть два класса: Student и Course, и необходимо добавить на диаграмму атрибут Grade (Год обучения).
В этом случае возникает вопрос: в какой класс добавить атрибут? Если мы поместим его в класс Student, то придется вводить атрибут для каждого посещаемого студентом курса, что значительно увеличит этот класс. Если же мы поместим его в класс Course, то придется задавать атрибут для каждого посещающего этот курс студента.
Для решения подобной проблемы можно создать класс Ассоциаций. В него следует поместить атрибут Grade, относящийся в большей степени к связи между курсом и студентом, чем к какому-то классу конкретно. Нотация UML для класса Ассоциаций представлена на рис. 28.
Рис. 28. Элементы связи (классы Ассоциаций)
2.5.2. Диаграммы Состояний
На диаграмме Состояний отображают жизненный цикл одного объекта, начиная с момента его создания и заканчивая разрушением. С помощью таких диаграмм удобно моделировать динамику поведения класса. Как правило, диаграммы Состояний не требуется создавать для каждого класса.
Сложные классы имеют много различных состояний. В нашем примере заказ может находиться в состояниях: оформлен, выполнен, отменён. В каждом из состояний заказ ведет себя по-разному.
Для анализа динамики поведения класса необходимо рассмотреть его атрибуты. Экземпляр класса может вести себя по-разному в зависимости от их значений. Полезно исследовать также связи между классами. Рассмотрите все связи, множественность которых может принимать нулевое значение. Нули указывают, что данная связь не является обязательной. Ведет ли себя экземпляр класса по-разному при наличии и отсутствии связи? Если да, то он имеет несколько состояний.
В среде Rose на основании диаграмм Состояний не генерируется никакого исходного кода. Они нужны для того, чтобы документировать динамику поведения класса, благодаря чему аналитики и разработчики получат о нем четкое представление. Реализацией заложенной в эти диаграммы логики будут заниматься разработчики. Как и в случае других диаграмм UML, диаграммы Состояний дают команде возможность обсудить и документировать логику перед началом процесса кодирования.
Рис. 29. Диаграмма состояний для класса Заказ.
2.5.2.1. Создание диаграмм Состояний
В среде Rose можно создать одну диаграмму Состояний для класса. На ней отображаются все определенные для этого класса состояния и переходы. В браузере диаграмма Состояний располагается ниже класса.
2.5.2.1.1. Добавление состояний
Состоянием (state) называется одно из возможных условий, в которых может существовать объект. Как уже говорилось, для выявления состояний объекта необходимо исследовать две области модели: значения атрибутов объекта и связи с другими объектами. Рассмотрите различные значения, принимаемые атрибутами. Определите также состояние объекта в зависимости от того, существует некоторая связь или нет.
Находясь в конкретном состоянии, объект может выполнять определенные действия. Например, он может генерировать отчет, осуществлять некоторые вычисления или посылать событие другому объекту. В Rose информация такого типа добавляется к модели посредством окна спецификации состояния.
С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния.
Деятельностью (activity) называется поведение, реализуемое объектом, когда он находится в данном состоянии. Например, когда поручение находится в состоянии "Инициализация", пользователь вносит данные. Деятельность — это прерываемое поведение. Оно может выполняться до своего завершения, если объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние. Если деятельностей много, то их можно выделить в отдельную диаграмму. Деятельность изображают внутри самого состояния, ей должны предшествовать слово do (делать) и "/". Например: do/ заполнить все поля.
Входным действием (entry action) называется поведение, которое выполняется, когда объект переходит в данное состояние. Например, при переходе поручения в состояние "Инициализация" выполняется действие "Сгенерировать новый номер поручения", независимо от того, откуда объект переходит в это состояние. Таким образом, данное действие осуществляется не после того, как объект перешел в состояние, а скорее как часть этого перехода. В отличие от деятельности, входное действие рассматривается как непрерываемое.
Входное действие также показывают внутри состояния, ему предшествуют слово entry (вход) и "/". Например: entry/ Сгенерировать новый номер поручения.
Выходное действие (exit action) подобно входному. Однако оно осуществляется как составная часть процесса выхода из данного состояния. Как и входное, выходное действие является непрерываемым. Например: exit/ Сохранить информацию в БД
Поведение объекта во время деятельности, входных и выходных действий может включать в себя отправку события другому объекту. В этом случае описанию деятельности, входного или выходного действия предшествует знак "^". Соответствующая строка на диаграмме выглядит как:
Do/ ^Цель.Событие(Аргументы),
где Цель — это объект, получающий событие, Событие — посылаемое сообщение, а Аргументы являются параметрами посылаемого сообщения. В Rose все эти детали можно добавить к посылаемому событию.
Деятельность может также выполняться в результате получения объектом некоторого события.