一图胜千言。
作为人类最古老的交流方式。
- UML对于开发者来讲,个人开发者也好,最重要的是让你的系统是思考过的。
- UML对于公司中的来讲, 也是,让系统的结构上有一个更直观的记录。而且交流起来确实比代码方便。因为代码以里有各种喜好,而UML没有。只是简单的关系。
面向对象方法的概念
-
对象
-
世界上万事万物都可以看作一个对象,这些是现实中的实体也被称作客观对象。
-
客观对象可以抽象其某些属性和方法来研究在某个问题或场景中的性质,这被称为问题对象。
-
抽象出来的问题对象通过封装等过程称为计算机中的一个包含有数据和操作的集合体,这被称为计算机对象
-
三者之间的关系:
客观对象(抽象) -> 问题对象(封装) < - > 计算机对象(模拟)。
-
一个对象应该是具有状态、行为和标识符的实体,并且对象之间往往可以通过通信互相交互。
-
对象有以下4个特性:
-
自治性
-
封闭性
-
通信性
-
被动性
-
-
-
类
-
类是拥有共同的结构、行为和语义的一组对象的抽象。类可以作为对象的一种描述机制,用来刻画一组对象的公共属性与公共行为,也可以用来作为程序的一个单位,用来形成程序中更大的模块。
-
类可以从以下4个角度来理解:
-
类是面向对象程序中的构造单位。一个面向对象程序就是一组相关的类。
-
类是面向对象程序设计语言的基本成分。在面向对象编程语言中,类内的成分是无法单独构成程序的,程序应该至少包含一个完整的类。
-
类是抽象数据类型的具体表现。类可以表示一种数据类型的抽象并给出了具体的数据结构表示与操作的实现方法。
-
类刻画了一组相似对象的共同特征。在面向对象程序的运行时,对象是根据类的定义而创建的,同类的对象具有相同的属性与操作。对象又被称为累的实例。
-
-
-
抽象
- 抽象就是揭示一个事物区别于其他事物的本质特征,去除从某一个角落看起来不重要的细节行为。
- 抽象具有动态与静态的属性。例如:文件的文件名属于静态,大小与内容为动态,常被抽象为对象的操作。
-
封装
- 封装即对其客户隐藏对象的属性和实现细节,仅对外公开接口,并控制在程序中属性的读和修改的访问级别。
- 封装强调两个概念,即独立和封闭。
- 独立是指对象是一个不可分割的整体,它集成了事物全部的属性和操作,并且他的存在不依赖于外部事物。
- 封闭是指与外部的事物通信时,对象要尽量的隐藏其内部的实现细节,它的内部信息对外界来说是隐蔽的,外界不能直接访问对象的内部信息,而只能通过有限的接口与对象发生联系。
- 类是数据封装的工具,而对象是封装的实现。类的成员又分为共有成员、私有成员和保护成员,他们分别有不同的访问控制机制。封装是软件模块化思想的重要体现。
-
泛化
- 泛化是类元的一般描述和具体描述之间的关系,具体描述建立在一般描述的基础之上,并对其进行了扩展。具体描述完全拥有一般描述的特性、成员和关系,并且包含补充的信息。
- 实现泛化关系的机制为继承(inheritance)。一个子类(subclass)继承一个或多个父类(superclass),从而实现了不同的抽象层次,实现两者之间的泛化关系。通过这种关系,子类可以共享其父类的结构和行为,从而容易复用已经存在的数据和代码,并实现多态处理。
-
多态
- 多态是在同一接口下表现多种行为的能力,是面向对象技术的根本特征。
面向对象方法的优点
在实际开发过程中,需求通常不稳定,在使用时,数据和功能最容易发生改变,而对象一般则是相对稳定的。
复用性也是面向对象方法带来的优势之一。面向对象方法通过封装、继承、聚合等手段,在不同层次上提供各种代码复用,以此提高软件的开发效率。
除此之外,面向对象方法还有改善软件结构、增强扩展性、支持迭代式开发等优势。
统一建模语言UML
统一建模语言UML是一种通用的可视化建模语言,可以用来描述、可视化、构造和文档化软件密集型系统的各种工作。
记录了与被构建系统的有关的决策和理解,可用于对系统的理解、设计、浏览、配置、维护以及控制系统的信息。
UML的应用范围
UML以面向对象的方式来描述系统。最广泛的应用是对软件系统进行建模,但它同样适用于许多非软件系统领域的系统。从理论上说,任何具有静态结构和动态行为的系统都可以使用UML进行建模。当UML应用于大多数软件系统的开发过程时,它从需求分析阶段到系统完成后的测试阶段都能起到重要作用。
在测试阶段,可以用UML图作为测试依据:用类图指导单元测试,用组件图和协作图指导集成测试,用用例图指导系统测试等。
初识UML
想要理解和使用UML,需要掌握UML的概念模型。UML的概念模型主要包括基本构造快、运用于构造快的通用机制和用于组织UML试图的架构。
UML构造快
构造块(building block)指的是UML的基本建模元素,是UML中用于表达的语言元素,是来自现实世界中的概念的抽象描述方法。
构造块包括事物(thing)、关系(relationship)和图(diagram)三个方面的内容。
- 事物是对模型中关键元素的抽象体现;
- 关系是事物和事物间联系的方式;
- 图是相关的事物及其关系的聚合表现。
事物
在UML中,事物是构成模型图的主要构造块,它们代表了一些面向对象的基本概念,事物被分为以下四种类型。
-
结构事物
结构事物(structural thing)通常作为UML模型的静态部分,用于描述概念元素或物理元素。结构事物总称为类元(classifier)。常见的结构事物有类、接口、用例、协作、组件、节点等。
- 类(class)是对具有相同属性、相同操作、相同关系和相同语义的一组对象的描述。在UML图中使用矩形表示类,核心内容包括类名、属性、方法(操作)。
- 接口(interface)是一组操作的集合,这些操作包括类或组件的动作,描述了元素的外部可见行为。接口仅仅定义操作的数量和特征,但不提供具体的实现方法。接口可以被类继承,继承了某接口的类必须提供该接口所有操作的实现。接口一般不需要属性。在UML中接口的声明也使用矩形描述,在接口名上方使用构造型<
>与类做区分。[见书 p17] - 协作(collaboration)定义了一个交互,它是在为实现某个目标而共同工作、相互配合的多个元素之间的交互动作。协作具有结构、行为和纬度,一个类或对象可以参与多个协作。在UML图中把协作画成虚线椭圆,仅包含名称。这种表示法允许从外部把一个协作视为一个整体,但我们通常不使用这种表示方式,而是对协作内部更感兴趣。因此,我们往往会放大一个协作,将其内部细节引导到一些图中——特别是类图(用来表示协作的结构部分)和交互图(用来表示协作的行为部分)。
- 用例(use case)描述了一组动作序列,这些动作序列将作为服务由特定的参与者触发或执行,在过程中产生有价值、可观察的结果,结果可反馈给参与者或作为其他用例的参数。在UML图中用例表示为实现椭圆,仅包含名称。
- 组件(component)是系统中封装好的模块化部件,仅将外部接口暴露出来,内部实现被隐藏。组件可以由部件和部件之间的连接表示,其中部件也可以包含更小的组件。接口相同的部件可以互相替换。在UML图中将组件表示称矩形框,左边框上附着两个小矩形,框内些组件名。
- 节点(node)是在软件部署时需要的物理元素,其本质为一种计算机资源。一组组件可以存在于一个节点内,也可以从一个节点迁移到另一个节点。在UML图中节点用一个立方体表示,仅包含名称。
-
行为事物
行为事物(behavioral thing)也称为动作事物,是UML模型的动态部分,用于描述UML模型中的动态元素,主要为静态元素之间产生的时间和空间上的行为动作,类似于句子中动词的作用。
- 交互(interaction)描述一种行为,它产生于协作完成一个任务的多个元素之间。交互包含消息、状态和连接。在UML图中消息表示为实箭头,源自消息发出者,指向接收者,箭头上方写操作名。
- 状态机(state machine)定义了对象或行为在生命周期内的状态转移规则。状态机中包含状态、转移、条件(事件)以及活动。UML图中的状态机表示为圆角矩形,包含状态名。
- 活动(activity)描述了一个操作执行时的过程信息。一个活动包含在操作执行过程中每一个步骤(动作)之间的先后序列关系。UML图中的活动也表示为圆角矩形,它和状态机图例的区分依靠语义。
-
分组事物
分组事物(grouping thing)又称组织事物,是UML模型的组织部分,是用来组织系统设计的事物。主要的分组事物是包,另外,其他基于包的扩展事物(例如子系统、层等)也可作为分组事物。
-
注释事物
注释事物(annotation thing)又称辅助事物,是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素,简言之就是对UML中元素的注释。最主要的注释事物就是注解(note),是依附于一个元素或一组元素之上对其进行约束或解释的简单符号,内容为对元素的进一步解释文本。这些解释文本在UML图中可以附加到任何模型的任意位置上,用虚线连接到被解释的元素,当不需要显示注解时可以隐藏,也可以以链接形式放到外部文本中(如果注释很长)。几乎所有的UML图形元素都可以用注解来说明。
关系
关系是模型元素之间具体化的语义连接,负责联系UML的各类事物,构造出结构良好的UML模型。
在UML中有四种主要的关系:
- 关联(association):描述不同类元的实例之间的连接。它是一种结构化的关系,指一种对象和另一种对象之间存在联系,即“从一个对象可以访问另一个对象”。更详细地,我们说两个对象之间互相可以访问,那么这是一个双向联系,否则称为单项联系。关联中还有一种特殊的情况,称作聚合关系,聚合表示两个类元的实例具有整体和部分的关系,表示整体的模型元素可能是多个表示部分的模型元素的聚合。
- 依赖(dependency):描述一对模型元素之间的内在联系(语义关系),若一个元素的某些特性随某一个独立元素的特性的改变而改变,则这个不是独立的,它依赖于上文所给的那个独立元素。
- 泛化(generalization):类似于面向对象方法中的继承关系,是特殊到一般的一种归纳和分类关系。泛化可以添加约束条件,说明该泛化关系的使用方法或扩充方法,称为受限泛化。
- 实现(realization):描述规格说明和其实现的元素之间的连接的一种关系。其中规定说明定义了行为的说明,真正的实现由后一个模型元素来完成。实现关系一般用于两种情况下:接口和实现接口的类和组件之间与用例和实现它们的协作之间。
这四种关系是UML模型中包含的最基本的关系,它们可以扩展和变形。
图
图是一组模型元素的图形表示,是模型的展示效果。多数的UML图是由通过路径连接的图形构成的。信息主要通过拓扑结构表示,而不依赖于符号的大小或者位置(有一些例外,如顺序图)。
根据UML图的基本功能和作用,可以将其划分为两大类:结构图(structure diagrams)和行为图(behaviour diagrams)。
结构图捕获事物与事物之间的静态关系,用来描述系统的静态结构模型;
行为图则捕获事物的交互过程如何产生系统的行为,用来描述系统的动态行为模型。
UML2
规范中包含14种图:类图、对象图、组合结构图、组件图、部署图、包图、外廓图、用例图、活动图、状态机图、顺序图、通信图、时序图、交互概念图。
UML通用机制
UML提供了四种通用机制,它们被一直地应用到模型中,描述了达到面向对象建模目的的4种策略,并在UML的不同语境下被反复运用,是的UML更简单并易于使用。
这四种机制分别是:规格说明(specifications)、修饰(adornments)、通用划分(common divisions)和扩展机制(extensibility mechanisms)。
规格说明
UML不仅仅是一个图形化的语言,恰恰相反,在每个图形符号后面都有一段描述用来说明构建模块的语法和语义。
UML的规格说明用来对系统的细节进行描述,在增加模型的规格说明时可以确定系统的更多性质,细化对系统的描述。通过规格说明,我们可以利用UML构建出一个可增量的模型,即首先分析确定UML图形,然后不断对该元素添加规格说明来完善其语义。
修饰
UML中大多数的元素都有一个唯一的和直接的图形符号,用来给元素的最重要的方面提供一个可视的表达方式。
修饰是对规格说明的文字的或图形的表示。
在UML中的每个元素符号都以一个基本的符号开始,在其上添加一些具有独特性的修饰。
通用划分
在面向对象系统建模中,通常有几种划分方法,其中最常见的两种划分是类型-实例与接口-实例。
UML扩展机制
构造型(stereotype)
标记值(tagged value)
约束(constraint)
用例图
用例图(use case diagram)是表示一个系统中用例与参与者关系之间的图。它描述了系统中相关的用户和系统对不同用户提供的功能和服务。
用例图是UML中对系统的动态方面建模的五种图之一(其他四种是活动图、状态机图、顺序图和通信图),是对系统、子系统和类的行为进行建模的核心。
用例图的组成元素
-
参与者
凡有用例,必存在参与者。一个不能被任何用户感知到的“功能”和“事物”,在系统中存在的意义又是什么呢? 太精辟了!
什么是参与者?
参与者(actor,也被译为执行者),是与系统主体交互的外部实体的类元,描述了一个或一组与系统产生交互的外部用户或外部事物。参与者以某种方式参与系统中一个或一组用例的执行。
参与者位于系统边界之外,而不是系统的一部分。也就是说,参与者是从现实世界中与系统有交互的事物中抽象出来的,而并非系统中的一个类。
在UML中,参与者有两种表示法。一般情况下,习惯用图表表示法来代表人,用类符号表示法来表示事物。此外参与者可以分栏来表示它的属性和接收到的事件。
如何确定参与者?
确定参与者是构建用例图的第一步。一般可以从以下几个角度来考虑:
- 为系统提供输入的人或事物。
- 接收系统输出的人或事物。
- 需要接入的第三方系统或设备。
- 时间是否会触发某些事件。
- 负责支持或维护系统中信息的人。
除了从以上角度考虑参与者,还可以参考参与者的分类来进行确定。系统中的参与者一般可以分为四类。
- 主要业务参与者(primary business actor):主要从用例的执行中获得好处的关联人员。主要业务参与者可能会发起一个业务事件。
- 主要系统参与者(primary system actor):直接同系统交互以发起或触发业务或系统事件的关联人员。主要系统参与者可能会与主要业务参与者进行交互,以便使用系统。
- 外部服务参与者(external server actor):响应来自用例的请求的关联人员。
- 外部接收参与者(external receiver actor):从用例中接收某些价值或输出的非主要的关联人员。
-
用例
在UML建模中,用例无疑是最重要的元素之一。
用例图是UML中最重要的元素之一,准确的用例定义是在软件开发过程中不可或缺的要素。什么是用例?
用例(use case,又被译作用况)是类元(一般是系统、子系统或类)提供的一个内聚的功能单元,表明系统与一个或多个参与者之间信息交换的顺序,也表明了系统执行的动作。一个用例就是系统的一个目标,描述为实现此目标的活动和系统交互的一个序列。用例的目标是要定义系统或子系统的一个行为,但不揭示系统的内部结构。
用例是一种理解和记录系统需求的出色的技术,用例所描述的场景实际上包含了系统的一个或多个需求,因此用例与用例图被广泛用于系统的需求建模阶段,并在系统的整个生命周期中被不断细化。
在UML中,用例用一个包含名称的椭圆形来表示,其中用例的名称可以显示在椭圆内部或椭圆下方。
用例与参与者?
参与者与用例是用例图中最重要的两个元素,二者也存在着密不可分的关系。用例是参与者与系统主体的不同交互作用的量化,是参与者请求或触发的一系列行为。一个用例可以隶属一个或多个参与者,一个参与者也可以参与一个或多个用例。没有参与任何用例的参与者是无意义的。
用例与参与者之间存在关联关系,即参与者实例通过与用例实例传递消息实例(信号与调用)来与系统进行通信。
ER图
ER图的核心要素:
实体,属性,关系;
图例:
功能结构图
一般情况下产品或系统的总功能可分解为若干分功能,各分功能又可进一步分解为若干二级分功能,如此继续,直至各分功能被分解为功能单元为止。这种由分功能或功能单元按照其逻辑关系连成的结构称为功能结构。分功能或功能单元的相互关系可以用图来描述,表达分功能或功能单元相互关系或从属关系的图称为功能结构图。
定义
功能结构图就是按照功能的从属关系画成的图表,图中的每一个框都称为一个功能模块。功能模块可以根据具体情况分的大一点或小一点,分解得最小功能模块可以是一个程序中的每个处理过程,而较大的功能模块则可能是完成某一个任务的一组程序。
系统流程图
系统流程图是概括的描绘系统物理模型的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个具体部件(程序、文件、数据库、表格、人工过程等),表达数据在系统各个部件之间流动的情况。
说明
系统流程图表达的是系统各部件的流动情况,而不是表示对信息进行加工处理的控制过程。
系统流程图的作用表现在以下几个方面:
- 制作系统流程图的过程是系统分析员全面了解系统业务处理概况的过程,它是系统分析员做进一步分析的依据。
- 系统流程图是系统分析员、管理员、业务操作员相互交流的工具。
- 系统分析员可直接在系统流程图上画出可以有计算机处理的部分。
- 可利用系统流程图来分析业务流程的合理性。
图例
组织结构图
- 可以显示其职能的划分.
- 可以知道其权责是否适当.
- 可以看出该人员的工作负荷是否过重.
- 可以看出是否有无关人员承担几种较松散,无关系的工作.
- 可以看出是否有让有才干的人没有发挥出来的情形.
- 可以看出有没有让不胜任此项工作的人担任的重要职位.
- 可以看出晋升的渠道是否畅通.
- 可以显示出下次升级时谁是最合适的人选.
顺序图
是描述动态交互过程图,以时间为顺序,强调时间。
- 包图 -> 组织结构图
- 用例模型 -> 岗位职责图
静态用类图
动态用顺序图(描述了一堆对象)
- 百度文库
- bsdn博客
- 中国知网