让技术人员看得懂的流程(3)——领域模型

               让技术人员看得懂的流程(3)

                            ——领域模型

按照一般的项目管理过程,“需求”之后是“分析”,那么在分析阶段对应的技术流程又是哪个?如何将需求阶段和分析阶段联系起来呢?答案就是“领域模型”

什么是“领域模型”呢?只要抓住“领域(Domain)”二字就可以理解,也就是说领域模型是帮助我们理解相关领域知识的模型。

进一步来问:为什么需要领域模型?前面不是有“用例模型”吗,看起来用例模型好像就是描述相关领域知识的,是否完成用例模型就可以进行设计了?

如果你曾经写过用例文档,或者仔细看过用例文档,那么你肯定知道“用例”本身和“面向对象”、“类”这些都没有关系,用例就是纯自然的语言(比如英语、汉语)写的,因为用例实际上由客户口述给我们、然后由我们形成文档化的用例文档,客户才不管我们是什么面向对象还是面向过程还是阿猫阿狗的。

因此,单纯从用例来看,是没有类的概念的,无法完成从自然语言到面向对象语言的转换。但是,既然我们已经完成了用例模型,那么就必须基于用例模型进行分析(否则用例模型岂不是白做了),而“领域模型”就是自然语言向面向对象语言的一座桥梁。

让我们来看看“领域模型”阶段我们要做什么、该怎么做。其实很简单,简单概括就是“找名词”,分为四个步骤:(1)找出用例模型中的名词,(2)然后识别这些名词本身的相关信息,(3)以及名词之间的相互关联关系,(4)用UML画出领域模型。

我们来看在“用例模型”章节中的POST用例如何得出领域模型。

第一步:找出用例模型中的名词

原有用例如下,用蓝色加黑标出名词(重复的就不标了):

1)顾客携带商品收银台

2)收银员扫描商品条形码

3)系统根据条形码获取并显示商品信息

4)收银员重复2~3步,直到所有商品扫描完毕;

5)系统计算商品总额

。。。。。。。。。。。。。。。。。。。。

n)系统打出商品清单,完成交易

这个用例中的名词有“顾客”、“商品”、“收银台”、“收银员”、“商品条形码”、“系统”、“商品信息”、“商品总额”、“商品清单”、“交易”。稍加整理:

1)“顾客”、“收银员”是系统的外部对象,不需要我们进行设计,但这些对象要和系统进行交互;

2)“商品”、“商品条形码”、“商品信息”、“商品总额”、“商品清单”、“交易”是领域对象,但“商品条形码”、“商品信息”可以算作“商品”的属性、“商品总额”可以算作“交易”的属性,最后从这个用例总结出来的领域对象有“商品”、“商品清单”、“交易”三个。

第二步:识别这些名词本身的相关信息

一个对象的属性可能分布在多个用例中,因此可以通过迭代不断的完善一个对象的属性,大家可以看到,我们在第一步中的样例就已经分析了一部分了:“商品条形码”、“商品信息”可以算作“商品”的属性。

对象除了属性外,还有一些约束或者限制,这些在用例中可能有,也可能没有,这就需要分析人员来发现了。比如说交易金额必须大于0.1元小于99999元这种约束,用例中不一定会体现,可能需要分析人员向客户咨询。

第三步:识别对象间的关系

面向对象设计就是依靠对象间的互相协作来配合完成相应的功能,因此识别出对象和对象本身的属性外,还要识别对象间的关系,例如1对多、1对1、依赖等,详细的各种关系可以参考UML的标准定义。

我们以第一步识别的三个对象为例:“商品清单”包含多个“商品”、一次“交易”对应一个“商品清单”、一个“商品”只能属于一个“交易”等。

第四步:画出领域模型UML

UML这里就不啰嗦了,我们结合前三步的分析,画出这个样例的UML领域模型图:

 

 (由于CSDN关闭了图片上传功能,因此无法贴出,大家可以根据前三步自己画一个)

大家可以看到,经过“领域模型”的分析后,已经完成了自然语言到面向对象语言的初步转化了,领域对象已经识别出来,面向对象已经初具雏形。

需要提醒的是:领域模型过程中识别出来的对象和具体的语言无关,也没有方法。换句话说,public、private、函数这些面向对象的属性在领域模型阶段不需要分析出来。

时间: 2024-11-05 19:30:59

让技术人员看得懂的流程(3)——领域模型的相关文章

让技术人员看得懂的流程(2)——用例模型

                    让技术人员看得懂的流程(2)                          --用例模型 一般的管理流程都将软件项目划分为"需求->分析->设计->实现->维护",对应的技术流程中首先也肯定是要将需求明确,而"用例模型"就是用于获得和分析需求的. 简单来说,用例模型就是要将客户的需求写下来."需求"不是很好理解,更加通俗的讲法是"故事(story)".我觉得&

