从实践中体会用例建模
程序员文章站
2022-07-14 17:19:57
...
本文背景:工作中需要对某电子政务系统进行需求抽取,电子政务系统本身具有高复杂性的业务流程,并且业务规则十分庞杂。
本文目的:记录下简要分析过程,以便以后进行类似分析时候更容易把握需求。
首先,我们都知道,需求分析是一个很复杂的过程,一方便需要与客户交谈获取领域知识,业务流程,另外一方面还需要考虑到技术上的实现。作为开发人员往往容易考虑到技术上的技术,而忽略了原本的业务流程。引用“DDD”中的一些话“在启动一个软件项目时,我们应该关注软件涉及的领域。软件的最终目的是增进一个特定的领域。为了达到这个目的,软件需要跟要它服务的领域和谐相处,否则,它会给领域引入麻烦,产生障碍、灾难甚至导致混乱等。我们怎样才能让软件和领域和谐相处呢?最佳的方式是让软件成为领域的反射(映射)。软件需要具现领域里重要的核心概念和元素,并精确实现它们之间的关系。软件需要对领域进行建模。”。
我觉得一个完善的软件,最重要的是符合业务领域业务流程,即到业务进行到什么阶段就该做什么事,而不是把所有业务功能都丢在一个版面上,让软件使用者自己通过自身的领域知识进行选择。这样的例子很多,例如,ATM取款机中已经没钱了,那么就不应该显示“提款”这个功能,例如ATM取款机已经通信故障了,那么所有功能都不应该显示,因为这些功能在ATM的当前状态是不可见的,是不可操作的,所以按照ATM机的业务规则,他是不能出现的。 但是,大型企业与*的业务流程可不仅仅如此,他们的可达状态远远比ATM复杂得多,例如一个玩具生产系统(技术法律允许就接单做),假设他们的玩具根据材料分塑料玩具、橡胶玩具、布料玩具、木制玩具,每种机动类型的玩具又分电动玩具、非电动玩具,整个玩具生产的正常业务流程是 接收订单---->建立项目单----->分配项目单----->生产玩具----->完成订单 ,好了,现在假设一下每个阶段的业务规则, 接收订单 需要根据 玩具材料类型+玩具机动类型 产生不同的参数, 比如现在接收到一笔 塑料电动玩具 的订单, 除了常规参数以外(价格 数量),还需要输入 塑料耐热性,塑料的环保型,以及电动方式是否为电池,是否无线等等,假设每种组合类型都需要这样进行操作,现在细看一下 接收订单 这个过程,4*2=8种参数输入(这里结果之所以为8的意思是两种类型的任意组合输入参数的不一样,就是说 都为电动玩具的塑料玩具与橡胶玩具 他们的电动参数 是不一样的)。
好了,这个是第一个过程,这里仅仅是冰山一角,现在假设进入第二个过程了,建立项目单,假设这个过程没什么区别,就是像可行性研究,看看我们厂子是否可以搞定这笔单子,这个又跟玩具类型+玩具机动类型关系了,比如 木制电动玩具,先要考证 电动过程中是否会使得木制玩具着火等等,等通过这一道又一个道的检验,那么才可以进入下一个工作周期。好了,现在进行分配项目单了,这个基本上是一致的,只是把一个单子指定到一个生产车间罢了(事实上,任何分配都有很多种,这里是简化了再简化)。
到了生产阶段,这个阶段要处理的信息可与具体的玩具类型具有很大关联了,每种类型的玩具需要记录的信息就有许多地方不一样了,意味着各种用例出现的条件受限制了,比如“测量塑料玩具的耐热程度”这个过程很显然是在类型位塑料玩具的情况下才会出现的。
仔细从头来看整个系统,姑且叫他 玩具生产系统吧, 很复杂的系统, 一层套一层,每个层次的工序还可能不一样,就像“测量塑料玩具的耐热程度”,可能要分在干燥、潮湿情况下的数据,这样十分复杂的系统应该怎么做呢?
我觉得,首先肯定是进行业务建模的,但是要表达出整个玩具生产的全部过程似乎不是那么容易,那么多的分支。第一步,应该确立业务用例,所谓业务用例,就是一个完备的,对于用户来说是可见并且有业务价值的,例如取款是业务用例,而输入卡号跟密码却不是。第二步,描述业务规则,我个人看法用矩阵进行比较规则并且数量较大的业务规则描述会比较适合。第三步,利用状态图显示影响系统全局状态的用例,这个过程大概是这样的,首先我们当前系统的五个订单状态是这样的 未接收的---->接收订单中---->建立项目单中----->分配项目单中----->开始生产----->完成订单 那么至少我们可以抽象出影响状态的五个用例,新接收订单,新建项目单,分配项目单,开始生产,生产完成。 这五个用例都会使得整个项目的状态发生变化,但是不仅仅是这五个而已,例如新建项目单的时候进行项目考究时候发现项目无法完成,那么订单状态也会发生改变,然而这种改变完全根据每种材料的不同进行判断,所以这些会影响状态的用例需要逐步进行填充。
然而这些仅仅是业务建模,仅仅是现实世界如何操作这项业务,下一步需要进行系统建模,系统建模主要加入需要关注的界面细节,业务可执行细节,例如在之前的玩具厂例子中,在某个订单状态就限定了能操作的业务功能,就需要在某些地方表现出来。
本文目的:记录下简要分析过程,以便以后进行类似分析时候更容易把握需求。
首先,我们都知道,需求分析是一个很复杂的过程,一方便需要与客户交谈获取领域知识,业务流程,另外一方面还需要考虑到技术上的实现。作为开发人员往往容易考虑到技术上的技术,而忽略了原本的业务流程。引用“DDD”中的一些话“在启动一个软件项目时,我们应该关注软件涉及的领域。软件的最终目的是增进一个特定的领域。为了达到这个目的,软件需要跟要它服务的领域和谐相处,否则,它会给领域引入麻烦,产生障碍、灾难甚至导致混乱等。我们怎样才能让软件和领域和谐相处呢?最佳的方式是让软件成为领域的反射(映射)。软件需要具现领域里重要的核心概念和元素,并精确实现它们之间的关系。软件需要对领域进行建模。”。
我觉得一个完善的软件,最重要的是符合业务领域业务流程,即到业务进行到什么阶段就该做什么事,而不是把所有业务功能都丢在一个版面上,让软件使用者自己通过自身的领域知识进行选择。这样的例子很多,例如,ATM取款机中已经没钱了,那么就不应该显示“提款”这个功能,例如ATM取款机已经通信故障了,那么所有功能都不应该显示,因为这些功能在ATM的当前状态是不可见的,是不可操作的,所以按照ATM机的业务规则,他是不能出现的。 但是,大型企业与*的业务流程可不仅仅如此,他们的可达状态远远比ATM复杂得多,例如一个玩具生产系统(技术法律允许就接单做),假设他们的玩具根据材料分塑料玩具、橡胶玩具、布料玩具、木制玩具,每种机动类型的玩具又分电动玩具、非电动玩具,整个玩具生产的正常业务流程是 接收订单---->建立项目单----->分配项目单----->生产玩具----->完成订单 ,好了,现在假设一下每个阶段的业务规则, 接收订单 需要根据 玩具材料类型+玩具机动类型 产生不同的参数, 比如现在接收到一笔 塑料电动玩具 的订单, 除了常规参数以外(价格 数量),还需要输入 塑料耐热性,塑料的环保型,以及电动方式是否为电池,是否无线等等,假设每种组合类型都需要这样进行操作,现在细看一下 接收订单 这个过程,4*2=8种参数输入(这里结果之所以为8的意思是两种类型的任意组合输入参数的不一样,就是说 都为电动玩具的塑料玩具与橡胶玩具 他们的电动参数 是不一样的)。
好了,这个是第一个过程,这里仅仅是冰山一角,现在假设进入第二个过程了,建立项目单,假设这个过程没什么区别,就是像可行性研究,看看我们厂子是否可以搞定这笔单子,这个又跟玩具类型+玩具机动类型关系了,比如 木制电动玩具,先要考证 电动过程中是否会使得木制玩具着火等等,等通过这一道又一个道的检验,那么才可以进入下一个工作周期。好了,现在进行分配项目单了,这个基本上是一致的,只是把一个单子指定到一个生产车间罢了(事实上,任何分配都有很多种,这里是简化了再简化)。
到了生产阶段,这个阶段要处理的信息可与具体的玩具类型具有很大关联了,每种类型的玩具需要记录的信息就有许多地方不一样了,意味着各种用例出现的条件受限制了,比如“测量塑料玩具的耐热程度”这个过程很显然是在类型位塑料玩具的情况下才会出现的。
仔细从头来看整个系统,姑且叫他 玩具生产系统吧, 很复杂的系统, 一层套一层,每个层次的工序还可能不一样,就像“测量塑料玩具的耐热程度”,可能要分在干燥、潮湿情况下的数据,这样十分复杂的系统应该怎么做呢?
我觉得,首先肯定是进行业务建模的,但是要表达出整个玩具生产的全部过程似乎不是那么容易,那么多的分支。第一步,应该确立业务用例,所谓业务用例,就是一个完备的,对于用户来说是可见并且有业务价值的,例如取款是业务用例,而输入卡号跟密码却不是。第二步,描述业务规则,我个人看法用矩阵进行比较规则并且数量较大的业务规则描述会比较适合。第三步,利用状态图显示影响系统全局状态的用例,这个过程大概是这样的,首先我们当前系统的五个订单状态是这样的 未接收的---->接收订单中---->建立项目单中----->分配项目单中----->开始生产----->完成订单 那么至少我们可以抽象出影响状态的五个用例,新接收订单,新建项目单,分配项目单,开始生产,生产完成。 这五个用例都会使得整个项目的状态发生变化,但是不仅仅是这五个而已,例如新建项目单的时候进行项目考究时候发现项目无法完成,那么订单状态也会发生改变,然而这种改变完全根据每种材料的不同进行判断,所以这些会影响状态的用例需要逐步进行填充。
然而这些仅仅是业务建模,仅仅是现实世界如何操作这项业务,下一步需要进行系统建模,系统建模主要加入需要关注的界面细节,业务可执行细节,例如在之前的玩具厂例子中,在某个订单状态就限定了能操作的业务功能,就需要在某些地方表现出来。
上一篇: 可嵌套2层的网格系统
下一篇: C++利用zxing识别二维码
推荐阅读