在大型项目中（假设有至少500,000行代码），你有没有使用UML? 你都使用UML做了什么？
------解决方案--------------------------------------------------------
呵呵，我曾经在两个项目中，接近全过程的使用了uml，不过，有一个是在代码导出后，我让弟兄们放弃了uml的后续使用。
这是因为那是一个工程项目，我们需要竞标，需要比对手更快的推出产品功能，而不是在前期做的更为完善减少后期的错误率。
------解决方案--------------------------------------------------------
呵呵，的确，国内能做到的人很少，尤其是后面的内容，应该是根本没有人能做到，大部分公司都是为了商业利益而在放卫星而已。
卫星放多了，就没有意义了，因为大家都知道那是卫星，不是汽车和自行车，我们实际上是看不到，也摸不到的，到底能有多少好处，的确不好让大家信服。
至少因为我做到了前面的部分，因为我自己在多个项目中的操作，同时，每一个操作我都亲自实施的，所以，我才会说，我能做到这些。
如果讨论维护方面的问题，我目前还不好说，因为此前的项目大都因为种种原因没有进入到这个阶段，或者进入这个阶段前我已经辞职走人了，所以，也只能从非实操的角度来看待。
个人认为，维护阶段如果能够很好的在前期使用模型，后面的工作量应该是可以减少的，因为维护中的修订和问题反馈，采用我曾经提出过的那两种模式来解决，过程比原来的过程要清晰不少，同时，还可以很大程度上避免因为人员流失而造成的风险。
因为最后交付出来的是模型+少量前期整理的文档，模型里面可以直接导出所有可直接编译并运行的代码，每一个变动，都可以从时序图根据实际变动情况进行逻辑上的分析然后在进行修改调整，这样的方式，比原来的代码+文档的方式是肯定要省力的，而且容易分析出来影响到的代码和模块数量，工作量统计也容易做到。
只是能够坚持到这一步的项目很少，毕竟工程项目，需要竞标的项目，都是需要赶时间加快进度的。
使用uml的全过程分析，前期投入时间会较多，到了后期，会节约时间，这一点是肯定的。
------解决方案--------------------------------------------------------
user case图，sequence图, Class图
现在已经是我们公司里开发必须的文档了，
根据需要有的时候还会使用activity图进行具体逻辑的描述。
不过其它的图就用的很少。
------解决方案--------------------------------------------------------
说到底还是盖狗窝和建摩天大楼的区别了。盖狗窝的程序员用不着这个，建摩天大楼的，这个就比较重要。
不过就是盖狗窝，也得量个尺寸比照着做吧，不然也太难看了。对于盖狗窝的程序员，这个有点大材小用，
浪费时间，而复杂点的，则有助于各方的理解，因为不是一个人去建，人多了，为了避免歧义，就得用
标准化的交流方法，不用图表示难道用代码？语言分两种：文字和图形，以图形表现力最强。所以在众人进行
交流的时候，画图最好，不然某此特征用文字表达费神费力。