九种关系总结,EA图中会用到:

关联关系(Association):双向关联,单向关联,自关联、多重性关联Multiplicity、

聚合(Aggregation):整体与部分的关系,整体对象销毁时成员对象不销毁,一般是构造函数或Set方法传入成员对象。

组合(Composition)整体与部分的关系,整体对象销毁时成员对象一并销毁,一般在构造函数中创建成员对象。

依赖关系(Dependency):Driver类依赖Car类的move方法,Driver--->Car

泛化关系(Generalization):父类与子类之间,由子类指向父类

实现关系(Realization):接口与实现类之间,由实现类指向接口  

         在UML类图中,常见的有以下几种关系: 泛化(Generalization),  实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)

         1. 泛化(Generalization)

        【泛化关系】:是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为。例如:老虎是动物的一种,即有老虎的特性也有动物的共性。

        【箭头指向】:带三角箭头的实线,箭头指向父类

UML类图几种关系的总结

        2. 实现(Realization)

        【实现关系】:是一种类与接口的关系,表示类是接口所有特征和行为的实现.

        【箭头指向】:带三角箭头的虚线,箭头指向接口

UML类图几种关系的总结

        3. 关联(Association)

        【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。

        【代码体现】:成员变量

        【箭头及指向】:带普通箭头的实心线,指向被拥有者

UML类图几种关系的总结

        上图中,老师与学生是双向关联,老师有多名学生,学生也可能有多名老师。但学生与某课程间的关系为单向关联,一名学生可能要上多门课程,课程是个抽象的东西他不拥有学生。 

        下图为自身关联: 

UML类图几种关系的总结

        4. 聚合(Aggregation)

        【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系,轮胎离开车仍然可以存在。

        聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。

        【代码体现】:成员变量

        【箭头及指向】:带空心菱形的实心线,菱形指向整体

UML类图几种关系的总结

        5. 组合(Composition)

        【组合关系】:是整体与部分的关系,但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系,没有公司就不存在部门。

       组合关系是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

【代码体现】:成员变量

【箭头及指向】:带实心菱形的实线,菱形指向整体

UML类图几种关系的总结

        6. 依赖(Dependency)

        【依赖关系】:是一种使用的关系,即一个类的实现需要另一个类的协助,所以要尽量不使用双向的互相依赖.

        【代码表现】:局部变量、方法的参数或者对静态方法的调用

        【箭头及指向】:带箭头的虚线,指向被使用者

UML类图几种关系的总结

        各种关系的强弱顺序:

        泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖 

        下面这张UML图,比较形象地展示了各种类图关系:

UML类图几种关系的总结

用例图:

用例图各部分:

  • 操作者Actor(其他图比如说类图中,需要对构造型进行设置)
  • 空心三角代表泛化关系,三角指向的对象是父类
  • 关联关系(带箭头的实线,箭头指向用例)include(虚线箭头+<<include>>字样,箭头由基础用例指向被包含的用例)、extend关系(虚线箭头+<<extend>>字样,箭头指向被扩展的用例(基础用例),添加新的行为到已有用例-可能不执行)
  • 区别include和extend:include包含的用例对基础用例可见,并且去掉被包含的用例后基础用例将不完整。Extend扩展的用例对基础用例不可见,并且去掉扩展的用例后基础用力依然完整。
    **绘制注意事项:
  1. 用例是动宾短语,要体现系统功能
  2. 参与者不一定是人**
  3. 不必要的时候不使用include、extend

甘特图

也称为条状图,是一种按照时间进度标出工作活动,用于项目管理的图表。甘特图用横轴表示时间,纵轴表示活动,线条表示在计划期间活动的安排以及完成情况。以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。

类图

