系统和系统实例-软件方法（下）第9章分析类图案例篇Part07

DDD领域驱动设计批评文集>>

《软件方法》强化自测题集>>

《软件方法》各章合集>>

9.2.2.2 系统

广义上，从整个宇宙，到上一小节的组织，到原子，都可以叫做系统。

本书的系统特指封装了一定的逻辑计算能力的智能系统。非人的生命体（从大猩猩到病毒）和非智能机械（从老式的汽车到算盘）都不算是智能系统。

系统分为人脑系统和非人信息系统（以下简称“信息系统”），简单定义如下：

人脑系统：运行在人脑中的智能系统。

我们把人看作容器，人担任的角色或职位看作安装在人脑中的一个系统。例如，张三担任项目经理和产品经理两个职位，可以看作张三大脑中安装了“项目经理”和“产品经理”两个智能系统。

信息系统：运行在计算机中的智能系统。

按道理，和上面的“人脑系统”对应，应该叫“电脑系统”，但考虑再三，还是采用“信息系统”这个目前最流行的叫法。

同理，我们把计算机看作容器，上面可以安装各种信息系统。此处的计算机是广义的，包括冯诺依曼体系结构的超级计算机到嵌入式计算机，也包括非冯诺依曼体系结构的计算机，也包括将来可能出现的光子、量子计算机。

《软件方法（上）》提到，我们把“时间”想象成上帝制造的、运行在宇宙中的一个信息系统。它不停地向其他人脑系统或信息系统发送时间信号。从现代物理学的角度，这个想象肯定是有问题的，但对于本书的内容来说，这个想象够用了。

系统的分类可以用图9-46的泛化关系描述：

图9-46 泛化关系描述系统分类

我们还需要表达具体的人脑系统和信息系统。

以案例一“答题抽奖”为例，在9.1.3业务序列图中，给出了两张业务序列图。在业务序列图顶部，我们可以看到这样一些系统的实例：

图9-47 案例一“答题抽奖”业务序列图的顶部截图

如果沿着图9-46继续使用泛化关系，可能会得到图9-48：

图9-48 用泛化关系表达具体系统

不过，这样做是不合适的，最下层这些具体的系统并不属于《软件方法》领域中的概念，而是“答题抽奖”领域的概念，不宜作为“发糕”的分析类出现，因此，图9-49红色分隔线下面的类不宜保留，这些信息可以作为对象的属性值出现。

图9-49 红色分隔线下面的类不属于《软件方法》领域

可以如图9-50，具体系统的信息记录在“名称”属性中，如果不够可以再加个“备注”属性。

图9-50 具体系统的信息记录在“名称”属性中

也许在系统名称之前还要有分类，甚至是多层分类。例如，手机应用商店就对其中的信息系统（app）做了分类，如图9-51。

图9-51 信息系统分类示例，摘自小米应用商店

人脑系统也可以分类，例如，先分管理岗、技术岗、工勤岗，然后再细分。

如果要表达更详细的分类，可以和上一小节的“组织”一样，通过类类型的自反关联表达，如图9-52。

图9-52 自反关联表示系统类型

“发糕”确实需要区分人脑系统和信息系统，因为涉众利益、愿景等概念只和人脑系统有关。如果不是这样，“系统类型”或泛化结构都可以不需要。

但“发糕”当前并不打算关心多层次的系统类型，因此采用9-50左侧或9-52的类图均可。

考虑到“发糕”不关心人脑系统和信息系统之间太复杂的行为差异，优先使用关联，即9-52的类图，“系统类型”上的自反关联也暂时保留，后面确认不需要时再删除。

9.2.2.3 系统实例

系统可能会存在多个实例，“发糕”有时需要维护系统实例的信息。例如，图9-47所列的业务序列图顶部就是一个个系统实例。

“发糕”可能还要维护同一个系统的多个实例。例如，在某个软件开发组织的流程中，有多名程序员参与，程序员用的编码环境是Visual Studio Code，如果画出序列图，就会出现多个“名称”为“程序员”的“系统”（人脑系统）的实例，多个“名称”为“Visual Studio Code”的“系统”（信息系统）的实例。

添加“系统实例”类，类图如图9-53：