让技术人员看得懂的流程(6)——处理模型

                   让技术人员看得懂的流程(6)                                 --处理模型 看完"实现模型",你是否长吁一声,准备拿起咖啡,惬意的喝上一杯?毕竟我们已经完成了从用例到编码的全过程了,确实是值得庆祝的一件事情,但"革命尚未成功.同志还需努力",现在还不是享受的时候,接下来我们需要进入"处理模型"阶段. l         "处理模型"阶段的任务 "处

让技术人员看得懂的流程(4)——设计模型

                       让技术人员看得懂的流程(4)                                     --设计模型 完成了"领域模型"阶段后,面向对象已经初具雏形,我们已经看到了那熟悉的"对象"了,例如"商品"."交易"."商品清单"等,看起来已经进入了面向对象的世界了,你是否已经摩拳擦掌,跃跃欲试,准备开始编码了呢? 且慢,"领域模型"只是

让技术人员看得懂的流程(5)——实现模型

                    让技术人员看得懂的流程(5)                                   --实现模型 经过前面的"用例模型"."领域模型"."设计模型"的讲解,面向对象分析设计都完了,面向对象已经基本成型,接下来就是要具体实现了,对应的就是"实现模型". "实现模型"是整个技术流程中大家接触最多的阶段,只要是做开发的,基本上都是先参与这个阶段的工作.顾名思义

技术人员如何跟传统行业打交道?

前几天,读了一本书叫<高难度谈话>,这本书主要讲的就是「沟通」问题,而本书的主题就是「人」--我们这些并不完美却真实的人.人是一种复杂的个体,我们每个人都有自己的观点.思想和感情.技术人员如此,传统行业的「老板」也是如此! 而在很多技术人员眼中,跟他们打交道要比敲代码要复杂「1000」倍.本期移动开发精英俱乐部讨论的主题就是「技术人员如何跟传统行业打交道?」,让我们来听一些技术同学的吐槽,还有哪些解决办法吧!本文系 OneAPM 市场部整理. 程序员眼中的传统行业 晓书生:我觉得跟传统行业打交

如何管理飞扬跋扈的技术人员

在互联网项目当中,相信每一个项目经理或者制作人,最头疼的就是技术部的管理.因为技术工作看起来是那么的棘手,一般人难以理解,而且技术人员大多数都似乎情商不高.管理人员既不能轻易了解技术工作的内涵,技术人员也觉得很难和管理人员沟通.特别是技术工作,难以在不同人之间交接,很多技术人员都声称无法继续别人做过的项目.这让管理者觉得技术人员特别喜欢耍大牌,而且他们要偷懒也非常容易.但正如军事中的定理,对付坦克最好的武器就是坦克,对付航母最好的武器也是航母,这条理论是通用的.要管理好技术人员,就一定要懂技术.

数据科学家和大数据技术人员工具包

数据科学家的常用工具与基本思路,数据分析师和数据科学家使用的工具综合概述,包括开源的技术平台相关工具.挖掘分析处理工具.其它常见工具等几百种,几十个大类,部分网址.为数据科学教育和知识分享,提高数据科学人员素质. 数据科学融合了多门学科并且建立在这些学科的理论和技术之上,包括数学.概率模型.统计学.机器学习.数据仓库.可视化等.在实际应用中,数据科学包括数据的收集.清洗.分析.可视化以及数据应用整个迭代过程,最终帮助组织制定正确的发展决策数据科学的从业者称为数据科学家.数据科学家有其独特的基本思

《进化——我们在互联网上奋斗的故事》一一1.4 从精兵到强将 ——技术人员的职场发展之路

1.4 从精兵到强将 --技术人员的职场发展之路 进化--我们在互联网上奋斗的故事 因兴趣而进入互联网行业 2000年,踏着世纪交替的步伐,我走进入了西北工业大学,学习航空飞行器动力专业而不是计算机专业.在入学之前,我就对计算机有不小的兴趣,进入大学后经常去学校图书馆或实验室上网,对计算机的兴趣越来越浓厚,就去图书馆找一些网页设计.网页特效等书籍学习并动手做一些练习.之后我就很喜欢用263的邮箱,因为它的邮箱支持自定义网页格式,我可以给同学和朋友发送自己设计的个性化的网页格式E-mail.那时很

谈谈技术人员转管理岗的问题

现代通信网络中,交换机发挥的作用越来越大:海量的数据到达这个信息节点,然后按照既定的规则,快速有效地传送到目的地.网络里的交换机就象一个组织里的管理者,把任务拆解分配给不同的人或者单元,并确保任务的完成. 交换机的工作原理并不复杂,硬件基础就是普通的服务器,只不过上层加载的是专用软件,能够快速高效地完成数据和信息交换的任务.如果数据量不大,IT系统中不必引入专用的交换机,通过自行开发的软件也能实现信息交互的目标.就象在一个小规模的组织里,或者完成一项不太复杂的任务,就不一定需要专用的管理人员,技