UML-第1课-建模概述-new

建模概述刘宇鹏软件工程系2012-2013第一学期模型的用途在构建物理实体前进行可以用它先来测试一下〔仿真〕与客户进行交流〔架构师和产品设计师〕可视化——艺术家的草图降低系统复杂度可见：建模最主要的理由是处理由于过于复杂而难以直接理解的系统人脑每次可以处理的信息有限；模型将每次要处理的少量重要概念别离出来，从而降低了复杂度建模建模是对现实的简化。就是把复杂的系统变成小的系统，采用“各个击破”的原那么逐一解决。根据意图来进行抽象，而抽象的目标就是以某种目的隔离那些重要的方面，并抑止不重要的方面三个模型之间存在关联关系为什么要建模？建立大厦和建立茅草屋的区别是建设茅草屋不需要设计。要生产合格的软件就要有一套关于体系结构、过程和工具的标准。为什么要建模？更好地理解我们正在开发的系统并发现简化和重用的时机表达我们所渴望的系统结构和行为展示和控制系统体系结构进行风险控制为什么要建模？TocommunicatewithotherpersonsTofinderrorsoromissionsToplanoutthedesignTogeneratecode建模的目标1〕模型帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化。2〕模型允许我们详细说明系统的结构和行为。3〕模型给出一个知道我们构造系统的模板。4〕模型对我们的决策进行文档化。建模的误区无论你遵从的是重量级的方法,比方EnterpriseUnifiedProcess(EUP)，还是轻量级的开发过程，如ExtremeProgramming(XP)，建模在软件开发中都是不可或缺的。但不幸的是其中充满着各种谬误与迷思。这来自于各个方面，有从理论家错误的研究、数十年来信息技术领域内的文化沉积、软件工具开发商天花乱坠半的市场宣传以及象ObjectManagementGroup(OMG)和IEEE这类组织的标准EUP简介.ppt误区一：建模就等于是写文档事实分析：“模型”与“文档”这二者在概念上是风马牛不相及的－－－－你可以拥有一个不是文档的模型和不是模型的文档。建模很象是作方案：作方案的价值在于方案编制的过程中而非方案本身；价值表达在建模的活动中，而非模型本身实际上，模型不是你系统中的一局部正式的文档，而且在完成它们的使命后可以被丢掉。你会发现值得保存的只有很少的模型，而且它一定是非常完美。误区二：从开始阶段你可以考虑到所有的一切怎么才能走出这个误区呢？首先，你必须认识到你不能考虑到所有的细枝末节第二，认识到不管你的最初所作的规格说明书有多好，但注定代码会很快地与之失去同步，即便是你自己建模自己编码。一个根本的道理就是代码永远只会和代码保持一致。第三，认识到迭代法〔小规模地建模，编一些代码，做一些测试，可能还会做一个小的工作版本〕是软件开发的准那么。它是现代重量级的软件开发过程〔如EUP,Enterprise

Unified

Process〕，以及轻量级〔如XP,Extreme

Programming)的根本原理。误区三：建模是在浪费时间许多人都这样认为，这主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码，就如初级程序员。他们放弃了提高效率和学习技能的时机，这些技能能够使他们很容易地适应不同的工程或组织。事实分析：在大多数情况下，在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外，建模是一种很好的在工程组成员与工程负责人之间沟通途径。你们在这个过程中探讨问题，从而对所要的是一个什么样的东西可以得到更好的理解，涉及到该工程中的每个成员也可得到对该工程有一个从分的了解。误区四：所有的开发人员都知道如何建模事实分析：这肯定是不正确的。建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程序员常常相信自己无所不能，正因为这样的狂妄自大，他们承担的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂，单单一个人是很难具备所有的技能去成功地进行开发，甚至也不可能去配置有一定复杂程度的系统。开发者应该有自知之明，明白他们自己的弱点，学无止境。通过互相取长补短,建模者可从程序员身上学到一项技术的具体细节，程序员也可从建模者那里学到有价值的设计和体系结构的技术。我们现在面临照这样一个严重的问题：许多不是开发人员的人，包括高级经理和用户，不知道软件是如何建成的。其结果是，他们不能够区分开熟练的开发者和一般的程序员〔当然也分不清高级程序员和一般程序员〕，他们想当然地认为所有的开发人员都具备从头到尾开发整个系统的技能。参考文献：建模的误区建模的误区.docScott

Ambler

，对象技术和敏捷方法大师Agilesoftwaredevelopment.ppt建模十条原那么仅有数据模型对于现代软件是不够的。接收变化，并且允许你的模型能够随着时间进行改进,你不能冻结它们，然后就期待着成功。模型并不一定就是文档，文档也不一定就是模型。大多数的模型可能也应该被丢弃。只有代码才能与代码保持真正的同步。一些简单的工具，比方白板，就完全足以应付大多数建模工作。思考，然后再编码。你总能从别人身上学到东西。建模可以用一种轻盈的方式。设计直到代码发布以后才算完成。怎样成为优秀的软件模型设计者1.人远比技术重要2.理解你要实现的东西3.谦虚是必须的品格4.需求就是需求

5.需求其实很少改变，改变的是你对需求的理解6.经常阅读7.降低软件模块间的耦合度8.提高软件的内聚性9.考虑软件的移植性10.接受变化

怎样成为优秀的软件模型设计者11.不要低估对软件规模的需求12.性能仅仅是很多设计因素之一13.管理接口14.走近路需要更长的时间15.别信赖任何人16.证明你的设计在实践中可行17.应用的模式18.研究每个模型的长处和弱点19.在现有任务中应用多个模型20.教育你的听众21.带工具的傻瓜还是傻瓜22.理解完整的过程23.常做测试，早做测试24.把你的工作归档25.技术会变，根本原理不会面向对象的建模传统的软件开发是从算法的角度进行建模面向对象的建模方法是当前软件开发的主流方法一个最根本的建模类图中的各个类对象，按照顺序图的交互，完成一个用例建模从三种相关但是不同的角度来建模系统会很有效——类建模状态建模交互建模以上每种角度都描述了系统的某些重要层面，但是一个完整的系统还需要全部的3种模型类建模类模型描述了系统中对象的结构——它们的标识、与其他对象的关系、属性和操作，它提供了状态和交互模型的上下文。类模型表示系统静态的、结构化的“数据”层面构建类模型时，我们的目标是从真实世界中捕获那些对应用而言重要的概念状态建模状态模型描述了与操作的时间和顺序相关的对象层面——标记变化的事件，界定事件上下文的状态，以及事件和状态的组织。状态模型捕获“控制”，即描述操作出现的系统层面，不需要考虑操作做了什么，或者它们如何实现。状态模型表示系统时序的、行为的“控制”层面状态图中的动作和事件都变成了类模型中对象上的操作。状态图之间的引用变成了交互模型中的交互交互建模交互模型表示独立对象的协作，系统的“交互”层面——独立对象如何协作，来从整体上完成系统的行为。状态模型和交互模型描述了行为的不同侧面，它们两者的配合才能完整描述行为交互模型中的3个图：用例图，用例评述系统和外部参与者之间交互的主要内容顺序图，显示交互的对象和交互的时间顺序活动图，显示计算的处理步骤之间的控制流3种模型之间的关系彼此包含了对其他2种模型的引用类