看懂UML类图

转自https://www.cnblogs.com/me115/p/4092632.html

1. 之前一直遇到这些图,参考一下

这里不会将UML的各种元素都提到,我只想讲讲类图中各个类之间的关系; 能看懂类图中各个类之间的线条、箭头代表什么意思后,也就足够应对 日常的工作和交流; 同时,我们应该能将类图所表达的含义和最终的代码对应起来; 有了这些知识,看后面章节的设计模式结构图就没有什么问题了;

本章所有图形使用Enterprise Architect 9.2来画,所有示例详见根目录下的design_patterns.EAP

从一个示例开始

请看以下这个类图,类之间的关系是我们需要关注的:

注意:1.接口一般是abstract的

           2. 实现类是虚线形式加箭头

         3. 继承 是实线+箭头

        4.  组合  实线+ 菱形加粗  是xxx的组成部分  

        5. 关联关系   一条实线

        6. 聚合关系:实线+ 菱形

聚合关系用于表示实体对象之间的关系;例如一个部门由多个员工组成;部门撤销了,人员不会消失

与聚合关系一样,组合关系同样表示整体由部分构成的语义;比如公司由多个部门组成;

但组合关系是一种强依赖的特殊聚合关系,如果整体不存在了,则部分也不存在了;例如, 公司不存在了,部门也将不存在了;

uml_class_struct

  • 车的类图结构为<<abstract>>,表示车是一个抽象类;
  • 它有两个继承类:小汽车和自行车;它们之间的关系为实现关系,使用带空心箭头的虚线表示;
  • 小汽车为与SUV之间也是继承关系,它们之间的关系为泛化关系,使用带空心箭头的实线表示;
  • 小汽车与发动机之间是组合关系,使用带实心箭头的实线表示;
  • 学生与班级之间是聚合关系,使用带空心箭头的实线表示;
  • 学生与身份证之间为关联关系,使用一根实线表示;
  • 学生上学需要用到自行车,与自行车是一种依赖关系,使用带箭头的虚线表示;

下面详细介绍这六种关系;


类之间的关系

泛化关系(generalization)

类的继承结构表现在UML中为:泛化(generalize)与实现(realize):

继承关系为 is-a的关系;两个对象之间如果可以用 is-a 来表示,就是继承关系:(..是..)

eg:自行车是车、猫是动物

泛化关系用一条带空心箭头的直接表示;如下图表示(A继承自B);

uml_generalization

eg:汽车在现实中有实现,可用汽车定义具体的对象;汽车与SUV之间为泛化关系;

uml_generalize

注:最终代码中,泛化关系表现为继承非抽象类;

实现关系(realize)

实现关系用一条带空心箭头的虚线表示;

eg:”车”为一个抽象概念,在现实中并无法直接用来定义对象;只有指明具体的子类(汽车还是自行车),才 可以用来定义对象(”车”这个类在C++中用抽象类表示,在JAVA中有接口这个概念,更容易理解)

uml_realize

注:最终代码中,实现关系表现为继承抽象类;

聚合关系(aggregation)

聚合关系用一条带空心菱形箭头的直线表示,如下图表示A聚合到B上,或者说B由A组成;

uml_aggregation

聚合关系用于表示实体对象之间的关系,表示整体由部分构成的语义;例如一个部门由多个员工组成;

与组合关系不同的是,整体和部分不是强依赖的,即使整体不存在了,部分仍然存在;例如, 部门撤销了,人员不会消失,他们依然存在;

组合关系(composition)

组合关系用一条带实心菱形箭头直线表示,如下图表示A组成B,或者B由A组成;

uml_composition

与聚合关系一样,组合关系同样表示整体由部分构成的语义;比如公司由多个部门组成;

但组合关系是一种强依赖的特殊聚合关系,如果整体不存在了,则部分也不存在了;例如, 公司不存在了,部门也将不存在了;

关联关系(association)

关联关系是用一条直线表示的;它描述不同类的对象之间的结构关系;它是一种静态关系, 通常与运行状态无关,一般由常识等因素决定的;它一般用来定义对象之间静态的、天然的结构; 所以,关联关系是一种“强关联”的关系;

