МОДЕЛИРОВАНИЕ НА UML Политехнический университет 2012

Оглавление слайдов Об этом курсе Введение в UML Моделирование использования (3-50) Моделирование структуры Моделирование поведения

МОДЕЛИРОВАНИЕ НА UML Моделирование использования

Содержание Значение моделирования использования Диаграммы использования Реализация вариантов использования Выводы

Значение моделирования использования Диаграммы деятельности = блок схемы Диаграммы состояний = конечные автоматы Диаграммы классов = диаграммы « сущность – связь » … и так далее Диаграммы использования =... ???

Подходы к моделированию Структурный подход : система – подсистемы – модули … Структура соответствует команде, а не задаче БД : схема = таблицы + связи Табельный номер – атрибут сотрудника OO: словарь системы = классы Полнота и адекватность словаря

Три направления разработки (1/2) Программирование сверху вниз = программирование без Go To методом пошагового уточнения Проектирование первично, реализация вторична Разбиение исходной задачи на очевидные подзадачи Программирование снизу вверх Уровень языка программирования повышается, пока исходная задача не станет очевидной Программирование вширь Начиная с самого первого шага, создается и на всех последующих шагах поддерживается работоспособная версия программы Требует дополнительных трудозатрат, но вызывает положительные эмоции! На практике всегда применяется их комбинация

Три направления разработки (2/2) Сверху внизСнизу вверхВширь

С. С. Лавров Лавров Святослав Сергеевич (1923– 2004) – член-корреспондент РАН, классик программирования Основоположник ракетно- космической баллистики в СССР Разработал первый отечественный транслятор Алгола Разработал программное обеспечение первых полетов человека в космос Ему принадлежит терминпрограммирование вширь

Схема базы данных Описание данных и взаимосвязей между ними

ОО подход : словарь предметной области ТерминКатегорияПояснение Клиент Внешняя сущностьКлиент банка Счет Постоянно хранимый объект Счет клиента в банке Остаток Атрибут Атрибут класса Счет, значение которого является текущей денежной суммой на счете Номер Атрибут Атрибут класса Счет, значение которого однозначно идентифицирует экземпляр класса Счет

Недостатки традиционных подходов Первый шаг выполняется в терминах проектируемой системы Только одна структура выбирается за основу : Структурное проектирование – структура кода Моделирование данных – структура хранения Объектно - ориентированный подход – структура взаимодействующих элементов

Преимущества моделирования использования Простые утверждения Субъекты, предикаты ( и объекты ) Абстрагирование от реализации ЧТО делает система ( но не КАК или ЗАЧЕМ ) Декларативное описание но не императивное нет возможности указать, какая функция « раньше », а какая « позже » Выявление границ но не черный ящик

Сквозной пример Моделирование информационной системы отдела кадров Предметная область знакома всем Типичное офисное приложение Авторам случалось проектировать на самом деле

Техническое задание Информационная система « Отдел кадров » ( сокращенно ИС ОК ) предназначена для ввода, хранения и обработки информации о сотрудниках и движении кадров. Система должна обеспечивать выполнение следующих основных функций. 1. Прием, перевод и увольнение сотрудников 2. Создание и ликвидация подразделений 3. Создание вакансий и сокращение должностей

Диаграммы использования ОЧЕНЬ простые идеи и нотация Применяется на ВСЕХ фазах ( анализ, …, тестирование ) Понимают ВСЕ ( разработчики, заказчики, управленцы ) одинаково НЕ зависит от остальных средств UML Изобретены Иваром Якобсоном в 1986 г. Не меняется Может использоваться отдельно

Элементы диаграмм использования Сущности : действующие лица варианты использования примечания Отношения : ассоциация обобщение зависимости

Почему actor = действующее лицо? Альтернативные варианты : актёр ( неточно ), актор ( нет такого слова ), актант ( есть, но никто не знает ) Пьеса Шекспира Гамлет – модель Фильм Козинцева – экземпляр модели Гамлет – действующее лицо пьесы Смоктуновский – актёр, играющий роль Гамлета в фильме Козинцева по пьесе Шекспира Худой человечек означает Гамлета, но не Смоктуновского !

Почему use case = вариант использования? Альтернативные варианты: сценарий (неточно), элемент Use Case (нет такого слова), прецедент (абсолютно неверно) Ивар Якобсон (швед) использовал термины usage case и usage scenario Американские пользователи упростили Английские юристы издавна использовали понятие Use Case (прецедент) – принятие судебного решения на основании другого судебного решения Вариант использования – это функция, но не прецедент!

Действующие лица и их идентификация Действующее лицо – это множество логически взаимосвязанных ролей Стереотипный класс Находятся ВНЕ проектируемой системы Роль в UML это контракт (сервисы), поддерживаемый данным классификатором в данной ассоциации Типовые случаи: категории пользователей, внешние программные и аппаратные средства Выделение категорий пользователей : пользователи участвуют в разных бизнес-процессах пользователи имеют различные права пользователи взаимодействуют с системой в разных режимах: от случая к случаю, регулярно, постоянно.

