Моделирование БП

Моделирование использования

22/04/2021 /

Значение моделирования использования.
При первом знакомстве с диаграммами использования в UML у разработчиков программного обеспечения, особенно у опытных разработчиков, часто возникает вопрос: зачем это нужно? При этом такого вопроса относительно других средств UML не возникает, поскольку ответ на него в большинстве случаев очевиден по аналогии. Действительно, рассмотрим несколько примеров типичных ассоциаций, возникающих у разработчиков при первом знакомстве с UML.
Диаграммы деятельности — это не что иное, как блок-схемы алгоритмов. Разработчик программ, особенно со стажем, прекрасно понимает назначение и границы применимости блок-схем.

Подходы к моделированию

  • Структурный подход : систем — подсистема — модули …(структура соответствует команде, а не задаче)
  • БД : схема= таблицы + связи (табельный номер — атрибут сотрудника)
  • ОО: словарь системы = классы (полнота и адекватность словаря)

    • Преимущества моделирования использования

  • Простые утверждения
  • Абстрагирование
  • Декларативное описание
  • Выявление границ

    • Элементы диаграмм использования

    Сущности:

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

  • ассоциация
  • обобщение
  • зависимости
      Действующее лицо — это множество логически взаимосвязанных ролей.
  • Стереотипный класс
  • Находятся ВНЕ проектируемой системы

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

  • Типичные случаи: пункты технического задания
  • Если техническое задание смутное, его можно (и нужно!) попробовать переписать фразами субъект — предикат — объект
    Отношения элементов диаграмм использования

    Ассоциация между действующим лицом и вариантом использования. Это самое важное отношение на диаграммах использования. Эта ассоциация показывает, что действующее лицо принимает некоторое участие в той последовательности событий и действий, которая обозначена вариантом использования.

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

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

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

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

    Применяется 2 стереотипных зависимости между вариантами использования: со стереотипом «include» и со стереотипом «extend». В обоих случаях речь идёт о том, что последовательность событий и действий, соответствующая одному варианту использования, подключается в качестве подпоследовательности в последовательность событий и действий, соответствующих другому варианту использования.

    Комбинация отношений обобщения и зависимости
    Можно провести зависимость только один раз от абстрактного варианта использования. За счёт обобщений, которые уже введены в модель, эта зависимость будет распространена на оба варианта использования.

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

    Модель использования:

  • внутренняя моделируемая система — варианты использования
  • внешнееокружение — действующие лица
  • связь между моделируемой системой и внешним окружением
    Если нужно отделить применяется графический комментарий — Границы системы

    Способы применения моделей использования

    Действующим лицом может быть любая сущность, находящаяся вне моделируемой части системы. В частности любые внешние программные или аппаратные средства.

    Реализация вариантов использования
    Реализация варианта использования — это описание всех или некоторых сценариев, составляющих вариант использования.

  • Метод описания — указание алгоритма
  • Способы описания алгоритмов см. далее
    Переход от анализа и постановки задачи к решению (проектированию)

    Реализация диаграммами деятельности (блок-схемами)
    Например, возможны три различных типа сценария при приеме сотрудника на работу. Может быть проведён успешный прием, который заканчивается тем, что мы вносим информацию в базу данных (1). Прием может не состояться по той причине, что у нас нет подходящей позиции в штатном расписании (2). Прием также может состояться, если кандидат отвергает все сделанные ему предложения (3).

    Усовершенствование реализации
    Процесс начинается с записи информации о принимаемом сотруднике. Даже если прием не состоится, то в базе данных будет зафиксировано, почему он не состоялся. Если кандидат подходит, но на данный момент приема штатное расписание составлено неудачно, нет вакантной позиции, на которую надо его принять, блок схема предусматривает посылку соответствующего сообщения. В отличие от данной блок-схемы первый вариант блок-схемы не отвечал формальному определению, не было значимого результата.

    Реализация диаграммами взаимодействия

  • Прямо ведут к объектной модели
  • Целостность проектируемой системы
  • Возможность автоматизированного построения прототипов
    НО

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

  • Дает заготовку для построения детальной объектной модели проектирования и объектно ориентированной реализации системы.

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

    Сравнение способов реализации вариантов использования

    Диаграммы деятельности

  • Псевдокод эквивалентен блок-схемам (с точностью до параллелизма)
  • Наглядно, но менее компактно
  • Почти не приближают к объектной модели

    Диаграммы взаимодействия

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

    • Один комментарий

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *