如何用例图表示服务器
① 使用用例图描述系统时,如何识别用例
用例描述是对一个用例进行前置条件,后置条件,必要条件等信息的说明,是用例的特征之一,不一定每个用例都需要用例描述。 用例图可以看作是系统功能的完整表达,很多项目都是以用例为驱动进行的。
② 什么是用例图
额==个人做过的用例图就是把网站各个用户的动作分解一下,再用RATIONAL ROSE软件把它画出来。简单来说,画用例图分三个步骤,首先,确定系统角色;其次,确定用例,再次,对用例进行分解,确定下层的用例图。
比如这个用例,选课系统的角色之一是学生 用例名称:学生选课 执行者:学生
目的:完成一次学生选课的完整过程。
类型:主要的、基本的
级别:一级
(1)学生输入标识码(ID),系统识别标识码的有效性;
(2)对学生进行注册识别;
(3)流览本学期预开课程;
(4)选择学生自己要上的课程并确认;
(5)退出系统,系统给出所选课程列表及相应学分合计。
异常事件流处理:
(1)标识码有效性检查失败,允许学生重新输入(3次机会)。
(2)注册识别失败,没有注册(尙未交学费)的学生不能选课。
(3)选择课程确认失败,所选几门课程中在上课时间上发生冲 突时,系统提示重选。
画用例图就是将该过程描述符号化。并且有一些数据的泛化关系。
③ 系统的内部活动怎么用uml用例图表示
Visio画UML用例图步骤:1.在“文件”菜单上,依次指向“新建”、“软件”,然后单击“UML模型图”。2.在树视图中,右击要包含用例图的包或子系统,再指向“新建”,然后单击“用例图”。此时会出现一个空白页,而且“UML用例”模具也会显示在最顶部。工作区将“用例”显示为水印。树视图将添加一个表示该图表的图标。注释如果看不见树视图,请在“UML”菜单中指向“视图”,然后单击“模型资源管理器”。3.将“系统边界”形状拖到绘图页上。使用系统边界形状在用例图中指示系统边界4.Visio画UML用例图时要从“用例”模具中将“用例”形状拖出并放在系统边界内,然后将“参与者”形状拖到系统边界外。使用用例形状使用参与者形状5.使用“通信”形状指出用例和参与者之间的关系。使用通信形状指出参与者和用例之间的关系6.Visio画UML用例图时需要通过“使用”和“扩展”形状,指出用例之间的关系。指出两个用例之间的使用关系,指出两个用例之间的扩展关系7.双击任意形状(“系统边界”形状除外),打开其“UML属性”对话框,您可以在其中添加名称、特性、操作和其他属性。8.保存该图表。
④ 用例图 怎么表示 连接 服务器
用例图中表示链接服务器??
这个好像应该是部署图吧!!
⑤ 用例图中用例和包之间的关系应该怎么表示
方法/步骤
泛化。
泛化代表一般与特殊的关系。用例之间的泛化联系和类间的泛化联系类似,即在用例泛化中,子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性,还可以添加行为或覆盖、改变已继承的行为。当系统中具有一个或多个用例是较一般用例的特化时,就使用用例泛化。
用例的泛化用带空心箭头的实线表示,箭头的方向由子用例指向父用例。
使用联系。
使用联系是指一个用例使用另一个用例的功能行为。使用联系用于在用例间共享公共的功能行为。
使用联系是一种泛化联系,在用例图中用一个基本用例指向公共用例的泛化箭头线表示,并在箭头线上标有构造型<<uses>>
下图中,用例“删除教师”和用例“查找教师”之间、用例“更新教师”和“查找教师”之间存在着使用联系,在更新和删除教师信息之前,必须要找出要处理的教师。
包含联系。
包含联系是一种依赖联系,是指一个基本用例的行为包括了另一个用例。下图用一条从基本用例指向被包含的用例的虚箭头线表示,并在箭头上标识<<include>>。
扩展联系是把新行为插入到已有用例的方法。基础用例必须申明若干“扩展点”,而扩展用例只能在这些扩展点上增加新的行为。
一个基本用例可以是独立的,但是在某个条件下它的行为可以由另一个用例进行扩展。基本用例的行为只能在某些扩展点上被扩展。一个用例可以有多个扩展点。
如图所示是图书管理系统用例图的部分内容。基础用例是“还书”。如果借阅人所借图书超期,按规定应缴纳一定数额的罚金,这时就不能执行用例提供的常规动作。如果更改“还书”用例,必然会增加系统的复杂性。因此可以在还书用例中增加扩展点,特定条件是超期,如果满足特定条件,将执行扩展用例“缴纳罚金”,这样显然能使系统更容易被理解。
⑥ 简答题4.用例图有哪些元素构成如何使用用例图
用例图有:用例、参与者、关联、(系统边界)等元素;
用来显示在系统(或其它实体)内的用例与系统参与者之间的关系;
主要使用场合:需求获取、定义、分析。
⑦ 如何应用UML用例图描述软件系统的用户需求
用例图当然很好用,不然RUP(Rational Unified Process,统一软件开发过程,统一软件过程)也不会让用例驱动作为核心方法论之一,当然用例图自身也有很多不足,需要其它技术作补充。 ? 一、优点: ? 简洁、直观。是的,确实比较直观,几个小人人、几个椭圆,外加几条不多的线,用一个矩形一框就出来了,了不起再弄个用例描述,系统交互行为很清晰地表达出来。 规范、易理解。用例图是UML建模里比较常用的一个图,你用,我用,大家都用,并且标识、要素等均符合UML2中的约定,并且不依赖开发语言,所以说它和其它图一样规范因为规范所以对UML建模用户来说是易理解的。 用户导向、描述精准。用例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的。我们不管系统内部实现功能的机制,仅仅把系统看作一个黑盒,然后参与者与其进行交互,也就是用例是基于用户场景的,所以能更精准地表达用户功能需求。 需求与设计分离。因为用例图是站在系统外的视角描述系统需求的,所以并没有介入到系统内部实现细节,这就让需求和设计工作分离开来,条理清晰。 便于设计测试用例。用例图描述的就是一个用户场景,测试设计人员正好可以根据用例图设计测试用例。 边界清晰。一个矩形框把系统边界清晰、明确地表达出来,便于设计人员据此把握系统范围。 敏捷。用例图允许我们讲故事、写卡片,允许我们比较敏捷地实现功能需求方面的管理与交流。 ? 二、不足: ? 不能表达非功能需求。用例图是描述用户功能需求的工具,对于可靠性、性能等非功能需求无能为力。 对不懂UML的客户或程序员来说难以理解。对UML支持者来说,用例图可能是规范的、清晰的、简单的、易理解的,但对并未掌握UML建模技术的人来说理解那些椭圆并非易事,再说还有一系列如同伪代码似的事件流。 粗粒度。是的,用例图不涉及设计实现细节,只是一个功能划分,粒度非常粗,很多细节无从描述,需要用其他工具进行辅助说明。 ? 三、常见的错误用法和问题: ? 客户看不懂用例图,又要提供一个高大上(画UML图)的需求规格文档。这时候怎么办呢?作者建议画客户需要画的,然后把用例图制作成一个个卡片去跟客户讲故事,客户不会连故事都听不懂吧除非你讲故事的水平比画图的水平还拙劣。 架构师或程序员看不懂用例图。看不懂的话这些用例委实就成了摆设,这时又该怎么办呢?对的,仍旧讲故事,说业务场景并用用例规约加以辅助说明。 用例图涉及到实现细节。这个要加以避免,如果过早介入系统内部实现细节,过多的系统内部设计描述会让客户和程序员疲惫不堪。 系统边界模糊不清。建议用例图绘制时从上往下画,比较复杂的子系统可以拆在不同的用例图中。 用例过多。系统总的用例数不宜超过50个,建议最好是20-30个。过多的用例必定会有过多的Association、include、extend、generalize等关系,各种关系错综复杂违背了我们使用用例图的初衷。
⑧ 什么是用例图(use case diagrams)
1. 用例图(use case diagrams)简述 描述角色和用例之间的关系,着重展示系统必须实现的功能,用于在需求分析阶段分析客户需求。 2. 主要元素 用例(use case),系统为角色提供可见结果的一系列动作(简单理解为角色可见的系统功能),使用椭圆表示。 角色(actor),在与系统的一次或者多次交互中起作用的人,组织或者其他系统(即本系统的用户或者使用本系统的其他外部系统),使用小人图形表示。 关系(association),角色和用例的交互,使用带箭头或者不带箭头的实线表示,箭头表示调用关系。 系统边界(system boundary boxes),可选元素,用于划定系统范围,使用包围用例和角色的长方形表示,很少用。 包(package),可选元素,用于组织各种UML图,使之容易管理和浏览(类似java中的包),可以包括类图和用例图,使用文件夹的形式表示。 3. 分类 分为业务用例(business use case)和系统用例(system use case),一般来说,业务用例描述的系统功能比较粗糙和概括,业务人员更容易理解;系统用例更详细的描述系统所能提供的系统功能。 对于一般系统而言,使用系统用例即可满足需求。 4. 优缺点 优点:方便系统分析设计人员和业务人员沟通,方便系统分析人员对系统范围和规模有大概认识,方便构建测试用例,方便分析人员明确系统功能,方便接口设计人员尽早介入设计开发过程。 缺点:不适合描述没有交互或者交互很少的系统,不同的业务人员对于用例可能有不同的解读,不能清晰定义用户界面,主要适用于面向对象的系统。 5. 注意要点 将系统视为黑盒,从使用者的角度看系统,确定系统必须实现的功能。 角色描述的是系统中涉及的用户,现实生活中不同人可能拥有多个的角色。 所有的交互都发生在角色和用例之间,再没有其他可能发生的交互。 一般情况下一个用例只有一个actor拥有,如果有多个actor共用一个用例,就要考虑是否要增加新的角色,或者分拆用例。版权声明:原创作品,转载时请务必以超链接形式标明文章原始出处、作者信息和本声明,否则将追究法律责任。154414