Ted*_*son 23
我正在回答问题的新版本,它将UML作为文档工具.我将尝试在UML中扮演一个通信工具的角色,因为它们是同一个.
背景: 这种观点源于我作为架构师的日常工作,必须设计数百个系统/软件,10,000小时+工作,并为系统组合维护一致的文档和实践.这意味着我必须多次处理文档质量,一致性和定义.
总结:还有什么？当然你可以讨论文档的级别,UML真的比阅读条件逻辑的代码更好吗？可能不是,但总的来说,如果问题空间足够大,则没有真正的替代方案.
如果UML不是别的,那就是文档和通信.由Martin Fowler撰写的"UML Distilled",几乎是UML书籍的事实标准,带有这种观点.如果我读得正确的话,Fowler认为UML主要用于通信,文档就是静态类.没有那么多低级规范和代码生成.
IBM,Borland,Microsoft和Eclipse通过大型复杂工具支持UML.许多其他较小或有针对性的供应商也提供UML工具.我不知道有更多接受/实施的图表/建模标准.
另外考虑替代方案,哪种图表符号更常见？为什么不使用大多数人都知道的.大多数学院/大学如果他们教授任何图表或建模使用UML.除了一些流程或条件逻辑图样式之外,没有太多其他内容,有详细记录和标准化.
大多数人都知道标准符号甚至更为重要.在大型项目中,您不能总是阅读代码,与编写代码的人交谈,或者向业务合作伙伴询问他们想要的内容.这是标准至关重要的地方.不一致的使用会引起混淆,如果允许人们以非正式的方式发明或添加符号,它确实会发生.此外,您不想创建文档,并且始终必须解释您的意思.
除非你有,否则永远不要发明,这是UML最有可能的选择.想想每次新人加入团队或公司时.什么是盒子的意思,箭头？这个箭头可以朝这个方向连接到这个三角形,它是什么意思？您基本上必须发明特定于域的语言/模型.因此,您需要一个培训演示,教程,示例,审查工作,安排培训课程,维护发明的文档方法等.当然,您可以切换出任务合作伙伴,或者雇用一个新人,然后您必须重新执行此操作.让人们专注于学习系统而不是你的文档方法,或者是否必须使它成为可转换的知识或技能,如UML.让专家专注于编码和设计,而不是发明文档/图表标准.
对于所有UML评论家来说, 我并不是生活在象牙塔或玻璃泡沫中,每天我都要使用数百种不同的文档方法,因为人们发明了它们,或者我正在研究下一个供应商的技术.UML 并不完美,但它是最常见的,足够好的,并且不是简单的可替换的.
有效的其他问题:
sho*_*osh 18
思考是设计软件的唯一可行方法.
UML有时被视为部分描述您想出的设计的可行方式.
Joh*_*ley 10
UML只是表示设计的标准符号,它不是一个过程或方法.
IMO,UML失去了很多形象,成为软件开发中唯一且永远最好的解决方案.虽然一开始的爱好者(有些人仍然认为)UML会解决设计问题,而且理想情况下应该用UML绘制一切.事实证明它并没有比任何其他类型的图表好多少.
IMO,UML现在被广泛认为是它实际上是:oo分析和设计所需的许多图表的标准.它确实是最常用的图表标准.周围有更多工具,更多人了解UML,然后知道任何其他图表样式.