类图 软件工程_软件工程类图 - CSDN
  • 软件工程-类图

    2015-06-01 11:51:01
    类图的种类和实现一直没搞明白,参考网上的解释,大致整理了下:  类之间的关系种类:Realization(实现), Generalization(泛化),Dependency(依赖)、Association(关联)、Aggregation(聚合)、Composition(合成或...

    类图的种类和实现一直没搞明白,参考网上的解释,大致整理了下:

          类之间的关系种类:Realization(实现), Generalization(泛化),Dependency(依赖)、Association(关联)、Aggregation(聚合)、Composition(合成或组合)。 其中,Aggregation(聚合)、Composition(合成)属于Association(关联),是特殊的Association关联关系。

    1.实现(Realization)

    [实现]

    实现表示为实现接口关系

    [UML图]


    [代码表现]

    1. Class animal {}
    2. Class Cat implement animal { }

    2.泛化(Generalization)

    [泛化]

    表示类与类之间的继承关系,接口与接口之间的继承关系,或类对接口的实现关系。一般化的关系是从子类指向父类的,与继承或实现的方法相反。

    [具体表现]

    父类 父类实例=new 子类()

    [UML图]

     Animal类与Tiger类,Dog类的泛化关系

     

    [代码表现]

    1. class Animal{}   
    2. class Tiger extends Animal{}   
    3. public class Test   
    4. {   
    5.     public void test()   
    6.     {   
    7.         Animal a=new Tiger();   
    8.     }   
    9. }  

    3.依赖(Dependency)

    [依赖]

    对于两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,这两个对象之间主要体现为依赖关系。

    [具体表现]

    依赖关系表现在局部变量,方法的参数,以及对静态方法的调用

    [现实例子]

    比如说你要去拧螺丝,你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作

    [UML表现]

     Person类与Screwdriver类的依赖关系

     

    [代码表现]

    1. public class Person{   
    2.     /** 拧螺丝 */  
    3.     public void screw(Screwdriver screwdriver){   
    4.         screwdriver.screw();   
    5.     }   
    6. }  

    5.关联(Association)

    [关联]

    对于两个相对独立的对象,当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时,这两个对象之间为关联关系。

    [具体表现]

    关联关系是使用实例变量来实现

    [现实例子]

    比如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单;再例如公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司。

    [UML图]

    公司和员工的关联关系

     

    [代码表现]

    1. public class Company{   
    2.     private Employee employee;   
    3.     public Employee getEmployee(){   
    4.         return employee;   
    5.     }   
    6.     public void setEmployee(Employee employee){   
    7.         this.employee=employee;   
    8.     }   
    9.     //公司运作   
    10.     public void run(){   
    11.         employee.startWorking();   
    12.     }   
    13. }  

    (6)聚合(Aggregation)

    [聚合]

    当对象A被加入到对象B中,成为对象B的组成部分时,对象B和对象A之间为聚集关系。聚合是关联关系的一种,是较强的关联关系,强调的是整体与部分之间的关系。

    [具体表现]

    与关联关系一样,聚合关系也是通过实例变量来实现这样关系的。关联关系和聚合关系来语法上是没办法区分的,从语义上才能更好的区分两者的区别。

    [关联与聚合的区别]

    (1)关联关系所涉及的两个对象是处在同一个层次上的。比如人和自行车就是一种关联关系,而不是聚合关系,因为人不是由自行车组成的。

    聚合关系涉及的两个对象处于不平等的层次上,一个代表整体,一个代表部分。比如电脑和它的显示器、键盘、主板以及内存就是聚集关系,因为主板是电脑的组成部分。

    (2)对于具有聚集关系(尤其是强聚集关系)的两个对象,整体对象会制约它的组成对象的生命周期。部分类的对象不能单独存在,它的生命周期依赖于整体类的 对象的生命周期,当整体消失,部分也就随之消失。比如张三的电脑被偷了,那么电脑的所有组件也不存在了,除非张三事先把一些电脑的组件(比如硬盘和内存) 拆了下来。

    [UML图]

    电脑和组件的聚合关系

     

    [代码表现]

    1. public class Computer{   
    2.     private CPU cpu;   
    3.     public CPU getCPU(){   
    4.         return cpu;   
    5.     }   
    6.     public void setCPU(CPU cpu){   
    7.         this.cpu=cpu;   
    8.     }   
    9.     //开启电脑   
    10.     public void start(){   
    11.         //cpu运作   
    12.         cpu.run();   
    13.     }   
    14. }  

    (6)组合

    [组合]

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

    [UML图]

     

    [代码表现]

    public class Goose 
    {
        public Wing wing;
       
        public Goose()
        {
            wing =new Wing();
        }

     聚合和组合的区别:

    1.  聚合关系是“has-a”关系,聚合的整体与部分间关系较弱,
      其代表部分的对象与代表整体的对象生存期无关,删除了代表整体的对象不一定会删除代表部分的对象. 
    2. 组合关系是“contains-a”关系,组合的整体与部分间关系较强,
      其代表部分的对象与代表整体的对象具体相同的生存期,当删除代表整体的对象,同时也会删除了代表部分的对象.


    聚合:表示整体的类和表示部分的类之间“整体-部分”关系,一个类的对象,以另一个类的对象作为其组成部分,这样的对象之间具有“a part of(contains a) "或”has a"语义。

    整体-部分结构关系:如果一个对象a是对象b的一个组成部分,对象b为对象a的整体对象,对象a为对象b的部分对象,对象a和对象b的关系称作“整体-部分结构关系”。

     

    几种关系所表现的强弱程度依次为:组合>聚合>关联>依赖
    展开全文
  • UML和建模软件Rose的使用已在上一篇介绍过了,这一篇我们继续介绍画图方法。 我们介绍“类图”: 用于描述系统中的类与类之间的各种关系。 继承:父子类关系; 实现:类与接口关系; 关联(全局变量, 组合/聚合): 值、引用...
    UML和建模软件Rose的使用已在上一篇介绍过了,这一篇我们继续介绍画图方法。
    我们介绍“类图”:

    用于描述系统中的类与类之间的各种关系。

    继承:父子类关系;

    实现:类与接口关系;
    关联(全局变量, 组合/聚合): 值、引用;
    依赖:局部变量(非Spring中 依赖注入)。


    1.类图举例
    我们在Rose中创建类图的方法:



    创建一个实体:


    然后鼠标放在实体上面,单击鼠标右键,可以添加这个实体类的属性和方法:

    添加一个属性,然后双击属性,点检attribute可以设置属性的详细:


    然后我们再添加一个name的属性。

    之后我们按照上面类似的方法,给实体类添加一个方法:



    然后我们给它设置一个参数(String name),无返回(void)


    然后用同样的方法我们添加getName()方法:



    如果不显示方法的参数,可以勾选“显示原型”:



    之后我们添加一个接口:


    接口图形如果是圆的,不想用圆的:



    想改成方的,就在这里更改:



    好了,我们的类图的例子和设置方法给大家了,我们将使用这种画图方法来画一个完整的类图。
    我们画一个用户管理模块的类图:

    其中图中的"关联"和"依赖"的不同:
    关联:全局性
    依赖:局部性

    然后我们解释一下图中的各种关系:
    (1)继承关系
    public abstract class BaseDaoImpl{
    	
        public void save(Object entity){
        }
    	
        public Object findObject(Object id){
        }
    
    
    }
    
    
    public class UserDaoImpl extends BaseDaoImpl{
    }



    (2)实现关系
    public interface UserDao {
    }
    public class UserDaoImpl 
    implements UserDao {
    }



    (3)关联关系
    关联关系实际上就是类与类之间的联系;
    关联具有导航性:即双向关系或单向关系。



    (4)关联之聚合关系(By ref)
    聚合关系,表示的是整体和部分的关系,整体与部分可以分开。

    使用带空心菱形的实线来表示:


    (5)组合关系(By value)
    也是整体与部分的关系,但是整体与部分不可以分开;部分离开整体没有实际意义。
    使用带实心菱形的实线来表示:


    (6)依赖关系
    A类使用到了另一个B类型。

    关系具有:临时性的、偶然性,但是B类的变

    会影响到A。代码层面,为类B作为参数被类A在某个method方法中使用。


    转载请注明出处:http://blog.csdn.net/acmman/article/details/50326207

    展开全文
  • 软件工程 对象类图类图)与对象图 软件工程 对象类图类图)与对象图
  • 软件工程类图

    2020-07-26 23:33:26
    没有什么要描述的,,,需要的下载。
  • 软件工程导论》主编:薛继伟 哈尔滨工业大学出版社 第一章软件工程概述 软件:软件是程序以及所有使程序正确运行所需的相关文档和配置信息。软件=程序+数据+文档 软件危机:随着计算机应用的普及,软件的数量...

    《软件工程导论》主编:薛继伟 哈尔滨工业大学出版社


    第一章软件工程概述

    • 软件:软件是程序以及所有使程序正确运行所需的相关文档和配置信息。软件=程序+数据+文档
    • 软件危机:随着计算机应用的普及,软件的数量急剧增加,众多因素导致了软件开发过程中所开发的软件产品质量低下,众多软件无法满足用户需求,软件的可维护性差,以至于问题不断堆积矛盾日益尖锐,称此现象为软件危机。
    • 软件工程:软件工程是一类工程,是将理论和知识应用于实践的学科,它借鉴了工程的原则和方法,以求高效的开发高质量的软件。
    • 软件生命周期:是指软件在生产到报废的生命周期,包括可行性分析,项目开发计划,需求分析,概要设计,详细设计,编码,测试,维护等阶段。
    • 瀑布模型:详见《软件工程导论》薛继伟-哈尔滨工业大学出版社
    • 快速原型原型模型:详见《软件工程导论》薛继伟-哈尔滨工业大学出版社
    • 增量模型:详见《软件工程导论》薛继伟-哈尔滨工业大学出版社

    第二章软件工程方法与工具

    • UML
    • UML:UML是用来对软件密集系统进行可视化建模的一种语言,是对面向对象开发系统的产品进行说明、可视化、和文档编制的一种标准语言。
    • 用例图:用例描述了系统的工作方式,以及系统提供的服务。用例图描述了系统外部参与者如何使用系统提供的服务。(P.37)
    • 类图:类图用来表示系统中的类以及类与类之间的关系描述系统的静态结构,用于逻辑视图中。(P.38)
    • 对象图:对象图是类图的示例,描述了一组对象以及他们之间的关系,表示类的对象实例。对象图表示在某一时刻这些类的实例以及这些实例之间的关系。
    • 状态图:状态图表示一个状态机,强调对象行为的时间顺序,显示一个对象的状态以及状态与状态之间的转换。
    • 对象之间的关系
    • 依赖:依赖是一种使用关系,表示一个元素以某一钟方法依赖于另一个元素,一个事物的变化会影响到另一个使用它的事物。
    • 关联:关联是一种结构关系,说明一个事物的对象与另一个事物的对象之间的联系,表示模型元素及链接实例。
    • 泛化:泛化是一种“一般事物”(父类)与“特殊事物”(子类)之间的关系,表示一般与特殊关系,即“一般元素”是“特殊元素”的泛化,“特殊元素”是“一般元素”的特化。
    • 聚集:聚集表示整体与部分的关系,即“部分元素”是“整体元素”的一部分。
    • 面向对象
    • 对象
    • 封装
    • 继承
    • 多态
    • 消息

    第三章软件立项

    • 可行性研究:可行性分析的目的是从各个方面去综合对比分析,对比成功或者失败的可能性有多大,是否值得进行立项等。一般可行性分析的要素有:市场可行性分析、政策(政府)可行性分析、技术可行性分析和成本效益分析。

    第四章软件需求分析

    • 需求分析:收集用户需求,找到用户真正的需求,确定系统具体需要什么功能。
    • 需求规格说明书:需求分析的产物为需求规格说明书。
    • 需求验证:需求验证是指需求规格说明书完成之后,对需求规格说明书文档进行验证的活动,目的是发现并纠正说明书中的错误、遗漏和不一致的地方。以确保所有的系统需求规格说明书最大限度的正确、清晰、完整、无歧义并符合标准和规范。
    • 数据流图(泡图):从数据加工的角度,以图形的方式来表达系统的逻辑功能,数据在系统内部的逻辑流向,和逻辑变换过程,是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
    • 数据字典:数据字典是关于数据的信息集合,即数据字典的作用是为数据流图上的每一个成分加一定义和说明。
    • ER图(实体-联系图):表示数据对象及其关系,也叫做E-R图。包括数据对象、对象的属性、对象间相互连接的关系。
    • 功能模型:功能模型表示系统的“功能”性质,它指明了系统要应该“做什么”,反映了用户对目标系统的需求。
    • 对象模型:表示静态的,结构化的,系统的数据性质。是对模拟客观世界实体的对象以及对象和对象之间的关系的映射,描述了系统的静态结构。
    • 动态模型:UML动态模型图主要包括交互图和行为图,交互图又分为时序图和协作图,行为图又分为状态图和活动图。在开发交互式系统的时候动态模型非常重要。
    • 程序设计语言(过程设计语言PDl):又称为伪码.它是一种用于描述模块算法设计和处理细节的语言.

    第五章软件设计

    • 概要设计:把需求转换为需要的体系结构,概要设计就是设计软件的结构,该结构有哪些模块组成,这些模块的层次结构是怎么样的,模块之间的调用关系是什么样的,每个模块的功能是什么。
    • 详细设计:为每个模块的功能进行详细的描述,把功能描述转变为精确的、结构化的过程描述,即该模块的控制结构是怎样的,先做什么,后座什么,有什么样的判定条件,有生重复处理等,并用相应的表示工具将这些控制结构表示出来。
    • 软件体系结构:一个程序或者计算机系统的软件体系包括一个或者一组软件构件、软件构件的外部的可见特征性,及其相互关系。(1997年)
    • 抽象:暂时忽略事物之间的微小差别,将彼此之间相似,共性的东西进行概括。
    • 控制抽象:从指令到汇编语言再到高级语言,让程序员在更高的层次进行抽象,屏蔽不同机器和指令集之间的差异。
    • 过程抽象:将处理过程抽象为存储过程,函数和方法,通过提供不同的参数实现具体化。
    • 数据抽象:使用数据抽象能够设计出数据库表和字段,或者设计出类的属性。
    • 模块:具有相对独立性的,由数据说明执行语句等程序对象构成的集合。(在高级语言中模块体现为函数、子过程、过程)
    • 模块化:每个模块有特定的子功能,各个模块按照一定的方法组合起来称为一个整体,从而从而实现整个系统的功能。
    • 模块独立性:是指每个模块只完成系统要求的独立的子功能,并且与其他模块的联系最小,接口最简单。
    • 信息隐蔽:是指一个模块将自身的内部信息向其他模块隐藏起来,以避免其他模块不恰当的访问和修改。
    • 耦合:模块与模块之间的联系越高,耦合性就越大。
    • 数据耦合:两个模块之间仅仅通过模块参数交换信息,且交换的信息全部为简单数据。
    • 公共耦合:两个或者多个模块通过应用公共数据相互联系。
    • 内容耦合:一个模块对另一个模块的内容进行了直接的引用甚至是修改,或者通过非正常的入口,进入到另一个的内部,或者一个模块具有多个入口,或者两个模块共享一部分代码。
    • 控制耦合:一个模块通过传送开关、标志、名字等控制信息,明显的对另一个模块的功能进行控制。
    • 内聚: 标志着一个模块内各个元素彼此的紧密程度,他是信息隐藏和局部化概念的自然扩展。主要有一下7中内聚类型,内聚性逐渐增大。
    • 偶然内聚:一个模块内各个语句段之间的联系十分松散或者直接没有联系,或者根本没有什么联系,很可能是在一种场合允许修改该模块,而另外一种场合不允许修改该模块。
    • 逻辑内聚:一个模块实现多个逻辑上相同或类似的一类功能。
    • 时间内聚:模块内的多个功能在同一个时间内执行。
    • 过程内聚:模块内各个部分相关,并且必须按照特定的次序执行。
    • 通信内聚:模块内各个元素都使用同一个输入数据和(或)都产生同一个数据输出。
    • 顺序内聚:模块的各个功能必须顺序执行(往往后一个功能需要依托前一个功能的结果)。
    • 功能内聚:模块内所有处理元素属于同一个整体,完成一个单一的功能。
    • 数据流类型:
    • 变换型:信息流沿输入通路进入系统,同时由外部形式装换成内部形式,进入系统的数据流经过变换中心,加工处理之后,再沿输出通路变换成外部形式离开软件系统。
    • 事务型:数据沿输入通路进入到一个处理T后,这个处理根据输入数据的类型在若干个动作系列中选择一个来执行。
    • 程序流程图:即程序框图。
    • PAD图:用于详细设计的图形表达工具,只能用于结构化程序的描述。
    • NS图:即无线流程图。
    • 面向对象设计(OOD):建立在面向对象分析之上的,把分析阶段得到的需求转变为符合成本和重量要求的抽象的系统实现方案的过程。

    第六章软件实现

    • 编码:通过选定的程序语言,将详细设计阶段的模块过程性描述,转变为特定语言书写的源程序(源代码)。
    • 编码风格:代码应该是正确的、有效的、可维护的、易读易懂的。

    第七章软件测试

    一、软件测试:是为了发现错误而执行程序的过程,或者说是根据软件开发的各个阶段的规格说明书和程序内部结构而精心设计的一批测试用例。并且用这些用例来运行程序,发现其中的错误。有一下几种测试方法:

    1、黑盒测试:根据被测程序的功能来进行测试,也称为功能测试或者是数据驱动测试,主要着眼于程序的外部结构,不考虑内部的逻辑结构,针对软件界面软件功能进行测试。(在已知产品的功能情款下,通过测试检验已知功能是否能正常使用)。

    • 等价类划分法:完全不考虑软件的内部结构,只是根基软件的规格说明书设计测试用例,因为不可能输入所有情款的测试数据(穷举测试是不可能实现的),所以采用等价类分化的方法将输入数据的可能值分为若干个等价类,使每一个等价类中的任何一个测试用例,都能代表同一等价类中的其他测试用例。
    • 边界值分析法:程序往往会在处理边界情况是后发生错误,边界值是指输入或者输出的等价类边界上的值。当使用边界值分析法选取测试用例的时候,选择的测试数据应该刚好等于,刚好小于,刚好大于等价类的边界值的数据。
    • 错误推测法:往往根据测试人员的检验与直觉,推测程序中可能存在的各种错误,从而有针对性的编写检查这些错误的测试用例进行有针对性的测试。
    • 因果图法:在测试用例输入条件之间会存在着联系,不同的联系会产生不同的结果。所以必须考虑一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑测试用例。

    2、白盒测试:是以程序的结构为依据,又称为结构测试。它是按照程序内部的结构测试程序。检查程序中的每一条路是否都能按照预定的要求正常工作。

    • 逻辑覆盖测试:是以程序内部的逻辑结构为基础的设计测试用例的技术。
    • 语句覆盖
    • 判定覆盖
    • 条件覆盖
    • 判定/条件覆盖
    • 路径测试:测试程序运行的路径,保证程序中的每一条可能执行到的路径至少测试一次。
      ####软件测试过程:(P.206)
    • 1、单元测试:针对程序模块,进行正确性的测试。
    • 2、集成测试:又称为组装测试或者联合测试,在单元测试的基础上,将模块或组件按照设计的要求租转起来,同时进行测试,主要目的是发现与接口有关的问题,即模块与模块之间的协作与通信。
    • 3、确认测试:经过集成测试之后软件已经组装起来了,接口方面的错误也已经排除,之后进行确认测试(有效性测试),主要任务是验证软件的有效性,验证软件功能和性能是否与用户的需求一直。
    • α测试和β测试用以发现只有最终的用户才可以发现的错误。
    • α测试:是在受控制的环境下进行的测试,主要是评价软件的FURPS(即功能、可使用性、可靠性、性能、和支持),尤其注重产品的界面和特色。
    • β测试:是指软件的一个或者多个用户在一个或多个用户的实际使用环境下进行的测试。开发者不在测试现场,主要衡量产品的FURPS,着重于产品的支持性,包括文档,客户培训和支持产品生产能力。
    • 4、系统测试:通过确认测试之后的软件作为基于计算机系统的一个元素,除了被测程序之外硬件,等实际环境下的测试。

    二、软件调试:调试的任务就是根据测试时发现的错误,找出错误的原因和具体位置,并进行改正。改正后重新测试。


    第八章软件维护

    软件维护:在软件交付使用之后,为了纠正软件的错误,满足新的需求,或者适应新的软件、硬件环境而对软件进行修改的过程。

    • 可维护性:是指维护人员为了满足用户的需求而对软件系统出现的错误和缺陷进行修正,或对系统进行完善的难易程度。
    • 改正性维护(纠错性维护):软件产品投入使用支出会暴露出各种各样的错误,改正性维护是针对在系统运行过程中暴露的错误而进行的一种维护活动。
    • 完善性维护:随着软件产品平稳运行之后,用户往往会提出新的需求或者对性能的要求,为了满足这种要求,维护人员需要扩展软件的功能,提升软件的性能,是产品有更高的效率。
    • 适应性维护:软件产品在使用过程中会随着软件、硬件环境的变化,为了使软件产品适应这种环境的变化而对软件产品做出的维护,称为适应性维护。
    • 预防性维护:此目的是为了在问题有可能发生之前,主动的提高软件的可靠性,为今后的维护工作创造更加便利的条件,提高软件的可维护性。

    第九章软件质量保证

    • 软件质量:软件质量是软件产品满足规定的和隐含的与需求能力有关的全部特征和特性。包括:①软件产品满足用户需要的程度;②软件拥有所期望的各种属性组合的程度:③用户对软件产品的综合反映度;④软件在使用过程中满足用户需要的程度。
    • 软件质量的属性:
    • 功能性:软件按照需求正确执行任务的能力。
    • 可靠性:软件在特定条件下和特殊时间内,不出故障,维持其正常性能水准的能力的程度。
    • 易使用性:用户为使用一个软件而付出的努力以及其他代价的程度,也就是用户使用软件的容易程度。
    • 效率:指在特定的条件下,软件功能与所占用资源之间的比例关系。
    • 可维护性:是指当发现错误,运行环境改变或用户需求改变的时候,程序可被修改的难易程度。
    • 可移植性:是指将软件从一种环境移植到另一种环境的难易程度,主要体现为代码的可移植性。

    PS:

    • 期末考复习资料整理;
    • 文章为《软降工程导论》(主编:薛继伟 哈尔滨工业大学出版社)的内容要点抽取。知识点以原书为准。
    展开全文
  • UML软件工程--类图

    2011-04-11 11:30:00
    UML 基础:类图 选自:IBM 这是关于统一建模语言、即UML 里采用的基本图的一系列文章的一部分。在我 先前关于序列图的文章 里,我把重点从 UML 1.4 版,转移到 OMG的采用UML 2.0版草案规范(又称为UML 2...
    UML 基础:类图
    选自:IBM

    这是关于统一建模语言、即UML 里采用的基本图的一系列文章的一部分。在我 先前关于序列图的文章 里,我把重点从 UML 1.4 版,转移到 OMG的采用UML 2.0版草案规范(又称为UML 2)。在这篇文章中,我将会讨论结构图,这是已经在 UML 2 中提出的一种新图种类。由于本系列文章的目的是使人们了解记号元素及它们的含意,该文主要关注类图。你很快就会知道这样做的理由。随后的文章将会覆盖结构范畴中包含的其它图。

    我也想提醒读者,这一系列文章是关于 UML 记号元素的,所以这些文章并不意味着为建模的最好方式提供指导方针,或是该如何决定哪些内容应该首先被建模。相反的,该文及本系列文章的目的主要是帮助大家对于记号元素 -- 语法和含义有一个基本的理解。借由这些知识,你应该可以阅读图,并使用正确的记号元素创建你自己的图。

    这篇文章假定你对面向对象的设计已经有了基本的理解。你们当中如果有人需要一些面向对象 概念的帮助,那么可以访问http://java.sun.com/docs/books/tutorial/java/concepts/,来获得 Sun公司关于面向对象编程的简短指导。阅读 “什么是类?”和 什么是继承?” 章节,将提供给你足够的理解,并对该文的阅读会有所帮助。另外,David Taylor的书《 Object-Oriented Technologies: A Manager's Guide》提供了面向对象设计的优秀,高水平的说明,而无需对计算机编程有高深的理解。

    UML 2 中的阴和阳
    在 UML 2 中有二种基本的图范畴:结构图和行为图。每个 UML 图都属于这二个图范畴。结构图的目的是显示建模系统的静态结构。它们包括类,组件和(或)对象图。另一方面,行为图显示系统中的对象的动态行为,包括如对 象的方法,协作和活动之类的内容。行为图的实例是活动图,用例图和序列图。

    大体上的结构图
    如同我所说的,结构图显示建模系统的静态结构。关注系统的元件,无需考虑时间。在系统内,静态结构通过显示类型和它们的实例进行传播。除了显示系统类型和 它们的实例,结构图至少也显示了这些元素间的一些关系,可能的话,甚至也显示它们的内部结构。

    贯穿整个软件生命周期,结构图对于各种团队成员都是有用的。一般而言,这些图支持设计验 证,和个体与团队间的设计交流。举例来说,业务分析师可以使用类或对象图,来为当前的资产和资源建模,例如分类账,产品或地理层次。架构师可以使用组件和 部署图,来测试/确认他们的设计是否充分。开发者可以使用类图,来设计并为系统的代码(或即将成为代码的)类写文档。

    特殊的类图

    UML 2 把结构图看成一个分类;这里并不存在称为“结构图”的图。然而,类图提供结构图类型的一个主要实例,并为我们提供一组记号元素的初始集,供所有其它结构图 使用。由于类图是如此基本,本文的剩余部分将会把重点集中在类图记号集。在本文的结尾,你将对于如何画UML 2类图有所了解,而且对于理解在后面文章中将涉及的其他结构图有一个稳固的基础。

    基础
    如先前所提到的,类图的目的是显示建模系统的类型。在大多数的 UML 模型中这些类型包括:


    • 接口
    • 数据类型
    • 组件

    UML 为这些类型起了一个特别的名字:“分类器”。通常地,你可以把分类器当做类,但在技术上,分类器是更为普遍的术语,它还是引用上面的其它三种类型为好。

    类名

    类的 UML 表示是一个长方形,垂直地分为三个区,如图 1 所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在一个类图上画一个类元素时,你必须要有顶端的区域,下面的二个区域是 可选择的(当图描述仅仅用于显示分类器间关系的高层细节时,下面的两个区域是不必要的)。图 1 显示一个航线班机如何作为 UML 类建模。正如我们所能见到的,名字是 Flight ,我们可以在中间区域看到Flight类的3个属性:flightNumber,departureTime 和 flightDuration。在底部区域中我们可以看到Flight类有两个操作:delayFlight 和 getArrivalTime。

    图 1: Flight类的类图

    图 1: Flight类的类图

     

    类属性列表

    类的属性节(中部区域)在分隔线上列出每一个类的属性。属性节是可选择的,要是一用它,就包含类的列表显示的每个属性。该线用如下格式:

    name : attribute type
    
    flightNumber : Integer
    

    继续我们的Flight类的例子,我们可以使用属性类型信息来描述类的属性,如表 1 所示。

    表 1:具有关联类型的Flight类的属性名字

    属性名称 属性类型
    flightNumber Integer
    departureTime Date
    flightDuration Minutes

    在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。然而,用于生成代码的类图,要求类的属性类型必须限制在由程序语言提供的类型之中,或包含于在系统中实现的、模型的类型之中。

    在类图上显示具有默认值的特定属性,有时是有用的(例如,在银行账户应用程序中,一个新的银行账户会以零为初始值)。UML 规范允许在属性列表节中,通过使用如下的记号作为默认值的标识:

    name : attribute type = default value
    

    举例来说:

    balance : Dollars = 0
    

    显示属性默认值是可选择的;图 2 显示一个银行账户类具有一个名为 balance 的类型,它的默认值为0。

    图 2:显示默认为0美元的balance属性值的银行账户类图。

    图 2:显示默认为0美元的balance属性值的银行账户类图。

     

    类操作列表

    类操作记录在类图长方形的第三个(最低的)区域中,它也是可选择的。和属性一样,类的操作以列表格式显示,每个操作在它自己线上。操作使用下列记号表现:

    	name(parameter list) : type of value returned
    

    下面的表 2 中Flight类操作的映射。

    表 2:从图 2 映射的Flight类的操作

    操作名称 返回参数 值类型
    delayFlight
    Name Type
    numberOfMinutes Minutes
    N/A
    getArrivalTime N/A Date

    图3显示,delayFlight 操作有一个Minutes类型的输入参数 -- numberOfMinutes。然而,delayFlight 操作没有返回值。1 当一个操作有参数时,参数被放在操作的括号内;每个参数都使用这样的格式:“参数名:参数类型”。

    图 3:Flight类操作参数,包括可选择的“in”标识。

    图 3:Flight类操作参数,包括可选择的“in”标识。

     

    当文档化操作参数时,你可能使用一个可选择的指示器,以显示参数到操作的输入参数、或输出参数。这个可选择的指示器以“in”或“out”出现,如图3中的操作区域所示。一般来说,除非将使用一种早期的程序编程语言,如Fortran ,这些指示器可能会有所帮助,否则它们是不必要的。然而,在 C++和Java中,所有的参数是“in”参数,而且按照UML规范,既然“in”是参数的默认类型,大多数人将会遗漏输入/输出指示器。

    继承

    在面向对象的设计中一个非常重要的概念,继承 ,指的是一个类(子类)继承 另 外的一个类(超类)的同一功能,并增加它自己的新功能(一个非技术性的比喻,想象我继承了我母亲的一般的音乐能力,但是在我的家里,我是唯一一个玩电吉他 的人)的能力。为了在一个类图上建模继承,从子类(要继承行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。考虑银行账户的类型:图 4 显示 CheckingAccount 和 SavingsAccount 类如何从 BankAccount 类继承而来。

    图 4: 继承通过指向超类的一条闭合的,单箭头的实线表示。

    图 4: 继承通过指向超类的一条闭合的,单箭头的实线表示。

     

    在图 4 中,继承关系由每个超类的单独的线画出,这是在IBM Rational Rose和IBM Rational XDE中使用的方法。然而,有一种称为 树标记 的备选方法可以画出继承关系。当存在两个或更多子类时,如图 4 中所示,除了继承线象树枝一样混在一起外,你可以使用树形记号。图 5 是重绘的与图 4 一样的继承,但是这次使用了树形记号。

    图 5: 一个使用树形记号的继承实例

    图 5: 一个使用树形记号的继承实例

     

    抽象类及操作
    细心的读者会注意到,在图 4 和 图5 中的图中,类名BankAccount和withdrawal操作使用斜体。这表示,BankAccount 类是一个抽象类,而withdrawal方法是抽象的操作。换句话说,BankAccount 类使用withdrawal规定抽象操作,并且CheckingAccount 和 SavingsAccount 两个子类都分别地执行它们各自版本的操作。

    然而,超类(父类)不一定要是抽象类。标准类作为超类是正常的。

    关联
    当你系统建模时,特定的对象间将会彼此关联,而且这些关联本身需要被清晰地建模。有五种关联。在这一部分中,我将会讨论它们中的两个 -- 双向的关联和单向的关联,而且我将会在Beyond the basics 部分讨论剩下的三种关联类型。请注意,关于何时该使用每种类型关联的详细讨论,不属于本文的范围。相反的,我将会把重点集中在每种关联的用途,并说明如何在类图上画出关联。

    双向(标准)的关联
    关联是两个类间的联接。关联总是被假定是双向的;这意味着,两个类彼此知道它们间的联系,除非你限定一些其它类型的关联。回顾一下Flight 的例子,图 6 显示了在Flight类和Plane类之间的一个标准类型的关联。

    图 6:在一个Flight类和Plane类之间的双向关联的实例

    图 6:在一个Flight类和Plane类之间的双向关联的实例

     

    一个双向关联用两个类间的实线表示。在线的任一端,你放置一个角色名和多重值。图 6 显示Flight与一个特定的Plane相关联,而且Flight类知道这个关联。因为角色名以Plane类表示,所以Plane承担关联中的 “assignedPlane”角色。紧接于Plane类后面的多重值描述0...1表示,当一个Flight实体存在时,可以有一个或没有Plane与 之关联(也就是,Plane可能还没有被分配)。图 6 也显示Plane知道它与Flight类的关联。在这个关联中,Flight承担“assignedFlights”角色;图 6 的图告诉我们,Plane实体可以不与flight关联(例如,它是一架全新的飞机)或与没有上限的flight(例如,一架已经服役5年的飞机)关联。

    由于对那些在关联尾部可能出现的多重值描述感到疑惑,下面的表3列出了一些多重值及它们含义的例子。

    表 3: 多重值和它们的表示

    可能的多重值描述
    表示 含义
    0..1 0个或1个
    1 只能1个
    0..* 0个或多个
    * 0个或多个
    1..* 1个或我个
    3 只能3个
    0..5 0到5个
    5..15 5到15个

    单向关联
    在一个单向关联中,两个类是相关的,但是只有一个类知道这种联系的存在。图 7 显示单向关联的透支财务报告的一个实例。

    图 7: 单向关联一个实例:OverdrawnAccountsReport 类 BankAccount 类,而 BankAccount 类则对关联一无所知。

    图 7: 单向关联一个实例:OverdrawnAccountsReport 类 BankAccount 类,而 BankAccount 类则对关联一无所知。

     

    一个单向的关联,表示为一条带有指向已知类的开放箭头(不关闭的箭头或三角形,用于标志继承)的实线。如同标准关联,单向关联包括一个角色名和一个多重值描述,但是与标准的双向关联不同的时,单向关联只包含已知类的角色名和多重值描述。在图 7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 类,而且知道 BankAccount 类扮演“overdrawnAccounts”的角色。然而,和标准关联不同,BankAccount 类并不知道它与 OverdrawnAccountsReport 相关联。2

    软件包
    不可避免,如果你正在为一个大的系统或大的业务领域建模,在你的模型中将会有许多不同的分类器。管理所有的类将是一件令人生畏的任务;所以,UML 提供一个称为 软件包 的组织元素。软件包使建模者能够组织模型分类器到名字空间中,这有些象文件系统中的文件夹。把一个系统分为多个软件包使系统变成容易理解,尤其是在每个软件包都表现系统的一个特定部分时。3

    在图中存在两种方法表示软件包。并没有规则要求使用哪种标记,除了用你个人的判断:哪种更便于阅读你画的类图。两种方法都是由一个较小的长方形(用于定位)嵌套在一个大的长方形中开始的,如图 8 所示。但是建模者必须决定包的成员如何表示,如下:

    • 如果建模者决定在大长方形中显示软件包的成员,则所有的那些成员4 需要被放置在长方形里面。另外,所有软件包的名字需要放在软件包的较小长方形之内(如图 8 的显示)。
    • 如果建模者决定在大的长方形之外显示软件包成员,则所有将会在图上显示的成员都需要被置于长方形之外。为了显示属于软件包的分类器属于,从每个分类器画一条线到里面有加号的圆周,这些圆周粘附在软件包之上(图9)。

    图 8:在软件包的长方形内显示软件包成员的软件包元素例子

    图 8:在软件包的长方形内显示软件包成员的软件包元素例子

     

    图 9:一个通过连接线表现软件包成员的软件包例子

    图 9:一个通过连接线表现软件包成员的软件包例子

     

    了解基础重要性

    在 UML 2 中,了解类图的基础更为重要。这是因为类图为所有的其他结构图提供基本的构建块。如组件或对象图(仅仅是举了些例子)。

    超过基础
    到此为止,我已经介绍了类图的基础,但是请继续往下读!在下面的部分中,我将会引导你到你会使用的类图的更重要的方面。这些包括UML 2 规范中的接口,其它的三种关联类型,可见性和其他补充。

    接口
    在本文的前面,我建议你以类来考虑分类器 。事实上,分类器是一个更为一般的概念,它包括数据类型和接口。

    关于何时、以及如何高效地在系统结构图中使用数据类型和接口的完整讨论,不在本文的讨论 范围之内。既然这样,我为什么要在这里提及数据类型和接口呢?你可能想在结构图上模仿这些分类器类型,在这个时候,使用正确的记号来表示,或者至少知道这 些分类器类型是重要的。不正确地绘制这些分类器,很有可能将使你的结构图读者感到混乱,以后的系统将不能适应需求。

    一个类和一个接口不同:一个类可以有它形态的真实实例,然而一个接口必须至少有一个类来实现它。在 UML 2 中,一个接口被认为是类建模元素的特殊化。因此,接口就象类那样绘制,但是长方形的顶部区域也有文本“interface”,如图 10 所示。5

    图 10:Professor类和Student类实现Person接口的类图实例

    图 10:Professor类和Student类实现Person接口的类图实例

     

    在图 10 中显示的图中,Professor和Student类都实现了Person的接口,但并不从它继承。我们知道这一点是由于下面两个原因:1) Person对象作为接口被定义 -- 它在对象的名字区域中有“interface”文本,而且我们看到由于Professor和Student对象根据画类对象的规则(在它们的名字区域中没有额外的分类器文本)标示,所以它们是 对象。 2) 我们知道继承在这里没有被显示,因为与带箭头的线是点线而不是实线。如图 10 所示,一条带有闭合的单向箭头的 线意味着实现(或实施);正如我们在图 4 中所见到的,一条带有闭合单向箭头的 线表示继承。

    更多的关联
    在上面,我讨论了双向关联和单向关联。现在,我将会介绍剩下的三种类型的关联。

    关联类
    在关联建模中,存在一些情况下,你需要包括其它类,因为它包含了关于关联的有价值的信息。对于这种情况,你会使用 关联类 来绑定你的基本关联。关联类和一般类一样表示。不同的是,主类和关联类之间用一条相交的点线连接。图 11 显示一个航空工业实例的关联类。

    图 11:增加关联类 MileageCredit

    图 11:增加关联类 MileageCredit

     

    在图 11 中显示的类图中,在Flight类和 FrequentFlyer 类之间的关联,产生了称为 MileageCredit的关联类。这意味当Flight类的一个实例关联到 FrequentFlyer 类的一个实例时,将会产生 MileageCredit 类的一个实例。

    聚合
    聚合是一种特别类型的关联,用于描述“总体到局部”的关系。在基本的聚合关系中, 部分类 的生命周期独立于 整体类 的生命周期。

    举例来说,我们可以想象, 是一个整体实体,而 车轮 轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造,并放置于仓库中。在这个实例中,Wheel类实例清楚地独立地Car类实例而存在。然而,有些情况下, 部分 类的生命周期并 独立于 整体 类的生命周期 -- 这称为合成聚合。举例来说,考虑公司与部门的关系。 公司和部门 都建模成类,在公司存在之前,部门不能存在。这里Department类的实例依赖于Company类的实例而存在。

    让我们更进一步探讨基本聚合和组合聚合。

    基本聚合
    有聚合关系的关联指出,某个类是另外某个类的一部分。在一个聚合关系中,子类实例可以比父类存在更长的时间。为了表现一个聚合关系,你画一条从父类到部分类的实线,并在父类的关联末端画一个未填充棱形。图 12 显示车和轮胎间的聚合关系的例子。

    图 12: 一个聚合关联的例子

    图 12: 一个聚合关联的例子

     

    组合聚合
    组合聚合关系是聚合关系的另一种形式,但是子类实例的生命周期依赖于父类实例的生命周期。在图13中,显示了Company类和Department类之间的组合关系,注意组合关系如聚合关系一样绘制,不过这次菱形是被填充的。

    图 13: 一个组合关系的例子

    图 13: 一个组合关系的例子

     

    在图 13 中的关系建模中,一个Company类实例至少总有一个Department类实例。因为关系是组合关系,当Company实例被移除/销毁 时,Department实例也将自动地被移除/销毁。组合聚合的另一个重要功能是部分类只能与父类的实例相关(举例来说,我们例子中的Company 类)。

    反射关联
    现在我们已经讨论了所有的关联类型。就如你可能注意到的,我们的所有例子已经显示了两个不同类之间的关系。然而,类也可以使用反射关联与它本身相关联。起先,这可能没有意义,但是记住,类是抽象的。图 14 显示一个Employee类如何通过manager / manages角色与它本身相关。当一个类关联到它本身时,这并不意味着类的实例与它本身相关,而是类的一个实例与类的另一个实例相关。

    图 14:一个反射关联关系的实例

    图 14:一个反射关联关系的实例

     

    图 14 描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。然而,因为“manages”的关系角色有 0..*的多重性描述;一个雇员可能不受任何其他雇员管理。

    可见性
    在面向对象的设计中,存在属性及操作可见性的记号。UML 识别四种类型的可见性:public,protected,private及package。

    UML 规范并不要求属性及操作可见性必须显示在类图上,但是它要求为每个属性及操作定义可见性。为了在类图上的显示可见性,放置可见性标志于属性或操作的名字之前。虽然 UML 指定四种可见性类型,但是实际的编程语言可能增加额外的可见性,或不支持 UML 定义的可见性。表4显示了 UML 支持的可见性类型的不同标志。

    表 4:UML 支持的可见性类型的标志

    标志 可见性类型
    + Public
    # Protected
    - Private
    ~ Package

    现在,让我们看一个类,以说明属性及操作的可见性类型。在图 15 中,所有的属性及操作都是public,除了 updateBalance 操作。updateBalance 操作是protected。

    图 15:一个 BankAccount 类说明它的属性及操作的可见性

    图 15:一个 BankAccount 类说明它的属性及操作的可见性

     

    UML 2 补充
    既然我们已经覆盖了基础和高级主题,我们将覆盖一些由UML 1. x增加的类图的新记号。

    实例
    当一个系统结构建模时,显示例子类实例有时候是有用的。为了这种结构建模,UML 2 提供 实例规范 元素,它显示在系统中使用例子(或现实)实例的值得注意的信息。

    实例的记号和类一样,但是取代顶端区域中仅有的类名,它的名字是经过拼接的:

    Instance Name : Class Name
    

    举例来说:

    Donald : Person
    

    因为显示实例的目的是显示值得注意的或相关的信息,没必要在你的模型中包含整个实体属性及操作。相反地,仅仅显示感兴趣的属性及其值是完全恰当的。如图16所描述。

    图 16:Plane类的一个实例例子(只显示感兴趣的属性值)

    图 16:Plane类的一个实例例子(只显示感兴趣的属性值)

     

    然而,仅仅表现一些实例而没有它们的关系不太实用;因此,UML 2 也允许在实体层的关系/关联建模。绘制关联与一般的类关系的规则一样,除了在建模关联时有一个附加的要求。附加的限制是,关联关系必须与类图的关系相一 致,而且关联的角色名字也必须与类图相一致。它的一个例子显示于图 17 中。在这个例子中,实例是图 6 中类图的例子实例。

    图 17:图 6 中用实例代替类的例子

    图 17:图 6 中用实例代替类的例子

     

    图 17 有Flight类的二个实例,因为类图指出了在Plane类和Flight类之间的关系是 0或多 。因此,我们的例子给出了两个与NX0337 Plane实例相关的Flight实例。

    角色
    建模类的实例有时比期望的更为详细。有时,你可能仅仅想要在一个较多的一般层次做类关系的模型。在这种情况下,你应该使用 角色 记号。角色记号类似于实例记号。为了建立类的角色模型,你画一个方格,并在内部放置类的角色名及类名,作为实体记号,但是在这情况你不能加下划线。图 18 显示一个由图 14 中图描述的雇员类扮演的角色实例。在图 18 中,我们可以认为,即使雇员类与它本身相关,关系确实是关于雇员之间扮演经理及团队成员的角色。

    图 18:一个类图显示图14中扮演不同角色的类

    图 18:一个类图显示图14中扮演不同角色的类

    注意,你不能在纯粹类图中做类角色的建模,即使图 18显示你可以这么做。为了使用角色记号,你将会需要使用下面讨论的内部结构记号。

    内部的结构
    UML 2 结构图的更有用的功能之一是新的内部结构记号。它允许你显示一个类或另外的一个分类器如何在内部构成。这在 UML 1. x 中是不可能的,因为记号限制你只能显示一个类所拥有的聚合关系。现在,在 UML 2 中,内部的结构记号让你更清楚地显示类的各个部分如何保持关系。

    让我们看一个实例。在图 18 中我们有一个类图以表现一个Plane类如何由四个引擎和两个控制软件对象组成。从这个图中省略的东西是显示关于飞机部件如何被装配的一些信息。从图 18 的图,你无法说明,是每个控制软件对象控制两个引擎,还是一个控制软件对象控制三个引擎,而另一个控制一个引擎。

    图 19: 只显示对象之间关系的类图

    图 19: 只显示对象之间关系的类图

     

    绘制类的内在结构将会改善这种状态。开始时,你通过用二个区域画一个方格。最顶端的区域包含类名字,而较低的区域包含类的内部结构,显示在它们父类中承担不同角色的部分类,角色中的每个部分类也关系到其它类。图 19 显示了Plane类的内部结构;注意内部结构如何澄清混乱性。

    图 20:Plane类的内部结构例子。

    图 20:Plane类的内部结构例子。

     

    在图 20 中Plane有两个 ControlSoftware 对象,而且每个控制二个引擎。在图左边上的 ControlSoftware(control1)控制引擎 1 和 2 。在图右边的 ControlSoftware(control2)控制引擎 3 和 4 。

    结论
    至少存在两个了解类图的重要理由。第一个是它显示系统分类器的静态结构;第二个理由是图为UML描述的其他结构图提供了基本记号。开发者将会认为类图是为 他们特别建立的;但是其他的团队成员将发现它们也是有用的。业务分析师可以用类图,为系统的业务远景建模。正如我们将会在本系列关于 UML 基础的文章中见到的,其他的图 -- 包括活动图,序列图和状态图——参考类图中的类建模和文档化。

    关于“UML 基础”的本系列的后面的元件图。

    脚注
    1 delayFlight没有返回值,因为我作出了设计决定,不要返回值。有一点可以争论的是,延迟操作应该返回新的到达时间,而且,如果是这种情形,操作属性将显示为 delayFlight(numberOfMinutes : Minutes) : Date。

    2 可能看起来很奇怪, BankAccount 类不知道 OverdrawnAccountsReport 类。这个建模使报表类可以知道它们报告的业务类,但是业务类不知道它们正在被报告。这解开两个对象的耦合,并因此使系统变得更能适应变化。

    3 软件包对于组织你的模型类是庞大的,但是记住重要的一点是,你的类图应该是关于建模系统的容易交流的信息。在你的软件包有许多类的情况下,最好使用多个主题类图,而不是仅仅产生一个大的类图。

    4 要理解重要一点,当我说“所有的那些成员”时,我仅仅意味着在当前图中的类将显示出来。显示一个有内容的软件包的图,不需要显示它的所有内容。它可以依照一些准则,显示包含元素的子集,这个准则就是并非所有的软件包分类器都是必需的。

    5 当画一个类图时,在 UML 规范中,全部要做的只是把类放入长方形的顶部区域,而你同理处理接口;然而,UML 规范认为,在这个区域放置“class”文本是可选的,如果类没有显示,那么它应该被假设。

    参考资料

    • 您可以参阅本文在 developerWorks 全球站点上的 英文原文

     

    关于作者
    Author photo Donald Bell是IBM全球服务的一个IT专家,在那儿他和IBM的客户一起致力于设计和开发基于软件解决方案的J2EE。

    展开全文
  • 软件工程概论:一堂快乐听讲(玩游戏)、快乐(熬夜)画图、开心查实验的课 快考试了 记录一下快乐学习2小时速成大法之UML类图与类的关系 虚线箭头指向依赖; 实线箭头指向关联; 虚线三角指向接口; 实线三角指向...
  • 软件工程---类图画法

    2019-12-24 20:36:19
    类图画法 类 简要画法 类有三个单元格的矩形(看上图中的动物类) 第一格:类名称(如果是抽象类,名称标注为斜体字) 第二格:类属性名称 第三格:类操作名称 类属性或者操作的访问修改符的标注: public用...
  • Unified Modeling Language (UML)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,...
  • 在UML的类图中,类图之间的关系分为4中:关联(Association)、依赖(Dependency)、泛化(Generalization)和实现(Realization)。 一、关联(Association) 关联关系是一种“拥有”关系,它使一种类“知道”另...
  • 第三章:类图 概念 类图的概念:类图是描述类、接口以及它们之间关系的图,它显示了系统中各个类的静态结构,是一种静态模型。 分类可以有效地使复杂问题简化。建立类模型的过程,是把现实世界中与问题有关的各种...
  • UML类图与类关系 关联关系:一个类知道另一个类的实现方法(实线箭头表示) 泛化:继承(子类指向父类) 实现:类与接口,类指向接口(虚线,实现类指向接口) 依赖:一个类调用被依赖类的某些方法得以完成自己...
  • 1. 一下截图是基于一个 教务管理系统的,本人仅为存此 作为笔记,若是有幸能够帮到您,万分荣幸。
  • 阅读说明:本节主要是介绍UML类图事物和解释,主要也是让大家对UML建模中的类图基本表示有一个初步了解和认识,后面还会陆陆续续的更新更多详细的UML开发应用学习文章,直接对接我们当下的开发。  注意事项:UML...
  • 一:UML类图思维导图 思维导图地址:http://naotu.baidu.com/file/df1cb03489378d2a541d3d8d181399da?token=2eb1feb8006fa607 密码:33bZ二:详细分析和介绍下面就从上面的思维导图开始,详细的介绍UML类图! ...
  • 软件工程类图Classes are used to represent the object-oriented models. As we know that in the OOPs structure, every entity is treated as an object. A class thus can be defined as a collection of ...
  • 阅读说明:本节主要是介绍UML类图关系与解释,主要也是让大家对UML建模中的类图基本关系有一个初步了解和认识,后面还会陆陆续续的更新更多详细的UML开发应用学习文章,直接对接我们当下的开发。 注意事项:UML...
  • 软件工程uml图 用例图

    2020-07-27 23:33:26
    uml 软件工程 用例图、时序图、类图
  • 一:UML类图思维导图 二:详细分析和介绍 下面就从上面的思维导图开始,详细的介绍UML类图! 1、 什么是UML,概念是什么? UML(Unified Modeling Language)中文统一建模语言,是一种开放的方法,用于说明、...
1 2 3 4 5 ... 20
收藏数 15,438
精华内容 6,175
关键字:

类图 软件工程