Вы начали с моделирования, что очень важно, особенно в области компьютерных наук - вы все время моделируете. Имейте в виду, что UML - это стандарт для нотации моделирования для программных систем, не более того (например, это не методология анализа или проектирования) и не менее (например, это не способ для разработчиков выглядеть продуктивно, рисуя глупости).
Вы на правильном пути, всегда помните, что на самом деле полезно и дает вам некоторую ценность. Это не совсем относится к вашему вопросу, но судебные иски не являются диаграммами прецедентов, их гораздо больше, они имеют письменную форму и могут помочь вам во многом из того, что вы описали в следующем курсе.
Что касается вас, то моделирование - это абстрагирование от неважных деталей, поэтому могут возникнуть некоторые неясности. Дело в том, что они должны быть не важны для целей моделирования. Например, на самом деле не имеет значения, включаете ли вы все свойства ваших классов, если хотите показать структуру дизайна, например, использование некоторого образца. Вы также можете использовать открытые свойства, не беспокоясь о себе, если они являются частными полями с методами получения и установки (Java), свойствами (C #) или сгенерированными объектными методами с использованием метапрограммирования (Ruby). То же самое относится и к сценариям, полученным с использованием сценариев использования - конечно, вы не можете (и не должны пытаться) захватывать альтернативные ветви с помощью UML, но вы можете описать условия в описаниях сценариев использования достаточно, чтобы избежать двусмысленности без необходимости сначала разрабатывать систему и впоследствии обнаружив, что это неправильно.
Что касается вещей вуду - проблема в том, что UML большой, и поэтому многие разработчики не знают, как правильно его использовать, и часто создают больше беспорядка, чем ценности. Не смущайтесь общим неуважением к UML, проблема заключается в поставщиках инструментов, комитетах и ленивых разработчиках ... За многими концепциями в UML стоят хорошо известные формальные модели, опирающиеся на академическую научную работу, например, диаграммы состояний взяты из диаграмм состояний Харела (http://linkinghub.elsevier.com/retrieve/pii/0167642387900359).) Так что, на мой взгляд, это не так уж и много, как вуду, в принципе, они просто перепроданы инструментами, не поддерживающими стандарт, а также стандарт пытается объединить все (это унифицированный язык. ..), но это медленно улучшается.
Моим советом для вас будет попытаться узнать, что важно - эти формализмы, методы анализа и проектирования, попробовать их на практике и решить для себя, что полезно. Если по какой-либо другой причине изучите UML, потому что это язык для анализа и проектирования, хотя он и большой, но он все же лучше, чем его ~ 50 предшественников вместе взятых:).