常熟理工UML复习资料教材

1、1. 软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据、及相关 文档的完整集合。程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵的信息的数据结构文档是程序开发、维护和使用有关的图文材料2. 软件生存周期:正如同任何事物一样，软件也有一个孕育、诞生、成长、成熟、 衰亡的生存过程。我们称其为计算机软件的生存周期。3.00A :面向对象的分析00D :面向对象的设计OOP:面向对象的编程00T :面向对象的测试ODBMS :面向对象数据库4. 类：看作结构化中的表定义+访问数据库的代码定义对象：看作结构化中的记录。记录:数据库中；对象：内存中属性：看作结构化中的记录

2、中的字段方法：看作结构化中的函数或过程5. *消息：是发送对象objl向目标对象obj2发送请求的载体，申请对象obj2 的一个方法面向对象系统中，对象之间通过相互发送消息来协同工作，完成系统功能6. +public :公共的- private :私有的# protected :受保护的 friendly :友好的7. *单继承与多继承的区别：多继承引发的问题：属性和操作的命名冲突C+支持多继承、Java不支持多继承8. 多态定义：同一操作作用于不同的对象，可以有不同的解释，产生不同的执行结 果。多态性分为俩种：1.编译时的多态性2.运行时的多态性实现多态的两种方法：1.采用继承UML9种图结

3、对象图对象以及对象之间的昭互关系构行为掏件图ins活动图：对工作流程建模用例图：需求捕離，测试依据类EL类以及类之间的相互关系构件及其相互依赖关系 构件在各节点上的部署 顺序图：强调时间顺序的交互图 协作图强调对象协件的交互图 状态图：类所经历的各种状态2.使用接口类建模语言109.UML 全称：Unified Modeling Language利用执行者（actor）和用例（use case来描述系统的边界和它的主要功能 通过各种交互图形来描述use case的实现用类图来描述系统的静态结构和特性用状态转换图来描述对象的动态特性用构建图和部署图来描述系统物理特性的体系结构通过自定义类型，扩展

4、系统功能11. 用例图（用例图的组成）：展示系统外部的各类执行者与系统提供的各种用例之间 的关系执行者：不是系统的一部分，可以是（用户）人，也可以是一个在执行过程中 要调用本系统的另一个应用系统用例：表示的是不同的执行者对系统的应用方式*用例图包括6个元素：参与者、用例、关联关系、包含关系、扩展关系以及泛 化关系12. 类图：是描述类、接口、协作以及它们之间关系的图类图包含7个元素：类、接口、协作、依赖关系、泛化关系、关联关系以及实现 关系类三个部分：类名、属性、方法13. 状态图：描述一类对象具有的所有的可能状态以及其转移关系。 状态图由表示状态的结点和表示状态之间转换的带箭头的直线组成。

5、状态图的图标分为三个部分：名称、内部转换、嵌套状态图。14. 协作图：描述的是和对象结构相关的信息。协作图从另一个角度展示对象之间的动态协作关系协作图包含3个元素：对象、链、消息15. 顺序图与协作图关系：角度不同16. UML中那5个视图：用例视图、逻辑视图、构件视图、并发视图、部署视图Rose中那4个视图：用例视图、逻辑视图、构件视图、部署视图18.19. UML对使用它的方法提出下列要求支持用例驱动（use case driven以体系架构为中心(architecture-centric)迭代递增式开发20. 类图的三个透视角度： 概念视角：描述应用域(domain)中的概念 说明视角：

6、考察对象的接口，即对象的类型而不是对象的实现 实现视角：描述对象类的实现21. 包：包是分解复杂问题的一种机制任何大系统都必须划分为较小的单元，以便人们在某一时刻可以和有限的信 息工作，使团队的工作不相互影响包可以包含各种模型元素和其他的包，包之间还可能存在一定的依赖22. 交互图:主要是用来描述对象之间的动态合作关系以及合作过程中的行为次序。常常用来描述一个用例的行为，显示用例中所涉及的对象和这些对象之间的 消息传递情况。包括：顺序图：描述对象之间的交互的时序。 协作图：描述对象之间的合作关系。23.Browser窗口有四个视图：j-O U?e Case View y-LJ Logical

