2010-08-13 4 views
2

Как классическая диаграмма фактически отличается от того, как просто смотреть на определение класса, когда все функции рухнули? Меня попросили написать некоторые и поняли, что все это просто .. прочитайте источник .. у него есть комментарии. В чем смысл диаграммы классов, как она отличается от даже незначительно прокомментированных определений, и что делает хорошую диаграмму классов лучше, чем другие?Диаграммы классов - сомнительно полезны?

Редактировать: Да, источник уже существует и делал это задолго до диаграмм классов.

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

+0

Ум, что это за классная диаграмма, о которой вы говорите? Те, с которыми я знаком в UML, определенно являются графическими по своему характеру, а не текстовыми: классы являются ящиками, а также существуют различные типы соединителей для отображения отношений между классами. Да, в них есть текст, но обычно это не главное в диаграммах, которые я написал. –

ответ

3

Если у вас есть один или два класса, это не делает различия. Если у вас сложная объектная модель, все меняется.

И, по крайней мере, для меня легко смотреть сначала на диаграмме, чтобы искать то, что я хочу, вместо того, чтобы смотреть на кучу исходных файлов. Также видя классы на картинке и их отношениях, вы помогаете понять идеи проекта.

0

Хорошая диаграмма классов четко показывает классы ответственности и ассоциации классов - на соответствующем уровне абстракции.

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

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

+0

Операции на белой доске легче изменить на начальной стадии проектирования, но если источник уже существует (как подразумевается в вопросе OP), тогда мне придется не согласиться. – nukefusion

+0

Инструмент для создания кругового поворота удобен здесь. :) – Mike

+0

segway! = Segue ... Кто-нибудь когда-либо использовал «segway» и «повсеместно» в предложении? :) –

0

Если источник уже существует, я думаю, что это старая пословица: «Картина говорит тысячу слов». Для кого-то, не знакомого с источником, диаграмма может помочь им быстрее выполнить общий дизайн, а затем прочитать источник, независимо от того, насколько хорошо документирован. Некоторые люди более визуальны, чем другие. Лично я предпочел бы источник. Как и многие вещи, это, вероятно, вопрос вкуса.

Edit:

Я думал, что определение схемы было то, что она является визуальный. Однако, если это всего лишь куча текста, то единственным моментом, который я вижу, является то, что он дает обзор намерений без лишних деталей реализации.

2

Я бы предпочел иметь источник. Учитывая это, я всегда могу его перестроить.

Вы должны спросить, для чего предназначен UML: это просто коммуникационное устройство, способ передать ваши идеи другим разработчикам. Если UML помогает, отлично. Если это станет еще одним бременем для поддержания, предпочитайте рабочий код с хорошими модульными тестами.

0

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

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

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

Они также помогают увидеть, когда и где следует использовать код рефакторинга. Используйте диаграммы классов вместе с соответствующей документацией, и все будет готово.

0

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

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

Вот один простой один я нашел с быстрым Google:

http://netbeans.org/images_www/articles/uml-class-diagram/Completed-Class-Diagram.gif

некоторых инструментов (Visual Studio от Microsoft является одним) содержит инструменты, позволяющие рисовать диаграммы классов один раз, и он автоматически поддерживал на сегодняшний день («синхронно») с кодом. Очень полезно.

Смежные вопросы