搜索
+UML是一门语言，基本元素是UML的基本词汇，视图就是语法+本节学习视图，包括用例图、类图、包图等静态视图及活动图、状态图、时序图、协作图等动态视图+UML可视化的特性是由各种视图来展现的，每一种视图都从不同角度对同一个软件的方方面面进行展示，说明将要开发的软件是什么样子+描述软件和描述现实世界一样，一方面需要描述系统的结构性特征，结构决定了这个系统能做什么，另一方面需要描述系统的运行时行为，这些行为特征决定了系统怎么做+在UML中，结构性特征通过静态视图来表达，行为性特征通过动态视图来表达+静态视图–表达静态事物–只描述静态结构，不描述其他动态行为+采用参与者与用例作为基本元素+绘制用例视图和发现用例一般都是并行的，一边发现参与者和用例一边绘制用例视图+而绘制过程中则由可能回头修改已经获取的参与者和用例+最后，建模者通过用例视图将获得参与者与用例从某个角度进行展示，表达软件某个方面的视角+业务用例视图–业务用例图使用业务主角和业务用例展示业务建模的结果，大多数情况下，业务用例视图需要从业务主角和业务模块两个视角进行–业务主角视角从业务主角视角来展示业务主角在业务中使用那些业务用例来达成业务目标这个视角有利于向业务主角确认业务目标是否都已经齐全，以此来检查是否有遗漏的业务用例没有发现–展示借书管理系统的借阅人业务用例视角–图含义是：借阅人业务主角在借书管理系统中有借阅图书和办理借阅证两个业务目标–如果业务主角认为所有目标已经齐全，则认为针对此主角的业务用例定义完成–业务模块视图从业务模块视角来展示业务领域的目标，将参与了达成这一业务目标的业务主角与业务用例展现在这个视图中这个视角有利于从业务的完整性角度出发，检查完成某个业务的所有业务主角和业务用例是否已经齐全，以此来检查是否有遗漏的业务用例没有发现–例子展示了参与借书业务领域的业务目标，将参与了达成这一业务目标的业务主角和业务用例展示在这个视图中这个视图的含义是这些主角和业务用例完整地概括了借书业务的业务目标如果这项业务能被这些业务主角和业务用例完整地使命，则认为此对此业务模块的业务用例定义完成–其他视角建模过程，还可以根据实际需要从更多的视角来绘制业务用例视图例如可以从部门角度绘制一个部门参与的全部业务用例视图或者从一个重要业务实体的生命周期角度，例如一份文件，来描述文件从产生到销毁的整个生命周期过程中涉及的业务主角和业务用例视图+总之，在建模过程中，每当需要展现某个方面的视角时，都可以将获取到的业务主角和业务用例图展现出来，不要拘泥于某几个固定的形式+业务用例视图展现了业务系统的功能性需求，如果要描述这些需求的实现途径，则需要使用业务实现视图+业务用例实现视图–业务用例实现视图展现业务用例有哪些实现途径–业务用例是业务需求，而业务用例实现则是业务的实现途径–从软件工程的角度说，这个视图展示了需求的可追溯特点–如果在实际中，一个业务用例只有一个实现途径，那么业务用例实现视图就不需要了–例子展示了借阅图书业务的两个业务用例实现，借阅人可以到图书馆借书也可以通过网上借阅两个实现途径都可以达到同样的借阅图书业务目的用业务对象和业务过程来分析描述两个实现途径，会发现其中有重叠的过程和复用的对象，这些信息就是抽象概念的重要来源+概念用例视图–概念用例视图用于展现从业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系，一般来说，这些关系有扩展、包含和精化–对于概念用例视图来说，一般是以业务用例为单元展现的，即将视图名称命名为业务用例名称，如果某几个业务用例关系紧密也可以放在一个视图里展示–例子展示了借阅图书业务的概念用例视图表达的含义是借阅图书业务必须经过检查借阅证、借出图书、归还图书这三个关键业务单元，同时可能需要交纳借阅费用概念用例视图不是必需的，如果业务用例是一个复杂的业务，绘制概念用例视图有助于细化和更准确理解业务用例+系统用例视图–系统用例展现系统范围，将对业务用例进行分析以后得到的系统用例展现出来–系统用例视图是以用例为单位展现的，即将视图命名为业务用例名称–这表达了系统需求从业务需求的映射，保证了过程的可塑性–系统用例视图即系统的开发范围–例子展示了借阅图书的系统用例视图表达了：计算机系统即将开发本视图所列举出来的系统用例问题：检查图书证用例不见了？–检查图书证可能是手工工作而不需要列出系统建设范围+系统用例实现视图–与业务用例实现视图类似，如果一个系统用例有多种实现方式，也应当为其绘制实现视图–例子展示了系统用例实现视图，表达了从系统实现到系统需求的追溯–表达了每个系统用例都有其实现，其中缴纳费用系统用例有两个实现方式+用例图–包括业务用例视图、业务用例实现视图、概念用例视图、系统用例视图和系统用例实现视图–这些视图在软件的不同生命周期阶段表达了不同的含义–实际项目中，不是所有用例视图都一定要采用–根据情况可适当裁减，如保留业务用例和系统用例视图+类图用于展示系统中地类及其相互之间的关系+本质上，类图是现实世界问题的抽象对象的结构化、概念化、逻辑化描述+解决面向对象困难的方法源于面向对象方法中对类的理解的三个层次观点：概念层、说明层和实现层+在UML中，从开始的需求到最终的设计类，类图也是围绕这三个层次的观点建模的+类图建模是先概念层，而后说明层，进而实现这个一个随着抽象层次的逐步降低而逐步细化的过程+概念层类图–在这个层次的类图描述的是现实世界中的问题领域的概念理解–类图表达的类与现实世界的问题领域有着明显的对应关系–类之间的关系也与问题领域中的实际事物的关系有着明显的对应关系–概念层类图中的类和类关系与最终的实现类并不一定有着直接的明显的对应关系–概念层着重对问题领域的概念化理解，而不是实现，因此类名通常都是问题领域中实际事物的名称–概念层的类图独立于实现语言和实现方式–回顾图1.9，概念层类图位于建模阶段，此阶段类图是以领域模型图，即业务实体图来表示的–例子展示网上购物的实体图表达了概念层的类观点，说明在问题领域中，网上购物主要由商品、定单、支付卡这几个关键类构成，这几个类能够完成网上购物这个业务目标+说明层的观点认为：在这个层次的类图考察的是类的接口而不是实现+类图中表达的类和类关系应当是对问题领域在接口层次抽象的描述+也就是说，此时不必关心类最终使用什么语言编码的，是用什么设计模式设计的、是遵循什么标准的，我们只关心是这样的一些类，它们通过接口进行交互，进而完成了问题领域中的业务目标+说明层类图是现实世界和最终实现之间的一座桥梁，此时的类通常都非常粗略，虽然它表达了计算机的观点，但是在描述上却采用了近似现实世界的语言，以保证从现实世界到代码实现的过渡–回顾图1.9，说明层类图位于概念模型阶段–此阶段，类图以分析类和分析模型图来表示–图展示了网上购物的分析类图–这个类图表达了从计算机视角来说，网上购物这个业务目标是由那些类来完成的，这些类的接口保证了这个业务目标的达成+实现层认为，类是实现代码的描述，类图中的类直接映射到可执行代码+在这个层次上，类必须明确采用哪种实现语言、什么设计模式、什么通信标准、遵守什么规范等–回顾图1.9，实现层类图位于设计阶段–在此阶段，类图可视为伪代码，甚至可以用工具直接将实现层类图生成可执行代码–例子展示了J2EE结构实现查询商品功能的类图图中是伪代码+类图在不同的软件生命周期有三种不同的表达+包图一般用来展示高层次的观点+建模过程中获得的元素非常多，如果将这些元素的关系都绘制出来将如同蜘蛛网一样难以辨别+通过包这个容器来从大到小、从粗到细建立关系是一种很好的办法–例子展示了网上购物的领域包图表达了关键业务领域及其依赖关系–例子展示了查询商品功能的类层次表达了实现类位于哪个层次的软件架构的观点+动态视图描述事物动态行为+动态视图不能独立存在+必须特指一个静态视图或UML元素，说明在静态视图规定的事物结构下它们的动态行为+描述为了完成某一个目标需要做的活动以及这些活动的执行顺序+UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互+争议–活动图被引入UML是由争议的，因为活动图实际上描述的是业务流程，是一种过程化的分析方法，很多人担心面向过程的活动图引入会导致OO的类职责的混乱，这种担心是有道理的–在OO的眼中，是没有业务流程这种东西的，所谓流程，只不过是在外力推动下对象之间相互交流的一个过程，只是瞬间的–如果从活动图的观点来描述业务，实际上是不能直接看到对象是如何发挥作用的–这样在观念上很容易导致对象独立性被破坏，例如有的设计者可能会试图得到一个从头到尾参与整个业务流程的“对象”+在OO设计中，我们面临着这样一个矛盾，既要保持OO中对象的独立性，又要保持显示世界中业务目标的过程化描述+活动图的引入解决了业务目标过程化描述，但也给OO分析造成了混乱+但是，活动图在描述用例场景时仍然是十分有用的工具+关键是：建模者自己要避免被过程化的观点所困扰+使用活动图时，要保持清醒的头脑，它只是我们用来描述业务目标的达成过程并借此来发现对象的工具，并非我们的分析目标，也不是编程的依据，它只是对象的应用场景之一+我们使用活动图来描述用例场景，帮助我们认识问题领域，从问题领域中发现关键对象+用例表达了参与者的一个目标，用例场景描述了如何达到这个目标+活动图用来描述用例场景，也就是通常所说的业务流程+业务流程一般包括一个基本业务流程和一个或多个备选业务流程，而业务流程则通过多个活动按照一定的条件和顺序执行来推进+活动可以是手动执行的任务，也可以是自动执行的任务，每个活动完成一个工作单元+例子–展示了办理登记手续用例的用例场景–关键元素起始点÷标记业务流程的开始，一个活动图或者一个业务流程有且仅有一个起始点活动÷活动是业务流程中的一个执行单元÷在UML中，活动被赋予4个特定的事件：entry指进入(启动)活动时要执行的动作(或者方法)÷Do指活动执行过程中要进行的动作(或者类方法)；÷event事件指活动在执行中接收到某个事件执行的动作；÷exit指活动在退出(结束)时要进行的动作–判断判断根据某个条件进行决策，执行不同的流程分支–同步分为同步起始和同步汇合。同步起始表示它从开始多个支流并行执行；同步汇合表示多个支流同时达到之后再执行后续活动–结束点表示业务流程的终止一个活动图(或者一个业务流程)可以有一个或多个结束点–基本流表示最主要、最频繁使用的、默认的业务流程分支，如图所示从开始到结束办理的业务流程–支流表示不经常使用的、由某个条件触发的、非默认的业务流程分支，如图中无行李分支(假设大部分客户都需要托运行李)–异常流表示非正常、不是业务目标期待的、容错性的、处理意外情况的业务流程分支，如图身份核对错误分支，异常流通常导致业务目标失败–组合活动可以用嵌套活动来表示，不过此方式可能导致活动图太复杂而不清晰，建议不使用可以用另一幅活动图表示这些子活动例子展示了一个特殊的返回自身的执行顺序，一般用在条件循环的情况下+用例活动图–用于展示用例场景，一般可以理解为业务流程+对象活动图用于展示对象的交互+例子–查询商品的对象交互过程–尽管UML允许使用活动图描述对象交互图–实际工作中有其他更好的工具描绘对象交互+活动图描述了业务中活动的顺序执行，但没有描述谁来执行，即执行业务流程的执责被遗漏了+在面向过程的分析中，对象职责并不重要，重要的是业务的执行过程+而在OO的分析观点里则与之相反，业务的执行过程并不重要，对象的职责才最重要+泳道技术的引入多多少少解决了活动图不能描述对象职责的遗憾+泳道–顾名思义，一个游泳运动员只能在一个泳道里进行比赛一样–一个对象也正在一个业务流程中担任一个(或一类)职责–泳道代表了一个特定的类、人、部门、层次等对象的职责区–这些对象在业务流程中负责执行的活动集合构成了它们的责职–例子对比两附图，后者更清晰但是不推荐使用+实际中，客户的业务通常是以业务流程的形式存在，仅从单个客户代表处得到的需