Основы UML Victor Novikov Itransition training courses Стр.

Основы UML Victor Novikov Itransition training courses

Стр. 2 Что такое UML Unified Modeling Language. Язык моделирования, а не метод. Определяет нотацию и метамодель. Язык общения между разработчиками, системными аналитиками и заказчиками систем. Не определяет процесс и технологию разработки.

Стр. 3 Зачем нужен UML Спецификация, конструирование, визуализация и документирование. Посредством набора из нескольких наглядных видов модели позволяет создать интегральный образ сложной компьютерной системы. Позволяет интегрировать лучший практический опыт. (e.g. Design patterns). Повторное использование. Контроль сложности. Обеспечивает независимость от конкретных языков программирования, процессов разработки и CASE-средств. Позволяет расширения посредством профайлов.

Стр. 4 Общая схема взаимосвязей моделей и представлений сложной системы в процессе ООАП

Стр. 5 Анализ и проектирование Основная роль UML это анализ и дизайн (OOAD). Основные цели OOAD: Определение ключевых сценариев использования ПО для различных пользователей (групп пользователей) Определить набор действий посредством которых пользователь взаимодействует с системой. Определить поведение основных обьектов в системе.

Полезные практики: Избегайте избыточного дизайна с нуля. (Big Design Up Front or BDUF). Чтобы начать писать код не требуется наличие детального дизайна системы, но основа должна быть. Используйте итеративный процесс. При анализе use cases обращайте внимание на существительные и глаголы: первые помогут определить классы системы, вторые методы или события. Стр. 6 Анализ и проектирование

Стр. 7 OOA Цель: определить функциональные требования: Определить actors и uses cases. Создать use case модель. Описать основные события для успешных сценариев работы системы. Определить связи. Описать дополнительные/альтернативные сценарии. Выделить предположительные объекты. Отфильтровать список объектов (исключить одинаковые, неопределенные и.т.д.)

OOA Результат OOA: Концептуальная модель (conceptual model). Use cases. Диаграммы последовательностей системы (system sequence diagram). Описание GUI. Реляционная модель (relational model). В UML концептуальная модель может быть задана: Диаграммой классов, где классы определяют концепции. Ассоциациями, определяющими связи между концепциями. Типами ролей ассоциаций. Стр. 8

Стр. 9 Роли сотрудников (Сбор требований по RUP)

Стр. 10 Цель: определить объектную модель на основании результатов OOA. Перевод аналитического use case в use case уровня объектов. Определение Boundary (GUI), Control (классы передачи данных) и Entity классов (бизнес логика). Определение атрибутов. Определение диаграмм взаимодействия высокого уровня. Определение поведения и ответственности. Какие модули(классы) отвечают за конкретное поведение системы. Взаимосвязи. Добавление сценариев возможного поведения системы. OOD

Результат OOD – диаграммы классов и расширенные диаграммы последовательностей. Полезные практики: Используйте паттерны проектирования (Design patterns). Определите application framework (если возможно). Используйте готовые frameworks. Выделяйте reusable code. Стр. 11 OOD

Стр. 12 Основы процесса разработки Твердое ломается, гибкое торжествует. Допускайте изменения. Быстро, дешево, хорошо – выберите любые два. Итеративность.

Стр. 13 Фазы процесса разработки Бизнес-моделирование Анализ требований Разработка архитектуры Кодирование Тестирование Документирование Сопровождение

Стр. 14 Модели разработки Люди гораздо важнее любого процесса. Хорошая команда с хорошим процессом всегда превосходит хорошую комманду при отсутствии процесса. Работающее ПО лучше чем исчерпывающая документация. Реагирование на изменения лучше чем следование плану.

Визуальное представление системы в UML Стр. 15

Стр. 16 Структура UML

Пиктограммы и отношения Стр. 17 Пиктограммы Отношения

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

Стр. 19 Варианты использования (Use cases) Актер – некоторая роль, которую играет пользователь по отношению к системе. Один актер может выполнять несколько вариантов использования; у варианта использования может быть несколько актеров, которые его выполняют. Выделение актеров – первый шаг по определению uses cases. Актеры не обязательно люди. Внешние события – источник идентификации вариантов использования. Диаграммы сами по себе второстепенны. Текстовое описание первично.

Use cases Цели разработки вариантов использования: Определить общие границы и контекст моделируемой предметной области; Сформулировать общие требования к функциональному поведению проектируемой системы; Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей; Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. Примеры: Проверка состояния текущего счета клиента. Оформление заказа на покупку товара. Получение дополнительной информации о кредитоспособности клиента. Отображение графической формы на экране монитора. Стр. 20

