На UML и доске

Question

Я пытаюсь создать правильный UML, когда у нас есть сеансы дизайна / доски, но моя попытка хорошо структурированного UML ВСЕГДА превращается в уродливый, но понятный для тех, кто в комнате -с-а-мало-объяснения. Но достаточно ли этого для непревзойденного инженера? Вы всегда производите хорошо структурированный UML на своих сессиях на доске? Что вы посоветуете для разработчика, который может и не подумать, что это важно, чтобы он не увидел это в книге шаблонов проектирования и не знал, что происходит.

Answer 1

Я никогда не использую UML в моих сессиях дизайна. Это всегда в свободной форме. Затем, в зависимости от проекта, мы возвращаемся назад и преобразуем его в гораздо более структурированный дизайн UML при создании «окончательных» спецификаций документов, из которых разработчики будут кодировать. По моему опыту, это сильно мешает проектным сессиям, чтобы сосредоточиться на правильной форме, особенно когда половина или больше людей в комнате не имеют представления о том, что означает любая из диаграмм.

Answer 2

Вы видите, что существует много споров о разработке программного обеспечения и о том, нужно нам это или нет, факт зависит от того, какую систему вы разрабатываете. Чем более двусмысленны требования к системе, тем больше вам нужны инструменты и методы SE!

UML помогает клиенту иметь изображение внутренней системы. Это когда у вас есть диаграммы вариантов использования. Это правда, что некоторые люди не понимают этого, но это очень легко объяснить, особенно диаграмму вариантов использования. Затем у вас есть диаграмма классов, которая поможет вам понять первые основные классы и пакеты, которые вам нужно разработать. Другие UML-биграммы не так важны.

Вот простой веб-сайт, который поможет вам создать классную диграмму и использовать регистрационную диграмму в считанные секунды:

http://yuml.me/

Я никогда не делал проект среднего / большого размера без использования этих двух диграмм

Answer 3

Ну, я действительно не думаю, что вам нужен строгий UML.

Насколько все понимают дизайн и признают его, все в порядке. Я предпочитаю гибкую методологию, чтобы иметь возможность создавать прототипы / тестировать проект на ходу и изменять «нестрогую» спецификацию, чем когда все решено и неприкосновенно с нуля.

В реальном мире вас ждут сюрпризы даже с самой тщательно спланированной спецификацией UML