- •Государственное образовательное учреждение высшего профессионального образования
- •Лабораторная работа № 1 Построение модели вариантов использования
- •Заказчик
- •Упражнение 1 . Создание диаграммы вариантов использования
- •Этапы выполнения упражнения
- •Создать действующие лица (актанты), варианты использования и определить отношения между ними.
- •Добавить ассоциации
- •Добавить расширения
- •Добавить включения
- •Указать абстрактные варианты использования
- •Вид диаграммы вариантов использования Main показан на рисунке 1. Добавить описания к действующим лицам (актантам)
- •Бухгалтер: "Вводит и редактирует данные об оплате счетов или о возврате оплаты при аннулировании клиентом просроченного заказа";
- •Добавить описания к вариантам использования
- •Создать файлы сценариев и прикрепить их к вариантам использования
- •Лабораторная работа № 2 Построение модели анализа
- •Поставщик
- •Окно программы
- •Заголовок
- •Подклассы
- •Геометрическая фигура
- •Подклассы
- •Упражнение 2. Создание структуры модели анализа, пакетов реализаций, диаграмм трассировок и классов реализаций
- •Этапы выполнения упражнения
- •Создать кооперации и осуществить трассировку реализаций
- •Создать диаграммы классов анализа для реализации вариантов использования
- •Упражнение 3 . Создание диаграмм взаимодействия
- •Создание диаграмм Взаимодействия
- •Этапы выполнения упражнения
- •Добавление на диаграмму дополнительных объектов
- •Назначение ответственностей объектам
- •Соотнесение объектов с классами
- •Соотнесение сообщений с операциями
- •Создание Кооперативной диаграммы
- •Добавление действующего лица и объектов на диаграмму
- •Добавление сообщений на диаграмму
- •Добавление на диаграмму дополнительных объектов
- •Назначение ответственностей объектам
- •Соотнесение объектов с классами (если при разработке описанной выше диаграммы Последовательности сами классы вы уже создали)
- •Соотнесение объектов с классами (если вы не создавали описанную выше диаграмму Последовательности)
- •Соотнесение сообщений с операциями (если при разработке описанной выше диаграммы Последовательности сами операции вы уже создали)
- •Соотнесение сообщений с операциями (если вы не создавали описанную выше диаграмму Последовательности)
- •Упражнение 3 . Создание диаграмм классов
- •Создание диаграммы Классов
- •Этапы выполнения упражнения Настройка
- •Создание пакетов
- •Создание Главной диаграммы Классов
- •Создание диаграммы Классов для сценария "Ввести новый заказ" со всеми классами.
- •Добавление стереотипов к классам
- •Объединение классов в пакеты
- •Добавление диаграмм Классов к каждому пакету
- •Упражнение 4 . Создание диаграмм классов (учет новых требований)
- •Добавление атрибутов и операций
- •Этапы выполнения упражнения Настройка
- •Добавление нового класса
- •Добавление атрибутов
- •Добавление операций к классу OrderItem
- •Подробное описание операций с помощью диаграммы Классов
- •Подробное описание операций с помощью броузера
- •Подробное описание операций с помощью любого из описанных методов
- •Упражнение 5 . Создание диаграмм классов (добавление связей между классами)
- •Добавление связей
- •Этапы выполнения упражнения Настройка
- •Добавление ассоциаций
- •Упражнение 6 . Создание диаграммы состояний
- •Подробное описание состояний
- •Добавление переходов
- •Подробное описание переходов
- •Упражнение 7 . Создание диаграммы компонентов
- •Этапы выполнения упражнения
- •Создание диаграммы Компонентов системы
- •Размещение компонентов на диаграмме Компонентов системы
- •Добавление оставшихся зависимостей на диаграмму Компонентов системы
- •Соотнесение классов с компонентами
- •Упражнение 8 . Создание диаграммы размещения
- •Создание диаграммы Размещения
- •Этапы выполнения упражнения Добавление узлов к диаграмме Размещения
- •Добавление связей
- •Добавление процессов
- •Показ процессов на диаграмме
- •Этапы выполнения упражнения Ввод тел пакетов на диаграмму Компонентов системы
- •1 . Основы методологии объектно-ориентированного
- •1.1 Методология объектно-ориентированного программирования
- •1.4. Этапы создания аис с использованием uml. Унифицированный процесс разработки программного обеспечения
- •Компоненты языка uml
- •Концептуальный уровень. Модель вариантов использования
- •Заказчик
- •Множество ассоциаций - агрегация
- •Бинарная ассоциация
- •Ас «Продажа товаров по каталогу»
- •Ас тепличного хозяйства
- •Класс в
- •Сотрудник
- •Работает в
- •Лекция №9
- •Лекция № 10 отношение реализации (Realization relationship)
- •Объекты (objects)
- •Шаблоны (параметризованные классы)
- •Рекомендации по построению диаграмм классов
- •Фрагмент диаграммы классов для Асу тепличного хозяйства
- •1.8. Диаграмма состояний
- •Обязательные условия для конечного автомата:
- •Лекция №12
- •Анализ предметной области и разработка концепции построения системы
- •Заказчики
Рекомендации по построению диаграмм классов
Диаграмма классов во многом определяет реализации системы. На концептуальном уровне следует использовать русские имена. На логическом уровне и физическом уровнях осуществляется переход на английские имена с использованием рекомендаций по транскрипции и трансляции русских букв латинскими буквами (Ц – ts, Ж – zh, Ы – Y и т.д.).
Примеры диаграмм классов:
Фрагмент диаграммы классов для Асу тепличного хозяйства
Перевод диаграммы классов на логический и далее – физический уровень приблизит стадию автоматизированного кодирования. Однако полностью автоматизировать этот процесс пока не удаётся из-за некоторой неоднозначности и неопределённости описания модели и возможности различных методов реализации.
1.8. Диаграмма состояний
Диаграмма состояний (statechart diagram)– диаграмма, на которой изображается конечный автомат с простыми состояниями, переходами вложенными композитными состояниями.
Концепция диаграммы состояний разработана Дэвидом Хэрелом (David Harel).
В отличие от статического представления диаграмма состояний является детализацией диаграммы вариантов использования, на логическом уровне она описывает поведение объектов системы и системы в целом.
Поскольку речь идёт о состояниях объектов – экземпляров классов, то предварительно должны быть определены классы объектов на логическом уровне, т.е. должна быть построена диаграмма классов.
В основе диаграммы лежит понятие конечного автомата (state machine).
Конечный автомат– это спецификация последовательности состояния, через который в течение своей жизни проходит объект, в том числе взаимодействуя с другими объектами и находясь под воздействием некоторого потока событий. Конечный автомат всегда связан или определён для некоторого исходного элемента модели (объекта класса, метода или диаграмма кооперации).
Состояния, в которых может находиться элемент, образует пространство состояний, обычно оно считается конечным (конечный автомат).
Графически автомат может быть описан графом, в котором вершинами является состояние, а дугами – возможные переходы.
Простейший пример: техническое устройство, которое может быть в двух состояниях: исправно/неисправно.
Состояния изображаются прямоугольником с закруглёнными углами, у него может быть один или несколько необязательных разделов.
Обычно состояния имеют уникальные имена, если имени нет, то состояния называются анонимными. Чтобы не было путаницы, на диаграмме не рекомендуется одно и то же состояния изображать дважды.
Состояния понимаем как условия или ситуация в жизненном цикле объекта, когда объект выполняет какую-либо деятельность, либо ожидает какие-либо события.
Считается, что в определённом состоянии объект может находиться конечное время. Каждый конечный автомат описывает поведение какого-либо класса. Каждый класс может иметь конечный автомат.
Переход (transition)– реакция объекта на некоторые событие. Объект выполняет действие, прикреплённое к переходу, и меняет своё состояние. Каждому состоянию соответствует своё множество переходов.
Изменения состояния является атомарным действием, которое нельзя прервать извне. Обычно время перехода считается нулевым(если оно не оговорено отдельно), т.е. переходы осуществляются мгновенно.
Поведение объекта определяется как последовательная переменная по графу состояний от вершины к вершине по дугам.
Из всей совокупности состояний выделяются два особых: начальное состояние и конечное.
Последовательность изменений состояний упорядочена во времени. Хотя в явном виде время может не указываться.
Каждое состояние должно быть достижимо, т.е. существовать ориентированный путь в графе от начального состояния к нему.
Автоматы могут вкладываться друг в друга, в связи с этим состояния могут содержать в себе другие состояния. Макросостояния изображаются большим прямоугольником, содержащим в себе другие состояния.
Дополнительные автоматы называются подавтоматами(submachines).
Пример: неисправность может быть подразделена на более детальные подсостояния.