面向对象软件开发需要经过OOA(面向对象分析)、OOD(面向对象设计)和OOP(面向对象编程)三个阶段。OOA对目标系统进行分析,建立模型,并将之文档化;OOD用面向对象的思想对OOA的结果进行细化,得出设计模型。OOA和OOD的分析、设计结果需要统一的符号来描述、交流并记录,UML就是这种用于描述、记录OOA和OOD结果的符号表示法。
如图,UML2.0一共包括13种正式图形:活动图(activity diagram)、类图(calss diagram)、通信图(communication diagram)、组件图(component diagram)、复合结构图(composite structure diagram)、部署图(deployment diagram)、交互概观图(interactive overview diagram)、对象图(object diagram)、包图(package diagram)、顺序图(sequence diagram)、状态机图(state machine diagram)、定时图(timing diagram)、用例图(use case diagram)。
真的太多了,谁设计的,头皮发麻。其实很少有一个软件系统在分析、设计阶段对每个细节都使用13种图形来表现。记住一点:不要把UML表示法当成是一种负担,而应该把它当成一种工具,一种用于描述、记录软件分析设计的工具。最常用的UML图包括例图、类图、组件图、部署图、顺序图、活动图和状态机图等。
用例图用于描述系统提供的系列功能,而每个用例则代表系统的一个功能模块。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的需求功能,用例图对系统的实现不做任何说明,仅仅是系统功能的描述。
用例图包括用例(以一个椭圆表示,用例的名称放在椭圆的中心或椭圆下面)、角色(Actor,也就是与系统交互的其他实体,以一个人形符号表示)、角色和用例之间的关系(以简单的线段来表示),以及系统内用力之间的关系。用例图一般表示出用例的组织关系——要么是整个系统的全部用例,要么是完成具体功能的一组用例。
用例图通常用于表达系统或者系统范畴的高级功能。如图所示,很容易看出该系统所提供的功能。这个系统允许注册用户登录、发帖和回复,其中发帖和回复需要依赖于登录;允许管理员删除其他人的帖子,删帖也依赖于登录。
用例图主要在需求分析阶段使用,主要用于描述系统实现的功能,方便与客户交流,保证系统需求的无 性,用实例图表示系统外观,不要指望用例图和系统的各个类之间有任何联系 不要把用例做得过多,过多的用例将导致难以阅读,难以理解:尽可能多地使用文字说明。
类图是最古老、功能最丰富、使用最广泛的UML图。类图表示系统中应该包含哪些实体,各实体之间如何关联;换句话说,它显示了系统的静态结构,类图可用于表示逻辑类,逻辑类通常就是业务人员所谈的食物种类。
类在类图上使用包含三个部分的矩形来描述,最上面的部分显示类的名称,中间部分包含类的属性,最下面的部分包含类的方法。
特别好理解这个,类图除可以表示实体的静态内部结构之外,还可以表示实体之间的相互关系。类之间有三种基本关系:
客观世界中两个实体之间总是存在一定的关系。当两个实体抽象到软件系统中时,两个类之间必然存在关联,关联具有一定的方向性。如果仅能从一个类单方向地访问另一个类,则被称为单向关联,;如果两个类可以互相访问对象,则被称为双向关联。一个对象能访问关联对象的数目被称为多重性,例如,建立学生和老师之间的单向关联,则可以从学生访问老师,但从老师不能访问学生关联使用一条实线来表示,带箭头的实线表示单向关联。
关联关系包括两种特例:聚合和组合,它们都有部分和整体的关系,但通常认为组合比聚合更加严格。当某个实体聚合成另一个实体时,该实体还可以同时是另一个实体的部分,例如,学生既可以是篮球俱乐部的成员,也可以是书法俱乐部的成员 当某个实体组合成另 个实体时,该实体则不能同时是一个实体的部分。聚合使用带空心菱形框的实线表示,组合则使用带实心菱形框的实线表示。
如图,Teacher和Student之间的关联关系:他们是双向关系,而且使用了多重性来表示Teacher和Student之间存在1:N的关联关系(1…*表示可以一个到多个),即一个Teacher实体可以有1个或多个关联的Student实体;Student和BasketBallClub存在整合关系,即一个或多个Student实体可以聚合成一个BasketBallClub实体;而Arm(手臂)和Student之间存在组合关系,2个Arm实体组合成一个Student实体。
泛化与继承是同一个概念,都是指子类是一种特殊的父类,类与类之间的继承关系是非常普遍的,继承关系使用带空心三角形的实践表示。
如图可以看出,Student是Person的子类,即Student类是一种特殊的Person类。
如果一个类的改动会导致另一个类的改动,则称两个类之间存在依赖。依赖关系使用带箭头的虚线表示,其中箭头所指向被依赖的实体。依赖的常见可能原因如下:
(1)改动的类将消息发送给另一个类
(2)改动的类以另一个类作为数据部分
(3)改动的类以另一个类作为操作参数
通常而言,依赖是单向的,尤其是当数据表现和数据模型分开设计时,数据表现依赖于数据模型。
其中当DefaultTableModel发生改变的时候,JTable将相应地发生改变。记住!!!,跟我们理解有点反向,JTable是受改变方。
对于现代的大型应用程序而言,通常不只是单独一个类或单独一组类所能完成的,通常会由一个或多个可部署的组件完成。对Java程序而言,可复用的组件通常打包成一个JAR、WAR等文件;对C/C++应用而言,可复用的组件通常是一个函数库,或者是一个DLL(动态链接库)文件。
组件图提供系统的物理视图,它的用途是显示系统中的软件对其他软件组件(例如,库函数)的依赖关系。组件图可以在一个非常高的层次上显示,仅显示系统中的粗粒度的软件,也可以在组件包层次上显示。
组件图通常包含组件、接口和Port等图元,UML使用带两个矩形加一个大矩形的符号表示(如下图所示),使用圆圈代表接口,使用位于组件边界上的小矩形代表Port。
组件的接口表示它能对外提供的服务规范,这个接口通常有两种表现形式。
(1)用一条实线连接到组件边界的圆圈表示
(2)使用位于组件内部的圆圈表示
组件除可以对外提供服务接口之外,组件还可能依赖于某一个接口,组件依赖于某个接口使用一条带半圆的实线来表示。
如图所示,本系统绘制电子购物平台的几个核心组件,其中Order组件提供OrderQuery接口,该接口允许Dispatch组件查询系统中的订单及其状态,Order组件又需要依赖于Customer组件的CustomerLookup接口,通过该接口查询系统中的顾客信息;Order组件也需要依赖于Inventory组件的ProductQuery接口,通过该接口查询系统中的产品信息。
现代的软件工程早已超出早期的单机程序,整个软件可能是跨国家、跨地区的分布式软件,软件的不同部分可能需要部署在不同地方、不同平台上。部署图用于描述软件系统如何部署到硬件环境中,它的用途是显示软件系统不同的组件将在何处物理允许,以及它们将如何彼此通信。
因为部署图是对物理运行情况进行建模,所以系统的生产人员就可以很好的利用这种图来进行安装、部署软件系统。
部署图中的符号包括组件图中所使用的符号元 ,另外还增加了节点的概念:节点是各种计算资源的通用名称,主要包括处理器和设备两种类型,两者的区别是处理器能够执行程序的硬件构件(如计算机主机) ,而设备是 种不具备计算能力的硬件构件(如打印机 UML 中使用 维立方体来表示节点,节点的名称位于立方体的顶部 17 显示了 个简单的部署图。
整个应用分为5个组件:Student、Administrator、应用持久层、Student数据库和UI界面组件,部署图准确地表现了各组件之间地依赖关系。其中普通客户端无须部署任何组件,直接使用客户端浏览器即可 管理者客户机上需要部署 UI 界面 应用服务器上需要部署 Student Administrator应用持久层 个组件:而数据库服务器上需要部署 Student 数据库。
顺序图显示具体应用(或者是用例地一部分)的详细流程,并且显示流程中不同对象之间的调用关系,同时还可以很详细地显示对不同对象地不同调用。顺序图描述了对象之间的交互(顺序图和通信图都被称为交互图),重点在于描述消息及时间顺序。
顺序图有两个维度:垂直维度,以发生的时间顺序显 消息 调用的序列;水平维度,显示消息被发送到的对象实例 顺序图的关键在于对象之间的消息,对象之间的信息传递就是所谓的消息发送,消息通常表现为对象调用另 个对象的方法或方法的返回值,发送者和接收者之间的箭头表示消息。
顺序图的绘制非常简单 顺序图的顶部每个框表示每个类的实例(对象) 框中的类实例名称和类名称之间用冒号或空格来分隔 ,例如myReportGenerator : ReportGenerator 如果某个类实例向另 个类实例发送一条消息,则绘制 条指向接收类实例的带箭头的连线 ,并把消息/方法的名称放在连线上面。
对于某些特别重要的消息,还可以绘制 条带箭头的指向发起类实例的虚线上, 将返回值标注在虚线绘制带返回值的信息可以使得序列图更易于阅读。
当绘制顺序图时,消息可以向两个方向扩展,消息穿梭在顺序图中,通常应该把消息发送者与接收者相邻摆放,尽量避免消息跨越多个对象。对象的激活期不是其存在的时间,而是它占据 PU 的执行时间,绘制顺序图时,激活期要精确。
阅读顺序图也非常简单,通常从最上面的消息开始(也就是时间上最先开始的消息) ,然后沿消息方向依次阅读。
PS:与顺序图相似的还有通信图,一般来说,通信图可以描述的内容,顺序图都可以描述,但是顺序图比通信图多了时间观念。
活动图和状态机图都被称为演化图,其区别和联系如下:
演化图的5要素如下:
对于激发对象状态改变的事件,通常有如下两种类型:
活动图主要用于描述过程原理、业务逻辑以及工作流技术 活动图非常类似于传统的流程图 它也使用圆角矩形表示活动 ,使用带箭头的实线表示事件:区别是活动图支持并发。
如图,如果将这个活动图的两支分开,每支就是 个传统的流程图,每个活动依次向下 ,遇到条件分支使用菱形框来表示条件 ,与传统的流程图不同的是 ,活动图可 以使用并行分支分出多条并行活动。
绘制活动图时以活动为中心, 整个活动图只有 个开始活动,可以有多个结束活动.活动图需要将并行活动和串行活动分离,遇到分支和循环时最好像传统的流程图那样将分支、循环条件明确表示动图最大优点在于支持并行行为,并行对于工作流建模和过程建模非常重要 所以有了并行 因此需要进行同步,同步通过汇合来指明。
状态机图表示某个对象所处的不同状态和该类的状态转换信息。 实际上, 通常只对"感兴趣的"对象绘制状态机图。 就是说, 在系统活动期间具有 三个或更多潜在状态的对象才需要考虑使用状态机图进行描述。
状态机图的符号集包括5个基本元素:
终于结束了,实话说,这一部分的内容太太太枯燥难懂了。下面就来做一个总结吧: