淘宝做网站,哈尔滨网站建设方案外包,南京seo网站优化,小型企业网站开发现状1.定义 UML-Unified Modeling Language 统一建模语言#xff0c;又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。
2.UML的三个级别 《UML精粹》一书中把这三个级别称为概念级、规格说明级和实现级。
2.1 概念级 概念级的图示和源代码之间没有很强的关联。…1.定义 UML-Unified Modeling Language 统一建模语言又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。
2.UML的三个级别 《UML精粹》一书中把这三个级别称为概念级、规格说明级和实现级。
2.1 概念级 概念级的图示和源代码之间没有很强的关联。它们更多是和人的语言相关的。概念级的图示可以作为一种速记方法用于描绘存在于人类问题领域中的概念和抽象。因此它们不必遵循强的语义规则其含义可以是模糊的通过解释来确定。
2.2 规格说明级 规格说明级的图示与源代码之间有很强的关联。实际上规格说明级图示的目的就是要能够转换成源代码。
2.3 实现级 实现级图示是要描绘已有的源代码。 其中规格说明级和实现级这两个级别的图示必须得遵循某些规则和语义。这样的图示非常明确并且有着大量的规范。
3.软件模型 模型需要具备两个特点即可测试可评估。如果模型不具备这两个特点那它便没有存在的意义。为什么要建模型?那你可以联想一下航天工程师为何不直接造飞机然后试飞呢结构工程师为何不是直接建大桥然后看看它是否能够不倒答案很简单飞机和桥梁比模型造价高多了。当模型比构建的真实实体便宜很多时我们就会用模型来研究设计。这个观点在软件的建模上同样适用。 接下来我们思考两个问题UML图是可测试可评估的么与代码相比它更加便宜么事实上我们无法给出一个明确的答案或者说无法像航天工程师以及结构工程师那样在绝大多数场景下都能给出肯定的答案这是因为软件建模的性价与具体的应用场景相关。 我们来看UML是否具备模型的特点即可测试可评估。很遗憾测试在UML图方面并没有严格的标准同时模型的评估最终仍然是主观的。那么性价比呢客观的说大多数情况UML图的绘制比编写代码代价要小一点但是并没有小多少。事实上经常出现更改源代码比更改图示更加容易的情况。 说了这么多你们是不是认为我在陈述一个伪命题或者说UML图就是个鸡肋。这么说对了一半因为UML确实很容易被误用当硬性规定“必须图示一切”这样的规则还不如没有规则。大量项目时间和精力会被浪费在绘制没人会看的图示上面这时候UML图就是一个鸡肋。但如果用在与团队同步大型系统的结构时脉络图就是一个非常适合的选择。所以恰当而有效的使用UML图是非常重要。
4.UML的应用场景 那么我们什么时候应该使用UML图呢我们把这个问题更加细化一点写代码之前是否需要做好详细设计我们都知道在建筑行业一个建筑师的设计图可以拿个及时甚至上百人来建造房子。在做设计图时不需要挖地基、浇灌混凝土或者安装窗户。总之设计的代价比直接建造的代价低很多。丢弃一个错误的设计比拆除有问题的建筑代价也低很多。但是这样的性价比在软件领域却不明显绘制UML图比写代码代价更低根本不明显事实上许多项目团队在图示上花的时间已经远远超过了写代码。丢弃图示比丢弃代码成本更低同样不明显。因此我们并不鼓励在写代码之前画一份详细的UML图示。 那么我们到底什么时候才应该使用UML图呢大师马丁总结了一下的情形可以画图的情况如下
几个人都需要理解设计的某个特定部分的结构因为他们同时都要用到它。一旦所有人都理解就停止。你希望团队能够达成一致但是有两个或者更多的人不同意某个特定元素的设计。把讨论限定在一个时间盒内然后选择一种决策的手段比如投票或者公平裁判。在时间盒终止或者能够做出决策时就结束。然后擦掉图示。你想尝试一个设计想法并且图示有助于思考。当你可以使用代码完成思考时就停止。丢掉图示。你要向其他人或者自己解释代码某些部分的结构当通过浏览代码可以更好地进行解释时就停止。接近项目的尾声并且客户要求要把图示作为一部分文档提供给他们。
不要画图的情况如下
过程要求。不画图会有负罪感或者认为这是好的设计师要做的事情。好的设计师是要写代码的。他们只有在必要时才画图。为了在编码前创建出面面俱到的设计阶段文档。这种文档基本上没有任何价值却耗费了大量的时间。为了方便其他人编码真正的软件架构师是要为自己的设计编码的。
下面将给出UML主要的几个具体应用场景:
4.1 与他人交流时可以使用UML 使用UML在软件开发者间交流设计构想是非常方便的。一小组开发者站在一块白板前可以完成许多工作。如果你有一些想法需要和他人进行交流UML是非常有用的。UML有助于交流清晰的设计想法。我们很容易就可以想象出一组开发人员站在一块白板前讨论着一幅类似图示的场景。事实上图示非常清晰地表达了代码结构。另一方面在交流算法细节方面UML并不是非常合适。
4.2 大型系统的架构图 架构图可以使得开发人员快速找到类与类之间的依赖关系并提供一份关于整个系统结构的参考。这样的架构图是很有用的教学工具任何团队成员都要能够立即在白板上画出这样一幅图来。
4.3 项目结束文档 要编写需要保存的设计文档最佳时机是在项目结束时并把它作为团队的最后一项工作。这种文档会精确地反映出设计的状态对团队非常有用。不过仍有一些问题需要注意。UML图必须得经过仔细考虑。我们不需要厚达几千页的顺序图我们想要的是那些描述系统关键要点的少量重要图示。充斥着大量混乱不堪、纠缠在一起的令人迷惑的线条和框框的UML图是无法理解的。
5.要不要使用UML工具 UML CASE工具可能非常有用但也可能是昂贵的垃圾收集器。在决定购买并部署UML CASE工具时一定要非常小心。
难道UML CASE工具没有使得画图变得更容易一些吗没有它们使得画变得图更加困难了。要想熟练掌握工具需要一个很长的学习曲线即使掌握了工具也相对更笨重而白板则非常易于使用。开发者通常都已经非常熟悉白板。即使不熟悉也基本上没有什么学习曲线。难道UML CASE工具并没有使得大团队在协作绘图方面更容易一些吗有些情况下确实更容易。不过绝大多数开发者和开发项目都不需要产出如此数量和复杂性的图示多到需要一个自动协作系统来协凋。无论如何都应该先用一个手工系统当其显现出不堪负荷并且此时唯一的选择就是自动化时才是考虑购买UML图绘制协调系统的最好时机。难道UMLCASE工具并没有使得代码生成更加容易吗画图生成代码然后使用生成的代码所涉及的工作量之和很可能不比直接写代码的成本更低。如果说有收益的话也不会是一个数量级甚至不会是2倍。开发者知道如何编辑文本、使用IDE。从图示生成代码听起来像是个好主意但我很希望你在大把花钱之前先度量一下生产力方面的提升。那些本身就是IDE并且可以同时显示代码和图示的CASE工具如何呢这些工具确实很酷。不过总是显示UML图并没有多大意义。修改代码时图示会相应改变或者修改图示时代码会相应改变实际上并不会带来多少帮助。坦白讲我更愿意花钱买专注于更好地帮助我处理程序而不是图示的IDE同样在决定投入大笔资金之前请先度量生产力的提高。简而言之三思而后行。给团队装备一套昂贵的CASE工具也许有好处但在购买这些很可能无人问津的东西之前请先通过实验来验证它的好处。
6.总结 不要试图一次就把软件系统整体架构用UML绘制出来从最简单的行为开始绘制一幅有关具体问题的简单顺序图或者协作图然后根据需求不断的补充和扩展。 在使用图示时非常重要的一点是要能够想象出代码。我们把图示作为代码的速记而不是替代。如果在画图时不能想象出它所表示的代码那么就是在构建空中楼阁。停止绘图想一想该如何把它翻译成代码。千万不要为了画图而画图。必须时刻确保自己知道正在表达什么代码。 UML是一个工具不是最终结果。作为一个工具它可以帮助思考和交流设计。如果少量使用它会带给你巨大的好处。如果过度使用它会浪费你大量的时间。使用UML时少即是好。
引用
《敏捷开发》—— 罗伯特.C.马丁
