DDD领域驱动设计批评文集>>
《软件方法》强化自测题集>>
《软件方法》各章合集>>
9.2.2 分析类图
在“答题抽奖”案例，我们针对优先级最高的用例“学员→回答问题”的用例规约，逐个词句提炼类、属性、关系，逐步精化。
如果建模人员的大脑中没有大局上的核心域概念及关系的轮廓，也没有现成的成熟模型可以借鉴，像“答题抽奖”这样逐个用例来探索和拼凑是可以接受的。
如果建模人员对核心域的概念及关系在大局上有相当清晰的认识，可以先抛开目标系统的某个具体用例，从大局上对目标系统需要涉及的核心域概念建模，然后再参照用例规约，增减得到目标系统的分析模型。这一点，在8.2.3.1 从需求规约之外的其他素材提炼以及图8-48中，已经阐述过。
“发糕智能建模工具”所封装的核心域知识总量近似于《软件方法》中讲述的建模方法学知识，而且建模人员（作者自己）对《软件方法》中所讲述的方法学非常熟悉，我们就不再逐个用例探索和拼凑，而是按照《软件方法》中的内容，逐个子域展示出软件开发方法学的画卷。
在以下的建模过程中，提到某些知识不属于当前关注范围之内时，我们使用“发糕智能建模工具”（简称“发糕”）作为主语，而不是《软件方法》，例如：
“发糕”当前不需要关心不同类型组织的行为有什么差别。
而不是说：
《软件方法》当前不需要关心不同类型组织的行为有什么差别。
我把软件开发目前涉及的知识、《软件方法》目前涉及的知识和“发糕”打算封装的核心域知识画成图9-35：
图9-35 三个知识范围
软件开发的场景花样多多，不好说“《软件方法》不需要关心***”，但换成“发糕”作主语是可以的，毕竟还有人——使用“发糕”来建模的人类执行者可以弥补。
9.2.2.1 组织
组织的分类
世界上有很多组织，这些组织有的是正式的，有的是非正式的。
正式的组织可以分为企业、党政军单位、事业单位、社会团体、民办非企业单位等类型，这些类型下面还可以分为更细的类型。
非正式组织可以有家庭、家族、团队等类型，正式组织中的部门、团队也可以看作非正式组织。
这样的组织分类可以用泛化关系来表达，如图9-36：
图9-36 泛化关系表达组织分类
图9-36还可以继续向下分出子类，最终得到很多层的泛化结构。
“发糕”当前不需要关心不同类型组织的行为有什么差别，因此图9-36可以转为类类型的递归关联（知识点参见第8章），如图9-37：
图9-37 泛化转为关联
“发糕”当前也不需要关心各种类型的组织对应的类型特征不同，例如，“企业”有“信用代码”，“家庭”没有，“高校”有“办学层次”，“企业”没有，所以也不需要“组织类型特征”、“组织特征”等类。
去掉图9-37下半部，得到图9-38：
图9-38 关联的简化
组织的结构
组织还可以分为更小的内部组织。例如，公司内部可以有分公司，分公司内部分为部门，部门还可以再分为小部门。
像图9-39这样生硬地表达组织结构肯定是不行的：
图9-39 生硬地表达组织结构
如果再加一级中间组织，或者升级为矩阵式管理，图9-39就要修改；另外，图9-39只是公司的结构，政府机关、学校等组织的结构又有差别。
如果用图9-38的类来表达，“公司”、“分公司”、“部门”等都被看作“组织类型”的一个实例。图9-39的组织结构可以通过组织之间的自反关联表达，如图9-40：
图9-40 组织结构表达为组织的自反关联
如果要表达更复杂的管理方式，组织的自反关联可能会有多个，如图9-41：
图9-41 多种上下级关系
如果有更多的上下级关系，“组织”周围就会围上许多自反关联，可以把上下级关系进一步抽象，如图9-42：
图9-42 进一步抽象上下级关系
“发糕”需要描述目标组织内部的结构。用“发糕”来建模的目标系统是多种多样的，系统的目标组织也是多种多样的，因此，确实需要图9-42的灵活结构。
图9-42没有规定组织上下级关系的规则，也就是说，通过它无法判断“人力资源部”内部有一个“信息技术学院”是否合理。这些交给使用“发糕”的人类执行者操心，“发糕”不负责封装这方面的逻辑。
参考资料
关于组织的结构和行为，一些企业架构（Enterprise Architecture）框架提供了元模型。例如近几年名气比较响的TOGAF（The Open Group Architecture Framework），给出的元模型如图9-43：
图9-43 摘自 “TOGAF® Standard — Architecture Content”2022版本
不过，这样的元模型涉及的概念太广，而在局部的概念上又不够精细和严谨，仅能作为粗略的参考。
（*注：“Enterprise”译为“企业”并不准确，其含义应该类似于上文说的“组织”，因此“Enterprise Architecture”说的不只是“企业”的架构，也包括“非企业”组织的架构。）
David C. Hay的“Data Model Patterns: Conventions of Thought”（1996）和Martin Fowler的“Analysis Patterns: Reusable Object Models”（1996）给出了更精细的组织结构模型。
图9-44 摘自“Data Model Patterns: Conventions of Thought”, David C. Hay, 1996
图9-45 摘自“Analysis Patterns: Reusable Object Models”, Martin Fowler, 1997
图9-42参考了Fowler书中的模型。
9.2.2.2 系统
（待续……）
8月18-21晚网课：软件需求设计方法学全程实例剖析
8月11-14晚剔除“伪创新”的领域驱动设计-网络公开课
[新增EA027智慧公寓系统]25套UML EA和StarUML的建模示范视频-全程字幕（2022.7.25更新）
《软件方法》书中自测题-题目全文 分卷自测（1-8章）16套111题
《软件方法》强化自测题集110题
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
作者微信：umlchina2
