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：
图9-53 添加“系统实例”
很多情况下，“系统实例”对象的属性值不需要赋值，有“系统”对象的属性值已经足够。
提供对象图如图9-54以帮助理解：
图9-54 对象图
从图9-54还可以看出，组织的职位相当于“系统类型”为“人脑系统”的“系统”，职位背后的人实际上是被忽略的，如果需要记录具体人的信息，可以在“系统实例”的“名称”中记录，如图9-54左上角的“张三”。
“程序员张三”实际上说的是某个“程序员”职位由某个人担任，这个人的姓名叫“张三”，但我们在这里把人的姓名（其他内容也可以）写在“系统实例”的“名称”属性中。
图9-54还有一个“系统实例”的“名称”也叫“张三”，它链接到的“系统”的名称是“产品经理”，这个“产品经理张三”和上一个“程序员张三”是不是同一个人，“发糕”就不关心了。
9.2.2.4 组织-组织、组织-系统、系统-系统
（待续……）
389
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
