Что диаграмма UML должна я использовать для функций простого приложения..?
Меня действительно смущают этим, судят для чтения много о схемах, но я просто не могу понять то, что наиболее подходит для этого случая.
Я должен только ПОКАЗАТЬ, что у меня есть 10 модулей, которые имеют 10 функций. Одна из той функции может назвать другую функцию модуля..
что-то вроде этого. очень простой. лучше только быть некоторыми блоками с depedencies [как функции] и как каждый блок модуля будет взаимодействовать с другим блоком
цель состоит в том, чтобы показать то, что система с открытым исходным кодом не имеет, и что эта система будет иметь после модификации. И конечно с цветами, легко отобразить все модификации.. чем его легче начать планировать проект и рассчитывать, на какое количество часы будут проведены на вещи, которые необходимо сделать..
4 ответа
Причина, по которой вы запутались, состоит в том, что создатели UML просто составили каталог своих диаграмм (дюжина типов) и никогда не говорят вам, когда использовать ту или иную.
Если вы говорите о функциях, это означает диаграммы вариантов использования. Вы можете увидеть здесь несколько примеров: http://askuml.com/blog/login-page-use-case-diagram/ или http://askuml.com/blog/e-commerce/
Действительно, как уже было сказано, UML не поддерживает напрямую то, что вам нужно. Насколько я понимаю, вы хотите фиксировать структуру (модули), поведение (функции) и взаимодействия (зависимости), хотя в базовой форме вы все же стремитесь захватить слишком много одновременно.
Итак, давайте рассмотрим ваши возможности с помощью UML, я надеюсь, это поможет вам решить:
Диаграмма пакетов может отображать структуру и зависимости в виде пакетов и импорта
Диаграмма компонентов может отображать структуру и зависимости как компоненты с соединителями
Диаграмма составной структуры позволяет изобразить сложную структуру и взаимодействия посредством составных частей, портов, соединителей и взаимодействий.
Диаграмма вариантов использования содержит участников, взаимодействующих с системой для выполнения вариантов использования, которые могут быть объединены с диаграммой пакетов, чтобы просто разложить систему на различные модули, которые предоставляют различные функции - варианты использования и для изображения взаимодействий, вы можете связать участников с вариантами использования.
Итак, как вы догадались, я выберу диаграмму вариантов использования с диаграммой пакетов. Они довольно простые, содержат небольшое количество шума, что может быть необходимо в вашем простом случае. Эта комбинация позволяет реализовать большую часть того, что вам нужно, однако, чтобы показать, что модули взаимодействуют определенным образом, вам понадобится модуль как в виде пакета, так и в качестве исполнителя, что не является хорошей практикой. Но, судя по тому, что вы говорите, я предполагаю, что вы хотите рекламировать изменение существующей системы, которое будет хорошо смотреться на этих диаграммах и будет легко объяснено клиентам, которые ничего не знают о UML. Вы можете подумать об удалении взаимодействия между модулями и отображении только функций, предоставляемых пользователям (обозначенных как субъекты).
Как насчет Package diagram или Component diagram?
Я думаю, что для вашего конкретного случая Package diagram вполне подойдет.