类图

• 前言
• 1 类图的概念
• • 1、类图
  • 2、类图的作用
  • 3、类图的组成元素
• 2 UML中的类
• • （１）类的定义
  • （２）类的表示
  • （３）类的命名
  • （４）类的属性
  • （５）类的操作
  • （６）类的职责
  • （７）类的约束
• 3 类图中的关系
• • 关联（association）
  • • （1）关联名
    • （2）角色
    • （3）多重性
    • （4）导航性
  • 包含
  • • 聚合
    • 组合
  • 泛化
  • 实现
  • 依赖
  • • 关于依赖
  • 例
  • • 神州飞船
    • 运算类
    • 简易画图软件
    • 小李打妖怪
    • 老张开车去东北
• 4 阅读类图
• • • 电子商务网站的静态模型
  • 读图过程
  • • 增强的辅助建模元素
• 5 如何建立类图
• • 1、类图的抽象层次
  • 2、建立类图的步骤
  • 3、寻找类的方法
  • • *使用名词/动词寻找类：*
    • *使用CRC分析法寻找类：*
    • *根据边界类、控制类、实体类帮助分析系统中的类：*
  • 例
  • • 需求描述
    • 发现类
    • 筛选备选类
    • 得到候选类
    • 职责分析
    • 限定与修改
• 补充
• • 递归关系
  • 三角关系
  • 识别关联类
  • 关于画类图

前言

       copy自老师的PPT，不只有知识点，还有一些相关内容的介绍顺便复制进来了。 如有问题请多指教

1 类图的概念

1、类图

类图是描述类、协作(类或对象间的协作)、接口及其关系的图。
类图是逻辑视图的重要组成部分，用于对系统的静态结构建模，涉及到具体的实现细节。

• 在系统分析阶段，类图主要用于显示角色和提供系统行为的实体的职责；
• 在系统设计阶段，类图主要用于捕捉组成系统体系结构的类结构；
• 在系统编码阶段，根据类图中的类及它们之间的关系实现系统的功能。

2、类图的作用

类图常用来描述业务或软件系统的组成、结构和关系。

3、类图的组成元素

• 类
• 接口
• 协作
• 关系
• 注释
• 约束
• 包

2 UML中的类

类的表示

（１）类的定义

类是具有相似结构、行为和关系的一组对象的抽象。

（２）类的表示

（７）类的约束

约束指定了类所要满足的一个或多个规则。 在UML中，约束是用花括号括起来的自由文本。

（2）角色

