Может ли диаграмма последовательности реально отразить вашу логику на той же глубине, что и код?

Question

Я все время пользуюсь диаграммами последовательности UML и знаком с нотацией UML2.

Но я только использую их, чтобы уловить суть того, что я намерен делать. Другими словами, диаграмма всегда существует на уровне абстракции над реальным кодом. Каждый раз, когда я использую их, чтобы попытаться описать точно , что я собираюсь сделать, я в конечном итоге использую столько горизонтального пространства и столько кадров alt / loop, что это не стоит усилий.

Так что это может быть теоретически возможно, но каждый ли кто-нибудь действительно использовал диаграмму с таким уровнем детализации? Если да, можете ли вы привести пример, пожалуйста?

Answer 1

У меня та же проблема, но когда я понимаю, что у меня низкий уровень, я перечитал это:

Вы должны использовать диаграммы последовательности когда вы хотите посмотреть на поведение из нескольких объектов в пределах одного использования дело. Диаграммы последовательности хороши в показывая сотрудничество между объекты; они не так хороши в точное определение поведения.

Если вы хотите посмотреть на поведение один объект во многих случаях использования, используйте диаграмму состояний . Если ты хочешь смотреть на поведение во многих использования случаи или много потоков, рассмотрим диаграмма активности .

Если вы хотите изучить несколько альтернативные взаимодействия быстро, вы может быть лучше с CRC картами , как это избегает много рисования и Стирание. Часто удобно иметь CRC карточная сессия для изучения дизайна альтернативы, а затем использовать последовательность диаграммы для захвата любых взаимодействий что вы хотите сослаться позже.

[ выдержка из Мартина Фаулера UML Distilled book ]

Answer 2

Это все относительно. Закон убывающей отдачи всегда применяется при построении диаграммы. Я думаю, что хорошо показать взаимодействие между объектами (objectA инициализирует objectB и вызывает для него метод foo). Но непрактично показывать внутреннюю часть функции. В связи с этим диаграмма последовательности нецелесообразна для захвата логики на той же глубине, что и код. Я бы поспорил за запутанную логику, вы бы хотели использовать блок-схему.

Answer 3

Я думаю, есть две проблемы для рассмотрения.

Будь бетоном

Диаграммы последовательности в лучшем случае, когда они используются для передачи одного конкретного сценария (например, варианта использования).

Когда вы используете их, чтобы изобразить более одного сценария, обычно, чтобы показать, что происходит на каждом возможном пути в сценарии использования, они очень быстро усложняются.

Поскольку исходный код в этом отношении подобен сценарию использования (т. Е. Общее описание вместо конкретного), диаграммы последовательности не очень подходят. Представьте себе расширение уровней x графа вызовов некоторого метода и отображение всей этой информации на одной диаграмме, включая все условия if & loop.

Вот почему «захват сущности», как вы ее выразили, так важен.

В идеале диаграмма последовательности помещается на одной странице формата A4 / Letter, все, что больше, делает диаграмму громоздкой. Возможно, как правило, ограничьте количество объектов 6-10, а количество звонков 10-25.

Фокус на общении

Диаграммы последовательности предназначены для выделения связи, а не внутренней обработки.

Они очень выразительны, когда речь идет об определении связи, которая происходит (участвующие стороны, асинхронная, синхронная, немедленная, задержка, сигнал, вызов и т. Д.), Но не когда речь идет о внутренней обработке (на самом деле только действия) 1019 *

Кроме того, хотя вы можете использовать переменные, это далеко не идеально. Объекты наверху - это, ну, объекты. Вы можете рассматривать их как переменные (то есть использовать их имена как переменные), но это просто не очень удобно.

Например, попробуйте изобразить обход связанного списка, где вам нужно следить за элементом и его предшественником с помощью диаграммы последовательности. Вы можете использовать два «переменных» объекта с именами «текущий» и «предыдущий» и добавить необходимые действия, чтобы сделать current = current.next и previous = current, но результат просто неловкий.

Answer 4

Ответ - нет - он захватывает его лучше, чем ваш исходный код! По крайней мере, в некоторых аспектах. Позвольте мне уточнить.

Вы, как и большинство программистов, включая меня, думаете в строках исходного кода. Но программный конечный продукт - назовем его Системой - это гораздо больше. Это существует только в сознании членов вашей команды. В лучших случаях он также существует на бумаге или в других документально оформленных формах.

Существует множество стандартных «представлений» для описания Системы. Как и диаграммы классов UML, диаграммы деятельности UML и т. Д. Каждая диаграмма показывает Систему с другой точки зрения. У вас есть статические представления, динамические представления, но в архитектурном / программном документе вам не нужно останавливаться на достигнутом. Вы можете представить нестандартные виды своими словами, например, представление о развертывании, представление о производительности, представление об удобстве использования, представление о корпоративных ценностях, представление о любимых вещах начальника и т. д. Каждое представление фиксирует и документирует определенные свойства Системы.

Очень важно понимать, что исходный код - это всего лишь одно представление. Но самое главное, потому что это необходимо для создания компьютерной программы. Но он не содержит всех данных вашей Системы, ни явно, ни неявно. (Например, общие данные между программными модулями, которые подключаются только через автономную активность пользователя. Нет трассировки в источнике). Это просто статичное представление, которое очень мало помогает понять ваши процессы, динамику выполнения вашей программы дыхания живого.

Классический пример шаблона Observer. Особенно, если он интенсивно используется, вы вряд ли поймете механизм системы из исходного кода. Вот почему вы используете диаграммы последовательности в этом случае. Он захватывает «динамическую логику» вашей системы намного лучше, чем ваш исходный код.

Но если вы имели в виду какую-то бизнес-логику в мельчайших деталях, вам лучше использовать простой текст / исходный код / ​​псевдокод и т. Д. Вам не нужно использовать диаграммы UML только потому, что они являются стандартом. Вы можете использовать моделирование использования без рисования диаграмм использования. Всегда выбирайте вид, который подходит вам и вашим целям.

Answer 5

Лично я использовал диаграммы последовательности только в качестве описания общего взаимодействия между различными объектами, то есть в качестве быстрого "эскиза временного взаимодействия". Когда я попытался углубиться, все быстро начало сбиваться с толку ...

Я обнаружил, что лучшим компромиссом является «упрощенная» диаграмма последовательности, за которой следует четкое, но подробное описание логики внизу.

Answer 6

U.M.L. Диаграммы являются ориентировочными, а не строго правилами.

Вам не нужно делать их точно и подробно, как в исходном коде , но вы можете попробовать, если хотите.

Иногда это возможно сделать, иногда невозможно из-за деталей или сложности систем, или у них нет времени или деталей для этого.

Приветствие.

P.D. Любой сыр-бургер или тунец-бургер для кошки?