Стр. 21 Примеры вариантов использования Actor, System, Use case

Стр. 22 Примеры вариантов использования Отношения между use cases: Include(uses), Extend, Generalization

Стр. 23 Диаграммы классов Описывает структуру системы, показывая её классы, их атрибуты и операторы, и также взаимосвязи этих классов. Взаимосвязи экземпляров (объектов классов): Связь. Ассоциация (5 видов) Классы рейс и самолёт связаны двунаправленной ассоциацией, а классы человек и кофейный автомат связаны однонаправленной. Агрегация - “has a” вариант ассоциации. Композиция - более строгий вариант “has a” ассоциации. Взаимосвязи классов: Обобщение - наследование или “is a” взаимосвязь. Реализация

Стр. 24 Диаграммы классов Не пытайтесь использовать сразу все доступные понятия Выбор точки зрения для построения модели должен соответствовать конкретному этапу работы над проектом: Концептуальная. Точка зрения спецификации. Точка зрения реализации. Концентрация на главных аспектах модели. Опасность увязнуть в деталях.

Стр. 25 Примеры диаграмм классов Паттерн command

Стр. 26 Примеры диаграмм классов Паттерн command

Стр. 27 Примеры диаграмм классов Паттерн Chain of responsibility

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

Стр. 29 Пример диаграммы последовательности Паттерн Command

Стр. 30 Пример диаграммы последовательности и кооперации Паттерн Chain of responsibility

Стр. 31 Пакеты и кооперации Пакет – блок классов более высокого уровня Идея пакета может быть применена не только к классам, но и любому другому элементу модели Зависимость пакетов = зависимость классов в этих пакетах Кооперация – взаимодействие двух и более классов Кооперация может быть применена для описания взаимодействия пакетов Кооперация может быть параметризованной Группировка пакетов: По стереотипу По функциональности

Стр. 32 Пример диаграммы пакетов

Стр. 33 Пакеты и кооперации Использование На больших проектах Когда диаграмма классов становится трудночитаемой Для unit тестов

Стр. 34 Диаграммы состояний Отражают все возможные состояния в которым может находится конкретный объект Показывают изменения состояния объекта, которые происходят в результате влияния некоторых событий на этот объект Как правило строится для класса

Стр. 35 Примеры диаграмм состояний

Стр. 36 Диаграммы деятельности Описывает последовательность деятельностей Позволяет отображать условное и параллельное состояния По сути то же самое что и диаграмма состояний, где каждое состояние есть действие Поведение описывается с помощью ветвлений и соединений Параллельное поведение изображается с помощью слияний и разделений

Стр. 37 Примеры диаграмм деятельности

Стр. 38 Физические диаграммы Диаграммы развертывания Отражает физические взаимосвязи между программными и аппаратными компонентами разрабатываемой системы Каждый узел представляет некоторый тип вычислительного устройства Диаграммы компонентов Показывает различные компоненты системы и зависимости между ними Компонент представляет собой физический модуль программного кода

Стр. 39 Примеры физических диаграмм. Диаграмма развертывания

P-Modeling Стр. 40

P-Modeling Безмолвные сессии моделирования (Speechless Modeling Sessions) Обратная семантическая трассировка (Reverse Semantic Traceability) Используется для: Проверки UML моделей; Проверки изменений в требованиях; Проверки исправлений ошибок в коде; Быстрой адаптации нового человека в команде; Стр. 41

Стр. 42 Достоинства и недостатки UML UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на ООП. UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы. Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом. UML расширяем и позволяет вводить собственные текстовые и графические стереотипы, что позволяет применять не только в сфере программной инженерии. UML получил широкое распространение и динамично развивается.

Критика: Избыточность языка. Неточная семантика. Проблемы при изучении и внедрении. Только код отражает код. Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Пытается быть всем для всех. Стр. 43

Книги и ссылки Краткое руководство по унифицированному языку моделирования. Мартин Фаулер и Кендал Скотт Язык UML. Руководство пользователя. Гради Буч, Джеймс Рамбо, Ивар Якобсон Для аналитиков: UML for the IT Business analyst: A Practical Guide to Object-Oriented Requirements. Howard Podeswa Ссылки: http://www.intuit.ru/department/pl/umlbasics http://ooad.asf.ru/standarts/UML/spr/ Стр. 44

Стр. 45 The end www.itransition.com