第7章UML建模.ppt

* * * * * * * * * * * * * 电梯控制器状态图 1 5 9 7 8 6 2 4 3 10 6.5.1 状态图 或关系的子状态 　　嵌套状态图　 状态图可能有嵌套的子状态图，且子状态图可以是另一个状态图。子状态又可分为两种：“与”子状态和“或”子状态， 与子状态及或子状态 前进 后退 低速 高速 运行 向前 向后 行使 7.3.4 活动图 活动图可以用于需求获取、分析和设计的工作流中，最常用于把用例建模为一系列的动作。 适合描述系统中多个对象跨多个用例的活动顺序。 普通活动图示例 活动图的模型元素 活动还有其它的图符：初态、终态、判断、同步。 初态 终态 [条件1] [条件2] 判断 同步线 活动 转移 　　转移描述活动之间的关系，描述由于隐含事件引起的活动变迁，即转移可以连接各活动及特殊活动（初态、终态、判断、同步线）。 　　转移用带箭头的直线表示，可标注执行该转移的条件，无标注表示顺序执行。 例：一个网上商店处理顾客订货的活动图示例，如图8.1所示。 Home 活动图 分划活动图示例 取款用例的活动图 动作状态 活动状态 动作流 泳道 泳道（Swimlance）代表对象对活动的责任。 泳道把活动图中的活动划分为若干组，并把这些组指定给对象，这些对象必须履行该组所包括的活动。泳道明确表示哪些活动是由哪些对象进行的。 在活动图上泳道用垂直实线划出，垂直线分隔的区域就是泳道。在泳道上方给出泳道的名字或对象（对象类）名字，该对象（对象类）负责泳道内的全部活动。 活动图 7.4 售票系统UML建模 7.4.1业务简述 剧组排练好剧目后，售票中心对外宣传并通过多个售票终端进行售票。 顾客可多次买票或订票，但每一次买票或订票只能由一个顾客来执行。票分两种：个人票或团体票；前者只是一张票，后者包括一或多张票。每一张票不是个人票就是团体票中的一张，但是不能又是个人票又是团体票中的一张。 顾客可采用两种途径买票：一种是通过售票中心，另一种是通过自动售票机，但订票只能通过售票中心。另外，买个人票可以通过售票中心，也可以通过自动售票机，但买团体票只能通过售票中心。 买票和订票都支持现金和信用卡两种结账方式。 每场演出都有多张票可供预定，每张票对应一个唯一的座位号。 在票开始对外出售前，一部分票是给订票者预留的。当顾客预定票后，被预定的票处于锁定状态，此时顾客有是否确实要买这张票的选择权，故这张要票可能出售给顾客也可能因为顾客不要这张票而解除锁定状态。如果超过了指定的期限顾客仍未做出选择，此票被自动解除锁定状态。订票者也可以换其他演出的票，此时，预留票可以对外出售 。 售票系统用例图 7.4.2 用例建模 1.类图 订票类图 * 1 -time:Date Time 7.4.3 静态建模 2.部署图 售票系统部署图 1.活动图 排练剧目活动图 7.4.4 动态建模 2.顺序图 自动售票机买票顺序图 3．状态图 票对象的状态图 7.5 使用和扩展UML 使用UML的准则 1.不要试图使用所有的图形和符号 应该根据项目的特点，选用最适用的图形和符号。一般来说，应该优先选用简单的图形和符号，例如，用例、类、关联、属性和继承等概念是最常用的。 2.不要为每个事物都画一个模型 应该把精力集中于关键的领域。最好只画几张关键的图，经常使用并不断更新、修改这几张图。 7.5 使用和扩展UML 3. 应该分层次地画模型图 根据项目进展的不同阶段，用正确的观点画模型图。如果处于分析阶段，应该画概念层模型图；当开始着手进行软件设计时，应该画设计层模型图；当考察某个特定的实现方案时，则应画实现层模型图。 使用UML的最大危险是过早地陷入实现细节。为了避免这一危险，应该把重点放在概念层和说明层。 4. 模型应该具有协调性 模型必须在每个抽象层次内和不同的抽象层次之间协调。 7.5 使用和扩展UML 5. 模型和模型元素的大小应该适中 过于复杂的模型和模型元素难于理解也难于使用，这样的模型和模型元素很难生存下去。如果要建模的问题相当复杂，则可以把该问题分解成若干个子问题，分别为每个子问题建模，每个子模型构成原模型中的一个包，以降低建模的难度和模型的复杂性。 * * * ** * * * * * * * * 顺序图的组成 序号为消息在整个交互中的顺序号。可以是正整数1，2，3，也可以是1.1,1.2,2.1。 保安条件（Guard Condition）是一个布尔条件表达式。只有当其保安条件被满足时才能发送该消息。保安条件可以缺省，表示该消息是无条件发送的。 循环说明规定该消息发送的重