UML复习大纲以及整理.docx
- 文档编号:8000965
- 上传时间:2023-01-27
- 格式:DOCX
- 页数:15
- 大小:144.66KB
UML复习大纲以及整理.docx
《UML复习大纲以及整理.docx》由会员分享,可在线阅读,更多相关《UML复习大纲以及整理.docx(15页珍藏版)》请在冰豆网上搜索。
UML复习大纲以及整理
考试题型:
选择15道,判断15道,大题20分,简答50分,答题请简明扼要。
一、软件工程及面向对象技术、RUP概述
1、软件生命周期的主要阶段
•需求分析(RequirementAnalysis)
•软件设计(SoftwareDesign)
•编码(Coding/Programming)
•测试/调试(Testing/Debug)
•运行/维护(Running/Maintenance)
2、几种经典的软件过程模型及其相应的特点
从项目的需求定义情况、项目规模和复杂程度以及管理、控制的模式来看,大致可分为:
–线性模型
•瀑布模型Waterfallmodel,也称为线性顺序模型或典型的生命周期模型
特点:
a软件开发各阶段严格按照顺序进行,前一阶段的任务没有完成,不能进入下一阶段
b每一阶段的工作成果必须经过评审,确认无误,才能作为下一阶段的输入和依据
c每一阶段结束时要求交出规定的软件文档资料
缺点:
a缺乏灵活性
b对软件开发过于理想化,如对系统的需求分析
适用范围:
a适用于小型项目
b要求在项目开始时就明确需求。
•快速应用开发(RAD)模型
瀑布模型的高速变种,强调在短期内开发软件
强调重用在以前项目中开发过和测试过的构件
特点:
a开发速度快
b适用于在开发过程之前就充分理解需求的情况
c需要有足够的人力资源以建立相应的RAD小组
dRAD不适合技术风险很高或系统难以模块化的情况
–原型模型
特点:
a循环模式(Circulation)
b引入用户评价
c逐步求精
–演化模型
a优点
–便于开发人员和用户之间的交流沟通
–开发过程变得简单、灵活
–可以吸引客户,抢占市场(慎用)
b缺点
–要求开发团队有较高的原型开发能力,如果团队经验不足,可能会影响原型的质量
–没有考虑软件的整体质量和可维护性
•增量模型
a优点:
–能够明确需求,可以实施较好的风险管理
–人员分配灵活,项目开始时不用投入大量人力资源,当核心产品很受欢迎时,可增加人力实现下一个增量
b缺点
–至始至终都必须和客户沟通,直至完成最终版本
–只适用于大型系统,对小系统划分小的功能增量很困难
•螺旋模型
a优点
–对于大型系统来说,这个模型是一个很好的方法,
开发者和客户能够较好地对待和理解每一个演化层
次上的风险
b缺点
–需要相当的风险评估技术
–潜在的风险将导致问题的发生
•基于构件的开发模型
a优点
–构件可复用,提高了开发效率
–采用了面向对象的技术
b缺点
–过分依赖于构件,构件库的质量影响着产品质量
3、面向对象的基本建模原则
–抽象
–封装
–继承
–分类
–关联
4、面向对象分析分大致过程
•描述需求
•识别潜在对象
•筛选对象
•对象的命名
•识别对象的属性
•识别对象的行为
•识别对象所属的类
•定义类的结构
5、面向对象程序设计语言
•Simula,1967
•Smalltalk,20世纪60年代
•C++
优点
–可在操作系统的任何层次上作任何事情
–可能是现有的速度最快的面向对象语言
–C++编译器十分流行,程序员很多
缺点
–指针的大量使用难以保证软件在运行时的安全性
•Java
特点:
–平台无关性,可移植性高
–垃圾回收机制
–没有指针
•C#
•Ada
6、RUP的基本概念、基本特征以及裁剪
——基本概念:
AProcessdefineswhoisdoingwhatwhenandhowtoreachacertaingoal.
–(软件过程描述了什么时候,什么人,做什么事,以及怎样实现某一特定的目标)
RationalUnifiedProcess
是一种软件的开发过程,是将用户需求转化为软件系统所需的活动的集合。
是一个通用的过程框架。
——基本特征:
•用例驱动
采用用例来捕获对目标系统的功能需求
采用用例来驱动软件的整个开发过程,保证需求的可跟踪性,确保系统所有功能均被实现。
•以软件体系结构为中心
软件体系结构刻画了系统的整体设计,它去掉了细节部分,突出了系统的重要特征
在开发过程的早期形成良好的软件体系结构,有利于对系统的理解、支持重用和有效的组织软件开发
在后续阶段中对已形成的体系结构框架进行不断细化,最终实现整个系统。
•受控的迭代式增量开发
将软件开发过程分为一系列小的迭代过程,在每个迭代过程中逐步增加信息、进行细化
根据具体情况决定迭代的次数、每次迭代延续的时间以及迭代工作流
每次迭代都选择目前对风险影响最大的用例进行,以分解和降低风险。
7、RUP与UML的关系
要实施RUP,应该用UML统一建模语言。
二者是一起发展起来的,是不可分的关系。
二、UML概述
1、UML基本概念以及其与编程语言的区别
UnifiedModelingLanguage
–是对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言
2、UML中图的分类
——结构图:
类图、构件图、对象图、部署图、组合结构图、包图、用例图
——行为图:
•活动图
–显示系统内的活动流
•状态图
–显示一个对象的状态和状态之间的转换
•合作图
–突出对象之间的合作与交互
•顺序图
–强调一个系统中不同元素间传递消息的时间顺序
•时间图
–描绘与交互元素的状态转换或条件变化有关的详细时间信息
•交互概观图
–用于从总体上显示交互序列之间的控制流
3、UML的组成
由基本构造块、规则、通用机制组成。
4、UML可见性原则
可见性:
Public,Protected,Private,Package
5、常用的UML工具
1、•RationalRose(功能强大,市场占有率高)
2、•StarUML
3、•EnterpriseArchitect
4、•ArgoUML
5、•Visio
三、用例图
1、用例图建模步骤
①找出系统外部的参与者和外部系统,确定系统边界和范围
②确定每一个参与者所期望的系统行为
③把这些系统行为命名为用例
④使用泛化、包含、扩展等关系处理系统行为的公共或变更部分
⑤编制每一个用例的脚本
⑥绘制用例图
⑦区分主要事件流和异常事件流,如果需要,可以把异常事件流处理为单独的用例细化用例图,解决用例间重复与冲突的问题
2、用例是为了获得系统需求。
需求技术、需求的类型
——两种类型的需求
–功能性需求:
系统应该提供什么行为
–非功能性需求:
系统上的特定属性或约束
——三种需求技术
–XP中的用户故事
由用户参与编写,说明需要系统为他们做什么
简短的文字描述
–FDD中的特性描述
特性驱动的软件开发方法
特性(feature)描述:
–RUP中的用例
描绘一个系统外在可见的需求情况,是代表系统中各个项目相关人员之间就系统的行为所达成的契约。
——需求类型
功能性需求:
系统应该提供什么行为
非功能性需求:
系统上的特定属性或约束
3、用例图的三要素
A、参与者:
•参与者是虚拟的概念,可以指人,也可以指外部系统、设备等
•一个参与者可以执行多个用例
•一个用例也可以由多个参与者所使用
•尽管在用例建模时使用参与者,但参与者实际上并不是系统的一部分
B、用例:
用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列
用例是系统、子系统或类和外部参与者交互的动作序列的说明,包括可选的动作序列和会出现异常的动作序列
C、参与者与用例之间的关系:
参与者和用例之间是关联关系,表示了参与者与用例间的通信
可以用一条实线箭头表示,由参与者指向用例
4、用例之间的关系
–泛化(generalization)
–包含(include)
–扩展(extend)
–自定义
四、类图
1、类的基本概念
类是具有相似结构、行为和关系的一组对象的描述符
接口是一种特殊的类。
接口是一种类似于抽象类的机制,是一个没有具体实现的类。
关联类既是关联又是类。
嵌套类:
在诸如JAVA的语言中,允许将一个类的定义放在另一个类定义的内部,这就是嵌套类,嵌套类是声明在它的外层类中的,因此只能够通过外层类或外层类的对象对它进行访问。
2、类之间的关系及相应表示方法
聚合,组合,依赖,关联四种关系的强弱:
组合>聚合>关联>依赖。
3、三种主要的类版型及其表示方法
边界类:
实体类:
控制类:
边界类位于系统与外界的交界处每个参与者-用例对至少要有一个边界类,但并非每个参与者-用例对要生成唯一边界类,多个参与者可以用同一个边界类。
实体类描述要保存到持久存储体中的信息。
实体类可以通过事件流和交互图发现。
控制类是主要负责其它类工作的类。
4、类图的抽象层次
概念层(分析阶段)、说明层(设计阶段)、实现层(实现阶段)
——概念层:
描述应用领域中的概念
–一般这些概念与类有很自然的联系,但未必有直接的映射关系
•独立于程序设计语言,类的描述可能没有或有少量属性和操作名称
——说明层:
•描述软件的接口部分,不是实现部分
–接口可能因为实现环境等不同而有不同的实现
•主要列出属性和操作名称
——实现层
•考虑类的实现问题
•提供类的实现细节
——比较
•类图的三个层次之间没有一个清晰的界限
•三个层次的观点并不是UML的组成部分,但它
们对于画类图或者阅读类图非常有用
•指明类图层次的方法
–版型:
《implementationclass》《type》
5、多重性的概念
表示有多少个对象参与该关联
*(即0..n)0个或多个
四、对象图与包图
1、对象的特征以及命名方法
——状态、行为、标识
•对象的状态包括这个对象的所有属性(通常是静态的)以及每个属性当前的值(通常是动态的)
•为了将一个对象与其它所有对象区分开来,我们通常会给它起一个“标识”
•行为是对象根据它的状态改变和消息传递所采取的行动和所作出的反应;
对象的行为代表了其外部可见的活动;
操作代表了一个类提供给它的对象的一种服务。
•对象名
–“对象名:
类名”
–“:
类名”
–“对象名”
•属性
–“属性名=属性值”
2、对象和类的关系
•对象是一个存在于时间和空间中的实体,类仅代表一种抽象,抽象出对象的本质
•类是静态的,对象是动态的
•类是一般化,对象是个性化
•类是定义,对象是实例
•类是抽象,对象是具体
3、包在UML体系中的位置
基本构造块:
事物:
分组事物
•包是一种常规用途的组合机制
•在UML中,包是
–一种分组事物
–一个UML建模元素的容器
–通过包可将以下元素聚集在一起
•类
•用例
•构件
•……
4、包中可包含的元素
类、接口、构件、节点、协作、用例、其他子包或图
5、包的版型
•《system》版型
–表示正在建模的整个系统
•《subsystem》版型
–表示正在建模的系统中某个独立的部分
•《facade》版型
–是其它包的视图,主要为复杂的包提供简略视图
•《stub》版型
–是一个代理包,通常用于分布式系统的建模
•《framework》版型
–表示一个框架,框架是一个领域中的应用系统提供可扩充模板的体系结构模式
6、包之间的关系
依赖关系:
《use》《import》《access》《trace》
泛化关系
7、包图建模原则
重用等价原则:
•把类放入包中时,应考虑把包作为可重用的单元
•重用的粒度就是发布的粒度
•该原则倾向于把包做的越小越好
共同重用原则:
•不会一起使用的类不要放在同一个包中
•一个包中的所有类应该是共同重用的,如果重用了包中的一个类,就应该重用包中的所有类
•该原则倾向于把包做的尽可能小
共同闭包原则:
•把需要同时改变的类放在同一个包中
•以下情况两个类放在一个包中:
–一个类的改变要求另一个类做相应改变
–删除一个类后,另一个类变成多余
–两个类间有大量的消息发送
•该原则倾向于将包做的尽可能的大
非循环依赖原则:
•包之间的依赖关系不要形成循环
•包A依赖包B,包B依赖包C,包C依赖包A,形成了循环,怎么办?
•将这些包中的元素放入一个更大的包中
8、包内元素的可见性
•包内元素的可见性控制了包外部元素访问包内部元素的权限
•包的可见性有
–“+”表示“public”
–“#”表示“protected”
–“-”来表示“private
五、活动图
1、概念以及构成元素
•活动图描述系统或业务的一系列活动构成的控制流
•活动图描述系统从一种活动转换到另一种活动的整个过程
•活动图通常对业务过程、工作流和用例实现进行建模
初始节点、活动终点、活动节点、转换、分支和监护条件、分岔与汇合
2、活动图建模的原则
•尽量使用分支、分岔和汇合等基本建模元素绘制活动图
•根据活动图中是否要体现出不同的实施者,来决定是否采用泳道
•根据需要,加入对象流以及对象的状态变化
•根据需要,加入高级的建模元素(比如辅助活动图、汇合描述、信号节点、引脚及扩展区)
3、分岔与分支的区别
分岔:
活动是并发执行;有一个进入转换,有两个或多个离开转换
分支:
活动的转换是有条件的;有一个进入转换,一个或多个离开转换
六、状态机图
1、基本概念以及构成元素
•一个状态是指在对象的生命期中的一个条件或状况,在此期间对象将满足某些条件、执行某些活动或等待某些事件
•状态机图是一种用来表达状态机的图
•在状态机图中,状态节点由状态符号表示,状态之间的转换由连接状态节点的有向弧表示
•状态机图描述状态到状态的控制流程,常用来对系统的动态特征建模
•状态机图可以用于对不同建模元素的实体建模
•初态和终态
•源状态和目标状态
•触发事件
•监护条件
•动作
•分支
2、复合状态
•指状态本身包含一个或多个状态机的状态
•顺序复合状态–只包含一个状态机的复合状态
•并发复合状态–包含两个或两个以上并发执行的状态机
3、历史状态
•用于记住上次离开复合状态时所处的子状态
•表示方法
–浅历史
–深历史
七、交互图
1、分类
•顺序图(时序图,序列图)
•通信图(协作图)
•定时图
•交互概述图
2、顺序图基本概念、建模元素以及编号
•顺序图是显示对象之间交互的图,这些对象是按时间顺序排列的
•顺序图显示参与交互的对象及对象之间消息交互的顺序
•对象
•生命线
•控制焦点
•消息
顺序编号、嵌套编号
编号对协作图是必须的,对顺序图不必须。
3、通信图的组成元素
对象、链、消息
链:
•用来表示对象之间的语义连接
•一般而言,链是关联的一个实例
消息:
•通信图中的消息类型与顺序图中的相同
•为了说明交互过程中消息的时间顺序,需要给消息添加顺序号
–顺序号是在消息的前面加一个整数,每个消息都必须有唯一的顺序号
4、顺序图与通信图对比
•顺序图强调消息的时间顺序,通信图强调参加交互的对象的组织,两者可以相互转换
•顺序图不同于通信图的两个特征:
–顺序图有对象生命线
–顺序图有控制焦点
•通信图不同于顺序图的特征:
–通信图必须有消息顺序号
5、定时图与交互概述图的概念
•如果要表示的交互有很强的时间特性,使用定时图
•定时图是一种特殊的顺序图,其与顺序图的区别在于
–坐标轴交换了位置,改为从左到右来表示时间的推移
–用生命线的“凹下凸起”来表示状态的变化,每个水平位置代表一种不同的状态,状态的顺序可以有意义、也可以没有意义
–生命线可以跟在一根线后面,在这根线上显示不同的状态值
–可显示一个度量时间值的标尺,用刻度表示时间间隔
•交互概述图是将活动图和顺序图嫁接在一起的图
•可以看作活动图的变体
–它将活动节点进行细化,用一些小的顺序图来表示活动节点内部的对象控制流
•也可以看作顺序图的变体
–它用活动图来补充顺序图
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 复习 大纲 以及 整理
![提示](https://static.bdocx.com/images/bang_tan.gif)