ГЛАВА 4 Диаграмма вариантов использования (use case diagram)
ГЛАВА 4 Диаграмма вариантов использования (use case diagram)
Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы вариантов использования преследует цели:
• Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
• Сформулировать общие требования к функциональному поведению проектируемой системы.
• Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
• Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.
Примечание 35
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами. При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.
Как было отмечено в главе 3, рациональный унифицированный процесс разработки модели сложной системы представляет собой разбиение ее на составные части с минимумом взаимных связей на основе выделения пакетов. В самом языке UML пакет Варианты использования является подпакетом пакета Элементы поведения. Последний специфицирует понятия, при помощи которых определяют функциональность моделируемых систем. Элементы пакета вариантов использования являются первичными по отношению к тем, с помощью которых могут быть описаны сущности, такие как системы и подсистемы. Однако внутренняя структура этих сущностей никак не описывается. Базовые элементы этого пакета – вариант использования и актер. С этих понятий мы и приступим к изучению диаграмм вариантов использования.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
4.5. Отношения на диаграмме вариантов использования
4.5. Отношения на диаграмме вариантов использования Между компонентами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и
4.6. Пример построения диаграммы вариантов использования
4.6. Пример построения диаграммы вариантов использования В качестве примера рассмотрим процесс моделирования системы продажи товаров по каталогу, которая может быть использована при создании соответствующих информационных систем.В качестве актеров данной системы
4.7. Рекомендации по разработке диаграмм вариантов использования
4.7. Рекомендации по разработке диаграмм вариантов использования Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе с помощью понятий соответствующего пакета и возможности согласования полученной
ГЛАВА 5 Диаграмма классов (class diagram)
ГЛАВА 5 Диаграмма классов (class diagram) Центральное место в ООАП занимает разработка логической модели системы в виде диаграммы классов. Нотация классов в языке UML проста и интуитивно понятна всем, кто когда-либо имел опыт работы с CASE-инструментариями. Схожая нотация
ГЛАВА 6 Диаграмма состояний (statechart diagram)
ГЛАВА 6 Диаграмма состояний (statechart diagram) Рассмотренная выше диаграмма классов представляет собой логическую модель статического представления моделируемой системы. Речь идет о том, что на данной диаграмме изображаются только взаимосвязи структурного характера, не
ГЛАВА 7 Диаграмма деятельности (activity diagram)
ГЛАВА 7 Диаграмма деятельности (activity diagram) При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации
ГЛАВА 9 Диаграмма кооперации (collaboration diagram)
ГЛАВА 9 Диаграмма кооперации (collaboration diagram) Как отмечалось в предыдущей главе, особенности взаимодействия элементов моделируемой системы могут быть представлены на диаграммах последовательности и кооперации. Если первая служит для визуализации временных аспектов
ГЛАВА 10 Диаграмма компонентов (component diagram)
ГЛАВА 10 Диаграмма компонентов (component diagram) Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления. Особенность логического представления заключается в том, что оно оперирует
ГЛАВА 11 Диаграмма развертывания (deployment diagram)
ГЛАВА 11 Диаграмма развертывания (deployment diagram) Физическое представление программной системы не может быть полным, если отсутствует информация о том, на какой платформе и на каких вычислительных средствах она реализована. Конечно, если разрабатывается простая программа,
ГЛАВА 12 Особенности реализации языка UML в CASE-инструментарии Rational Rose 98/2000
ГЛАВА 12 Особенности реализации языка UML в CASE-инструментарии Rational Rose 98/2000 Появление на рынке программных продуктов первых CASE-средств (Computer Aided Software Engineering) ознаменовало новый этап развития программной инженерии, характерными особенностями которого являются существенное
12.4. Разработка диаграммы вариантов использования в среде Rational Rose
12.4. Разработка диаграммы вариантов использования в среде Rational Rose Работа над проектом в среде Rational Rose начинается с общего анализа проблемы и построения диаграммы вариантов использования, который отражает функциональное назначение проектируемой программной системы.
ГЛАВА 7: ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ СИСТЕМ
ГЛАВА 7: ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ СИСТЕМ Далее я привожу лучшие, на мой взгляд, системы, которые наиболее полно отражают системный подход к управлению делами.СИСТЕМА БЛОГГЕРА ДАРРЕНА КРОУФОРДАЯ искал несколько дней простой способ интегрировать Evernote с моей системой GTD. Я
Автоматизируй это: 8 простых вариантов использования IFTTT Олег Нечай
Автоматизируй это: 8 простых вариантов использования IFTTT Олег Нечай Опубликовано 13 января 2014 Аббревиатура IFTTT расшифровывается как «If this, than that», то есть «Если это, тогда то», и именно так и действует эта служба, автоматизирующая выполнение
Глава 10 CASE-СРЕДСТВА И ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ
Глава 10 CASE-СРЕДСТВА И ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ 10.1. ПРЕДПОСЫЛКИ ПОЯВЛЕНИЯ CASE-СРЕДСТВ Тенденции развития современных информационных технологий приводят к постоянному усложнению автоматизированных систем (АС). Для борьбы со сложностью проектов в настоящее время созданы