一个例子说明UML及系统分析
UML系统需求分析建模实例(包括业务建模)
系统用例几乎总是以黑盒形式编 写的。它们描述了软件系统之外 的参与者如何与将被设计的系统 进行交互。系统用例详细阐明了 系统需求。系统用例模型的目的 是从涉众的角度说明需求，而不 是设计如何满足需求。
业务用例图中，可以让业务参与者【业 在系统用例图中，让参与者与用 务执行者】和业务角色【业务工人】与 例进行交互。 业务用例进行交互。
做专业的企业，做专业的事情，让自 己专业 起来。2 020年1 2月上 午12时3 5分20. 12.200: 35Dece mber 2, 2020
时间是人类发展的空间。2020年12月2 日星期 三12时 35分4 秒00:35: 042 December 2020
科学，你是国力的灵魂；同时又是社 会发展 的标志 。上午1 2时35 分4秒上 午12时 35分00 :35:042 0.12.2
原始需求愿景
1. 为员工提供账务的自动化办理，提高办 事效率，方便员工。
2. 方便财务部门管理好账务信息。
涉众分析
涉众
解释
期望
员工
公司的正式录用雇员 通过网上办理账务业务申 请，计算机控制流程
部门经理 部门负责人，负责审 方便审核操作，通过计算 核员工提交的申请 机代替原来的手工审核方 式。
公司主任 公司负责人，负责 2 方便审核操作，通过计算
次审核员工提交的申 机代替原来的手工审核方
请
式，界面友好易用。
财务主任 公司财务部门负责人，通过计算机转账的方式替 负责发放报账款项 代原来的人为付款方式。
业务用例获取（1）
定义：
" 业务用例从一个外部的，增加值的角度来描 述一个业务过程。为了给这个业务的涉众创造 价值，业务用例是超越组织边界的业务过程， 很可能包括合作伙伴和供应商。“
UML用例图实例解析
UML⽤例图实例解析⽤例图主要⽤来描述“⽤户、需求、系统功能单元”之间的关系。
它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。
【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。
⽤例图所包含的元素如下： 1. 参与者(Actor) 表⽰与您的应⽤程序或系统进⾏交互的⽤户、组织或外部系统。
⽤⼀个⼩⼈表⽰。
2. ⽤例(Use Case) ⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。
⽤椭圆表⽰。
3. ⼦系统(Subsystem) ⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。
4. 关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
【箭头指向】：指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象的。
【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。
【箭头指向】：指向分解出来的功能⽤例 d. 扩展(Extend) 扩展关系是指⽤例功能的延伸，相当于为基础⽤例提供⼀个附加功能。
【箭头指向】：指向基础⽤例 e. 依赖(Dependency) 以上4种关系，是UML定义的标准关系。
但VS2010的⽤例模型图中，添加了依赖关系，⽤带箭头的虚线表⽰，表⽰源⽤例依赖于⽬标⽤例。
【箭头指向】：指向被依赖项 5. 项⽬(Artifact) ⽤例图虽然是⽤来帮助⼈们形象地理解功能需求，但却没多少⼈能够通看懂它。
很多时候跟⽤户交流甚⾄⽤Excel都⽐⽤例图强，VS2010中引⼊了“项⽬”这样⼀个元素，以便让开发⼈员能够在⽤例图中链接⼀个普通⽂档。
仓库管理系统系统分析和设计UML
题目：仓库管理系统的分析与设计姓名：徐昊学号：12427002班级：软件121目录一、需求分析 (4)1.1系统总功能需求 (4)1.2 用户登录功能需求 (5)1.2.1用户登录功能的模块图： (5)1.2.2用户登录功能流程图： (6)1.3 仓库管理功能需求 (7)1.3.1仓库管理功能模块 (7)1.3.2仓库进货流程图 (9)1.3.3仓库退货流程图 (9)1.3.4仓库领料流程图 (9)1.3.5仓库退料流程图 (10)1.3.6仓库盘点流程图 (10)1.4 查询功能需求 (10)1.4.1查询功能模块 (11)1.4.2库存查询流程图 (12)1.4.3出入库查询流程图 (12)二、仓库管理系统系统的建模 (12)2.1 用例图的建立 (12)2.1.1操作员的用例图： (13)2.1.2管理员用例图： (13)2.1.3总用例图： (14)2.2 时序图的生成 (15)2.2.1仓库盘点时序图： (15)2.2.2仓库管理时序图： (16)2.2.4查询时序图： (17)2.3 活动图的生成 (18)2.3.1入库活动图： (18)2.3.2出库活动图： (19)2.3.3查询活动图： (20)三、类图的生成 (21)一、需求分析1.1系统总功能需求仓库管理系统可以分成三个功能模块，分别是用户登仓库管理、查询功能。
本系统主要实现对仓库物资的管理，包括商品的入库、出库，并可根据需要查询仓库使用记录。
1.2 用户登录功能需求1.2.1用户登录功能的模块图：由用户登录、用户注销、退出系统3个部分组成。
用户可以用两种身份登录本系统..普通操作员或经理，管理人员。
不同身份登录被系统授予不同的使用权限，这样提高了本系统的安全性，避免了无关人员获取不在他权限范围内的信息。
用户在登录后可以不退出本系统，而采用用户注销的方式使系统不存在激活状态下的用户。
（1）用户登录：用户根据用户名、密码登录进系统进行操作。
UML系统需求分析建模实例包括业务建模
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
uml图例讲解剖析
证，验证通过后，数据库注销相应存款，返回注销完成信息，
银行系统在存折上打印取款记录。 请根据以上信息绘制顺序图。
UML图例讲解
(6)在某一学生指纹考勤系统中，有一个用例名为“上课登记”。此用例允 许学生在上课前使用系统识别自己的指纹信息进而识别自己的身份，同时 系统可以将登录信息存储在数据库中。 “上课登记”用例的主要事件流如下： 学生从系统菜单中选择“上课登记”； 系统显示指纹识别界面； 学生将手指放置于界面上； 系统捕获并识别学生的指纹，向学生返回识别的身份信息； 学生选择“确认”按钮； 系统生成一个关于该登记学生及当前日期、时间的新记录，并将该记录 保存到数据库中。 请根据以上描述绘制“上课登记”用例的顺序图。
UML图例讲解
(2)某银行储蓄系统需求说明如下。 ①开户：客户可填写开立账户申请表，然后交由工作人员验证并输入系统。 系统会建立账户记录，并会提示客户设置密码(若客户没做设置，则会有一 个缺省密码)。如果开户成功，系统会打印一本存折给客户。 ②密码设置：在开户时客户即可设置密码。此后，客户在经过身份验证后， 还可修改密码。 ③存款：客户可填写存款单，然后交由工作人员验证并输入系统。系统将建 立存款记录，并在存折上打印该笔存款记录。 ④取款：客户可按存款记录逐笔取款，由客户填写取款单，然后交由工作人 员验证并输入系统。系统首先会验证客户身份，根据客户的账户、密码，对 客户身份进行验证。如果客户身份验证通过，则系统将根据存款记录累计利 息，然后注销该笔存款，并在存折上打印该笔存款的注销与利息累计。 请根据以上信息绘制出系统的用例图。
②用户选择其中一种汽水，系统处理后将该种汽水释放。
请绘制此交互过程的协作图。
UML图例讲解
(9)医院拟引入一款患者监护系统。基本要求是随时接收每个 病人的生理信号(脉搏、体温、血压、心电图等)，定时记录病
软件工程与uml案例解析
软件工程与uml案例解析咱们来唠唠软件工程和UML（统一建模语言）。
一、软件工程那点事儿。
软件工程就像是盖房子，你不能乱盖一气，得有个规划。
比如说，有个小团队要开发一个电商APP。
首先得搞清楚需求，就像你要知道盖房子的人想要啥样的房子，几个卧室、客厅多大之类的。
这个电商APP呢，用户得能轻松注册登录、浏览商品、下单付款，商家得能管理商品库存、处理订单。
这就是需求分析的阶段。
然后就进入设计环节啦。
这就好比设计房子的蓝图，哪里是厨房，哪里是卫生间都得安排好。
在软件工程里，要考虑软件的架构，是用传统的三层架构（表示层、业务逻辑层、数据访问层）呢，还是搞点新花样，像微服务架构啥的。
对于这个电商APP，可能表示层得设计得特别漂亮，让用户看着舒服，业务逻辑层要处理好商品搜索、价格计算这些复杂的逻辑，数据访问层要稳稳地和数据库交互，确保数据不丢失、不出错。
二、UML闪亮登场。
UML就像是一种超级厉害的建筑绘图语言，不过是给软件用的。
1. 用例图。
拿电商APP来说，用例图能清晰地展示谁（参与者）在用这个APP干啥。
比如说，用户这个参与者，可以登录、搜索商品、下单；商家这个参与者，可以添加商品、查看订单。
用例图就像一张地图，告诉你这个软件世界里不同角色的行动路线。
画这个图的时候，就像在画一幅漫画，简单又直观。
2. 类图。
这就像是在给软件里的各种“角色”（类）画人物关系图。
在电商APP里，有用户类、商品类、订单类等等。
用户类可能有姓名、年龄、地址这些属性，还有登录、注册这些方法。
商品类有商品名称、价格、库存这些属性。
订单类和用户类、商品类有着千丝万缕的关系，比如一个订单对应一个用户，一个订单包含多个商品。
类图把这些关系都明明白白地摆出来，就像给软件里的元素做了一次详细的家族族谱。
3. 时序图。
时序图可有趣了。
它像是在演一场戏，按照时间顺序展示对象之间的交互。
比如说用户下单这个过程，用户先选择商品，然后系统检查库存，库存够的话就生成订单，再从用户账户里扣钱。
基于UML的系统分析与设计
系统分析
详细来说，分析阶段旳活动主要是： 辨认对象； 为对象分类； 拟定类旳属性和操作； 拟定类之间旳关系： 拟定对象之间旳交互： 拟定对象旳状态变化等。
1.辨认对象
辨认对象并不是从零开始旳工作，应该最 大程度地利用已经有旳劳动成果。比较经 典旳可利用旳资料有。
用例模型和用例描述。 术语表。权威旳术语定义集合。
邮件管理、协议管理
用例旳优化
拆分
对较大旳或复杂旳用例 用例描述，描述到了第四级，仍无法描述清楚，
需用例拆分 主流→子流→分支流→子分支流
用例旳优化
拆分例子 管理顾客涉及处理：添加顾客、修改顾客
信息、删除顾客、查找顾客、修改顾客口 令、变更顾客级别 拆分为：维护顾客信息、管理顾客权限两 个用例（按业务有关性）
基于UML旳系统分析与设计
UML建模
一种系统开发措施应由建模语言和开发过 程构成。
建模语言是设计旳表达符号,而过程则是描 述怎样进行开发所需旳环节。
UML旳开发过程涉及需求获取、系统分析、 系统设计、实现和测试5个环节。
第一阶段
需求获取
需求获取
1.需求获取 系统开发旳第一步工作就是进行需求搜
5.拟定顾客界面
拟定参加者怎样开启用例，以及用例以什 么形式向参加者提供信息，
是在构造顾客界面旳原型。 这项活动旳输入是：用例模型、详细描述
旳用例描述。 活动旳成果是顾客界面旳简图。 目旳是为参加者拟定顾客界面旳外观和感
UML中的用例图实践案例
UML中的用例图实践案例UML（统一建模语言）是一种用于软件开发的标准化建模语言，它提供了一套丰富的图形符号和概念，用于描述和设计软件系统的各个方面。
其中，用例图是UML中最为常用和重要的一种图形表示方法，它用于描述系统的功能需求和用户与系统之间的交互关系。
本文将通过一个实践案例，介绍用例图在软件开发中的具体应用。
假设我们要开发一个在线购物系统，该系统包括用户注册、浏览商品、添加购物车、下单、支付等功能。
首先，我们需要明确系统的角色和用例。
在这个案例中，系统的角色包括用户、管理员和支付网关。
用户可以注册账号、浏览商品、添加购物车、下单和支付；管理员可以管理商品信息；支付网关负责处理支付请求。
接下来，我们可以使用用例图来表示这些角色和用例之间的关系。
首先，我们可以在用例图中用椭圆形表示各个用例。
在本案例中，我们可以用椭圆形表示注册账号、浏览商品、添加购物车、下单和支付等用例。
然后，我们可以用矩形表示各个角色，即用户、管理员和支付网关。
接着，我们可以使用实线箭头来表示角色与用例之间的关系。
例如，用户可以注册账号，我们可以在用户和注册账号之间画一条实线箭头来表示这种关系。
除了角色和用例之间的关系，用例图还可以表示用例之间的关系。
在本案例中，用户可以浏览商品、添加购物车、下单和支付，这些用例之间存在一定的先后顺序。
我们可以使用虚线箭头来表示这种顺序关系。
例如，用户可以先浏览商品，然后将商品添加到购物车，最后下单和支付。
我们可以在浏览商品和添加购物车之间画一条虚线箭头，表示用户在浏览商品后可以将商品添加到购物车。
此外，用例图还可以表示用例之间的包含和扩展关系。
在本案例中，用户下单时可能需要选择配送地址，我们可以将选择配送地址作为一个包含关系，用一个带有加号的实线箭头表示。
另外，用户下单时还可以选择使用优惠券，这可以作为一个扩展关系，用一个带有箭头和加号的虚线箭头表示。
通过用例图，我们可以清晰地描述系统的功能需求和用户与系统之间的交互关系。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一个例子说明UML与系统分析一、案例场景描述 (2)二、问题与分析 (5)三、类图的基本认识 (7)四、领域模型 (10)五、系统结构与序列图 (11)六、系统结构与通信图 (16)七、总结 (20)一、案例场景描述仁医院案例背景描述在HSDc的RA与信仁医院的特助及用户经过一到两次的需求访谈后，HSDc的软件架构师（Software Architect）请他们的项目经理（Project Manager; PM）安排了一次跟信仁医院特助的访谈。
信仁医院的特助觉得很不可思议，因为他完全不懂软件的设计，也没有写过程序，在他以往的经验中，也只和其他软件公司的系统分析师（System Analyst; SA）进行过访谈。
在他的想象中，软件开发人员的对等窗口应该是医院的信息中心，似乎不大应该是他，HSDc的项目经理特别跟信仁医院的特助说明，他们的软件架构师主要是要了解一下信仁医院的领域模型（Domain Model），因此希望和信仁医院中的领域专家（Domain Expert）来沟通。
信仁医院的特助抱着有些怀疑又有点好奇的心态，参与了这次的访谈，以下是该次访谈的部分内容。
HSDc项目经理：特助，今天非常谢谢你百忙之中抽空来参加这次访谈，接下来我把时间交给这次项目的软件架构师。
信仁医院特助：别这么说，其实我也很好奇，希望可以帮助你们软件人员些什么，毕竟，我对软件开发一窍不通。
HSDc 软件架构师：特助，不要这么说，我们才是医院相关业务的新手，我想能够有机会和你谈谈，对于未来我们在进行软件设计时，有相当大的帮助。
信仁医院特助：哦，是这样啊，那我们要怎么开始呢？HSDc 软件架构师：嗯，首先，我想要了解一下，在贵单位的住出院业务中，有什么样的"事件"是特别重要的，需要被记录下来的。
信仁医院特助：所谓的"事件"指的是什么？HSDc 软件架构师：举个例子来说，像病人来医院看病时，必须要先到柜台去做一个登记，这个登记的动作必须被医院记录下来，以利后续的处理，这个事件在医院就称为"挂号事件"。
总之，所谓的"事件"指的是其发生于某一个特定的时间点，且对于后续某些业务会有相对影响的业务。
信仁医院特助：嗯，我好像有一点了解了，"事件"？还蛮有趣的。
HSDc 软件架构师：哈哈，软件就是这么有趣啊！信仁医院特助：好，让我想一想……有了，住出院业务应该会有一个重要的事件：住院，这是所有业务的一个起始点。
HSDc 软件架构师：嗯，非常好。
接下来我要请问的是，"住院事件"本身需要记录些什么？有没有需要什么相关的明细信息？信仁医院特助：我不大懂。
什么叫做"明细信息"？HSDc 软件架构师：让我再举一个例子。
特助有到书店买过书吗？信仁医院特助：当然有。
HSDc 软件架构师：那我就以买书作为一个例子来说明。
在买书时，对书店来说，必须要记录一个"顾客买书事件"。
信仁医院特助：对。
HSDc 软件架构师：可是顾客买的书可能超过一本，这时候，书店的"顾客买书事件"中，就必须要记录顾客买了哪些书的"明细信息"。
信仁医院特助：哦，我知道了。
那就是我们之前跟其他软件厂商谈的时候，他们老是挂在口中的什么"一单多料"、"Master-Details"什么的。
说实话，我真听不大懂他们在说什么。
HSDc 软件架构师：哈哈，这是软件人员常常会犯的一些错误，真地很抱歉哦！回到我们的问题，对于医院的"住院事件"来说，有没有什么明细信息是需要保存下来的？信仁医院特助：我想想。
病人的数据？这是明细信息吗？HSDc 软件架构师：病人的数据？是每一次不同的住院事件，病人的数据都会不同吗？信仁医院特助：那倒不是。
HSDc 软件架构师：那就不是明细信息了。
病人的数据倒比较像是参与这次"住院事件"的关系人。
信仁医院特助：哦。
那病人这次住院的病情信息呢？HSDc 软件架构师：嗯，这听起来就有点像了。
不过每一次的住院事件中，会有多个的病情信息吗？信仁医院特助：嗯，有可能。
病人可能是因为内科诊断需要住院，但是需要其他科别的会诊。
HSDc 软件架构师：很好，那我们找到了明细信息及相关征状的信息。
接着，我要请问的是，对于我们医院的工作人员来说，住院事件有哪些人员会参与？信仁医院特助：有医生、护士，还有柜台人员等。
HSDc 软件架构师：了解了。
我记得好像住院的时候有分主治大夫跟住院医生，这两个角色的人对于住院事件的处置会有所不同吗？信仁医院特助：嗯，大体来说，两个角色都要直接对病人负责，不过主要的病情判断还是由主治大夫来负责，住院医生只是担任紧急状况的紧急处置。
HSDc 软件架构师：所以对于一个住院事件来说，主治大夫跟住院医生是各有一个喽！信仁医院特助：原则上是这样。
HSDc 软件架构师：对了，我记得以前在SARS（非典型肺炎）时，好像有听说有些医院因为没有"负压隔离病床"，所以不能够接SARS的患者，那是不是代表在住院的时候，特定的病床会给特定的疾病来使用？信仁医院特助：我们医院没有这个问题。
当然，原则上病床有分为各科别各自的病床，不过这并非强制性的，外科的病人有时也可以住进内科的病床。
但是既然提到这个问题，让我想到跟医院经营相关的问题。
原则上，我们的病床分成两类，一类是医保病床，这类型的病床，病人不需要负担病床的费用；另一类的病床则是非医保的病床，这类型的病床，病人则需要部分负担病床的费用。
未来在结算病人住院的费用时，我们需要知道病人究竟是使用哪一种病床。
HSDc 软件架构师：太好了，这对我们的设计有很大的帮助，谢谢。
我想今天的会议到这边应该可以先告一段落，再次感谢特助的帮忙。
信仁医院特助：就这样啊？不用谈什么表单吗？HSDc 软件架构师：不用，这样就可以了。
二、问题与分析在前述的场景中，揭露了软件的几个主要特质。
在HSDc的软件架构师与信仁医院特助的对谈过程中，其实隐含了相当多对于软件本质的一些讨论。
先看一下这段对话：对话分析HSDc 软件架构师：嗯，非常好。
接下来我要请问的是，"住院事件"本身需要记录些什么？有没有需要什么相关的明细信息？……信仁医院特助：哦，我知道了。
那就是我们之前跟其他软件厂商谈的时候，他们老是挂在口中的什么"一单多料"、"Master-Details"什么的。
说实话，我真地听不大懂他们在说什么。
这一段对话中，揭露了软件人员在面对客户时，常犯的一个错误：用太多的专有名词（而且是自己发明的专有名词，像Master-Details等UI的呈现说明）跟客户沟通，而忽略了本质性的讨论。
HSDc的软件架构师想要知道的是事件本身的明细信息，这跟如何呈现其实并没有关系，然而由于信仁医院的特助以往与软件人员的接触中，有许多"不大美好"的经验。
因此，反而不知道HSDc软件架构师究竟想要什么。
这似乎有些"倒果为因"，由于对软件人员的"满嘴专业术语"有些抗拒，在回到事情的本质时，反而有些不习惯。
事实上，套用一句Nokia著名的广告语（slogan）：科技以人为本，软件也是一样。
软件的结构若脱离了"事物的本质"，其实就已经失败了一半。
这也是为什么许多的软件设计的书籍（甚至连结构化分析设计），都那么重视"本质"（essential）的原因。
那么，"本质"究竟是什么？正如同前一节中的场景描述，"本质"指的就是要想办法直指想要解决的问题的"核心"。
从流程的观点来看，本质就是前一章中所谈的"事务流程"的抽象化呈现；而从软件结构面来看，本质指的则是你所要解决的问题领域（problem domain）中的重要"概念"（concept）在抽象（abstraction）层次的呈现。
一般来说，这样的呈现方式，会通过"概念模型"（conceptual model）来表示。
何谓"概念模型"呢？其实就是能够用最简化的方式表达一个完整的"问题领域"的抽象表示法。
举例来说，孔子的学生问孔子，他的中心思想是什么？孔子说："吾道一以贯之"，就是一个"仁"字。
"仁"就是孔子表达其所有思想的一个"概念模型"。
所以，在《论语》一书中，"仁"字出现了109次，孔子每一次都用不同的方式来解释"仁"，这就代表了"仁"这个抽象概念，有至少109种的"体现"方式。
相同地，软件也有各种不同的抽象表达法。
传统的"结构化分析设计"（Structured Analysis and Design）使用"数据流图"（Data Flow Diagram; DFD）来表达软件的结构，其重视的主要是数据与数据之间的"处理程序"，这虽然贴近了商业处理的逻辑，但却忽略了"问题领域"的概念。
正如我们前面所说，"概念模型"是"问题领域"的一种抽象化呈现模式，因此，在设计"概念模型"时，务必先把"问题领域"定义清楚。
举例来说，我们要表达"医院内部如何处理住出院"的问题领域，那就需要先把这个问题领域中一些重要的"元素"（element）先抽象出来。
"数据"只是这些元素的其中一种表现方式，因此，我们可以把"数据"视作是找寻"概念模型"的参考，并不能把它当做是"概念模型"本身。
那么，如何找寻需要的"概念"呢？针对你所关心的问题领域，重要的概念不外乎"人、事、时、地、物"这5个方面。
因此，想办法把这5个方面找出来，并且把它们之间的关系构造起来，就成为找出"概念模型"的最佳实务。
所谓的"类"（Class），其实就是对于前述概念的一种"分类方式"，由于"概念"本身要呈现多种的"抽象"含义，UML中的类图，也是这13张UML图形中最复杂的（就好像孔子说的"仁"，到了现在，还是很多人不知其所以然）。