信息系统分析与设计PPT.ppt

Method 1 用例模型 概念模型 为概念模型添加关联 为概念模型添加属性精化术语表系统行为建模——系统顺序图系统行为建模——契约 术语表示例 术语 分类 注释 Buy Items 用例 描述顾客在商店购买商品的过程 ProductSpecification:Text 属性 对待售的一项商品的简短描述，以及与它相关的产品规格说明 Item 类型 商店中的一项待售商品 Payment 类型 一次支付的金额 ProductSpecification.price:Quantity 属性 一次商品在销售交易中的价格，以及与它相关的产品规格说明 SalesLineItem.quantity:Interger 属性 所购买的同种类商品的数量 Sale 类型 一次销售事务 SaleLineItem 类型 某个特定商品在一个销售项中的记录行 Store 类型 销售交易所在的场所 Sale.total:Quantity 属性 销售项的总金额 Payment.amount:Quantity 属性 顾客在一次交易中所支付的金额 ProductSpecification.upc:UPC 属性 商品的通用产品代码和它的产品规格说明 详细分析 白盒法 黑盒法 灰盒法 系统行为建模——系统顺序图 为什么在分析阶段建立系统顺序图 什么是系统顺序图(对UML顺序图的本地化) 交互的图示 顺序图（突出消息的时间顺序） 协作图（突出交换消息的对象间的关系） 系统顺序图(system sequence diagram)展示了在一个用例的特定的事件发生过程中与系统直接发生交互的外部参与者、系统以及参与者所发起的系统事件等。 基于过程设计与基于对象设计的区别！！！ 购买商品用例的系统顺序图： 1．将系统表示为一个黑盒子，在盒子下面划一条线。 2．识别出所有直接对系统进行操作的参与者。在每个参与者下面划一条线。 3．根据用例的典型事件发生过程的描述，找出每个参与者所发起的（外边）事件。将它们标在图中。 4．用例的描述文本放在顺序图的左边，这是任选的部分，也可以没有。 如何建立系统顺序图 识别系统事件和系统操作的几个关键点 关键一：系统边界 系统边界 传统方法在设计时才进行边界确定！ 关键二：如何命名系统事件和系统操作 系统操作应被记录下来 所有需要执行的系统操作都可以根据系统事件识别出来。这正是迭代开发的精髓。 system endSale() enterItem() makePayment() 系统行为建模——契约 契约 通过描述一个系统被调用后状态的变化情况来描述系统对外界的接口和系统行为。 契约依赖于： 概念模型、系统顺序图、和系统操作的定义等。 契约 名称 操作和参数的名字 职责 对这个操作所履行的职责的非形式化描述 类型 类型的名字（概念、软件类、接口） 交叉引用 所引用的系统功能好、用例等 注释 设计注释、算法注释等 异常 发生的例外情况 输出 非UI输出，例如向系统外部输出的消息或记录等 前置条件 在操作执行前对系统状态所做的假设 后置条件 操作执行完成后系统的状态 契约段采用如下模式： 如何建立一个契约 1．根据系统顺序图识别出每个系统操作； 2．为每个系统操作，建立操作的契约； 3．从职责段开始书写，描述该操作的目的，可以采用非正 规描述形式； 4．然后完成前置条件段的内容，声明性地描述概念模型中 的对象由于执行系统操作而引起的状态的变化； 5．最后完成后置条件段，根据以下几个类别来描述： ◇实例创建和销毁； ◇属性的修改； ◇关联的形成和销毁。 契约的后置条件 1．后置条件是在系统操作已经完成后对系统所处状态的陈述。 2．后置条件的分类： ◇实例的创建和销毁； ◇属性的修改； ◇关联的形成和破裂。 3．后置条件和概念模型相关。 4．使用后置条件的优点： 后置条件将确定软件设计和解决方案向后推迟，使我 们能够集中精力分析系统发生了什么而不考虑是如何 发生的。 后置条件的核心──舞台和帷幕 可以认为整个系统和系统中的对象在一个舞台上演出，从而用 Snapshot的方式来考察契约的后置条件： 1）操作执行之前，给舞台拍照一次； 2）拉下舞台上帷幕，然后执行系统操作（伴随着观众的鼓掌、大叫、嚎叫等的背景声音）； 3）拉起舞台上的帷幕，再给舞台拍照一次； 4）比较前一张和后一张照片，然后用后置条件来表达舞台状态的变化。（A SalesLineItem was cteated……） 用过去式表达后置条件，能够强调出后置条件描述的是过去的状态变化