信息系统开发4分析.ppt

4.4.3 用例说明 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 性别 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 年龄 0 0 0 1 1 1 2 2 2 0 0 0 1 1 1 2 2 2 文化程度 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 脱产学习 ※ ※ 当电工 ※ ※ 当钳工 ※ ※ 当车工 ※ ※ 当技术员 ☆ ※ ※ ☆ ※ ※ 当材料员 ※ ※ ※ ※ 初始判断表 4.4.3 用例说明 1 2 3 4 5 6 7 8 9 性别 0 0 1 1 年龄 0 0 1 1 2 2 1 1 文化程度 0 1 2 0 1 0 1 0 1 脱产学习 ※ 当电工 ※ 当钳工 ※ ※ 当车工 ※ ※ 当技术员 ※ 当材料员 ※ ※ 简化的判断表 4.4.3 用例说明 6、用例说明范例 4.4.4 情景描述板 “学生档案管理”操作界面 4.3.2 需求分析 4、“日常教学管理”业务流程需求分析 4.3.2 需求分析 5、总体功能需求描述 4.3.3 用例模型的建立及检验 1、建立用例模型 高层用例模型 4.3.3 用例模型的建立及检验 “教学计划管理”用例模型 4.3.3 用例模型的建立及检验 “日常教学管理”用例模型 4.3.3 用例模型的建立及检验 “排课处理”用例模型 4.3.3 用例模型的建立及检验 “学籍管理”用例模型 4.3.3 用例模型的建立及检验 2、用例模型间的层次关系 4.3.3 用例模型的建立及检验 角色之间的关系 4.3.3 用例模型的建立及检验 3、用例模型的检验 （1）检验用例模型与数据流程图之间的关系 （2）用例模型的检验 ①用例模型中，除扩展用例和包含用例可以没有参与者外，每个用例都应该有角色，并且由角色启动用例。 ②两个参与者之间不应该有“单向关联”线，即某个参与者不能启动另一个参与者。 ③用例间的包含关系和扩展关系出现循环回路，在逻辑上是不合理的，应该重新考虑扩展用例或包含用例的设置问题 ④如果发现有两个参与者共同启动一个用例，那么说明用例也还可以进一步分解。 ⑤每个用例应该是一个相对独立的功能，如果包含多个功能，那么可以考虑对用例进行分解 （3）用例模型的完整性检验 与用户一起彻底检查每一个用例，确认其功能需求是否完整，用例的命名是否存在歧义，用例所表达的功能需求是否与用户的想法一致 4.4功能描述 4.4.1 用例的活动图描述 1、活动图要素 开始、活动、状态、同步条、判断、结束、迁移和泳道 4.4.1 用例的活动图描述 2、用例内部的活动图描述 “学生档案管理”活动图 4.4.1 用例的活动图描述 “审核学籍”活动图 4.4.1 用例的活动图描述 “毕业资格审查”活动图 4.4.1 用例的活动图描述 3、用例间关系的描述 “学籍变更申请处理”活动图 4.4.2 状态图 “学籍变更申请处理”状态图 4.4.3 用例说明 1、用例说明的基本内容 简要说明：概要描述用例的作用。一般认为，用例名称是对用例功能的高度概括。 前置条件：说明执行该功能之前必须满足的条件。例如，“初审学籍变更申请”用例的执行前提是必须先由学生提交学籍变更申请。 场景：描述具体细节，说明具体操作步骤。指出用例如何开始、进行哪些操作、正常的流程、出错后如何处理、用例如何结束等等。对场景的描述可采用结构式语言、判断树和判断表。 后置条件：用例执行后必须为真的条件，即说明该用例执行完后在什么条件下才可以运行另一个用例等等。例如“初审学籍变更申请”用例执行完后，只有在初审通过的条件下才可以执行“审查学籍变更申请”用例。 非功能性需求：对用例的运行在可靠性、可用性、可支持性方面的要求，以及性能上和设计约束方面的要求。例如，当学生提交了学籍变更申请之后，在院系负责人的电脑上给出相应的提示信号，提醒院系负责人有待审的学籍变更申请需要处理。 4.4.3 用例说明 2、自然语言存在的问题 （1）界限不明确 例： 成绩（分数） 成绩等级 90～100 优 80～90 良 70～80 中 60～70 及 60以下 不 4.4.3 用例说明 2、自然语言存在的问题 （2）逻辑条件的次序不明确 例：学校有一项奖励条件“凡各科成绩平均在92分以上，或单科最低分在85分以上，且英语成绩平均在90分以上者，可申请特等奖学金。” 解释一：有两类学生可以申请奖学金，一类是各科成绩平均在92分以上且英语成绩平均在90分以上者；另一类是单科成绩最低在85分以上且英语成绩平均在90分以上者 解释二：有两类学生可以申请奖学金，一类是各科成绩均在92分以上者；另一类是单科成绩最低分在85分以上且英语成绩平均在90分以上