系统和系统实例-软件方法（下）第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：
图9-53 添加“系统实例”
很多情况下，“系统实例”对象的属性值不需要赋值，有“系统”对象的属性值已经足够。
提供对象图如图9-54以帮助理解：
图9-54 对象图
从图9-54还可以看出，组织的职位相当于“系统类型”为“人脑系统”的“系统”，职位背后的人实际上是被忽略的，如果需要记录具体人的信息，可以在“系统实例”的“名称”中记录，如图9-54左上角的“张三”。
“程序员张三”实际上说的是某个“程序员”职位由某个人担任，这个人的姓名叫“张三”，但我们在这里把人的姓名（其他内容也可以）写在“系统实例”的“名称”属性中。
图9-54还有一个“系统实例”的“名称”也叫“张三”，它链接到的“系统”的名称是“产品经理”，这个“产品经理张三”和上一个“程序员张三”是不是同一个人，“发糕”就不关心了。
9.2.2.4 组织-组织、组织-系统、系统-系统
（待续……）
系统和系统实例-软件方法（下）第9章分析类图案例篇Part07相关推荐
- 软件方法（下）分析和设计第9章分析 之 分析类图——案例篇（20211228更新）
软件方法(下)分析和设计第8章分析 之 分析类图--知识篇(20211227更新) 鸳鸯扣,宜结不宜解 <身似摇红烛影>,词:唐涤生,曲:王粤生,唱:红线女,1954 可到此处下载本文档最 ...
- 软件方法（下）分析和设计第8章连载[20210816更新]分析 之 分析类图——知识篇
墙上挂了根长藤,长藤上面挂铜铃 <长藤挂铜铃>:词:元庸,曲:梅翁(姚敏),唱:逸敏,1959 您在阅读<软件方法>时如果发现错误,欢迎通过微信umlchina2告知.如果作者 ...
- 软件方法（下）分析和设计第8章分析 之 分析类图——知识篇Part01（202204更新）
*为避免单篇文章篇幅过长,分成多篇以合集发布* _墙上挂了根长藤,长藤上面挂铜铃 _ <长藤挂铜铃>:词:元庸,曲:梅翁(姚敏),唱:逸敏,1959 可到此处下载<软件方法>( ...
- 软件方法（下）分析和设计第8章分析 之 分析类图——知识篇Part02（202204更新）
DDD领域驱动设计批评-文集-点击查看>> <软件方法>强化自测题集-点击查看>>**** 8.1.8 伪创新 有的人(国内国外都有)没有掌握相应技能,也不愿意认真 ...
- 软件方法（下）第8章分析之分析类图—知识篇Part09-审查类和属性1
可到此处下载<软件方法>(下)目前公开的最新pdf版本: http://www.umlchina.com/book/softmeth2.pdf 8.2.5 审查类和属性 8.2.5.1 属 ...
- 《软件方法》第8章 分析 之 分析类图（2）
8.1.6 识别分析类和属性的要点 8.1.6.1 关于中英文命名 该用中文就用中文,该用英文就用英文,该用日文就用日文.中英文命名问题和设计工作流(编码.设计数据库--)中碰到的问题是类似的.分析类 ...
- 《软件方法》第8章 分析 之 分析类图（1）
墙上挂了根长藤,长藤上面挂铜铃 <长藤挂铜铃>:词:元庸,曲:梅翁(姚敏),唱:逸敏,1959 8.1 步骤3-1 识别类和属性 在业务建模和需求工作流,我们的思考焦点一直在待开发系统 ...
- 《软件方法》第8章 分析 之 分析类图（3）
8.2.3 识别关联关系 8.2.3.1 关联的三种形式 UML规定了关联的三种形式:普通关联.聚合(Aggregation)和组合(Composition). 说到这里,我们有必要归纳类的关系如图8 ...
- 《软件方法》第三章 自测题
UMLChina软件方法各章练习题自测(三) 关于UMLChina 前言 <软件方法>第三章自测题 自测题1 自测题2 关于UMLChina 前言 笔者为在校大三生,初次接触UML建模语言 ...
最新文章
- phpstudy一个域名配置两个网站（一个是thinkphp5，一个是原生php）
- C#的基础琐碎总结-----委托
- Web应用开发技术-CSS
- Java学习之路(一)：日常第一课，认识JAVA
- 《剑指offer》-- 第一个只出现一次的字符、数组中只出现一次的数字、字符流中第一个不重复的字符、数组中重复的数字
- 服务器 远程存储,数据储存——远程服务器存储——框架方式
- python利用jieba(textRank、TFIDF)提取关键字
- elasticsearch体验（一.初识elasticsearch）
- LU分解的矩阵逆运算
- css3中的background的新特性background-origin,background-clip,background-size详解
- Atitit 项目常用模块 非业务模块 通用技术模块 attilax大总结 理论上可行。但要限制接口方式。 不然现在很多ui与后端接口模式很多，导致组合爆炸。。。 常用模块也就100来个而已。。
- 艾默生Ovation DCS OPC服务分析
- g41 计算机主板维修,解决方法：G41主板BIOS设置方法
- Mate30安装谷歌全家桶（20200215，成功）
- Crazy Kids
- 传递给Appium服务器以开启相应安卓Automation会话的Capabilities的几点说明
- iOS关于图片点到像素转换之杂谈
- 中国最美丽的地方排行榜国家地理
- OPENGL颜色混合
- 网络通信面试题详细解答