• 类图(Class Diagram)


    类图(Class Diagram):

    类(Class)封装了数据和行为,是面向对象的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称。

    类一般由三部分组成:

    类名(Class):每个类都必须有一个名字,类名是一个字符串。 

    属性(Attributes):属性是指类的性质,即类的成员变量。类可以有任意多个属性,也可以没有属性。

      UML中:可见性 名称:类型 [= 默认值]

    操作(Operations):操作是类的任意一个实例对象都可以使用的行为,操作是类的成员方法。

      UML中:可见性 名称(参数名):返回值

    接下来我们看一下类的关系:

    要注意uml中的关系是面向对象关系。如果不以面向对象的思维去考虑会感觉到有很多关系认为是一样的。

    关联关系(Association)

    通常关联关系用来实现连接有关联的对象所对应的类,即将一个类的对象作为另一个类的属性。

    还有就是关联关系可以是单向的也可以是双向的。双向的符号是没有方向标的,只是一条直线。

    例:

    单向:

    双向:

    自己:

    多重性关联关系:

    例:

     

    在这里要注意,看完此图中1…1以后不要认为一个Form是对应一个Button的。

    不是的,应该是一个Button是对应一个Form的。1..1是表示另一个类的一个对象只与一个该类对象有关系。记住上面的表格。是另一个类与该类是什么关系。

    聚合关系(Aggregation)

    表示整体与部分的关系。考虑到一个整体类的组成结构。找出成员类。即成员对象是整体对象的一部分,但是成员对象可以队里整体对象独立存在。所以也有人说此关系是一种弱关系,那么强关系是什么后面我们会降到组成关系。

    聚合关系有一个特点,那就是可替换

     

    直观的来看此图Car中必须得有一个Engine,这样才可以认为是一个完整体。

    但是这个Engine是可替换的。是以传参的形式给Car赋一个Engine。

    再次强调一下聚合是可替换的。Car中必须有一个Engine,但是此Engine可以是一个抽象的具体的Engine是在当你使用Car时可以具体去找一个合适的Engine装到Car上就行,如果没有Engin那么这个Car是跑不了。

    组合关系(Composition)

    表示整体与部分的关系。但是与聚合不同此关系是整体与部分是同生共死关系。即如果整体对象销毁了部分也会被销毁。

     

    上图Head是整体Mouth是部分,如果Head没了Mouth也跟着销毁了。如果Mouth没了Head也将是面目全非。在代码中Head中Mouth是直接new出来的。

    就是说当你去new Head时Mouth也被new出来。记住一同创建一同销毁关系。也叫强关系。那么有人会问关联,聚合,组合我怎么认为是一样呢。

    可以说他们是一样的都可以说是关联关系,是的,但是关联关系的强弱来区分了一下关联关系强度来看组合>聚合>关联

    依赖关系(Dependency)

    是一个使用关系。特定事物的改变有可能会影响到使用该事物的其他事物。简单说在一个类中通过另外一个类来调用其方法的表示。

    从图中可以看出Driver中使用了Car的move方法。那么就说明Driver是依赖于Car才能做Driver的职责。那么又有人会问聚合与依赖有区别吗,当然很明显Driver是一个整体,Car也是整体。不是整体与部分关系。

    泛化关系(Generalization)

    继承(extends)关系,父类与子类关系。这个好理解直接上图。

    从图中可以看出Student也是Person,Teacher也是Person。他们有共同的特征name,age。但是也有独自的特征一个是study一个是teach的特征。

    子类那么就是Student,Teacher父类是Person。继承了父类那么子类可以直接适用父类的方法或属性(家产)。

    实现关系(Realization):

    类实现(implements)了接口.当多个类有类似的行为方式的时候我们通常会适用接口。

    Ship,Car都有move的特征他们都属于交通工具(Vehicle)只是他们move的方式不一样。那么我们就可以适用接口实现的方式去设计。代码中是public class Car implements Vehicle

    好我们来看一下一个完整的类图例子:

     

    回顾一下之前关系。去分析一下此UML的类图。

    用户通过注册界面(RegisterForm)输入个人信息,
    用户点击“注册”按钮后将输入的信息通过一个封装用户输入数据的对象(UserDTO)传递给操作数据库的数据访问类(DAO),
    为了提高系统的扩展性,针对不同的数据库可能需要提供不同的数据访问类,因此提供了数据访问类接口,
    如IUserDAO,每一个具体数据访问类都是某一个数据访问类接口的实现类,
    如OracleUserDAO就是一个专门用于访问Oracle数据库的数据访问类。

    UserDTO只是把userAcount,userPassword封装了一下使用了Getter,Setter。

    那么肯定是RegisterForm的成员,注册窗体不能没有用户名与密码信息所以是组合关系。RegisterForm没有了用户信息(UserDTO)那么就没有意义了。

    然后IUserDAO与RegisterForm是聚合关系因为是可以替换的。比如说你可以使用Oracle的以后扩展成Mysql的那么可以方便替换。

    考虑到今后会扩展UserDAO所以适用了接口。

    IUserDAO为什么与UserDTO是依赖关系,因为IUserDAO要把用户信息保存到数据库中那么必须需要用户信息。如果没有了用户信息此工作无法完成所以是依赖关系。

    下一节我们讨论一下顺序图

  • 相关阅读:
    CF601B Solution
    CF847F Solution
    CF877D Solution
    CF1472F Solution
    CF1472G Solution
    CF1355E Solution
    CF912D Solution
    CF1167F Solution
    shell脚本自动备份MySQL数据库
    centos7 crontab笔记
  • 原文地址:https://www.cnblogs.com/hongguang-kim/p/5698710.html
Copyright © 2020-2023  润新知