Диаграммы UML. Когда они используются?
Итак, я понимаю, что UML-диаграммы помогают в построении программы, но когда они используются? Они нужны прежде, чем вы начнете кодировать? они вам нужны, чтобы вы знали, что нужно кодировать? Или вы используете их после того, как запрограммировали программу?
7 ответов
До, во время и после.
Вы используете их для описания требований, предполагаемой архитектуры, разработки программного обеспечения, внедрения и развертывания.
Даже рабочие процедуры для использования программного обеспечения могут быть описаны в форме диаграммы UML.
Я склонен быть немного циничным в этом вопросе... и отвечаю, что диаграммы UML никогда не следует использовать.
UML-диаграмма обычно используется, когда вам приходится общаться с людьми, которые не совсем понимают программирование. Приятные графические рисунки делают их более удобными и удобными, но обычно такими же невежественными, как и раньше.
По моему опыту, UML - это большая потеря времени, и он занимает место других инструментов, более простых и более эффективных. Псевдокод так же легко читается, как диаграмма классов (проще для меня), и его гораздо проще набирать; вариант использования менее эффективен, чем хорошая история пользователя, как в Scrum или XP; и т. д. Все диаграммы надо поддерживать вместе с базой кода и документацией. и вы можете так же легко сделать ошибки проектирования, рисуя их, чем в противном случае (и в качестве бонуса, когда вы помещаете их в форму UML, ошибки проектирования станут намного сложнее обнаруживать и преодолевать, согласившись, что вы, вероятно, избегаете наиболее очевидных ошибок при рассмотрении вашего чертежа).
Я полагаю, что потратил много времени на рисование диаграмм UML, но я все еще ищу случай, когда они дали мне какую-то полезную выгоду.
Я возьму несколько другую точку зрения.
За исключением диаграмм последовательности, которые часто находятся на этапах архитектуры / проектирования, мы не используем UML в его строгом смысле. Я бы сказал, что это наиболее полезно в научных кругах, когда вы описываете что-то точное и теоретическое.
В каждодневной работе любые коробки и стрелки на листке бумаги будут обязательны. На самом деле хорошим правилом является то, что если вы не можете объяснить свой дизайн на одной бумаге, нарисовав его от руки, это слишком сложно.
UML-диаграммы - это просто обозначение, поэтому реальный вопрос в том, когда следует использовать моделирование как таковое. Есть много разных методологий с разными подходами и взглядами. Unified Process является одним из них, который является бесплатным и широко использует UML, из него вы можете узнать, как можно использовать диаграммы UML и как они могут быть полезны. Тем не менее, вы должны решить, какие методы хороши для вас. Я лично рассматриваю UML и моделирование как инструмент, который можно использовать в основном для генерации кода, поэтому эти модели фактически являются декларативными программами. Тем не менее, они также служат в качестве документации. С другой стороны, может быть сомнительно, являются ли они лучшим инструментом, используемым для требований и описания динамического поведения. Надеюсь, я поделюсь с вами некоторыми подсказками.
Я использовал их по-разному в разных проектах. Я видел диаграммы классов и последовательностей, используемые как артефакты времени разработки, которые становятся частью проектных документов, и я думаю, что они могут быть очень полезными в то время. Они могут помочь рассказать об отношениях между классами и о том, как они будут взаимодействовать. Я нахожу это полезным с первого взгляда и знаю, что такое интерфейсы и классы, какие расширяют / реализуют друг друга, особенно когда я посещаю обзор проекта для кого-то другого. Однако я обнаружил, что эти UML-диаграммы могут довольно быстро устареть, если разработчики не будут усердно следить за актуальностью своих документов по дизайну.
Тем не менее, мы интенсивно используем UML в моем текущем проекте, потому что мы используем инструмент генерации кода UML под названием AndroMDA. Он определенно имеет свои взлеты и падения, но мы используем его для генерации некоторых внутренних классов, интерфейсов, заглушек, файлов конфигурации гибернации и файла конфигурации Spring. Конфигурационные файлы hibernate и spring возможны, потому что вы добавляете дополнительные аннотации в UML. В любом случае, поскольку мы используем этот инструмент, каждый раз, когда мы вносим изменения во внутренний код, мы должны сначала начать с обновления нашего UML. Таким образом, это гарантирует, что наш UML всегда представляет то, что действительно происходит в нашем коде.
В своем опыте использования методологии DSDM для управления разработкой приложения для мобильных телефонов я использовал UML-диаграммы на этапе функционального прототипирования (до начала разработки).
Я обнаружил, что они дали мне более четкое понимание того, как должно выглядеть приложение, как с ним взаимодействуют люди и другие системы, и начали показывать мне, как должен быть структурирован код.
Например, диаграмма классов будет создана до того, как вы начнете разрабатывать приложение, поскольку она позволяет вам думать о том, какие классы и атрибуты вам могут понадобиться.
По моему опыту, они в основном используются до реализации, чтобы сообщить, как будет построен компонент. Они предоставляют людям возможность рассмотреть потенциальный дизайн в хорошем стандартизированном формате (обзор проекта). Они также могут дать общее представление о системе не-разработчикам, интересующимся системой (обзор функций). Я также видел, как они использовались после внедрения в качестве справочного пособия для новых разработчиков, которым необходимо узнать, как работает система.