Я нахожусь в одной лодке и все еще пытаюсь продать своих сверстников на Enterprise Architect, инструменте CASE. Это инструмент для кругового путешествия - код для диаграмм для кода - возможно. Это тоже UML-ориентированный, хотя он также поддерживает другие методы обозначения, которые я незнакомы с ...
Вот некоторые вопросы, которые следует учитывать при выборе инструмента для документирования проектов (будь то межсистемная связь или просто проектирование внутренних компонентов одного приложения):
Удобство использования инструмента. То есть, насколько просто не только создавать, но и поддерживать интересующие вас данные.
Знакомство с обозначениями.
A. Обозначения, такие как UML, должны соответствовать вашим сотрудникам. Если вы попробуете использовать UML-инструмент, когда несколько человек понимают, как правильно его использовать, вы получите большой шар путаницы, так как некоторые люди неправильно документируют вещи, а кто-то понимает, что говорит UML, чтобы реализовать либо помечать ошибку, либо идти вперед и реализует ошибочно документированный элемент. И наоборот, более сложные нотации, используемые адептом, будут смешивать непосвященных.
B. Документация не должна/не должна создаваться только для эксклюзивных авторов. Поэтому те, кто будет читать документацию, должны понимать, что они читают. Поэтому получение инструмента с гибкими параметрами вывода всегда является хорошим выбором.
Стоимость. Есть гораздо более сложные инструменты, чем Enterprise Architect. Мое рассуждение об использовании этого одного инструмента заключается в том, что из-за отсутствия привычки UML и графиков высокого давления, у вас мало места, чтобы обучать себя или моих сверстников, не используя базовые структурные диаграммы. Этот инструмент легко облегчает такое использование и является более стабильным, чем StarUML. (Я пробовал оба, StarUML умер от обратной инженерии в массах кода - миллионы строк). Для небольших проектов я нашел StarUML достаточным для домашнего использования, пока не установил вист. Будучи open source, он также бесплатный.
При всем том вы всегда должны будете документировать, что использует то, что означает поддержание документации! Эта задача - это несколько компаний, которые видят ценность, несмотря на ее очевидную ценность для тех, кто это делает. , ,
+1: отличный совет! Но я не уверен, что эта программа - это то, что я ищу. Может быть, потому что это похоже на очень подробное приложение. – Tommy
Инструменты CASE многословны, но вам не нужно использовать все грани. Ведение документации часто игнорируется во многих компаниях. В конце концов, это балансирующий акт для усилий, связанных с выплатой. Вопрос: спросите себя: если ** Особенность X ** не имела «полной» проектной документации, кто-нибудь новый понимает ее достаточно хорошо, чтобы не сломать ее через три года? Если да, то это «относительно безопасно», чтобы сэкономить на нем, а не опустить его. * Значение ** вы правы **, и вы можете сэкономить дополнительное наращивание, когда требуется техническое обслуживание. * –
Я надеялся на несколько альтернатив, но это был единственный – Tommy