用脚本判断用户传参的参数是否有对应的进程在运行并把结果显示给用户
2013-12-31 13:26
337 查看
l
简介
n
用例图比较官方定义是这么说的:
用例图就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。
n
可以从两个方面来理解用例图的重要性:
u
对客户来说用例图是他们业务领域的逻辑化表达;
u
对建设单位来说,用例图是系统蓝图和开发的依据。
也就是说只有画好了用例图才能更好的了解系统的功能性需求,才能比较准确的做出客户希望的系统。
l
遇到的问题
相信画过用例图的朋友一定有这么一个体会,要么满篇一个小人几个圆圈几根连线——空荡荡;要么N多小人M多圆圈满篇连线——蜘蛛网。这些都是我们所不希望的,这样的用例图可以说没有存在的意义。因为失败的用例图不能准确的表达这个系统具备什么功能,如下面得“用电业务”用例图(其中只画出边界和涉众,未画出各个用例,相信如果画出各个用例将是一片蜘蛛网)。可以说失败的用例图使阅读者看起来就头大,更别说搞懂整个系统的功能需求了!
![](http://hi.csdn.net/attachment/201103/5/0_1299336904Ckj2.gif)
l
解决方案
造成上述问题的原因是没有准确的找到系统边界,进而没有找到真正的主角(actor)!也就是说如果把一个用例的所有涉众都画出来,那么这个用例图肯定是一塌糊涂的。
我们画图的宗旨:先找系统的边界然后再确定对应的主角,最后才能画出清晰明了的用例图。
n
怎样确定比较合理的边界?
通过业务目标(还以上图为例,业务目标是办理业务和交费)可以得到相应比较合理的边界,例如上图的“用电客户服务边界”可以这么确定(如下图)
![](http://hi.csdn.net/attachment/201103/5/0_1299336909Aj3n.gif)
可以清楚的看到,有了一个准确的业务目标后就可以轻松的找到这个业务的边界。
具体的方法:只要是关于“办理业务和交费”的操作统统属于这个用例之内,而这个目标的受益者是“银行”和“用电客户”,其他的涉众只能算是配合完成业务目标。于是自然而然的涉众被我们划分成了内外两部分。其中外部的涉众(“用电客户”和“银行”)很可能成为业务主角,内部的涉众(其他涉众)很可能成为业务工人。
n
确定主角
在上面的一个步骤中我们知道了可能成为业务工人或业务主角的涉众。
这里为什么说是可能呢?
主角一定是对系统有着希望并且直接对系统进行操作的人。
注意:在系统边界之外的人固然可能对系统有希望,但他们不一定直接对系统进行操纵。
这也就是说需要一个代理者来行使操作这个系统的动作,而这个代理者正是我们千辛万苦要寻找的业务主角!(如下图)
![](http://hi.csdn.net/attachment/201103/5/0_12993369125SzN.gif)
就像上图那样,业务主角找到了用例自然而然就清晰鸟~
l
确定最终用例图
以上仅仅是画用例图前期准备工作,真正我们最终要的用例图才刚刚开始。
首先说明我们平时口中说的用例实际上是指系统用例,是从系统的视角来看待整个需求的。而上面我们分析了大半天的那些个用例只能叫做业务用例,是从客户业务视角来分析需求和功能的。如果您还不是很清楚的话,以上图中的“申请永久用电”这个业务用例为例可以推导出对应的系统用例(如下图)
![](http://hi.csdn.net/attachment/201103/5/0_1299336914uUpu.gif)
也就是说系统用例是将业务用例“具体”、“细化”,即加上要完成这项业务需要的那些其他操作,把这些小项聚集到一起就是我们最重要的也是我们苦苦追求的系统用例!
到此为止用例图就告一段落,当然用例图只是UML建模的开始,后面系统细化、编码、其他图的绘制等软件开发的每一项都需要用例进行驱动。那些都是后话,咱以后再说……
文中用到的例子及图片引用自《大象》,感谢原书作者提供这么好的案例
简介
n
用例图比较官方定义是这么说的:
用例图就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。
n
可以从两个方面来理解用例图的重要性:
u
对客户来说用例图是他们业务领域的逻辑化表达;
u
对建设单位来说,用例图是系统蓝图和开发的依据。
也就是说只有画好了用例图才能更好的了解系统的功能性需求,才能比较准确的做出客户希望的系统。
l
遇到的问题
相信画过用例图的朋友一定有这么一个体会,要么满篇一个小人几个圆圈几根连线——空荡荡;要么N多小人M多圆圈满篇连线——蜘蛛网。这些都是我们所不希望的,这样的用例图可以说没有存在的意义。因为失败的用例图不能准确的表达这个系统具备什么功能,如下面得“用电业务”用例图(其中只画出边界和涉众,未画出各个用例,相信如果画出各个用例将是一片蜘蛛网)。可以说失败的用例图使阅读者看起来就头大,更别说搞懂整个系统的功能需求了!
![](http://hi.csdn.net/attachment/201103/5/0_1299336904Ckj2.gif)
l
解决方案
造成上述问题的原因是没有准确的找到系统边界,进而没有找到真正的主角(actor)!也就是说如果把一个用例的所有涉众都画出来,那么这个用例图肯定是一塌糊涂的。
我们画图的宗旨:先找系统的边界然后再确定对应的主角,最后才能画出清晰明了的用例图。
n
怎样确定比较合理的边界?
通过业务目标(还以上图为例,业务目标是办理业务和交费)可以得到相应比较合理的边界,例如上图的“用电客户服务边界”可以这么确定(如下图)
![](http://hi.csdn.net/attachment/201103/5/0_1299336909Aj3n.gif)
可以清楚的看到,有了一个准确的业务目标后就可以轻松的找到这个业务的边界。
具体的方法:只要是关于“办理业务和交费”的操作统统属于这个用例之内,而这个目标的受益者是“银行”和“用电客户”,其他的涉众只能算是配合完成业务目标。于是自然而然的涉众被我们划分成了内外两部分。其中外部的涉众(“用电客户”和“银行”)很可能成为业务主角,内部的涉众(其他涉众)很可能成为业务工人。
n
确定主角
在上面的一个步骤中我们知道了可能成为业务工人或业务主角的涉众。
这里为什么说是可能呢?
主角一定是对系统有着希望并且直接对系统进行操作的人。
注意:在系统边界之外的人固然可能对系统有希望,但他们不一定直接对系统进行操纵。
这也就是说需要一个代理者来行使操作这个系统的动作,而这个代理者正是我们千辛万苦要寻找的业务主角!(如下图)
![](http://hi.csdn.net/attachment/201103/5/0_12993369125SzN.gif)
就像上图那样,业务主角找到了用例自然而然就清晰鸟~
l
确定最终用例图
以上仅仅是画用例图前期准备工作,真正我们最终要的用例图才刚刚开始。
首先说明我们平时口中说的用例实际上是指系统用例,是从系统的视角来看待整个需求的。而上面我们分析了大半天的那些个用例只能叫做业务用例,是从客户业务视角来分析需求和功能的。如果您还不是很清楚的话,以上图中的“申请永久用电”这个业务用例为例可以推导出对应的系统用例(如下图)
![](http://hi.csdn.net/attachment/201103/5/0_1299336914uUpu.gif)
也就是说系统用例是将业务用例“具体”、“细化”,即加上要完成这项业务需要的那些其他操作,把这些小项聚集到一起就是我们最重要的也是我们苦苦追求的系统用例!
到此为止用例图就告一段落,当然用例图只是UML建模的开始,后面系统细化、编码、其他图的绘制等软件开发的每一项都需要用例进行驱动。那些都是后话,咱以后再说……
文中用到的例子及图片引用自《大象》,感谢原书作者提供这么好的案例
相关文章推荐
- 4.设计一个Email邮箱注册应用程序。要求:用户输入完成单击“立即注册”按,判断“密码”和“确认密码”文本框内容是否一致,如果一致在立即注册按钮上方显示用户输入的邮件地址,运行结果如图所示。
- 判断当前进程Token对应的用户是否在某一组之中
- VC 判断进程是否是以管理员权限运行,并且判断是否是用户进程而非服务进程
- 多线程判断用户是否在线(后台运行ping脚本)
- 在主函数中提示用户输入用户名和密码。另写一方法来判断用户输入是否正确。该方法分别返回一个bool类型的登录结果和和一个string类型的登录信息。如登录成功,返回true及“登录成功”,若登录失败则返回false及“用户名错误”或“密码错误”(使用out参数)
- shell脚本判断进程是否运行
- shell 脚本 判断ps进程管理中目标进程是否在运行
- 如何编写一个shell脚本查看某个进程是否在运行
- shell脚本判断进程是否存在,并重新启动
- 用shell脚本判断进程是否存在,并重新启动
- linux的shell脚本判断当前是否为root用户
- UNIX-判断程序是否已经运行的脚本在crontab与命令行下的不同
- shell练习:写一个脚本实现如下功能:输入一个数字,然后运行对应的一个命令。显示命令如下:*cmd
- IOS开发中如何判断程序第一次启动(根据判断结果决定是否显示新手操作引导)
- Inno Setup安装、卸载时判断是否程序正在运行,安装完成时自动打开网页的脚本
- shell脚本之判断输入参数是否为整数值
- Shell脚本实现检测进程是否正在运行
- 安装前判断进程中是否有程序在运行
- shell脚本示例,运行无限循环的shell脚本来检测拒绝列表上的用户是否登录到UNIX系统多于一次。
- 判断当前进程是否以管理员程序运行的方法