面向对象：用UML类图重塑产品需求分析的方法

最近在读一本书，叫《“图解”产品：产品经理业务设计与UML建模》，其中提到用类和对象来梳理需求，我之前在学习python的时候也学过面向对象。

类的定义：类是对一类具有共同属性和行为的事务的抽象。

对象的定义：对象是类的实例。

这个怎么理解呢？比如我有一个动物类animal，那么动物就有属性，比如动物类型、所属科属、体重、身高等，这就是共同属性。行为呢，就类似进食、散步。那么animal就是类，那什么是对象呢？比如一条狗大黄就可以算作是一个对象，因为大黄可以是动物类的实例。

当然这个例子只是用来简述类跟实例，如果要在需求分析中要使用类图，我们可以用更详细的例子来分析。比如我们现在要设计一个图书馆管理系统，那么图书馆管理系统应该具有以下的产品结构：

• 用户端：
  • 注册/登录；
  • 借书；
  • 预约；
  • 还书；
  • 查看个人信息；
  • 修改密码；
• 图书管理员端：
  • 添加图书；
  • 编辑图书信息；
  • 删除图书；
  • 查看图书借阅历史；
  • 发布公告；
  • 处理预约；

以上是图书馆管理系统大致的结构，我们这里只是用来进行用面向对象的方法进行需求分析，在这个系统中应该存在几个类？

首先用户肯定有很多，图书管理员应该也有很多，如果这两部分系统参与者都要通过系统来分配账号的话，那么首先应该有人员类，人员具有基础属性，比如姓名、地址、电话号码。

那在人员类的基础上就可以区分出图书管理员类与用户类，图书管理员可以执行上述结构中的一系列操作，这个在代码中也通常称之为方法。

图书管理员对应的还应该有图书类，比如图书的一系列属性以及查看详细信息的方法。

用户还能对系统进行预约，反之也可以取消预约。

把上述描述整理成类图就如下图所示：

通过这个类图，对于产品经理来说，就已经能够很清晰的梳理出大致的需求，以及了解这个系统的全貌了。对应的我们可以给出一份基于python提供的伪代码：

class 图书:
    pass

class 用户:
    pass

class 预约:
    pass

class 图书管理员:
    def __init__(self, 管理员ID: int, 密码: str):
        self.__管理员ID = 管理员ID
        self.__密码 = 密码

    def 添加图书(self, 图书: 图书) -> None:
        # 示例方法
        pass

    def 编辑图书信息(self, 图书: 图书) -> None:
        # 示例方法
        pass

    def 删除图书(self, 图书ID: int) -> None:
        # 示例方法
        pass

    def 查看图书借阅历史(self, 图书: 图书) -> List[用户]:
        # 示例方法
        return []

    def 处理预约(self, 预约: 预约) -> None:
        # 示例方法
        pass

    def 发布公告(self, 内容: str) -> None:
        # 示例方法
        pass

# 实例化
管理员1 = 图书管理员(1, "admin123")
管理员2 = 图书管理员(2, "admin123")
管理员1.添加图书(图书())

在上文中的类图我是使用plantuml绘制的，我一直比较推崇产品经理用uml语言来绘图，而不是各种图形化的工具，因为用图形化的工具绘图效率很低，而且修改不方便，下面补充一些plantuml中类图的知识。

@startuml

class 示例类 {

    - 私有属性: String
    + 公开方法(): void
    # 受保护方法(): void
    ~ 包内方法(): void

}

@enduml

类基本是由属性跟方法构成的，大部分绘图都只会用到私有熟悉跟公开方法，至于受保护方法跟包内方法（也成私有函数）一般不会太用到，这个研发在写代码的时候更应该考虑。

在UML类图中，有以下关系：

1. 关联(Association)：这是最常见的一种关系，表示一个类知道另一个类的信息。关联关系常常有方向性，并且可能有一个“角色名”和“多重性”。在上面的示例中：

   • 用户 "1" -- "*" 图书 : 借阅/预约 表示一个用户可以借阅或预约多本图书，同时一本图书可以被多个用户借阅或预约。
   • 用户 "1" -- "*" 预约 : 生成 表示一个用户可以生成多个预约。
   • 图书管理员 "1" -- "*" 图书 : 管理 表示一个图书管理员可以管理多本图书。

   在这些关联中，“1” 和 “*” 分别表示关联的多重性，意味着一个实例与另一边的多个实例之间的关联。

2. 聚合(Aggregation)：这是一种特殊的关联，表示“整体与部分”的关系，通常用一个空心的菱形表示。比如，学校与学生的关系，学校是整体，学生是部分。

3. 组合(Composition)：这是聚合的一种特殊形式，表示一种更强的“整体与部分”的关系。它表示部分不能脱离整体单独存在。使用一个实心的菱形表示。例如，车和车轮的关系，车轮不能脱离车单独存在。

4. 继承/泛化(Generalization)：这种关系表示一个类是另一个类的子集。用一个带箭头的直线表示，箭头指向超类或父类。例如，汽车是交通工具的一个特定类型，那么汽车与交通工具之间就是泛化关系。

5. 依赖(Dependency)：表示一个类的变化可能会影响到另一个类，但不一定有持久的关系。这通常是因为一个类使用了另一个类的方法。用带箭头的虚线表示。

下面是这个示例图：

写法如下：

@startuml

class 大学 {
}

class 教授 {
}

class 学生 {
}

class 本科生 {
}

class 研究生 {
}

class 课程 {
}

class 教材 {
}

大学 "1" -- "多" 教授 : 拥有
大学 o-- "多" 学生 : 聚合
课程 *-- "1" 教材 : 组合
学生 <|-- 本科生 : 泛化
学生 <|-- 研究生 : 泛化
课程 ..> 教授 : 依赖

@enduml

以上就是最近读到用类分析产品需求时候的一些个人收获，在我待过的企业中，从没见过产品经理用类图分析需求的，权当爱好了。但是类图的确可以帮助需求方在梳理需求时更好的把握整理需求逻辑，无论系统有多大，其代码实现最终都是通过抽象成多个类来完成。