系统分析与设计第2章讲义.ppt

§ 2.3.3 分析阶段类图的构建 三、 组织类并确定其关系　 第一步，确定关联关系及多重性。 第二步，识别继承：自顶向下或自底向上。 第三步，考虑是否存在聚合或组合关系。 第四步，对于复杂的系统，用包图为其建模。 2.3.4 在线销售系统类图分析示例 候选类的数据字典 §2.3.4 在线销售系统类图分析示例 在线销售系统 的分析类图 § 2.4 用例分析 软件开发过程中，首先需要明确客户对系统的需求是什么，即系统应该做什么。 例建模是从用户的角度、以用户可理解的方式描述系统需求，是从外部视角来描述系统行为的过程。 用例建模是用于描述系统应该做什么的建模技术，它是从用户的角度、以用户可理解的方式描述系统需求，是从外部视角来描述系统行为的过程。 § 2.4.1 用例元素的确定 用例图主要由下述3种建模元素组成： 　　参与者（actor) 　　用例（use case） 　　关系 还可以有：注释和约束，包，系统边界框。 § 2.4.1 用例元素的确定 一、参与者 参与者，Actor，是与系统交互的实体，包括需要和系统交换信息的一切实体。 1.参与者的表示 2.参与者与角色 （1）参与者代表角色 （2）角色不是对职位建模． 3.参与者的类型 （1）主要参与者它使用系统的主要功能，并驱动系统需求。 （2）次要参与者：处理系统的辅助功能。　　 § 2.4.1 用例元素的确定 二、用例 用例本质上是用户需求的描述，是一个具体的用户目标。 1.用例的表示 用例用一个水平椭圆表示，用例名称可在椭圆的上部、内部或下部。用例名称是一个字符串，应该采用简短的动词短语字。 2.用例的特征 　　用例是从用户的角度考虑系统做什么。 　　用例是对系统行为的描述。 　　用例的执行结果对参与者来说应该是有意义的。　　 § 2.4.1 用例元素的确定 3.用例与场景（脚本） 例，如表2-5所示，小张通过银行ATM机取款2000元的场景，是“取款”用例的一个实例。 § 2.4.1 用例元素的确定 4.用例的描述 （1）事件流 事件流就是用例所包含的一组动作序列。 （2）通常使用类似下面的模板来进行用例描述 X.1 用例ID号及用例名 X.2 用例概述 X.3 参与者 X.4 前置条件（Pre-Conditions） X.5 后置条件（Post-Conditions） X.6 事件流 X.6.1 基本事件流（Basic Flow） X.6.2 扩展事件流（Alternative Flows） § 2.4.1 用例元素的确定 三、关系 1.参与者与用例之间：关联关系 2.参与者与参与者之间：继承关系 3.用例之间存在的关系分为三种： （1）继承关系 （2）包含关系（Include） （3）扩展关系（Extend） §2.4.2 分析阶段用例图的建造 构建用例模型，具体步骤如下： 　　确定系统的边界和范围 　　识别系统参与者 　　发现用例 　　描述用例及确定用例关系 　　建立用例图 　　定义用例图的层次结构 §2.4.3 在线销售系统用例分析示例 在线销售系统用例图 §2.4.3 在线销售系统用例分析示例 100.1 用例ID号及用例名 Uc_100 “下订单”用例描述 100.2 用例概述 该用例描述一个在线商务系统中，会员提交一份商品订单，系统验证会员信息及商品可用性，将各条目加入订单中，会员支付后，系统生成订单。 100.3 参与者： 会员 101.4 前置条件 会员登录 100.5 后置条件 订单被记录下来并定向到订单处理部门。 100.6 事件流 100.6.1 基本事件流 会员请求输入新订单。系统产生商品目录。 会员选择购买项（商品）以及数量。系统显示会员的个人信息（送货、收费地址）。会员验证信息。Ｅ－１系统验证会员订购的每个项（商品）的可用性，获取会员价格及订单总额。并显示订单总结。会员验证订单。Ｅ－２系统提示会员选择支付方式。会员选择支付方式并支付。Ｅ－３系统记录订单信息，生成一个订单确认，显示给会员，并通过电子邮件发送给会员。 100.6.2 扩展事件流 Ｅ－１（替代第５步）：如果需要修改，会员修改送货地址、收费地址，系统验证修改，存储。Ｅ－２（替代第７步）：如果订单需要修改，会员可以删除不需要的项目或修改订购数量等等，一旦会员完成修改，系统继续处理订单，转到（第６步）。如果会员选择继续购买转到第３步。Ｅ－３：（替代第９步）：如果付款不成功，系统通知会员并请求其他支付方式。如果会员不能同时选择其他支付方式，会员可以选择取消或挂起订单。如果会员选择挂起订单，系统把订单设置为挂起状态，系统返回主页面。如果会员选择取消订单，系统清除输入信息，返回主页面，终止用例。 § 2.5 包图 包是用来对模型元素分组的。 在对一