3、面向接口_业务模型分析实例1

来源:互联网 发布:怪物猎人激活码淘宝 编辑:程序博客网 时间:2024/05/17 08:31

剧本开始拍摄啦,首先作为一个纯业务人员,先说下想法:

我是一个程序小菜鸟,偶尔有一天想先把2部分对技术的理解记录在网站里,一部分是“接口”,另一部分是“可变业务定制” ,不但我可以往这2部分中添加新内容,公司新招的一些小小菜鸟也想分享内容和心得在里面,并且最后还想给看懂了的大神们一席之地,让他们也能各抒己见那就最好不过了
并且我还想在网站首页上去说明下我做这个网站的直接目的:1、帮助企业快速建立uml模型  2、帮助企业快速实现编码  3、还没想好啊。。。可能还有很多这样的目的。
还有一个大胆的想法就是呢,可以在网站上能够时不时的定制一个不同内容表单让大家都来提交,一来可以投个票啥的,二来呢组织个交友会啥的岂不很爽
最后一个需求啦:就是时常换换网站风格

以上就是全部需求,虽然省略了剩下的1W多没说的需求,但已经足够说明问题了:)

好了,问题来了,请注意上面这个需求明显有几个问题不知道大家发现了没:

  1. 这个需求用词不准,确切的说是随口说的,这个怎么办,如何提取受众、业务实体?
  2. 这个需求目的不太明确,user case怎么划定?
  3. 没有具体实现,只有朦胧的结果,没有如何的细节啊,活动图如何画?其它的更别说了

我们在现实中经常会遇到这样的情况,当然比这种情况要好,我就拿这个不好的例子来说明下,只有这些我们能做什么,通过这些我们能屡出什么头绪,大家也可以想一下,我明天会把所有的分析以及图型补齐。下面开始

工具:uml、面向对象,业务模型接口(暂且这么命名) 说下想法:我需要把所有可能的受众先剥离出来,然后从这些受众入手,把它们的所有要干的有成果(并且得到利益)的事情大致清理出来,然后在尽量不破坏业务原貌的基础上(也就是尽量不做任何抽象),提取业务模型接口,然后兵分2路,一路细化或是准确业务用词。一路根据接口的特性把实现强行订立出来(活动图),有详细实现过程的业务则可以顺便验证并测试业务模型接口或是user case是否准确,业务分析大致完成

下面开始动手:

  • 受众分析:程序小菜鸟     小小菜鸟    大神游客    普通游客    注册用户 。这里我逐个做一下解释,程序小菜鸟和小小菜鸟这2个明眼人一看就知道是超级管理员和技术部的编辑啊,为什么让这样恶心的名词出现在受众中呢,我的习惯是尽可能的保存业务模型的原味,这样做的好处是尽可能的不让自己的想法去影响原始业务,让业务本身能慢慢的浮现出来它应有的特性,而不是用自己的经验判断。那么大神游客这个也是因为很有可能游客的文章需要某人的审核才可以发表,所以才会单独的出现。普通游客 和注册用户同理
  • user case分析:其中管理还有可能其他usercase没有细化分析,否则太大了,但实际项目必须画全,这里不冗述如何提取usercase了明天继续


继续分析其它的actor基本没有价值。更新图1为

user case 建立完成,按照计划提取业务模型接口:

      很明显几个受众都有增加频道博文的期望,那么有个问题,它们的实现方式一样吗?拥有相同的期望又意味着什么呢?我的做法是将它作为业务模型接口进行再分析,如下图对于增加博文接口而言,根据接口的特性,我需要知道它的输入项(前置条件)和是否拥有输出项,然后根据实际情况去决定由几个实现来表示,也就是说这时必须要去确定东西了,而我在确定完之后,就完善下面的图,以上完全是根据我对业务的再次确定而得出的,那么到目前为止我们已经有了3个业务接口可以用了。接下的很重要,如果我的需求变了,也许某一天我坚持认为大神游客拥有自己独特的增加频道博文的方法该怎么办?或是增加博文也许需要天朝网监的审核呢?那么同理只需增加相应的接口即可,在此我就不都画出来了,那么为什么订立业务接口呢?有如下几点

1、 对于业务模型的最初分析是混沌的,分析受众的行为是引出问题,把利益点暴露出来,也就是分析业务不外乎就是要把受众最关心的问题挖掘出来(以防项目失败), 然后订立接口是为了继续分析业务,这次需要有意识的明确目的(订立目的),并把驱使者剥离出来,实现业务模型的首次解耦

2、还是根据接口的特性,吃什么吐什么决定后,接下来就好确定实现了,也就是接下来需要画的活动图了,反过来活动图的建立又可以验证业务接口的准确性

3、业务接口有了,就有了边界,有了边界就有了分析概念模型的材料了

4、去除了受众则为了单纯从行为上去验证是否会有其它的实现方式。为将来的分析类和控制类做准备

5、还有一些名词会浮现在接口中,这些名词都为我们接下来的工作提供了依据(当然usercase分析也有这一步)

6、另外最主要的还是要从业务的高度上先不考虑实现来验证工作的必要性,也就是最关键的是否有必要去分析它

可以看到订立 接口的最主要目的还是在于分析,是有意识有目的的在分析,多角度,多次数的分析,杜绝经验判断或是武断判断,当然不是每一个usercase都需要如此,关键的理不太清楚的有必要去订立,那么在以上用例中还有哪些可以订立的呢,我会在“4、面向接口_业务模型分析实例2”中去具体分析