对于大中型系统,用例驱动设计、流程驱动设计、领域驱动设计的方法都可使用,并辅以状态图来梳理业务的具体操作。比如,一个银行系统用用例驱动设计的方式,梳理出贷款功能、开户功能、存取款功能。然后,再用流程驱动设计的方法,梳理贷款审批的流程,并辅以状态图梳理出关键的操作。最后,再用领域驱动设计的方法,梳理后台贷款信息的组织和展现。
在采取了以上方法后,对应的 UML 图是否要画呢?对于一项复杂业务,流程图、状态图和类图都应画出,这样表达也很清晰。用例图则可不画,用思维导图代替即可,我们主要用的是用例的思路。
首先,如果业务不复杂,就可不画。如果流程图和状态图都很简单,那么就可以不画。但前提是,产品经理要能做到纸上无图,心中有图。也就是说,在脑中有图,即使不画图,其文档也没问题。
其次,还要看研发人员的需求。因为虽然产品经理自己明白了,但是研发人员也要通过看图,来理解业务并设计软件。所以,如果研发人员需要,就应画一下。
UML 因为内容全面而被业界广泛认可,也因为过于复杂,而被专家和从业人员批评。但是复杂不是 UML 的错,UML 仅仅是一种语言,如何使用它关键在于人。
UML 的目标是应用在各行各业,所以必须全面和复杂。也正是因为全面,UML 才会被 ISO 所接受。对于 UML 而言,不仅可以用在软件行业中,还可用在非软件行业中,并且系统越大、越复杂,效果就越好。
UML 可以用在银行系统、电力系统、医疗电子软件设计中,或用在法律部门的工作流、战斗机飞行系统及通信设备的设计中。
虽然 UML 的复杂有其道理,但其因为过于复杂而饱受批评。
业界的主要批评是,UML 过于庞大和复杂,以致于人们很难熟练掌握它,并很难有效应用它。而 UML 的有些概念也很少使用,一些概念间只有细微的差别,找到这些差别又缺乏现实意义。另一种意见是,UML 应定义一个精炼的核心,只提供最常用的建模元素。但这个目标没有实现,UML 仍然很复杂。
虽然 UML 的一些表达有一定的问题,如用例的包含关系和扩展关系的划分,但 UML 的复杂是必须的,因为 UML 是一种语言。
但是,UML 的规定的确多,导致其难以掌握和有效运用。因此,我们只需要学习部分内容,并且要多学如何用。只有这样,才能更好地梳理业务、设计业务。同时,也应把 UML 图和文字描述结合起来,让它们发挥各自的优势。
如果要做一个小系统,无论是产品经理还是研发人员,都不太需要用 UML。但如果要做一个大系统,或者要把小系统做的游刃有余,则产品经理和研发必须掌握 UML。这也是做过较大系统的产品经理和研发人员的共识。
比如,我们可用用例图梳理出业务范围、定义出功能模块。我们还可以用流程图梳理业务流程,用状态图梳理操作,用类图梳理后台管理等。这些都是好的思考习惯。同时,运用结构化的思考模式,产品经理能把业务想得周全,并有利于对外沟通和对内表达。
学全,用全大可不必。如果都学会固然是好的,但如果花了大量时间去学知识却很少得到应用,这样就失去了意义。
第一类:基本结构
类图、对象图、部署图
第二类:体系结构
构建图、组成结构图、包图、扩集图
第一类;基本行为
用例图、活动图、状态图
第二类:交互行为
顺序图、通信图、定时图、交互图
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/chengqiuming/article/details/122797648
内容来源于网络,如有侵权,请联系作者删除!