搜索
Uml实用技术在设计阶段如何发挥作用主题软件开发过程详解•目前的现实是什么？——业务建模•在这个现实下，开发系统是为了达到什么目标？——愿景•为了达到目标，系统应对外提供什么样的功能和性能？——需求•为了提供这些功能，系统内部应该有什么样的核心业务机制？——分析•为了满足性能，系统的核心机制如何在选定的架构上实现？——设计找到问题解决问题UML三个主要作用使用可视化建模来获取并表现商业逻辑和对象使用可视化建模来分析和设计计算机应用程序•理由一：UML是客户、系统分析员和程序员之间的“桥梁”•用例图•活动图•状态图•时序图•对象图•部署图•……UML三个主要作用•理由二：UML从客户的角度将复杂的系统整理清楚UML三个主要作用software可移植技术交互性能全面容量稳定性错误处理容错性功能需求成本兼容性•理由三：UML能使越来越复杂的软件系统架构更加合理和健壮系统模型可由“4+1”视图展现逻辑视图场景视图系统功能分析设计结构系统并发工作情况实现视图实现模块和代码间的关系部署视图系统物理拓扑架构进程视图省公司工业企业商业分公司Internet行业内网行业内网国家局工业企业MIS/ERP数据映射数据抽取数据过滤数据校验数据清洗数据装载数据交换体系（ETL）前置数据库本地管理机联机采集局域网数据审核数据上报国家局服务器工商数据库数据传输体系（MQ）商业企业MIS/ERP数据映射数据抽取数据过滤数据校验数据清洗数据装载数据交换体系（ETL）前置数据库本地管理机联机采集局域网数据审核数据上报省域网数据传输体系（MQ）数据传输体系（MQ）本地管理机局域网数据审核数据上报数据传输体系（MQ）数据传输体系（MQ）国家局MIS联机采集数据映射数据抽取数据过滤数据校验数据清洗数据装载数据交换体系（ETL）数据中心数据中心加工体系4+1视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容系统模型可由“4+1”视图展现•逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务.在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问题领域（ProblemDefinition)。在面向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图（ClassDiagram）来描述逻辑视图。逻辑视图LogicView系统模型可由“4+1”视图展现•开发视图主要用来描述软件模块的组织与管理（通过程序库或子系统）。服务于软件编程人员，方便后续的设计与实现。它通过系统输入输出关系的模型图和子系统图来描述。要考虑软件的内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：JavaSDK，图像处理软件包）。开发视图Development/ModuleView上升到组件概念系统模型可由“4+1”视图展现•进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系统集成人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。进程视图ProcessView现在公司里不再考虑功能能不能实现，而在于PK性能，可扩展性等非功能性。系统模型可由“4+1”视图展现•物理试图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。物理视图(physicalview)系统模型可由“4+1”视图展现•场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。文本、图形表示皆可。n小结逻辑视图、开发视图，都主要是用来描述系统的静态结构。进程视图、物理视图，主要是用来描述系统的动态结构。并非每个系统都必须把5个视图都画出来，而是各有侧重。例如MIS系统侧重于逻辑视图、开发视图，而实时控制系统则侧重于进程视图、物理视图场景(Scenarios)模型可由9个图来展现UseCaseDiagramUseCaseDiagram用例图ScenarioDiagramScenarioDiagram协作图StateDiagramStateDiagram组件图ComponentDiagramComponentDiagram部署图StateDiagramStateDiagram对象图ScenarioDiagramScenarioDiagram状态图UseCaseDiagramUseCaseDiagram时序图StateDiagramStateDiagram类图活动图模型墨绿色表示动态图粉红色表示静态图（可把用例图单列出来）功能静态结构物理架构动态行为用例图，类图，时序图经常用UML9种图•描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。用例图•类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。类图•与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。对象图•描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。活动图UML9种图•描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；状态图•序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。序列图（顺序图）•和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。协作图•描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。构件图（组件图）•是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。部署图（配置图）UML9种图•用例图：业务建模、需求、测试•类图：业务建模、分析、设计•对象图：业务建模、分析、设计•组件图：设计•部署图：设计•顺序图：业务建模、分析、设计•协作图：业务建模、分析、设计•状态图：需求、分析、设计•活动图：业务建模、设计结构行为敏捷建模原则：需要时再添加可互换可互换主要步骤我们动手做做练习UML帮助我们做需求简单了解UMLUML在设计阶段如何发挥作用主题UML之用例图需求分析中我们如何整理和抽象我们从用户那得到的业务描述。用流程图描述业务流程、用用例图表达用户业务工作识别执行者执行者要点：•系统外——必须和它交互•系统边界——直接与系统交互•有意义的交互——属于目标系统的责任•任何事物——人、外系统、外部因素、时间识别执行者抽象出执行者的思路：•谁使用了系统的主要功能？•谁改变了系统的主要数据？•谁从系统获取信息？•谁需要系统的支持以完成日常工作任务？•谁负责维护、管理并保持系统正常运行？•系统需要应付（处理）哪些硬件设备？•系统需要和哪些外部系统交互？•谁（或什么）对系统运行产生的结果感兴趣？•有没有自动发生的事件？识别执行者责任类似或重叠——抽象出执行者UML之执行者Actor之间也有继承关系。且注意图形表示。识别用例用例的基本定义：用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。——IvarJacobson（RUP）通俗地讲：执行者通过系统达到某个有用目标步骤路径目标识别用例设计用例要注意以下要点：•价值结果→有意义的目标•系统执行→价值结果由系统生成•执行者可见→业务语言，用户观点注意：抽象一组用例实例时控制好用例的粒度识别用例有意义的目标：√×识别用例用户观点而非系统观点：用户观点系统观点识别用例用例命名：执行者视角动词（+宾语）状语定语如：批量修改登录记录编号识别用例执行者使用这个系统达到什么目标？语法测试：【执行者】使用系统来【用例】用例命名：慎用弱动词、弱名词30弱动词：进行、使用、复制、加载、重复……弱名词：数据、报表、表格、表单、系统……会掩盖真正的业务识别用例识别用例讨论：几个登录？或注意角色的划分和公共用例的定义要不把用户抽象成三种，或者把登录抽象成三种。识别用例用例的粒度：四轮马车任何业务归根到底都可以看作CURD，但光CURD能为Actor提供价值吗？CRUD是Create（创建）、Read（读取）、Update（更新）和Delete（删除）缩写警惕CURD泛滥！一般要避免全部使用，要抽象，公用的，其它的不要，但默认有。识别用例用例的粒度：在四轮马车之前尽量细致另注：多个用例会操作同一项数据，即对一个数据项操作用例未必是同一个用例识别用例讨论：登录怎么处理？（确定用例之间的关系）用例有先后或前提关系时不要简单认为是简单的包含或者是扩展关系更进一步的精度用例图可以作用例文档的总图，进一步的精度：有层次的文档，文档中每一句话都有其价值通过关系整理用例——用例的关系扩展：分离扩展路径包含：提取公共步骤，便于复用泛化：同一业务目的的不同技术实现大多数为包含关系include是指用例中的包含关系，通常发生在多个用例中，有可以提取出来的公共部分（就象提取公因式一样），例如UseCaseA中包括了a和b两个流程，而UseCaseC中包含了c和b两个流程。为了提高复用性，可以把b提取出来，形成另一个用例UseCaseB，此时，UseCaseAincludeUseCaseB（表现为一条指向UseCaseB的虚线，箭头在UseCaseB侧），UseCaseC也includeUseCaseB。因而，当有include关系时，被include的用例通常会被两个以上的其他用例include（否则就不需要重用，也就不需要提取出来了），用例图如下：通过关系整理用例通过关系整理用例——包含关系的误用extend则恰好相反。假设UseCaseA的功能描述为“发送一条通知”，可是，发送通知的方式可能有许多种，例如通过邮件发送、通过短信发送等。在需求分析阶段，可能无法明确到底有多少种方式，在用例分析阶段，UseCaseA需要留出扩展接口，然后把已知的发送方式作为扩展用例给出，例如UseCaseB是“通过短信发送”，而UseCaseC是“通过邮件发送”，此时，UseCaseB和UseCaseCextend了UseCaseA，表现为两根虚线，箭头指向UseCaseA，用例图如下：通过关系整理用例如果两个用例之间，一个要调用另一个时，怎么办？”（有可能是混淆了用例和模