- •Государственное образовательное учреждение высшего профессионального образования
- •Лабораторная работа № 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
- •Анализ предметной области и разработка концепции построения системы
- •Заказчики
Заказчики
Рис. 2 - Изображение внешней сущности на диаграмме
Поток данныхизображается линией с горизонтальными и вертикальными участками (или дугой), заканчивающейся стрелкой. Направление стрелки указывает направление потока. Вдоль стрелки проставляется содержательное имя потока. По существу, поток – это логическая структура данных , которыми обмениваются между собой основные компоненты контекстной диаграммы: подсистемы с подсистемами и внешние сущности с системой или подсистемами.
Поток управленияиспользуется для анализа систем реального времени и рассматривается в подразделе 2.6.
Информационный канал(рис.3) логически отображает на диаграмме среду передачи информации для пространственно распределенных АСОИУ. Он не производит никаких действий по обработке данных и просто передает логическую структуру данных на определенное расстояние без изменения ее содержания. Информационный канал может реализоваться в виде, например, почты, курьерской службы, магистрали или шины данных, канала сети Интернет и т.д.
Информационный канал именуется подлежащим с соответствующими определениями. Для уменьшения числа пересечений линий потоков данных на диаграмме может создаваться несколько копий одного и того же информационного канала.
Номер канала Поле имени Номер копии
Рис. 3 - Условное обозначение информационного канала
Контекстная диаграмма строится на основе предварительного анализа предметной области путем изучения естественных текстовых описаний, требований заказчика, условий работы пользователей, решающих рассматриваемые задачи своими способами, или на основе предположений о решении этих задач, если система будет реализована и запущена в эксплуатацию.
Обычно при проектировании или анализе относительно простых АСОИУ создается единственная контекстная диаграмма первого уровня с топологией звезды, в центре которой находится символ системы, соединенный с источниками и приемниками информации, посредством которых с АСОИУ обмениваются информацией пользователи и другие системы.
Для сложных систем такая контекстная диаграмма неприменима, так как будет содержать большое количество внешних сущностей, которые трудно и даже невозможно расположить на листе бумаги разумного формата. В этом случае АСОИУ разбивается на ряд подсистем, соединенных потоками данных. На рис. 4 приведен пример контекстной диаграммы, нарисованной в CASE.Аналитике. Директор, обращающийся с информационным запросом к АСОИУ о выполнении заказа, является внешним источником-приемником информации и изображается на диаграмме символом внешней сущности.
На верхнем уровне в контекстной диаграмме внешние сущности могут обобщаться (например, «руководство», «заказчики» и т. п.) и более детально показываться на контекстных диаграммах следующих уровней иерархии, раскрывающих структуру подсистем верхнего уровня. Индекс «ДПД» в поле номера системы на рис. 4 означает, что на следующем уровне иерархии АСОИУ детализируется диаграммой потоков данных. Если на следующем уровне детализация идет через контекстную диаграмму, то в этом поле проставляется индекс «КД». Других способов детализации системы/подсистемы не существует.