比如,乘车人和车票之间就是一种关联关系;学生和学校就是一种关联关系;

关联关系默认不强调方向,表示对象间相互知道;如果特别强调方向,如下图,表示A知道B,但 B不知道A;

uml_association

注:在最终代码中,关联对象通常是以成员变量的形式实现的;

依赖关系(dependency)

依赖关系是用一套带箭头的虚线表示的;如下图表示A依赖于B;他描述一个对象在运行期间会用到另一个对象的关系;

uml_dependency

与关联关系不同的是,它是一种临时性的关系,通常在运行期间产生,并且随着运行时的变化; 依赖关系也可能发生变化;

显然,依赖也有方向,双向依赖是一种非常糟糕的结构,我们总是应该保持单向依赖,杜绝双向依赖的产生;

注:在最终代码中,依赖关系体现为类构造方法及类方法的传入参数,箭头的指向为调用关系;依赖关系处理临时知道对方外,还是“使用”对方的方法和属性;

 

<think>首先,用户的问题是:“我想了解如何绘制管理员用户的UML请问绘制管理员用户UML的方法和示例”。这基于站内引用[1],但引用是关于理解UML的,而不是专门绘制管理员用户的。我需要参考用户的上一次问题和我的回答。用户的上一次问题是:“参考站内引用:引用[1]:身为程序员还看不懂UML?...”,然后用户现在的问题是:“我想了解如何绘制管理员用户的UML”。所以,用户是从如何理解UML转向如何绘制特定。根据系统级指令:-所有行内数学表达式使用$...$格式(但这里可能不需要数学表达式)。-独立公式使用$$...$$(如果需要)。-LaTeX语法正确(但主要在文本中)。-使用中文回答。-生成相关问题。-回答中引用的段落末尾添加引用标识。这里的引用[1]是关于UML的一般文章,但我需要基于用户的问题来回答。-回答结构清晰,逐步解决问题,保持真实可靠。用户想要的是绘制管理员用户的UML的方法和示例。管理员用户可能是一个,代表在系统中拥有管理权限的用户。关键点:-UML用于表示和它们之间的关系。-对于管理员用户,我需要定义相关的属性和方法。-管理员用户可能继承自一个基础用户(User),或者是一个独立的。步骤来绘制管理员用户的UML:1.**识别和属性**:-名:管理员用户(AdminUser)。-属性:如id、用户名、密码、权限级别等。-方法:如管理用户的方法、添加用户、删除用户等。2.**定义关系**:-管理员用户可能继承自用户(User),所以是泛化关系(继承)。-如果管理员用户与系统中的其他实体有关联,比如日志系统、用户列表,需要显示关联关系。3.**绘制示例**:-提供示例UML。-在文本中描述,如果可能,用ASCIIart或简化来表示,但作为AI,我可以用文本描述和格式模拟。引用[1]中提到:-UML示例。-关系:如实现继承、关联、聚合、合成、依赖。-所以我可以用这些概念。我的回答结构:1.**解释UML基本概念**(简要回顾,因为引用[1]已经覆盖)。2.**描述如何绘制管理员用户的**:-步骤一:定义。-步骤二:添加属性和方法。-步骤三:显示关系。3.**提供一个示例**。4.**结束生成相关问题**(根据指令)。生成相关问题:-根据系统级指令,我必须生成相关问题。似于示例中的快速排序问题。-如:UML的更高级应用、管理员用户的扩展、其他关系等。添加引用:在回答中引用的部分末尾添加[^1],这里引用是[1],所以使用[^1]。回答使用中文。最终回答大纲:-介绍。-绘制方法。-示例。-相关问题。</think> 以下是针对“如何绘制管理员用户的UML”的专业解答。我将基于UML标准规范(参考引用[1])逐步解释,并提供清晰的方法和实际示例。UML是面向对象设计的关键工具,用于表示、属性、方法及其关系,尤其适用于描述管理员用户这种系统实体[^1]。 ### 绘制管理员用户UML的方法 绘制管理员用户的UML需要从定义开始,逐步添加细节和关系。以下是结构化步骤(基于UML 2.5标准): 1. **定义管理员用户(AdminUser)**: - **名**:为管理员用户创建单独,命名为“AdminUser”。这表示系统中拥有管理权限的用户。 - **属性**:添加核心属性,例如: - 用户ID:整数或字符串型,表示唯一标识。 - 用户名:字符串型。 - 权限级别:枚举型(如“admin”、“superuser”)或整数表示级别。 - 这些属性用格式:`属性名: 数据型`显示。 - **方法**:添加管理员特有操作,例如: - 管理用户:如`addUser()`或`deleteUser()`方法。 - 系统配置:如`updateSystemConfig()`。 - 方法用格式:`方法名(参数): 返回值型`显示。 - **提示**:属性和方法应封装在框中,分属性区和操作区。 2. **处理与其他的关系**: - **泛化(继承)关系**:通常,管理员用户继承自基础用户(User)。例如: - 管理员用户(AdminUser)继承用户(User),表示AdminUser是User的特殊形式。这用空心箭头实线表示。 - 基础用户(User)应有通用属性和方法,如用户名、密码、登录方法。 - **其他关系**(根据需要添加): - **关联关系**:管理员用户可能关联到系统中的用户列表(如UserList),用实线连接。 - **聚合关系**:如果管理员用户是一个“部分”或“组成”实体(如属于部门Department),用空菱形箭头实线表示。 - **依赖关系**:管理员用户操作可能依赖日志(Log)记录活动,用虚线箭头表示。 - **实现接口**:如果系统有权限接口(如Permissible),AdminUser实现该接口,用虚线空心箭头表示[^1]。 3. **绘制工具和注意事项**: - **工具推荐**:使用专业UML工具绘制,例如: - PlantUML:免费在线工具,支持文本到转换。 - Lucidchart:基于云的拖拽式工具,适合初学者。 - Enterprise Architect:专业级工具,支持完整UML规范[^1]。 - **最佳实践**: - 保持简洁:只包括管理员用户核心属性和方法。 - 使用统一建模语言标准:名大写首字母,属性/方法使用camelCase命名。 - 验证关系:确保泛化、关联等关系正确表达系统逻辑(例如,避免循环依赖)。 ### 管理员用户UML示例 以下是一个简化但完整的UML示例,基于企业管理系统场景。管理员用户(AdminUser)继承自基础用户(User),并关联到用户列表(UserList)。用文本格式模拟(实际可用工具生成形)。 ``` @startuml class User { // 属性区 - id: int - username: String - password: String // 方法区 + login(): boolean + logout(): void } class AdminUser { // 管理员特有属性 - privilegeLevel: int // 管理员特有方法 + addUser(user: User): void + deleteUser(userId: int): boolean } class UserList { // 属性 - userCount: int // 方法 + addUser(user: User): void + findUser(id: int): User } // 关系 User <|-- AdminUser // 泛化(继承):AdminUser继承User AdminUser o-> UserList // 聚合关系:AdminUser由UserList组成(空菱形实线) AdminUser ..> Log // 依赖关系:AdminUser依赖Log(虚线箭头) @enduml ``` - **解释**: - **结构**: - `User`:基础用户,有通用属性和方法(如登录/注销)。 - `AdminUser`:继承User,添加特有属性`privilegeLevel`和方法如`addUser`(管理用户)。 - `UserList`:表示用户集合,AdminUser与之有聚合关系(管理员拥有用户列表)。 - `Log`(未全定义):管理员操作可能依赖日志记录,如审计活动。 - **关系符号**: - `User <|-- AdminUser`:AdminUser是User的子(泛化)。 - `AdminUser o-> UserList`:聚合关系,管理员可以“包含”多个用户。 - `AdminUser ..> Log`:依赖关系,管理员操作需要日志支持。 - **应用场景**:这种可用于设计登录系统、后台管理系统等,确保权限隔离和数据一致性[^1]。 ### 相关问题(
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值