创业,不能兼职(34)--- 用例图原来是和我的word结构图很接近的东西
有些朋友,我真的感谢,他们会不嫌你白痴地耐心地指教你. 和这样的人交流,遇到问题时,他不会是以"你反正不懂,你不要管"这样的态度对待你.而是尽量用深入浅出的一些词语讲解给你听.或者指点你自己去了解一些概念. 比如,今天让我看用例图的人. 他是真的有些耐心.

虽然,我绝对不会真正去按技术人员的标准去学习,也绝对不会以外行的身份,真正对技术人员去指手画脚,但对一些基本技术概念的了解,还是非常需要的.

因为,我是在做自己想要做的东西,我并不是一个外包公司的客户,也不是一个所谓大公司的领导.不能简单地以外行的身份和人家讲完需求就了事. 你自己是创业者,是要把自己想要的东西和懂技术的人一起实现出来. 以我现在对互联网行业的了解,在具体这个项目实现的过程里,我的角色应该是产品经理. 我感受是,一个好的创业者,一定得是一个好的产品经理. 而一个好的产品经理,一定不能完全对技术毫无所知,否则,你没有办法和程序员很好地合作.你会经常在和他们的交流里,出现"神马"问题.你会完全不知道,技术对你项目的支撑度.你在产品设计时,也会受到很多因为自己不懂技术,而对产品设计思路带来的禁锢.

我现在,就是一个初入道还不太合格的产品经理.我需要一步步提高自己.

总有人和我说,人过30不学艺. 那是胡说,任何时候,学任何东西都不晚.只要,你心里有梦.

说起用例图,我百度后看到的一个帖子,和iteye里nkshan的跟贴,真的是很深入浅出地做了描述.我很吃惊地发现,原来,有些问题也不难啊,我大多都能看懂嘛. http://www.cnblogs.com/chenqingwei/archive/2010/07/01/1769361.html


比如,第一段,描述什么是用例图的.

用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。

下面逐一说明用例图中各种符号的意义：

一\小人：
对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。


关于这段,我的感受和疑问是:
1.微博里用户关注的人,用户的粉丝这些,算不算不同角色呢?没有注册的用户,就是仅仅浏览的用户,算不算一种角色呢?注册了没有登录的用户算不算一种角色呢?

我好像设计的时候,一直都是直接以自己是一个用户,进入网站后,如何操作这样的流程在写需求文档,同时设计界面.好像,没有想象过很多角色的问题.

2.角色可能不算人,是另外的一个系统,这个,没例子,我还不太能理解.

3.呃,那个小人咋画出来的?


二\圈圈：
圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。按着这样的读法，我们可以得到两句完整的句子：
“一般员工打卡”
“一般员工查看自己的考勤情况”
大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。

这段我理解起来,没问题.

三\大框框：
在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
系统边界能清晰表达出系统的范围，并不是所有的用例图都需要画出系统边界的，一般只需要在全局用例图中画出系统边界，当对用例进行细化时，不需要画出系统边界。

这段我理解起来好像也没问题.

四\线条：
线条是指角色与用例之间的线条，线条有三种：无箭头的，指向用例的箭头，指向角色的箭头。无论是否有箭头，这些线条是用来联系角色（小人）和用例（圈圈）的，表示某某角色能“做”什么用例。
有箭头的线条，表示角色与系统交互的过程中，数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。
而没有箭头的线条，则没有明确表示数据的流向，一般情况下不需要明确表示数据的流向，只需要画无箭头的线条就可以了。

这段里面,我的感受和疑问是:

"数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。"我觉得解释的很好,可是,我一下没想出 系统往角色输出数据是什么意思.是不是,比如 ,在我这里,一个用户,输入了一个旅行的数据, 这个数据,就和这个用户建立了某种关联,这个数据就属于这个用户的? 就是系统往角色输出数据?

第二段,是讲解用例图中的Extend、Include、继承

一\“打印报表”这个用例有一条指向“查看一般报表”用例的虚线，虚线上有“<<extend>>”的字样，这表示“打印报表”扩展了“查看一般报表”，用户可以在“打印报表”的基础上做“打印报表”的工作，这就是Extend的意思。如果“打印报表”这个用例不存在，是不会影响“查看一般报表”这个用例的，而“查看一般报表”这个用例如果不存在，则用户无法在“查看一般报表”的基础上做“打印报表”的工作了。

我的感受和疑问:
我发现,程序员和外行的思维看来真的不一样, 要是这个“打印报表”扩展了“查看一般报表",在我,就会是把箭头反过来画,是从"查看一般报表"指向"打印报表",因为,我会认为是 先"查看"了,再继续"打印". 箭头指向的,肯定是从箭头这边延伸出去的嘛.
哎呀,来自火星的程序员们.唉,他们先制定的规则,你就只有记住的份,不能改变那些约定俗成.

二\“管理数据”有三根虚线，箭头分别指向“查看数据”、“新增数据”、“修改数据”，虚线上有“<<include>>”字眼，这表示“管理数据”包含“查看数据”、“新增数据”、“修改数据”三个子用例，这就是Include的意思。在以下情况下，会用到Include：
1)某些用例的其中一些步骤可以单独抽离出来，成为一个子用例。
2)以“树”的方式条理化各种用例，用Include来组织好父子用例，子用例可以再次Include自己的子用例。
上图中将“管理数据”进一步分解为子用例，其实是没有必要的，实际项目中数据的查看、增加、修改、删除操作是很常见的，我们在描述用例的时候一般只需要将这4种操作说成“管理XX”就可以了。

我的感受和疑问:

啊,我明白了一个,刚刚我前面的疑问,那个虚线箭头虽然是方向和我想的相反,但人家是标了extend这词的.

唉,这个,分解子用例的例子,谁说没必要? 我之前,写需求时就没写这个.我也觉得这是理所当然地,根本就只顾写一步步主要的业务流程去了,就忘记写这个具体添加一个数据后,还需要编辑,删除,和继续添加了.等兼职的程序员做了后,我发现,.他没给我地方去编辑,也没删除.

还有感受,就是,这些类似的东西,我都用word文档写过的.我不会画表,采取的方式就是,用级别不同的标题来区分. 我自己要是在word里点文档结构图,觉得很明白. 可是,程序员们好像就是看不明白.看来,对他们来说,还是图表比word的文字容易明白.

三\细心的朋友可能会发现，角色与角色之间怎么会有一个类图中的“继承”符号呢？从上图看来，就是录入员继承一般用户，领导继承录入员，什么意思呢？
无论是录入员还是领导，都需要先登录系统，才能使用各种功能，我们是否需要分别在“登录用户”与“录入员”、“领导”之间各拉一条线？