类图是软件的蓝图,用于详细描述系统内各个对象的相关的类,以及这些类之间的静态关系。设计类是已经完成了规格说明并且达到能够被实现程度的类。
类组件:类名-如果是抽象类需要斜体
类属性:可见性 名称:类型 [=缺省值]
+(public) –(private) #(protected) ~(package)
** 六种类间关系(耦合度由低到高)**
依赖关系use-a、关联关系has-a、聚合关系、组合关系、泛化关系is-a、实现关系(类与接口)

  • 关联关系-单向关联:一个类知道另一个类的属性和方法
  • 关联关系-双向关联:互相知道
  • 关联关系-多元关联
  • 关联关系-聚集:整体包含部分,但是部分可以脱离整体单独存在。(图书馆与图书)【空心菱形,菱形在整体的那一边】
  • 关联关系-组合:整体包含部分,部分不可以脱离整体单独存在。(图书与目录)【实心菱形】
  • 关联关系-关联类:基于关联关系,既是关联也是类(比如一个方法不知道放到那个类的时候可以使用)【面向对象的编程不支持,可以转化】
  • 依赖关系:被依赖对象改变的时候会影响到依赖对象
    区分依赖和关联:某个类以成员变量的形式出现在另一个类中,这就是关联;而若是以一个局部变量的形式出现,则是依赖关系。(他的耦合度比关联关系低,相当于短暂使用关联)是一个临时的使用关系,不是静态关系,是非结构化的【比如借阅列表和图书的关系】或者用引用的概念来加以区分:属性引用-关联关系;参数引用-依赖关系;局部声明引用-依赖关系;全局引用(B对象是一个全局对象)-依赖关系。
  • 泛化关系:继承是耦合程度最高的,对绝大多数语言来说,继承是一种静态关系(注意LSP原则、从抽象类继承)
    注:只要有可能,不要从具体类继承。行为集中的方向是向上;数据集中的方向是向下
  • 实现关系:将一个类和一个接口连接起来,类是对接口的实现。
  • 类间关系的多重性:1-一个;-0或多个;1..一个或多个;0..1零或一个

顺序图

描述了一组对象的交互方式,它表示完成某项行为的对象和这些对象之间传递消息的时间顺序。
组成元素:参与者、对象、生命线、控制焦点、消息
用例图是系统外部对象(参与者)与系统这两大对象之间的互动,而类图是对系统中涉及到得所有对象,进行抽象描述。顺序图是参与者和系统进行交互、系统内部对象之间具体互动的实现。所以,顺序图关联了类图与用例图,可以通过用例图和类图进行整合。
【顺序:参与者-边界类-控制类-实体类,控制类只有一个,边界类和实体类可以有多个。】

  • 边界类:位于系统与外界的交界处,窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类。
  • 控制类:控制其他类工作的类。每个用例通常有一个控制类,控制用例中的事件顺序,控制类也可以在多个用例间共用。
  • 实体类:保存要放进持久存储体的信息,就是数据库、文件等可以永久存储数据的介质。通常每个实体类在数据库中有相应的表,实体类中的属性对应数据库表中的字段。

EA操作

  • 用例图
    新建一个.eap文件:打开EA-文件新建项目-不选模板-Module右键添加-新建增图-用例图
    绘制用例图:右键新建的图-添加图-选择UML Behavioral-Use Case
  • 类图
    -模板-core modeling-class
    -新建图-structural-class
    -新建类-右键功能属性
    -关联-右键多重值
  • 顺序图
    -新建图-behavioral-sequence
    -关联-右键特性-设置同步异步等等
  • 图导出
    选中需要导出的Model-右键仅仅图报告-BMP格式-运行

操作举例

题目:
游客可以通过输入关键词①检索美食、②店铺。③注册后,游客获得平台账号
登录后,游客成为正式用户
正式用户除①检索外,还可以对美食②发布评价、点赞其他用户评价以及举报违规评价正式用户还可以③收藏店铺
用户如果想要④申请店铺主页,可以在填写店铺基本信息后提交申请
系统管理员负责①处理主页申请以及②举报信息。

 

 

复习顺序图

 

 

复习用例图

 

 

复习类图

附加:面向对象设计7大原则

  • 单一职责原则:一个类只应该做和一个职责相关的事情,不要把过多的业务放在一个类中完成。
  • 迪米特法则:软件实体之间应该做到最少的交互。不要和陌生人说话。调用方只关心他需要使用的方法。
  • 接口隔离原则:使用专门的接口,比用统一的接口要好。便于分工,在实现接口时,不应该看到自己不用关心的方法。
  • 开闭原则:软件实体应该对扩展开放,对修改关闭。开闭原则是设计原则的核心原则,其他的设计原则都是开闭原则表现和补充。实现开闭原则的方法就是抽象。
  • 合成复用原则:多使用聚合/组合达到代码的重用,少使用继承复用。
  • 依赖倒置原则:面向抽象编程,不要面向具体编程。
  • 里氏替换原则:子类可以扩展父类的功能,但不能改变父类原有的功能。

 

 

Logo

开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!

更多推荐