第五章

　　1、重点用例分析（10分）DFD（10分）、类图（10分）

　　2、建模原则（了解）建模的原则：选择建立什么样的模型对如何发现和解决问题具有重要的影响； 每个模型可以有多种表达方式；最好的模型总是能够切合实际；孤立的模型是不完整的。任何好的系统都是由一些几乎独立的模型拼凑出来的。

　　UML建模（知道）背景：1994年10月，Rational公司的Booch和Rumbaugh决定将其Booch方法和OMT方法综合成一个新的建模语言，并于1995年10月公布了Unified Method 0．8。

　　1995年秋季，Jacobson及其OOSE方法加入Rational公司，决定将OOSE方法与Unified Method进行综合，更名为UML，并分别于1996年6月和10月公布了UML 0．9和UML 0．91。

　　1996年，DEC、HP、I－Logix、Intellicorp、IBM、ICON、MCI、Microsoft、Oracle、Rational、会，于1997 年1 月推出了UML 1．0，并向OMG 申请将其作为一种标准语言。1997 年9 月产生了UML 1．1，11 月被OMG 正式采纳。1999 年6 月，OMG 发布了UML 1．3。1999 年7 月，UML RealTime 随Rose RealTime 推出。2001 年9 月，OMG 发布了UML 1．4。 2004 年4 月，OMG 发布了UML 1．5。2005 年7 月，OMG 发布了UML 2．0。

　　用例：描述了一系列执行的活动所产生的一些输出结果。每个用例描述了外部用户如何来触发系统必须响应的事件。在事件驱动模型中，系统的一切行为都被认为是对某个触发事件的响应。

　　相关：用例是由外部用户触发；每个用例只描述单独的任务，而不能描述多个任务；用例必须产生一个对用户有意义的结果；场景（Scenario）是用例的一个执行实例，是例执行；过程中的一条实际路径，一个用例可能会包含多个场景；

　　UML中的用例视图只能反映出两类信息：

　　1）哪些外部用户会和统发生交互

　　2）系统需要实现哪些功能特性

　　基本信息：

　　1）每个用例都有一个名称、编号和简要描述。为了明确标识某些用例在整个系统中的相对重要性，需要使用优先级来表示。用例（use case）是一个行为上相关的步骤序列，代表的是一个相对完整的业务任务。UML中的用例是动作步骤的集合。动作（action）是系统的一次执行（能够给某个参与者输出结果值）。与参与者通信，或进行计算，或在系统内工作都可以称作动作。用例应支持多种可能发生的动作，每个动作由许多具体步骤实现。

　　2）用例的元素：参与者是存在于系统之外并与系统交互的人或事。所谓“与系统交互”指的是参与者向系统发送消息，从系统中接收消息，或是在系统中交换信息。参与者是一个群体概念，代表的是一类能使用某个功能的人或事，参与者不是指某个个体。

　　3）输入和输出每一个用例的主要输入、输出连同其来源和目的都要进行描述。它包括所有可能的输入输出，而不仅仅是用来通常用的部分。建造用例是一个逐渐提炼的过程，用例在分析的过程中可以逐步的完善。

　　4）细节：用例需要描述详细的步骤和它们所使用到的输入和输出，这些步骤就是用例中所执行的活动。