Примеры моделей доменов, которые большинство людей не понимают. Использование: создание требований
Я ищу модели предметной области, в которых большинство людей не очень хорошо знают или понимают. Я выбрал один домен, полис медицинского страхования, и я предъявляю требования (истории пользователей) для этого домена. Позже я проведу некоторое тестирование с пользователями для изучения понимания предметной области. Это идеальный пример, и я ищу больше таких: http://www.uml-diagrams.org/examples/health-insurance-policy-domain-diagram-example.html
Так как у меня ограниченные знания в области доменов, я считаю UML-представление и описание очень полезными. Чтобы иметь возможность создавать некоторые требования, мне нужно понять домен, по крайней мере, некоторые из них.
Вот и все, я надеюсь, что кто-нибудь получит какой-то вклад, я буду искать в Интернете.
1 ответ
UML не дает диаграмму для задачи. Он имеет диаграммы, которые можно использовать для абстрактного представления многих задач. Доменное моделирование является одним из них.
Диаграмма, показывающая, как люди работают с моделью предметной области, является диаграммой вариантов использования. У вас есть действующие лица - люди - люди-палки, системы и подсистемы (ИТ-системы и организации) - блоки, варианты использования - действия - овалы. Более формальные поведенческие диаграммы - State machine и Диаграммы Деятельности. Но подумай о них позже.
Если вы хотите установить структурную модель, ни одна диаграмма не будет лучше классовой. Но это слишком формально, и если вы не знаете, как его использовать, к нему трудно привыкнуть. Начните со следующего:
Более распространенная структурная модель - схема компонентов. Там вы показываете компоненты, их зависимости, их обмен информацией, какой компонент является элементом другого, контейнерный компонент, какой компонент является родительским (более распространенный случай) другого. Конечно, это покроет все ваши потребности сейчас. Что лучше для вас, из-за его не полной формальности, он может показать не только структуру, но и элементы поведения. Позже, если вы хотите больше абстрактности, формальности и точности, попробуйте диаграмму классов.
То, что вы видели по упомянутой ссылке, не является эффективной диаграммой классов. Это только формально. Кровь диаграммы классов - это ассоциации, и их всего две. Это пример использования диаграммы классов для отображения иерархии. Но вы можете показать иерархию на ЛЮБОЙ UML-диаграмме. Зачем использовать самый сложный?
Если вам нужна задача моделирования диаграмм классов, посмотрите, как это можно сделать:
Моя модель для структуры руководства пользователя:
