UML概述.docx
《UML概述.docx》由会员分享，可在线阅读，更多相关《UML概述.docx（24页珍藏版）》请在冰点文库上搜索。
UML概述
面向对象软件工程
1.CMM的五个级别
2.构建一个软件产品时应当完成的步骤:
需求、分析、设计、实现、交付后维护、退役.
3.面向对象范型技术:
OO方法;结构化方法.
4.面向对象方法与结构化方法的区别：
直观,自然,简单;支持递增式开发;支持软件重用;软件结构更科学,更能够适应未来变化.
5.统一过程是今天面向对象软件生产最主要的选择。
统一过程的五个核心工作流:
需求流、分析流、设计流、实现流、测试流.
6.统一过程的著名方法：
Booch方法（项目设计和构造阶段表达力极强）--Rational
Jacobson的OOSE方法（用例来驱动需求捕获）--Objectory
*Rumbaugh的OMT方法（分析数据密集型信息系统）--通用
7.统一过程的各个阶段:
开始阶段;细化阶段,构建阶段,转换阶段.
UML
1.什么是UML？
Unifiedmodelinglanguage
一种通用建模语言。
用来对软件密集型系统进行详述、构造可视化和文档化。
2.软件建模可以达成的四个目标：
模型帮助我们视觉化一个系统;模型允许我们详述一个系统的结构或是行为;模型给出了指引我们建构系统的一个样板;模型记录了我们所做的决定.
3.在详细研究UML各种图形之前，我们一定要先了解一下4+1观点，1是核心，是用例视图，在用例视图的驱动下，有了其他四种视图，描述系统逻辑的逻辑视图、描述软件构件的构件视图、窥探软件不同进程之间活动的进程视图、描述软硬件最终部署的配置视图。
这些图的集合才最终完整的描述了软件系统的体系结构。
*4.UML视图概述:
我们需要对系统的动态行为建模。
顺序图/协作图——交互图——对象群体之间的交互。
活动图——单个或多个对象的一组操作。
状态图——状态图——单个对象的生命期建模。
（1）用例图:
用例图就是4+1观点当中的1-用例视图。
看定义。
用例是一种技术，什么样的技术？
apturingthefunctionalrequirementsofaSystem,捕捉系统需求的这样一种技术。
用例是怎么工作的呢？
WorkbydescribingthetypicalinteractionsbetweentheusersofaSystemandtheSystemitself。
描述用户和系统之间的典型交互。
它可以描述系统和用户之间是怎样进行交互的？
最后自然而然地，providinganarrativeofhowaSystemisused.描述了系统是如何被使用的。
以我们常见的自动饮料销售机为例。
在用例模型中，直立人形图标代表参与者，椭圆代表用例，参与者和用例之间的关联线代表两者之间的通信关系
（2）类图:
如果有人跟你说：
hi，我想给你看一个UML图，那么80%的可能性都是什么图呢？
类图。
我们来看类图的定义：
类图描述了系统中各种类型的对象以及对象间的各种静态关系。
类图描述的是一种静态关系，用类和它们之间的关系来描述系统的一种图,在系统的整个生命周期都是有效的。
比如：
ATM取款系统.
（3）对象图描述系统在某个特定时间的静态结构。
（4）状态图概念：
通过对类对象的生存周期建立模型来描述对象随事件发生变化的动态行为。
描述一个类对象所有可能的生命历程。
（5）顺序图:
类图和对象图表达的是系统的静态结构。
在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。
UML顺序图所表达的正是这种基于时间的动态交互。
水平轴表示不同的对象，垂直轴表示时间顺序。
对象、生命线、消息。
表示的是对象之间的消息传递的时间顺序。
通过顺序图，我们能够弄明白程序运行时，这些对象之间随着时间消息之间的交互过程和顺序。
（6）协助图:
用来描述对象之间动态的交互关系和连接关系。
着重体现关联关系、消息传递。
协作图描述对象间的协作关系，协作图跟顺序图相似，显示对象间的动态合作关系。
除显示信息交换外，协作图还显示对象以及它们之间的关系。
与顺序图的不同点：
实际上是把序列图中的消息和类图叠加在一起的结果。
交互对象的整体组织，布图方式。
（7）活动图:
用于表达系统的一个过程（流程）或操作的工作步骤。
（8）构件图显示代码本身的结构。
代码之间的依存关系。
一般来说，软件组件就是一个实际文件，可以是源代码文件、二进制代码文件和可执行文件等。
可以用来显示编译、链接或执行时构件之间的依赖关系。
（9）部署图:
系统在执行处理过程时的硬件部署情况，以及软件实现构件到硬件资源的映射关系。
5.UML组成:
6.UML构造块——
（1）事物:
代表面向对象中的类，对象等概念，是构成图的最基本的常用的元素。
一个模型元素可以用于多个不同的图中。
（1）UML中类是用一个矩形表示的，它包含三个区域，最上面是类名、中间是类的属性、最下面是类的方法.对象则是类的一个实例.见上图中的类和对象.
（2）用例——系统的一个功能:
系统的一组使用场景、执行的一系列动作。
（3）构件:
在实际的软件系统中，有许多要比“类”更大的实体，例如一个COM组件、一个DLL文件、一个JavaBeans、一个执行文件等等。
为了更好地对在UML模型中对它们进行表示，就引入了构件（也译为组件）
构件是系统设计的一个模块化部分，它隐藏了内部的实现，对外提供了一组外部接口。
在系统中满足相同接口的组件可以自由地替换
（4）节点:
为了能够有效地对部署的结构进行建模，UML引入了节点这一概念，它可以用来描述实际的PC机、打印机、服务器等软件运行的基础硬件
节点是运行时存在的物理元素，它表示了一种可计算的资源，通常至少有存储空间和处理能力.
（5）包:
对于一个中大型的软件系统而言，通常会包含大量的类，因此也就会存在大量的结构事物、行为事物，为了能够更加有效地对其进行整合，生成或简或繁、或宏观或微观的模型，就需要对其进行分组。
在UML中，提供了“包（Package）”来完成这一目标.
（6）注释元素:
注释事物则是用来锦上添花的，它是用来在UML模型上添加适当的解释部分
7.UML构造块——（2关系
事物之间的关系:
关联：
连接（connect）模型元素及链接（link）实例。
依赖：
表示一个事物以某种方式依赖于另一种事物。
泛化：
表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化。
聚合、组合：
表示整体与部分的关系。
（1）关联—方向性
关联关系提供了通信的路径，它是所有关系中最通用、语义最弱的;
关联关系是有方向的，我们使用箭头来表示。
当A作用于B时，那我们就将箭头指向B。
我们需要准确的描述事物之间的关联的方向。
（2）关联—多重性
一个类可以和多个类关联
多个类可以和同一个类关联
（3）特定数字
非特定数字
“0..*”或“*”：
表示“0”或“多”；
“1..*”：
表示“1或多”；
特定范围m..n
枚举，or
（3）
关联—依赖
有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖（Dependency）于元素X。
（4）聚合关系是一种弱的“拥有”关系;组合关系是一种强的“拥有”关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
聚合关系:
聚合（Aggregation）是一种特殊形式的关联。
聚合表示类之间的关系是整体与部分的关系。
组合关系：
Composition。
组合是聚合的变种，加入了一些重要的语义。
如果发现“部分”类的存在，是完全依赖于“整体”类的，那么就应该使用“组合”关系来描述。
在组成体中，部分体有时可能会先于组成体消亡，如果组成体被销毁，则部分体随组成体一同被销毁.
（5）泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。
泛化的几种种类:
抽象类——指没有实例的类，定义一些抽象的操作，即不提供实现方法的操作，只提供操作的特征。
并附以{abstract}。
交叠泛化——在继承树中，若存在某种具有公共父类的多重继承，称为是交叠{overlapping}的。
否则是不交的{disjoint}。
完全泛化——一般类特化出它所有的子类，称为完全泛化，记为{complete}。
不完全泛化——即未特化出它所有的子类，称为是不完全泛化的，表示为{incomplete}.
（6）可以对关联施加约束。
在这个例子中，Serves关联上的{ordered}约束说明银行出纳员要按照顾客排队的次序为顾客服务;
（7）链是关联的实例。
链连接的是对象而不是类。
和对象名要加下划线一样，链名也要加下划线.例如：
特定的队员效力一个特定的球队
（8）自身关联的关联线从某个类出发又回到其自身。
自身关联也可以指明角色名、关联名、关联方向和多重性;一个类的对象可以充当多种角色时，自身关联就可能发生.
（9）UML有一套贯穿整个语言且一致应用的公共机制，使得UML变得较为简单，且建筑风格一致。
规格说明;修饰;通用划分;扩展机制
类图
1.如何读类图？
先看清有哪些类，然后看看类之间存在的关系，并结合多重性来理解类图的结构特点以及各个属性和方法的含义.
2.抽象类:
不能够直接被实例化的类;抽象操作:
没有实现，纯声明;描述方式:
采用斜体进行表达.当在白板上不好操作时，可以采用{abstract}{a}.
接口的定义:
也是一个类，定义了一组提供给外界的操作；接口类没有实现；<>标识.
声明时使用抽象接口，而创建时使用到具体类。
3.CRC卡是一种非正式的面向对象技术，它可以帮助我们发现和理清类之间的关系。
4.定义系统的对象和类:
Step1——确定对象类;Setp2——标识对象类的属性;Setp3——标识对象类的操作;Step4——标识对象类之间的关联（协作）;Step5——复审类的定义;Step6——建立类图.
用例
1.用例图用来图示化系统的主事件流程，描述客户的需求，即用户希望系统具备的功能，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系。
是设计系统分析阶段的起点。
用例图是用来描述系统功能的，那么怎样来描述呢？
引入具体的用例图。
2.用例图符号
3.执行者（actor）是指在系统外部与系统交互的人或其他系统，他以某种方式参与了系统内用例的执行。
定义执行者（参与者）时应注意的几个问题:
（1）执行者可以有泛化关系;
（2）执行者代表一种角色而不是具体某个人;（3）对同一个人担任角色的限制;（4）执行者可分成主执行者和副执行者;（5）执行者还可细分为主动执行者和被动执行者;（6）执行者分为启动者和支持者.启动用例的执行者，特称为“启动者”（INITATOR），其余不具有启动特质的执行者，可称之为“支持者”（SUPPORT）.
*注意:
执行者不一定是人,也有可能是其他系统.执行者的种类:
直接使用系统的人;直接与系统交互的硬件设备（电子显示屏、电话通话计时设备等）;直接与系统交互的外部系统
系统分析员在绘制用例图时，可以采用下列几项常见做法：
采用带箭头关系线，让启动者指向用例，用例指向支持者，这样一来，从图面上就可以明确分辨出启动者与支持者。
一个用例通常只有一个启动者，不过可能出现多个支持者。
详见上图.
4.用例图的关系
（1）包含关系：
使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便被多个基（Base）用例复用。
包含关系最典型的应用就是复用。
前者称为“基用例”（BaseUC），后者称为“包含用例”（InclusionUC）。
（2）两个用例之间可以有“扩展”关系，用以表示某一个用例的对话流程，可能会依条件临时插入另一个用例的对话流程中。
前者称为“扩展用例”（ExtensionUC），后者称为“基用例”（BaseUC）。
（3）泛化关系：
子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。
子用例可以使用父用例的一段行为，也可以重载它。
例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：
泛化侧重表示子用例间的互斥性；
包含侧重表示被包含用例对Actor提供服务的间接性；
扩展侧重表示扩展用例的触发不定性；
5.应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。
除此之外，我们还需要描述每一个用例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。
6.用例描述有许多种方法，如简单文字、模板、表格、形式化语言和图形等，开发人员可根据项目进展及用户特点灵活选择。
用例描述格式:
基本用例信息;执行流程;条件或规则;相关文档;优先级.
7.需求分析阶段流程:
（1）定义业务流程（业务用例模型）;
（2）分析业务流程（活动图）;（3）定义系统范围（系统用例图）.
活动图
1.活动图是用于表达系统的一个过程（流程）或操作的工作步骤。
常被用于：
（1）描述用例——业务流程（过程）；
（2）描述类的操作——计算的细节部分；
2.活动图的特点
（1）自动执行:
活动状态迁移不需要事件触发，活动执行完毕可以直接进入下一个活动状态；当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。
（2）描述并发:
活动图中还可以方便地描述并行执行要求。
活动图最适合支持描述并行行为，这使之成为支持工作流建模的最好工具。
（3）分类特性:
活动置于责任区（泳道）中，责任区将活动按责任目标和组织归属的原则分类。
3.活动图的基本描述图符:
（1）活动：
是真实世界的一个动作处理、一组动作程序。
（2）迁移：
用带箭头的实现表示，箭尾链接出发活动（源活动），箭头链接到达活动（目标活动）。
活动图中的迁移是无条件的，一个活动结束即可自动进入到下一个活动。
（3）有条件的迁移：
当一个动作或活动完成时直接到下一个活动的控制。
转换有成立条件的控制，以一个箭头旁注明的[成立条件]来表示.
（4）起始活动：
代表活动图的起始点，本身无活动。
起始活动是迁移的开始源点，不是迁移的目标。
起始活动由一个实心圆表示。
（5）结束活动：
代表活动图的最后活动，本身无活动，是活动图的终止点，结束活动是迁移的最后目标，不是迁移的源。
结束活动由一个圆形中套一个实心圆表示。
（6）条件判定：
与程序设计语言中条件分支类似，条件判定是一个转折点，活动迁移按照满足条件的方向进行。
条件判定图符用空心菱形表示，条件判定通常为一个入迁移，多个出迁移。
条件是一个逻辑表达式，活动迁移沿判定条件为真的分支迁移。
分支:
分支是用于表达当转换发生后，有多个选择路径，但仅能依条件选择其中一个路径执行之。
分支之表达符号是以一菱形，外加一条流入菱形之箭头与多条流出菱形之箭头表示。
合并:
合并是用于表达有多个路径汇集于某点，之后再往下一个路径执行。
合并之表达符号与分支相似，是以一菱形外加多条流入菱形之箭头与一条流出菱形之箭头表示。
（7）判定:
判定的两种方式如下图所示:
（注意菱形）
（8）并发活动：
并发活动描述活动的同步工作状态。
分岔（Fork）:
分岔是用于表达当转换发生后，有两个或两个以上之平行活动发生的情況。
分岔之表达符号是以一橫向黑实线条，外加一条流入之垂直箭头与多条流出之垂直箭头表示。
汇合（Join）:
接合是用于表达平行活动结束之情况，表达符号与分岔类似是以一横向黑实线条，外加多条流入之垂直箭头与一条流出之垂直箭头表示。
一定跟分岔（Fork）成双成对使用.
4.活动图的基本概念:
动作状态;活动状态;动作流;分支与合并;分叉与汇合;泳道;对象流.
（1）动作状态是原子的，动作状态是不可中断的状态，动作状态是瞬时的行为
（2）活动状态拥有一组不可中断的动作或操作，表达一个非原子性活动的运行。
（3）动作流：
表达不可中断的动作或操作的执行。
所有动作状态之间的转换流称之为动作流。
（4）一个分支有一个入转换和多个带条件的出转换，出转换的条件应当是互斥的，这样可以保证只有一条出转换能够被触发。
（5）一个合并有多个带条件的入转换和一个出转换，合并表示从对应的分支开始的条件行为的结束。
（6）分叉:
用于将动作流分为两个或者多个并发运行的分支;
汇合:
用于同步这些并发分支，以达到共同完成一项事务的目的;
分叉和汇合都使用加粗的水平线段表示;分叉和汇合必须成双配对使用，必须个数一致。
（7）泳道代表对象对活动的责任。
每个活动只能明确地属于一个泳道。
泳道没有顺序，不同泳道中的活动既可以顺序进行也可以并发进行，动作流和对象流允许穿越分隔线。
（8）对象流是活动与对象之间的依赖关系，表示动作使用对象或者动作对对象的影响。
流用带有箭头的虚线表示。
活动图实例:
顺序图
1.
2.顺序图:
描述对象按时间顺序的消息交换过程，它体现出系统用例的行为。
协作图:
描述对象间的组织协作关系，它也可体现出系统用例的行为。
顺序图和协作图都可以表示对象间的交互关系，但它们的侧重点不同。
3.顺序图的基本构成元素:
顺序图有两个主要的标记符：
活动对象和这些活动对象之间的通信消息。
（1）活动对象:
活动对象可以是系统的参与者或者任何有效的系统对象。
对象是类的实例，它使用包围名称的矩形框来标记。
从表示对象的矩形框向下的垂直虚线是对象的生命线，用于表示在某段时间内该对象是存在的。
（2）消息:
消息用来说明顺序图中不同活动对象之间的通信。
消息说明了对象之间的控制流，对象是如何交互的，以及什么条件会改变控制流。
（限制条件）
消息类型:
一条异步消息每次只发一个信号，即只做一件事.
5.顺序图中的动作:
创建对象;销毁对象;使用状态;修改控制流
6.在分支中，消息的开始位置是相同的，分支消息的结束高度也是相等的。
这说明在下一步中，其中之一将会执行。
7.消息内容标识的格式为：
[序号][条件]*[重复次数][回送值表：
=]操作名（参数表）
8.创建顺序图包含4个步骤：
确定需要建模的工作流;从左到右布置对象;添加消息和条件以便创建每一个工作流;绘制总图以便连接各个分图。
协助图
1.协作图:
描述对象间的组织协作关系，它也可体现出系统用例的行为。
按组织对控制流建模，强调交互中实例之间的结构关系以及所传送的消息。
侧重于对象之间的交互和链接。
描述了对象及其之间的链接，链接的对象之间如何发送消息。
2.协作图的组成成分
（1）对象:
对象在协作图中担当一个具体的角色，可以把对象名写为具体的角色名，如不标明角色，则说明该对象为一个匿名对象。
（2）链接:
自身《self》;全局《global>>;局部《local》;参数《parameter》;
广播性《broadcast》（指出这组消息没有确定的目标对象，系统中每个对象都是其潜在的目标对象）
（3）消息:
消息是传送信息的对象之间所进行的通信的详述，该信息带有对将要发生地活动的期望。
消息的种类:
（4）消息的序列:
一个对象又可能发送消息给下一个不同的对象，一直传下去，这个消息形成了一个序列。
3.对象创建：
{new}；说明对象实例或链是在交互的执行过程中被创建的。
对象消亡：
{destroyed}；说明对象实例或链将在交互全部执行完成之前被撤销。
对象创建并消亡：
{transient}。
说明对象实例或链在交互过程中被创建，并在交互执行完成之前被撤销。
升级会员 