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 系统
(待续……)
[新增EA027智慧公寓系统]25套UML+EA和StarUML的建模示范视频-全程字幕(2022.7.25更新)
《软件方法》书中自测题-题目全文+分卷自测(1-8章)16套111题
CTO也糊涂的常用术语:功能模块、业务架构、用户需求……[20210217更新]
作者微信:umlchina2