1.需求建模_基于类

基于类建模表示了系统操作的对象、应用于对象间能有效控制的操作（也称方法或服务）、这些对象间的关系以及定义类之间的协作

基于类的分析模型的元素主要有：类和对象、属性、操作、CRC模型、协作图和包

1.1基于类建模的基本思路

  1. 识别分析类（分析出有哪些类）
  2. 描述属性（对应编代码定义类属性）
  3. 定义操作（对应编代码定义方法）、
  4. CRC建模（解决类的功能是什么，协作关系如何）
  5. 关联与依赖（解决类之间有什么关系）

1.2识别分析类

通过检查需求模型开发的使用场景，或通过对为系统开发的用例或处理叙述进行“语法分析”，可以开始类的识别。
具体做法：

  • 首先用下划线画出每个名词或名词词组
  • 将这些名词输入到一个列表中，同时标注出同义词。
  • 筛选甄别，把描述问题的名词和解决方案的名词分开。

1.3分析类的表现形式

在所有名词的基础上，找以下对应形式：

  • 外部实体（例如，其他系统、设备、人员），产生或使用基于计算机的系统的信息。
  • 事物（例如，报告、显示、字母、信号），问题信息域的一部分。
    偶发事件或事件（例如，所有权转移或机器人的一组移动完成），在系统操作环境内发生。
  • 角色（例如，经理、工程师、销售人员），由和系统交互的人员扮演。
  • 组织单元（例如，部门、组、团队），和某个应用相关。
  • 场地（例如，制造车间或码头），建立问题的环境和系统的整体功能。
  • 结构（例如，传感器、四轮交通工具、计算机），定义了对象的类或与对象相关的类。

1.4识别与确定分析类

三种分析类
  • 边界类<>
    • 用户界面
    • 系统接口
    • 硬件接口
  • 控制类<< control>>
    • 封装用例所特有的控制行为
  • 实体类<>
    • 系统存储的信息及其相关行为

1.5定义操作

  • 操作定义了某个对象的行为。
  • 通常可以粗略地划分为四种类型：
    • 以某种方式操作数据；
    • 执行计算的操作；
    • 请求某个对象的状态的操作；
    • 监视某个对象发生某个控制事件的操作。
  • 操作必须“理解”类的属性和相关属性的性质。

2.CRC建模

  • 类-职责-协作者建模(Class-Responsibility-Collaborator，CRC)
  • 是一个简单方法，可以识别和组织与系统或产品需求相关的类。
  • CRC模型是表示类的标准索引卡片的集合。
  • 这些卡片被分为三部分，顶部写类名，下面左侧部分列出类的职责，右侧部分列出类的协作关系。
    • 职责是和类相关的属性和操作，即“类所知道或能做的任何事”。
    • 协作者是那些提供完成某个职责所需要信息的类。通常，协作意味着信息请求或动作请求。

2.1职责。

在给类分配职责有以下五个指导原则：
  • 系统智能应分布在所有类中以求最佳地解决问题的需求。（分的均衡，不易过度集中，降低局部复杂度）
  • 每个职责的说明应尽可能具有普遍性。（保持上层的通用性，抽象性，便于继承）
  • 信息和与之相关的行为应在同一个类中。 （封装和内聚）
  • 某个东西的信息应局限于一个类中而不要分布在多个类中。（数据封装，好维护）
  • 必要时，职责应由相关类共享。（父类中的被所有子类共享）

2.2协作。

类有两种方法实现其职责：
  1. 类可以使用其自身的操作控制各自的属性，实现特定的职责；（自己做）
  2. 类可以和其他类协作。（让别的做）
  • 以客户职责的角度，协作是从客户到服务器的请求。
  • 一般某个对象和其他对象协作以实现某个职责，就需要向其他对象发送消息。
  • 单独的协作是单向流，表示从客户到服务器的请求。
  • 从客户的角度看，每个协作都和服务器的某个职责实现相关。
  • 识别协作，可以通过确认类本身是否能够实现每个职责。如果不能，那么需要和其他类交互，就存在协作。
  • 当一组类相互协作以实现某个需求时，这些类可以组织为子系统。
  • 为识别协作者，分析师可以检查类之间三种不同的通用联系：

1)is-part-of(是……一部分)联系；
2)has-knowledge-of(有……的知识)联系；
3)depends-upon(依赖……)联系。

2.3CRC模型的评审

  • 当一个完整的CRC模型被开发出来时，客户代表和软件工程组织的代表可以使用如下方法评审模型：
    • 所有参加CRC模型评审的人员拿到一部分CRC模型索引卡，卡片按照协作分开（即每个评审员不得有两张存在协作关系的卡片）。
    • 所有的用例场景将被分类管理。
    • 评审组长细致地阅读用例。当评审组长看到一个已命名的类时，给拥有相应类索引卡的人员一个令牌。
    • 当令牌传递时，类卡的拥有者需要说明卡上所记录的职责。评审组确定职责是否满足用例需求。
    • 如果记录在索引卡上的职责和协作不能满足用例，就需要修改卡片。修改可能包括定义新类，或在已有的卡上说明新的或修改的职责、协作。
  • 持续进行该过程直到用例编写结束。当评审完所有的用例，将继续分析建模。

3.1关联与依赖

  • 关联(associations)
  • 两个分析类以某种方式相互关联，如两个数据对象相互关联。在UML中，这些联系被称作关联。
  • 关联具有多样性，
    • “一或多个”用1..*表示
    • “0个或多个”用0..*表示

3.2UML中类之间的关系表示

  • 依赖：A类的变化引起了B类的变化，则B依赖于A
  • 泛化：父类是子类的泛化（概括，更高层抽象）
  • 关联：有联系就是关联，还可以分很多种。
  • 聚合：整体和部分的关系，整体与部分可分开
  • 组合：整体和部分的关系，整体与部分不 可分开
  • 实现：类和接口之间的关系