UML类图几种关系的总结
例如：老虎是动物的一种，即有老虎的特性也有动物的共性。
【箭头指向】：带三角箭头的实线，箭头指向父类 2. 实现（Realization） 【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现. 【箭头指向】：带三角箭头的虚线，箭头指向接口 3. 关联（Association) 【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。
双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量 【箭头及指向】：带普通箭头的实心线，指向被拥有者 上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。
但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。
下图为自身关联： 4. 聚合（Aggregation） 【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。
聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
【代码体现】：成员变量 【箭头及指向】：带空心菱形的实心线，菱形指向整体 5. 组合(Composition) 【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。
如公司和部门是整体和部分的关系，没有公司就不存在部门。
组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
【代码体现】：成员变量【箭头及指向】：带实心菱形的实线，菱形指向整体 6. 依赖(Dependency) 【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖. 【代码表现】：局部变量、方法的参数或者对静态方法的调用 【箭头及指向】：带箭头的虚线，指向被使用者 各种关系的强弱顺序： 泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖 下面这张UML图，比较形象地展示了各种类图关系：
求一篇使用UML进行软件工程设计后的心得，要比较正式的，谢谢
这位同学，不用找了，如果发现交上来的跟这里的雷同，一律0分
求UML 知识点总结
校园一卡通顾名思义，使用一张卡完成校园所有电子业务的应用。
当前学校电子业务应用主要分为两类：消费和身份识别。
1、消费：包括餐厅吃饭消费、澡堂洗浴消费、超市消费、医务室、体育场馆收费等。
2、身份识别类：新生注册（数字迎新）、图书借阅、寝室和教学楼的门禁和考勤识别等。
而使用的校园卡多为mifare卡，根据卡中存放信息分为ic卡和id卡： 1、IC卡是集成电路卡，通过卡里的集成电路存储信息，此类卡存放的有各种人员信息和账户信息，与应用终端（消费机、考勤机）交互后需要上传到数据库人员信息表中，使得数据库与卡片同步，与数据库交互不够及时，批量上传数据。
2、ID卡是身份识别卡，卡中只存放一条帐号信息，每次与应用终端交互都需要与数据库交互，此类卡的应用终端必须实时联网，写校园一卡通设计的话推荐此种卡片。
数据库建一组相互关联的表，使得能存放完整的人员信息，人员信息主要字段自少包括：姓名、学号、班级信息、卡号、账户金额（消费金额）、消费各种状态信息（）、权限类别（考勤的权限、食堂消费权限、洗浴消费权限、门禁刷卡权限）等，消费记录表包括交易流水、交易时间、交易地点、交易金额等。
卡与消费终端交互流程： 1、鉴权：根据应用终端的类别，交互数据库取出该账户权限类别，判断是否有资格。
2、如鉴权通过，上传消费终端上输入的消费金额，平台根据上传金额与数据库提取出来的账户余额对比，判断金额是否合理。
3、平台自动操作数据库更改消费后的账户余额及相关信息。
注：一卡通的充值流程同消费流程，纯手工敲的，欢迎采纳，一卡通业务方面问题可以powerliu@163.com。
UML是什么
Unified Modeling Language