• 关联两端的类可以某种角色参与关联；
• 通常使用名词或名词短语；
  
  

  （4）导航性

  • 用箭头显示导航性；
  • 描述源对象通过链接访问目标对象；
  • A类有一个成员变量保存的是B类的一个引用，也就是说由A类可以找到B类，可以画成下图所示
    
    你可能觉得这样表示还不太合适，汽车应该包含4个轮子，或者说轮子本来就属于汽车的一部分，那怎样画能更加贴切表示这样的关系呢们可以这样画：
    

  组合

  • 是一种特殊形式的聚合（强聚合），聚合中的每个部分只能属于一个整体；
  • 表示类之间整体和部分的关系。
  • 整体与部分具有相同的生存期。
    
    • “弱”包含表示如果部门没有了，员工也可以继续存在；
      “强”包含表示如果部门没有了，员工也不再存在。
    • 在做软件需求时，往往会将所有的包含关系画成“弱”包含，后面发现某些关系可以表示为“强”包含时，才转为实心菱形。
      

    实现

    • 表达一种说明元素与实现元素之间的关系；
    • 类和接口之间的关系是实现关系，表示类实现接口提供的操作
    • 显示一个类引用另一个类
      
    • 如果一个烟鬼嗜烟如命，用类图可以这样表示：
      

    关于依赖

    假设你正在设计一个能显示公司全体成员的制表系统，公司的员工可以填写这个系统中的电子表格。员工要选择菜单来填写表格。在你的设计中，有一个Syetem（系统）类和一个Form（表格）类。System类的众多操作中有一个displayForm（f:Form），系统所要显示的表格取决于用户选择的表格。
    这种设计的UML表示法可以画成如下
    

    

  运算类

  
  
  

  4 阅读类图

  阅读顺序应遵循的原则

  • 先看清有哪些类；
  • 然后看看类之间存在的关系；
  • 结合多重性来理解类图的结构特点以及各个属性和方法的含义
    

    读图过程

    • 读出类：
    • 读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是Order类。
      1. OrderItem和Order之间是组合关系，根据箭头的方向可知Order包含了OrderItem。
      2. Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。

    多重性：用来说明关联的两个类之间的数量关系
    

    

  增强的辅助建模元素

  • 导航箭头：类的实例之间只能沿着导航箭头的方向传递 ，在Order中可以获取其相应的Consignee，而从Consignee中是无法了解与其相关的Order的
  • 角色名称：Customer端有一个“+Owner”字符串 ，这表示Customer扮演的角色是Owner，也能对关联进行命名
    

  2、建立类图的步骤

  1. 分析问题域，确定需求；
  2. 寻找类，确定类的含义和职责；
  3. 定义类的属性和操作；
  4. 确定类之间的关系；
  5. 精化类和类间的关系；
  6. 绘制类图。

  3、寻找类的方法

  使用名词/动词寻找类：

  1. 收集相关信息
  • 补充的需求规格说明
  • 用例
  • 项目说明文档
  • 其他文档
  2. 分析信息
  • 名词、名词短语       类或属性
  • 动词、动词短语       操作

  使用CRC分析法寻找类：

  C-class（类）
  R-responsibility（职责）
  C-collaboration（协作）
  CRC分析法是根据类所要扮演的职责来确定类。

  根据边界类、控制类、实体类帮助分析系统中的类：

  UML中类有三种主要的版型：边界类、控制类和实体类。

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

  例

  需求描述

  李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。

  发现类

  李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。

  筛选备选类

  • “李小平”、“人”、“家里”很明显是系统外的概念，无须对其建模；
  • 而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；
  • 很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。
  • “基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模；
  • “功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；
  • “计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；
  • “外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；
  • “购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类—书籍列表，也就是执行统计的主体。

  得到候选类

  在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需太过咬文嚼字 。

  

  限定与修改

  • 导航性分析：Book与BookList之间、BorrowRecord和BorrowList之间是组合关系均无需添加方向描述，而Book与BorrowRecord之间则是双方关联，也无需添加。
  • 约束：Book对象创建后就不能够被删除只能被修改，因此在Book类边上加上用自由文本写的约束 ；一本书要么属于计算机类，要么属于非计算机类，因此在ItBook和OtherBook间加了 “{Xor}”约束。
  • 限定符：一本书只有一册，因此只能够被借一次，因此对于一本Book而言只能有一个RecordId与其对应。
  
  接着又会被问到：
  • 文件夹里也可以有文件夹呀，这个怎样表示/li>
  • 里面的文件夹里面也可能有文件夹，咋办br>
    在表示公司与雇员的关系的直线上，拉出一条虚线，虚线另一端连接劳动合同类，这样的类叫做关联类，关联类是对两个类的关系的进一步约束。
    最开始你可能会认为薪金、职位、合同期似乎应该是雇员的属性，但现在应该认识到，这三个关键内容应该体现在公司和雇员的关系上，这些内容应该体现在劳动合同上。
    公司、雇员、劳动合同的关系，还可以画成这样
    

    关于画类图

    • 直线、几对几的关系、角色、箭头可以搭配使用，只要能准确反映出业务关系就可以了。
    • 做软件需求分析时，如果觉得两个业务概念之间有联系，但暂时不能确定具体是怎样的，那么就先画一条线将两者连起来再说，随着你对业务的理解，这条线会进一步具体化，你可以为这条线添加更多的元素。

    来源：来一粒4869

    声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！