Действующие лица ИС ОК Менеджер персонала Работает с конкретными людьми Менеджер штатного расписания Работает с абстрактными должностями и подразделениями

Варианты использования Вариант использования – множество возможных последовательностей событий/действий (сценариев), приводящих к значимому для действующего лица результату Типичные случаи: пункты ТЗ Если ТЗ смутное, его можно (и нужно!) попробовать переписать фразами субъект – предикат – объект

Варианты использования ИС ОК Менеджер персонала выполняет действия Прием сотрудника Перевод сотрудника Увольнение сотрудника Менеджер штатного расписания выполняет действия Создание подразделения Ликвидация подразделения Создание вакансии (= должности ) Сокращение должности

Варианты использования ИС ОК

Примечания Важно и нужно ! Позволяют хранить ВСЮ информацию ( в т. ч. необрабатываемую и внешнюю ) Могут иметь стереотипы : «requirement» описывает общее требование к системе «responsibility» описывает ответственность сущности ( классификатора )

Отношения между элементами диаграммы использования Ассоциация между действующим лицом и вариантом использования Обобщение между действующими лицами Обобщение между вариантами использования Зависимость между вариантами использования

Ассоциации между действующими лицами и вариантами использования

Иерархия категорий пользователей ИС ОК (обобщение) (1/2) Среди всех пользователей информационной системы следует выделить особую категорию пользователей ( высшее руководство ), которой разрешен доступ к любым данным и операциям

Иерархия категорий пользователей ИС ОК (обобщение) (2/2)

Абстрактное действующее лицо (1/2) Информационная система должна предоставлять возможность просматривать данные без внесения в них каких - либо изменений

Абстрактное действующее лицо (2/2)

Обобщение вариантов использования (1/2) Информационная система должна предоставлять возможность просматривать данные без внесения в них каких - либо изменений

Обобщение вариантов использования (2/2)

Зависимости между вариантами использования

Комбинация отношений обобщения и зависимости

Границы системы Модель использования : внутренняя моделируемая система варианты использования внешнее окружение действующие лица связь между моделируемой системой и внешним окружением Если нужно отделить применяется графический комментарий – границы системы (subject)

Границы системы

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

Реализация вариантов использования Реализация варианта использования это описание всех или некоторых сценариев, составляющих вариант использования Метод описания указание алгоритма Текстовые сценарии Программы на псевдокоде Диаграммы деятельности Диаграммы взаимодействия Переход от анализа и постановки задачи к решению ( проектированию )

Текстовые описания Увольнение по собственному желанию 1. Сотрудник пишет заявление 2. Начальник подписывает заявление (а если нет?..) 3. Если есть неиспользованный отпуск, то бухгалтерия рассчитывает компенсацию 4. Бухгалтерия рассчитывает выходное пособие 5. Системный администратор удаляет учетную запись 6. Менеджер штатного расписания обновляет базу данных Минус: неточность, которая незаметна

Программы на псевдокоде Минус: не подлежит повторному использованию Use case Pay Compensation if (from Self Fire) начислить за неиспользованный отпуск else if (from Adm Fire) начислить выходное пособие Use case Self Fire Получить заявление add_payment: Pay Compensation (Self Fire, add_payment) Include Delete Account Обновить информацию в базе данных Use case Adm Fire Получить приказ add_payment: Pay Compensation (Adm Fire, add_payment) Include Delete Account Обновить информацию в базе данных

Реализация диаграммами деятельности

Усовершенствование реализации

Реализация диаграммами взаимодействия Прямо ведет к объектной модели Целостность проектируемой системы Возможность автоматизированного построения прототипов НО Позволяют реализовать только ОДИН сценарий – нужно МНОГО диаграмм Сложная и непривычная нотация

Диаграмма последовательности для типового сценария

необходимость включения еще одного класса Диаграмма коммуникации для исключительной ситуации

Сравнение способов реализации вариантов использования (1/2) Текстовые описания Всем понятно, привычно и удобно Длинно и неточно, пропуски и ошибки Есть трансляторы в варианты использования (!) Программы на псевдокоде Традиционное средство программистов Компактнее текстового описания Навязывают структуру реализации Не приближает к объектной модели

Сравнение способов реализации вариантов использования (2/2) Диаграммы деятельности Псевдокод эквивалентен блок - схемам ( с точностью до параллелизма ) Наглядно, но менее компактно Почти не приближают к объектной модели Диаграммы взаимодействия Сложная и непривычная нотация Диаграммы объектного уровня – описывают ОДИН сценарий – нужно МНОГО диаграмм Прямо ведут к объектной модели

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

Выводы Составление диаграмм использования первый шаг моделирования Основное назначение показать, что делает система во внешнем мире Не зависит от программной реализации системы ( от структуры классов, модулей и компонентов ) Идентификация действующих лиц и вариантов использования ключ к успеху Способ реализации дело вкуса