7、View+' "O Component View D 即 lojjm&nt VieiUse Case用例图、顺序图、协作图、活动图Logical类图和状态图Comp onent组件图Deployme nt部署图4曲S函诵劇兩幾*函ETIE!F*lc£l爭 soads24.定义需求可以定义需求为“应该做什么的规格说明”。需求是系统的基础。原则上需求应该仅仅是陈述系统应该做什么，而不是它 应如何做。这是重要的区别。在理论上如何分离 what和how是引人注目的，实际上, 一组需求将是what和how的混合物。基本上有两种类型的需求：功能性需求系统应该提供什么功能

8、。 非功能性需求系统的特定特性或者约束。25. 系统需求规格说明SRS(System Requireme nt Specificatio n 说明系统将做什么SRS是软件构造过程的真正开始。它常常是 00分析和设计的初始输入。 可以用自然语言书写，也可用需求工程工具如 Requisite Pro(Rational Corporation)或者 DOORS对于任何一份SRS的基本提问是：“它对我有什么用？” “它是否帮助我理解系统应该做什么？”26. 用例建模活动输出用例模型，包括四个部分：系统边界 包围用例的方框，表示系统的范围，边界内的用例表示系统将 来要实现的功能。参与者在系统边界之外，透

9、过系统边界与系统进行有意义的交互的任何 人或事物。用例由系统执行的一个动作序列，给角色提供一项有价值的服务。关系一角色和用例、角色之间、用例之间有意义的联系27关联：角色与用例之间的关系关联代表的含义：参与者与用例之间进行通信NewUseCase其他系统NewUseCase 228. UP (Unified Process 或 USDP(Unified SDP )统一软件开发过程基于UML作者的工业标准 SEP目标“分而治之”将复杂系统的基本步骤构造为一组互联的小功能块来源Ericsson 方法，1967Ratio nal Objectory Process,1996-1997其他Ivar J

10、acobson常常被认为是 UP之父RUP(Ratio nal Un ified Process )统一开发过程：是一套面向对象的软件开发过程软件过程：是指实施于软件开发和维护中的阶段、方法、技术、实践和相关产 物(计划、文档、模型、代码、测试用例和手册等)的集合。29. UP (统一软件开发过程)的项目生命期项目生命期被划分成四个阶段:初始、细化、构造、移交初始：目标： 建立可行性，创建业务用例，捕获基本需求，识别关键任务，该阶段 的主要工作者是项目经理和系统设计师。焦点：需求和分析工作流 里程碑：生命期目标 (Life Cycle Objective)细化：目标：创建可执行的构架基线 ,精

11、化风险评估 ,定义质量属性 (缺陷率等 ),捕获 80%的功能需求用例，创建详细计划，含资源、时间、设备、人和成 本标价。焦点：八、八、需求，精化系统范围和需求。 分析，确定了需要构造什么。设计，创建稳定的构架。 里程碑：生命期构架的里程碑构造：目标：完成所有的需求、分析和设计，主要问题是维护系统构架的完整性。 焦点：实现里程碑：完成软件系统移交：目标： 修复缺陷，为用户场地准备新软件，修改不可预见的软件问题 ,创作 用户手册和文档 ,提供用户咨询 ,进行项目后评审。焦点：B测试以及在用户场地验收测试 里程碑：产品发布増量的开发30.31.UP三个基本公理用例和风险驱动构架为中心的 迭代和增量

12、的工作流32. 类图（类之间关系）类图描述了系统中的类及其相互之间的各种关系 类之间的关系表示了对象之间的通信能力。类之间有三种关系：关联（包括聚合和组合）继承 依赖33. 类的三个层次1.Conceptual：概念层。描述问题域中的概念，不考虑或很少考虑实现上的 细节一No Software.只考虑属性，在分析阶段使用。2.Specificatio n： 说明层。Look ing into Software,but only in terface of zhe software,not the implementation.Only type,not class 增加定义操作，在设计阶段使

13、用。3mplementation：实现层。只有当使用某一具体技术进行设计时使用。在 设计阶段使用。在创建类图或读类图的时候，需要清楚该类图是基于哪个层次34. 时序图生命线生命线是一条垂直的虚线，表示时序图中的对象在一段时间内的存在。每个 对象的底部中心的位置都有生命线。生命线是一个时间线，从时序图的顶部一直延伸到底部，所用的时间取决于 交互持续的时间。、对象与生命线结合在一起称为对象的生命线，对象的生命线包 含矩阵的对象图标以及图标下面的生命线。1735. 系统行为一契约SystemmdSXL 色 0 enterlttm JwakaFayni电 nt 0每一个系统操作都有一个契约, 用于描述

14、这个系统操作的行为名称：操作和参数的名称职责：对此操作所履行的职责的非形式化描述类型：类型的名字（概念、软件类、接口）交叉引用：所引用的系统功能号、用例等注释：设计注释、算法注释等异常：发生的例外情况输出：非UI输出，例如向系统外部输出的消息或记录等前置条件：在操作执行前对系统状态所做的假设后置条件：操作执行完成后系统的状态36.边界类每个角色/用例交互至少宴背一个边界类位于系统与外界的交界处，包牯斯有窗体 与打印机和扫描伙等硬件的接口，以 及与其他系统的接口。Actor 1Use Case 1Bou ndary Class037实体类保碍要肢进挣缤存備萍的信丢实件甘通苟壬萼件倚前：11忙二才

15、丄阳框囹中是对 用户握有意义的真，通常用业务域术谙命名。 鄴麟腳賈篙蠶溜偏字触可 以1發想库字锻回溯墓求从而避免收卑没k使用38.控制类控制类（管理者娄）b鱼责协輛其彳嵯曲工作。每个便用案例通膏有一个控制真，控制便用案 例中的事件I帧辰栓制类本身不完应任何功能，其他类并不向袒 制免发送许參消息，而是由控制宝危出许多消 耳 便用案例知识向具俺类委托责任一般的交互关系：Actor 接口类控制类实体类39.低耦合度 问题：如何支持低依赖关系和增加重用？ 解决方案：在分配一个职责时要保持低耦合度。 耦合度：一个类与其他类关联、知道其他类的信息、或依赖其他类的强弱程 度的度量。类之间的关系能简单则尽量简

16、单！40. 高耦合度类所存在的问题：其他类的改变会迫使这个类改变其自身的局部定义； 如果不联系其他类，难以孤立理解它； 难以重用，因为还要它所依赖的类必须一起存在。尽量降低类之间的耦合度41. 高聚合度聚合度：一个类中各个职责之间的相关程度和集中程度。 高聚合度：类中的职责高度相关并且这个类所完成的工作量不是特别巨大。 低聚合度：类中的很多职责彼此不相关。低聚合度类的问题：难以理解难以重用难以维护 易受外界所发生的细微变化的影响42.* 三层结构三层结构去示层L用八界面圣应用逻辑戻I存储层菜现址勢 耀组，如'*处S臥 R»teLiiel-*n43. 三层结构的优势1 便于统一

17、安装和维护，客户端几乎零维护。2表示层、应用逻辑层、存储层比较独立，可以分别进行修改和升级3 便于组件共享和升级。4方便对应用逻辑单独进行升级和修改。5 可以采用中间件技术，实现负载平衡。6 在复杂情况下具有很高的运行效率和稳定性。7. 完整的事物处理能力和简单的编程接口。8. 简化应用逻辑的编程，不关心存储的细节。44. 接口类ipnameO类A 类B 接口A接口实现B接口依赖45.状态图状态图刻划特定对象所有可能的状态及状态变迁 一个状态图表示一个状态机。状态图表现从一个状态到另一个状态的控制流状态图由表示状态的节点和表示状态之间转换的带箭头的直线组成组成：状态（State）转换（Transition） 初始状态（Start State 终结状态（End State 判定（Decision）示意图:on财*作i奉件乱宜存和1战态1dm动柞4监护总件X臣一46. 修改事件修改事件依靠特定属性值的布尔表达式所表示的条件的满足来触发状态的转