目录
一、UML的构成
1.1 事物
1.2 关系
1.3 图
二、事物
2.1 结构事物
2.1.1 类(class)
2.1.2 接口
2.1.3 协作
2.1.4 用例
2.1.5 主动类
2.1.6 构件
2.1.7 节点
2.2 行为事物
2.2.1 交互
2.2.2 状态机
2.2.3 活动
2.3 分组事物
包
2.4 注释事物
三、关系
3.1 依赖关系
3.2 关联关系
3.3 泛化关系
3.4 实现关系
四、公共机制
学些UML,首先要知道,UML包括哪些主要构成元素。
建议大家收藏本文,后续我会补画例子的图示,一站式学习。
UML的构成包括了事物、关系和图三个部分。以下是它们的详细解释:
UML中的事物也称为建模元素,包括结构事物、行为事物、分组事物和注释事物。
UML中的关系描述了事物之间的联系,包括关联关系、泛化关系、实现关系和依赖关系。
UML中的图描述了系统的一个方面或视角,包括静态图和动态图两种。
以上就是UML的构成部分及其解释。这些元素共同构成了UML的基础,使得我们可以使用UML对软件进行建模和分析。
如果只想了解大概,那么上面就是核心干货了。如果想具体了解,请继续阅读。
在UML中,类是一种基本的建模元素,它描述了具有相同属性、操作、关系和语义的一组对象的集合。类定义了一组对象的所有属性和行为。
类的定义通常包括以下几个部分:
例如,考虑一个简单的“狗”类,它可能具有以下定义:
类名:Dog
属性:
操作:
这个“狗”类定义了一个具有三个属性和三个操作的类。在实际编程中,这个类可以被实例化为一个或多个“狗”对象,每个对象都具有自己的属性和行为。
在UML类图中,类通常用一个矩形表示,类名放在矩形的顶部,属性和操作分别放在矩形的中部和底部。属性和操作之前可以加上可见性修饰符(+ 表示公有,- 表示私有,# 表示受保护的)。关系通常用线连接相关的类,并在线上标上关系的名称。
在UML中,接口(Interface)是一种特殊的类,它定义了一组操作的规范,但没有实现这些操作。接口描述了类应该具备的行为,但并不关心如何实现这些行为。接口定义了一种契约,规定了类必须遵守的行为规则。
接口的定义通常包括以下几个部分:
例如,考虑一个简单的“可绘制”接口,它可能具有以下定义:
接口名:Drawable
操作:
这个“可绘制”接口定义了一个具有一个操作的接口,即“绘制对象”。任何实现了这个接口的类都必须提供“draw()”方法的具体实现。
在实际编程中,接口可以被类实现(implement),这意味着类必须提供接口中定义的所有操作的具体实现。一个类可以实现多个接口,这意味着它需要提供多个接口中定义的操作的实现。
在UML类图中,接口通常用一个带有《interface》标签的矩形表示,接口名放在矩形的顶部,操作列在矩形的底部。与类不同,接口没有属性部分。实现关系通常用一条带有虚线的线连接实现接口的类和接口本身,线上标上“implements”或“<
使用接口的好处之一是它们提供了一种抽象层,允许不同的类实现相同的接口,从而实现多态性。这意味着可以使用相同的接口引用不同的对象,并在运行时确定实际执行的操作。这种灵活性使得接口成为面向对象编程中一种重要的工具,用于定义和扩展系统的行为。
在UML中,协作(Collaboration)是指多个类、接口或其他建模元素之间为了完成特定任务而进行的交互和合作。协作描述了不同建模元素之间的关系以及它们在实现共同目标时的行为。
协作的定义通常包括以下几个部分:
例如,考虑一个简单的在线购物系统,其中包括顾客、购物车和订单等类。在这个系统中,顾客可以将商品添加到购物车中,然后将购物车中的商品生成订单。这个过程涉及多个类之间的协作。
参与者:
交互:
关系:
这个简单的在线购物系统示例展示了类之间的协作,描述了它们在完成购物过程中的交互和合作方式。在实际的UML建模中,可以使用顺序图、通信图或活动图等来可视化和描述协作的详细过程。
UML中的协作描述了多个建模元素之间为了完成特定任务而进行的交互和合作,它涉及参与者、交互、关系和场景等元素。通过理解和建模协作,可以更好地理解系统的动态行为并设计有效的软件解决方案。
在UML中,用例(Use Case)是一种描述系统功能的模型元素,它代表了一个系统、子系统或类与外部用户或其他系统之间的交互行为。用例捕获了系统应该执行的功能性需求,并描述了系统如何与外部实体进行交互以实现这些功能。
用例的定义通常包括以下几个部分:
例如,考虑一个简单的在线图书馆系统,其中包括用户登录、浏览书籍、借阅书籍和归还书籍等功能。下面是一个关于“借阅书籍”功能的用例示例:
用例名:借阅书籍
参与者:图书馆用户
前置条件:用户必须已经登录并且具有借阅权限。
主成功场景:
扩展和异常场景:
这个示例展示了用例如何描述系统的功能性和交互行为。通过定义用例,我们可以更好地理解系统的需求和行为,并在设计和开发过程中确保满足用户的期望和需求。在实际的UML建模中,可以使用用例图来可视化和组织用例之间的关系,以便更好地理解和沟通系统的功能需求。
在UML中,主动类(Active Class)是一种具有生命周期并能主动启动和控制其行为的类。它描述了对象具有并发行为和独立控制流的情况。主动类具有与传统类相似的结构,但它们能够接收和处理事件,拥有自身的线程,并与其他主动类进行并发交互。
主动类的定义通常包括以下几个部分:
例如,考虑一个简单的电梯控制系统,其中电梯是一个主动类。每个电梯对象具有自身的状态(如开门、关门、上升、下降等),并且能够响应乘客的按钮按下事件。
类名:Elevator
属性:
行为:
并发性:
电梯对象具有自身的线程,可以在不同的时间点接收和处理多个乘客的按钮按下事件。
事件处理:
当乘客按下按钮时,电梯对象会触发相应的操作来改变其状态和目标楼层,并启动移动过程。
这个示例展示了主动类如何描述具有生命周期、并发行为和事件处理能力的对象。通过定义主动类,我们可以更好地理解和建模具有并发和反应性的系统,并在设计和开发过程中考虑并发和同步的问题。在实际的UML建模中,可以使用状态图和顺序图等来可视化和描述主动类的行为和交互。
在UML中,构件(Component)是软件系统中的可替换的物理部件,它封装了实现,并通过一组接口与外部环境进行交互。构件代表了在部署和运行时环境中可观察到的物理元素,例如可执行文件、库、框架或插件。
构件的定义通常包括以下几个部分:
名称和类型:每个构件都有一个唯一的名称和类型,用于标识和分类构件。类型可以是可执行文件、库文件或其他二进制文件等。
接口:构件通过接口与外部环境进行交互。接口定义了构件提供的服务或操作,并指定了与其他构件或系统元素的交互方式。
实现:构件封装了具体的实现细节,这些实现细节可以是源代码、二进制代码或其他形式的实现逻辑。
依赖关系:构件之间可能存在依赖关系,表示一个构件依赖于另一个构件的服务或功能。这些依赖关系可以是编译时依赖或运行时依赖。
例如,考虑一个简单的Web应用程序,其中包括前端和后端组件。前端组件负责用户界面和交互逻辑,而后端组件负责数据处理和业务逻辑。每个组件都可以被视为一个构件。
在这个示例中,前端组件可以是一个Web浏览器中的JavaScript文件,它提供了用户界面和交互功能。后端组件可以是一个Web服务器上的Java应用程序,它处理来自前端的请求并返回相应的数据。
前端构件(Frontend Component):
后端构件(Backend Component):
这些构件通过HTTP协议进行交互。前端构件发送HTTP请求给后端构件,并接收后端构件返回的HTTP响应。这种交互方式定义了构件之间的接口和依赖关系。
在实际的UML建模中,可以使用组件图(Component Diagram)来可视化和描述构件之间的关系和依赖。组件图显示了系统中不同构件之间的连接和交互方式,并提供了关于构件物理组织和部署的信息。
UML中的构件是软件系统中的物理部件,它封装了实现并通过接口与外部环境进行交互。通过定义构件,我们可以更好地理解和组织软件系统的物理结构,并确保在不同环境中正确部署和运行软件系统。
在UML中,节点(Node)表示运行时环境中的物理或逻辑资源,它是系统部署和执行的基本单位。节点可以是计算机、服务器、设备或其他具有处理、存储和通信能力的实体。节点描述了系统的物理拓扑结构以及在这些节点上运行的软件组件。
节点的定义通常包括以下几个部分:
例如,考虑一个简单的分布式系统,其中包括Web服务器、数据库服务器和客户端节点。每个节点都具有不同的功能和资源,并通过网络连接进行交互。
在这个示例中,Web服务器节点负责处理Web请求和生成响应,数据库服务器节点负责存储和管理数据,而客户端节点则是用户与系统交互的接口。
Web服务器节点(Web Server Node):
数据库服务器节点(Database Server Node):
客户端节点(Client Node):
这些节点通过网络连接进行交互,Web服务器节点接收来自客户端节点的请求,并与数据库服务器节点进行通信以获取数据。这种交互方式定义了节点之间的连接关系和数据传输方式。
在实际的UML建模中,可以使用部署图(Deployment Diagram)来可视化和描述节点之间的关系和连接。部署图显示了系统中不同节点的物理拓扑结构以及在这些节点上运行的软件组件的部署情况。它提供了关于系统如何在实际环境中部署和执行的信息。
总结而言,UML中的节点表示运行时环境中的物理或逻辑资源,描述了系统的物理拓扑结构和软件组件的部署情况。通过定义节点,我们可以更好地理解系统的实际部署和执行环境,并确保软件组件在正确的位置运行并与其他组件进行正确的交互。
在UML中,交互(Interaction)描述了对象之间为完成特定任务而进行的通信和协作。交互强调了在系统执行过程中对象之间的动态行为,包括消息传递、操作调用和状态变化等。交互是UML中用于描述系统动态行为的重要概念之一。
交互的定义通常包括以下几个部分:
例如,考虑一个简单的在线购物系统,其中包括用户、购物车和订单等对象。用户浏览商品并将商品添加到购物车中,然后提交订单进行结算。这个过程涉及多个对象之间的交互。
在这个示例中,用户对象发送消息给购物车对象,将商品添加到购物车中。购物车对象更新状态并返回确认消息给用户对象。然后,用户对象发送提交订单的消息给订单对象,订单对象处理订单信息并返回结算结果给用户对象。
交互示例(Interaction Example):
在实际的UML建模中,可以使用顺序图(Sequence Diagram)或协作图(Collaboration Diagram)来描述交互的详细过程。顺序图显示了对象之间消息传递的顺序和时间关系,而协作图则强调了对象之间的结构关系和协作方式。这些图表可以帮助我们理解和可视化系统中对象之间的动态行为和交互过程。
UML中的交互描述了系统执行过程中对象之间的通信和协作,包括消息传递、操作调用和状态变化等。通过定义交互,我们可以更好地理解系统的动态行为,并确保系统中的对象能够正确地进行协作和交互,以实现特定的功能和任务。
在UML中,状态机(State Machine)是一种用于描述对象在其生命周期内状态变化的模型。它描述了对象在不同状态下的行为以及状态之间的转换条件。状态机用于捕捉对象在不同情境下的反应和行为,是建模系统中动态行为的重要工具之一。
状态机的定义通常包括以下几个部分:
例如,考虑一个简单的电梯系统,其中电梯具有不同的状态,如开门、关门、上升和下降等。电梯的状态根据用户按下的按钮和其他条件进行转换。
在这个示例中,电梯的状态机可以描述如下:
状态:
转换:
事件:
动作:
在实际的UML建模中,可以使用状态图(State Diagram)来描述状态机的详细模型。状态图显示了对象的不同状态、转换条件、触发事件和动作,帮助我们理解和可视化对象的状态变化和行为。通过定义状态机,我们可以更好地捕捉和理解系统中对象的动态行为,并确保系统在不同状态下能够正确地响应和处理各种事件和条件。
在UML中,活动(Activity)是描述系统或对象执行过程的一种模型元素。活动代表了业务流程、操作流程或系统功能执行的一系列步骤和动作。活动通常用于描述系统中的工作流、任务流或交互流程,并可以包含决策点、并发执行和同步点等元素。
活动的定义通常包括以下几个部分:
例如,考虑一个简单的在线购物系统中的订单处理流程。该流程包括接收订单、验证订单、处理支付和发货等一系列步骤。
在这个示例中,订单处理流程可以建模为一个活动,具体描述如下:
这些步骤可以通过一系列动作来表示,并使用控制流来描述它们之间的顺序和条件。例如,如果订单无效,则可以通过一个决策点来中断流程并返回错误信息;如果支付成功,则可以继续到发货步骤;如果支付失败,则可以重新尝试支付或取消订单。
在实际的UML建模中,可以使用活动图(Activity Diagram)来描述活动的详细模型。活动图显示了活动中的动作、控制流、对象流、决策点和同步点等元素,帮助我们理解和可视化系统中的业务流程和执行过程。通过定义活动,我们可以更好地组织和描述系统中的工作流和任务流,以及它们之间的关系和交互。
在UML中,包(Package)是一种组织和管理模型元素的方式。它提供了一种将相关元素分组在一起的机制,以形成更高层次的结构和模块化。包可以用于对模型元素进行分类、划分访问权限、实现代码重用和模块化设计。
包的定义通常包括以下几个部分:
例如,考虑一个图书馆管理系统,其中包括用户管理、图书管理、借阅管理等多个功能模块。为了更好地组织这些功能模块和相关类,我们可以使用包来进行分组。
在这个示例中,我们可以创建以下几个包:
通过将相关类分组到不同的包中,我们可以实现更好的代码组织和模块化设计。每个包可以独立开发、测试和重用,降低了系统的复杂性。同时,通过使用包的可见性和依赖关系,我们可以控制不同包之间的交互和访问权限,提高了系统的安全性和可维护性。
在实际的UML建模中,可以使用包图(Package Diagram)来描述包的结构和关系。包图显示了包之间的依赖关系和包含关系,帮助我们理解和可视化系统的模块结构和组织方式。通过定义包,我们可以更好地管理和组织UML模型中的元素,提高建模的效率和质量。
注释事物(Commenting Elements)是一种模型元素,用于在模型中提供解释性、描述性或指导性的信息。注释事物不直接影响系统的执行或行为,但可以帮助开发人员、设计师和其他利益相关者更好地理解和解释模型。
注释事物的定义主要包括以下几个方面:
示例:
考虑一个简单的在线商店系统,其中包含一个名为“购物车”的类。为了更好地解释购物车类的功能和用途,我们可以使用注释事物来提供额外的信息。
在这个示例中,我们可以创建一个注释事物,具体描述如下:
在实际的UML建模中,注释事物可以帮助提高模型的可读性和可理解性。通过在模型中添加解释性和描述性的信息,注释事物可以促进团队成员之间的沟通和协作,并确保对模型的一致理解。此外,注释事物还可以用于记录设计决策、系统约束或其他重要信息,以便在开发过程中进行参考和回顾。
依赖关系(Dependency)是一种描述模型元素之间关系的方式,表示一个元素依赖于另一个元素的存在或行为。依赖关系表明一个元素在某种程度上依赖于另一个元素,当被依赖的元素发生变化时,可能会影响依赖它的元素。
依赖关系的定义通常包括以下几个方面:
示例:
考虑一个简单的在线商店系统,其中包括一个“用户”类和一个“订单”类。在这个系统中,“订单”类依赖于“用户”类,因为每个订单必须与一个用户相关联。
在这个示例中,我们可以描述以下依赖关系:
在实际的UML建模中,依赖关系可以用不同的方式表示,如在类图中使用带箭头的线、在序列图中使用消息流等。此外,还可以使用一些特定的UML构造型(Stereotype)来进一步描述依赖关系的性质,如<
理解和管理依赖关系对于软件系统的设计和维护至关重要。通过对依赖关系进行建模和分析,开发人员可以更好地了解系统组件之间的相互作用和影响,从而作出合理的设计决策和优化系统的结构。同时,减少不必要的依赖关系和降低耦合度也是提高软件质量和可维护性的关键措施之一。
关联关系(Association)是一种描述模型元素之间结构关系的方式,表示两个或多个类之间存在某种联系或连接。关联关系描述了类之间的静态结构,即对象之间的连接方式和它们如何相互引用。
关联关系的定义通常包括以下几个方面:
示例:
考虑一个简单的在线商店系统,其中包括“顾客”(Customer)类和“商品”(Product)类。在这个系统中,顾客可以购买多个商品,每个商品也可以被多个顾客购买。因此,“顾客”类和“商品”类之间存在一个多对多的关联关系。
具体地,这个关联关系可以描述如下:
在实际的UML建模中,关联关系通常用一条实线来表示,可以在关联线上添加箭头表示导航性,还可以在关联线的两端添加多重性标记来表示数量关系。此外,还可以使用一些特定的UML构造型(Stereotype)来进一步描述关联关系的性质,如<
通过建模关联关系,开发人员可以更好地理解类之间的联系和相互作用,从而设计出更合理和灵活的系统结构。同时,关联关系也为实现类之间的交互和协作提供了基础,帮助开发人员更好地组织和管理代码。
在UML(Unified Modeling Language,统一建模语言)中,泛化关系(Generalization)是一种描述类之间继承关系的方式,表示一个类(子类)继承另一个类(父类)的属性和方法。泛化关系也称为“继承关系”,是面向对象编程中一种重要的关系。
泛化关系的定义包括以下几个方面:
示例:
考虑一个简单的动物分类系统,其中包括一个“动物”(Animal)类和一个“狗”(Dog)类。在这个系统中,“狗”类是“动物”类的子类,继承了“动物”类的属性和方法。
具体地,这个泛化关系可以描述如下:
在实际的UML建模中,泛化关系通常用一条带空心的三角箭头的实线来表示,箭头指向父类。这个空心三角箭头是泛化关系的标志性符号,用于区分其他类型的关系。此外,还可以在泛化关系线上添加一些标签或注释来提供额外的信息,如访问修饰符(public、protected、private)或约束条件等。
通过建模泛化关系,开发人员可以更好地组织和管理代码,实现代码的重用和扩展。泛化关系也为构建更复杂的系统提供了基础,通过将公共的行为和属性抽象到父类中,可以简化子类的设计和实现,并提高系统的可维护性和可扩展性。
实现关系(Realization)是一种描述类(或组件)与其接口之间关系的方式,表示类实现了某个接口所定义的行为。实现关系在面向对象编程中非常重要,它确保类遵循接口规定的契约,从而实现代码的解耦和灵活性。
实现关系的定义包括以下几个方面:
示例:
考虑一个简单的在线支付系统,其中包括一个“支付方式”(PaymentMethod)接口和一个“信用卡支付”(CreditCardPayment)类。在这个系统中,“信用卡支付”类实现了“支付方式”接口,从而提供了一种具体的支付方式。
具体地,这个实现关系可以描述如下:
在实际的UML建模中,实现关系通常用一条带空心的三角箭头的虚线来表示,箭头指向接口。这个空心三角箭头是实现关系的标志性符号,用于区分其他类型的关系。此外,还可以在实现关系线上添加一些标签或注释来提供额外的信息,如接口名称或方法签名等。
通过建模实现关系,开发人员可以更好地理解类与接口之间的关系,并确保类实现了接口所规定的行为。这有助于实现代码的解耦和可扩展性,同时提高了系统的灵活性和可维护性。
(暂略,待举例说明)