第七章 现实中的软件工程 第八章 是思考还是思想
作为大的软件公司，不能只是关注与软件的开发工具，更应该完善公司的理论体系和实作工具，为了与行业的巨头相抗争，就该把握住自身拥有的一切力量，这甚至比创造力量来的更快。想要打压对手发展自己，也需要记住，敌人的敌人就是朋友，借助其他对手和同盟的力量来削弱自己的劣势或者补充实力也不失为一种好的方法。为什么大公司会在标准、理论、语言上踱来踱去呢？其实未必出于“软件实现”的考虑，对同一理论、统一工具、统一过程的企图最终的目的还是在整个软件工程体系中的全面胜出。
软件工程体系的发展是由两方面推动的，一是软件的本质力量，二就是商业因素的推动。商业因素的推动把软件工程从原始的“自生演进”状态，逐渐推进到“它激发展”的状态上了。虽然它激发展可能会影响到软件工程发展的速度， 然而在各个工程层面上的关注点并不会发生变化。从软件工程层状模型中可以看到，在“程序”与“方法”层面，是关注于“(具体的)实现”的；而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为； 而项目经理则保障团队的稳定性和一致性。审视MDA/MDD MDA讨论的是“创建出机器可读和高度抽象模型”的方法。受MDA影响的开发活动被称为MDDMDA架构作为一个新的软件开发方法的架构，如果没有成熟的软件理论支持，那么它在工程中的实用价值就有限。
软件工程三个要素的价值
三要素：工具、方法与过程，工程的整体问题仍旧是“实现”。其实RUP是一个杂物箱
RUP能够包容全部的已知理论，而RUP能不能被利用起来，取决于辨识能力和组织能力。
UML与甲骨文之间的异同。一方面UML的规范中没有提供一个标准来衡量“怎样的UML图是描述充分的”；另一方面，UML作为一个语言，也无法直接在某个硬件平台中被语法检错和调试。所以在工程中使用UML图应该有相应的文字来描述他。枝节与细节，枝节是事实发展的次要的分枝，它不涉及行为本身，也不是对行为本身的考量。细节只有做到何种程度的问题，而不并是关不关注(或做不做)的问题。矛盾：实现目标与保障质量。 在项目实施过程中，需要平衡时间、资源和功能（平衡三角）。其讨论的是目标问题，并没有讨论质量问题。于是项目实施过程中实现目标与保障质量是矛盾的。
但是，毕竟语言只是工具，是连接你与计算机之间的桥梁，所以其并没有好坏之分，有的只是适用范围的区别。矛盾是无处不在的，开发中也是如此。实现目标与保障质量之间的矛盾是不可避免的，时间、资源和功能永远是软件开发过程中的矛盾根源，无论在什么时候，这三者都是很难调和的问题。如果有一个好的项目经理，可能会减少矛盾的发生。其实软件开发并不是一成不变的死板的工程，有的细枝末节的问题是可以忽略的，灵活的忽略一些不重要的问题，不会影响软件的质量，相反，还会加快开发的速度，为自己赢得更好的机会。
未蕴而变，自欺也。知律而变，智者之道也