Скажите рассмотрение 6 основных типов диаграммы UML (от этого Элементы Стиля UML 2.0)
Притворитесь, что Вы безумны, и Вы испытываете желание составлять все 6 схем для своей системы.
С которого Вы запустили бы? Затем, в который Вы перешли бы? Что лучший порядок состоит в том, чтобы посетить каждую схему, если у Вас есть довольно четкое представление о том, что Вы хотите, чтобы Ваша система сделала?
Я думаю, что необходимо запустить с физической схемы и проложить себе путь к диаграмме классов. Вершина вниз, говорю я всегда..?Я неправ?
Варианты использования являются основными, которые определяют, «что» ваша система делает , возможно, за ними следуют конечные автоматы и диаграммы активности (что можно увидеть в любом случае - обычно диаграммы активности больше о «что», а конечные автоматы больше о «как», но я видел контрпримеры для каждого из них); диаграммы классов и последовательности, а тем более диаграммы компонентов и развертывания (в совокупности «физические»), все больше и больше посвящены тому, как ваша система делает то, что делает. Я определенно перейду от «что» к «как», поскольку обратная последовательность не имеет большого смысла - как может иметь смысл «как», если вы не определили «что»?
Итак, резюмируя, примерно : варианты использования, действие, конечный автомат, класс, последовательность, компонент, развертывание.Этот порядок имеет смысл, потому что он углубляется в аспекты реализации и уходит от аспектов анализа, например, кто-то, кто заинтересован в точном понимании того, какие варианты использования вы будете обслуживать и какие бизнес-правила вы будете применять (диаграммы действий), может перестать «читать» раньше, чем тот, кому необходимо понять полную подробную логику вашей стратегии развертывания.
Диаграммы UML - это изображения различных моделей дизайна. Я не уверен, что их можно чисто сериализовать так, как вы описываете. Часто диаграмма классов используется как на этапе анализа, так и на этапе разработки процесса. Аналогичным образом другие диаграммы используются в несколько этапов.
Это зависит от того, какой аспект дизайна вас интересует в любой момент времени, вы используете соответствующую диаграмму для «просмотра» модели дизайна.
Я видел предложения «начать с диаграммы классов» и «начать с модели варианта использования». Я пришел к выводу, что это не имеет значения.
Я думаю, вы хотите начать с высокоуровневого поведения системы, используя несколько диаграмм, а затем постепенно перейти к более детальному проектированию с использованием того же набора диаграмм.
Диаграммы классов, последовательностей и usecase составляют более 90% обычно создаваемых диаграмм в проекте. Сама диаграмма классов иногда представляет больше диаграмм, чем все остальные диаграммы.
Лучшее решение - сохранять простоту и адаптировать моделирование к уровню команды.
Если нет опыта работы с UML, то просто создайте диаграмму классов для представления скелета вашего приложения.
Если уровень начинающего, то начните с диаграмм usecase, последовательности и классов.
Если уровень средний, то используйте все диаграммы, потому что каждая диаграмма охватывает другое представление, которое не всегда возможно закодировать на Java. Я имею в виду, что java связана только с диаграммой классов и диаграммой последовательности.
Физическая диаграмма, вероятно, так же хорошее место для начала, как и любая другая. Я считаю, что диаграммы действий действительно полезны для устранения недостатков в дизайне, и последовательности хороши во многом по той же причине. Я редко возился с диаграммами конечных автоматов.
Я думаю, что на самом деле вам захочется пересмотреть любой дизайн, который вы делаете в первую очередь (повторный дизайн, у-у!), Поэтому, вероятно, стоит начать с того, что принесет максимальную ясность в ваш проект.