5-3信息系统设计.ppt

第五章信息系统设计 3 教学目的 学习完本章本部分后 学生应该能够 了解设计阶段的基本任务 主要活动及内容学习基于类图 交互图 状态图等的面向对象的设计方法学习信息系统的数据库设计学习信息系统的控制 输入和输出设计学习信息系统的人 机交互设计 教学内容 数据库设计 用户界面设计 系统设计概述 系统架构设计 设计类图 控制机制设计 综述设计中的类图设计中的交互图 设计类图 综述 1 详细设计设计活动包括类 类之间关系和类交互的详细定义 模型应该包括足够的信息 使得它们能被用作程序的定义 对类图重新审视 以便讨论在本阶段我们可能需要增加的类 例如管理界面和控制执行序列的类 在分析阶段没有特别关注的类的事情 如类之间的关联 类的可见性 属性和操作等技术细节 现在需要详细地确定 我们重新审视交互图来讨论如何建模对象的产生和删除 以及如何规定条件和控制 综述 2 设计中类图vs 分析中类图区别之一是模型的详细程度在分析中 交付的模型保持简洁和避免实施的决定 这使得图形不混乱 因此容易阅读和同客户讨论 同时也避免了不成熟的实施决定 在分析中 焦点是在组织做什么 以及它要新系统做什么 在分析类图中 大多数的类是实体类 即它们对问题域中的特征进行建模 在分析中可以开始确定边界和分析类 但对这些类的详细考虑主要是设计和实施的活动 综述 3 设计类随着我们逐渐接近编码 我们需要作出和记录关于实施的决定 详细地设计活动包括 增加类 诸如界面 控制和容器类 以便帮助交付解决方案详细定义类之间的联系定义属性和操作的可见性详细定义属性详细定义操作将控制和界面功能从实体类的信息和表现中分离开来的原因之一是孤立变化的影响 例如 对界面如何工作地改变不应该影响实体类 综述 4 设计类图设计类图是类图的另一形式 其带有描述类图内部设计部件的符号 设计类图详细描述了类的属性 以及定义传递到方法的参数 从方法返回的参数和每个方法的内部逻辑 设计类图非常类似于分析阶段的类图 但更详细 见图5 30在设计阶段 根据需要可以增加必要的新过程 如类方法 ListLargeAccount 在设计阶段 也可以根据需要增加新的属性 例如 表示同其它类对象的属性 增加一个对象指针域或插入一个外键域表示类状态的属性 见图5 31 综述 5 设计类图的组成与表示类名称 超类名称和 标识符 表示一个设计类 属性列表 属性的表示形式 可见性 表示可见 表示不可见 属性名称类型表达式 字符 字符串 数字 货币或日期等 初始值方法列表 方法的表示形式 方法标志方法的过程见图5 32 综述 6 方法的标志由方法名称 类型表达式 方法返回参数的类型 和方法参数表 输入参数 组成 方法重载 一个类的方法可以有若干个相同名称的版本 并利用不同的参数表来区分或确定 设计类图的扩展形式中 方法标志放在输入箭头处 方法的过程过程信息主要由状态图获得 故类似于状态图的表示图5 33方法与消息在状态图中 状态的转变是由消息触发的 因此 在序列图中发现的消息必须在状态图中有对应的转换 如果没有 状态图则缺乏定义处理消息的方法 见图5 34 综述 7 设计类图的绘制过程绘制是基于分析阶段的类图 序列图和状态图 绘制步骤 选择一个要设计的类 尽可能地列出属性 并表示可见性 找出该类所有的方法 分析整个序列图 找出到该类的所有消息 进而发现所有的方法 利用可获得的信息尽可能详细地描述设计类 包括消息名称 传递的参数和返回的参数 见图5 35 详细描述方法的逻辑 利用该类的状态图获取必要的信息 增加必要的类 1 边界和控制类边界类处理系统同用户的界面 例如它们被用来将用户的菜单选择转换成发送给一个对象的消息 一般地 每个用例有一个界面类和一个控制类 控制类处理在用例执行中的事件的序列 图5 36表示了 Maintainbikelist 用例中 Addbike 场景的协作图 我们已经添加了一个控制对象 MaintainBike 和一个界面对象 MaintainBikeUI到 Maintainbikelist 的协作中 在这个场景执行中的事件序列是被用户发送给控制类的消息 通过高层次的 MainMenuUI对象 所激活 然后通过控制类来完全控制的 增加必要的类 2 边界和控制类 续1 在参与者和对象之间的交互是 管理者从欢迎屏幕 主界面 上选择增加自行车选项这一选择传送到 通过一个 MainMenuUI对象 控制对象 MaintainBike MaintainBike 类产生一个新的界面对象 MaintainBikeUI管理者在界面对象的屏幕显示上输入他要增加的自行车的细节 界面对象将这些细节传送到控制对象 控制对象将自行车的细节传送到Bike对象 图5 37用序列图表示了这一交互过程 增加必要的类 3 边界和控制类 续2 实体 边界和控制类被建模成实例 stereotypes 被用来表示实例 见图5 38 注意 在图中显示一个类的实例是非常有帮助的 因为具有许多高进的建模特性 我们可以使用实例标识来增加附加的信息到交互图中 实际上 当我们实现类时 我们往往将控制类和边界类的功能合并到一个类中 见图5 39 然而 为了讨论边界和控制类的用途 我们将它们分别建模 详细定义类之间的联系 1 设计关联当我们设计时 我们需要决定类之间的关系如何实现 在早期的分析类图中 在类Customer Payment Hire和Bike之间的关系简单地反映了现实中的顾客租车交易和付款的关系 租车交易和自行车之间的关系 等等 利用某种方法 如CRC卡片 来确定类的职责和协作给我们提供了这些关联应该如何的更多的概念 到我们进入设计时 从交互图中 我们准确地知道哪个对象需要通讯 以及消息的内容和方向 在类之间的关联定义了实现这些类的对象之间导航路径的需要 我们如何实现一个关联取决于关联的多重性和通讯是单向的还是双向的 详细定义类之间的联系 2 一对一关联图5 40表示了在School类和SchoolLibrary类之间一对一的关联School对象需要能传送消息给SchoolLibrary对象 但反之则不能 这种消息传送的方向被称为关联的导航性 一个方向的关联被称为单向的 导航的方向被箭头所表示 两个方向的导航性既可以用关联两端的箭头表示 又可以都不标注箭头来表示 然而 没有箭头也能意味着导航性还没有规定 如在分析模型中的例子 因此 标识箭头更清楚些 详细定义类之间的联系 3 一对一关联 续1 为了实现一对一关联 School有一个属性library来用于存放它需要通讯的SchoolLibrary对象的对象标识符 或者称为一个指针或引用 在双向关联中 每个类都需要存放一个对于对方的引用 如果在School和SchoolLibrary之间的关联是双向的 School需要存放对SchoolLibrary的引用 而SchoolLibrary也需要存放一个对School的引用 图5 41表示了在界面类MaintainBikeUI和Bike类之间的单向关联 详细定义类之间的联系 4 一对多关联 续2 一个MaintainBikeUI类的对象必须同Bike类的对象通讯 反之不然 一个MaintainBikeUI对象必须能发送消息到一个以上的 Bike对象 有时 它发送消息到一个由bike 确定的特定 Bike对象 有时发送到同一品牌的 Bikes对象 有时发送到所有的 Bikes对象 为了做到这点 MaintainBikeUI必须知道所有Bike对象的标识符 它能利用一个简单的数组来存放这些标识符 然而 它需要操作来管理这个数组 要易于增加 删除 以及发现自行车的标识符 问题是这不是一个UI类的任务 并且其它的类 例如 IssueBikeUI类 也需要同样的功能 它们也需要一组 Bike标识符 以及操作它的代码 因此 产生一个专门存放并操作这些标识符的类将更加有效 这个类被称作集合类 collectionclass 详细定义类之间的联系 5 一对多关联 续1 图5 42表示了一个集合类BikeList 其能根据bike 来发现一个特定的自行车 增加 以及删除自行车 等等 MaintainBikeUI同BikeList有一对一的关联 因此 这一关联能通过在MaintainBikeUI中对BikeList的引用来实现 一个 BikeList将包含一个 Bike引用的表 bike 0 599 在数组中我们从0开始 访问一个特定的 Bike将实现如下 MaintainBikeUI发送一个getBike bike 消息到 BikeList 要求它找到一辆编号为bike 的自行车 BikeList将在 Bikes的表中反复查找看哪个自行车的编号同输入的编号相匹配 找到的 Bike的标识符 identifier 然后返回给 MaintainBikeUI 然后 MaintainBikeUI就能直接发送消息到这个 Bike 这个重复过程被建模 如图5 43中的序列图所示 详细定义类之间的联系 6 一对多关联 续2 换言之 如果一个对象需要发送一个消息 它必须知道如何使消息到达消息接受者 这意味着它必须知道接受对象的标识符 它能按各种不同的方法来做此事 通过在关联中的直接联接 例如在图5 40中 School的属性library保存了SchoolLibrary对象的对象标识符 这在School对象和一个SchoolLibrary对象之间建立了直接的联接 调用对象能够通过另一个已经同目标对象建立联接的对象来发送目标对象的标识符 在图5 43中 属性bikeID被设置成所要求的自行车的对象标识符 即 BikeList找到 Bike的标识符 然后将它返回到 MaintainBikeUI 一个对象标识符可以作为参数由构造器传递给它所产生的对象 例如 在图5 39中 界面对象 IssueBikeUI产生一个新的Payment对象 并将相关的Customer对象的标识符作为参数传递给它 IssueBikeUI也产生一个新的Hire对象 并将Bike和Customer对象引用传递给它 详细定义属性和操作 1 设计属性在设计中 我们需要制定每个属性的定义 一个属性定义的UML形式是 visibilityname type expression initial value例如 deposit Integer 0设计操作我们也需要定义操作操作可以有参数和返回值一个操作定义的UML形式是 visibilityname parameterlist return type例如 findBike bike Integer Bike 详细定义属性和操作 2 设计操作中的方法在详细设计阶段 我们更加关注操作或更加严格考虑实现操作operations的方法 方法逻辑由三部分组成 决策逻辑 if语句 来试验状态变量以保证对象处于正确的状态 过程主体 来自状态图的活动表达式 将状态变量设置成正确值的逻辑 见图5 33 我们的决策可以用一个活动图来记录 或描述过程的技术 结构化英语 决策表 决策树 之一来记录 或者用契约描述来记录 方法设计和伪码一个方法是由一个输入消息所调用 每个同一个消息关联的转换确定一个方法 方法的详细逻辑能够从同转换像关联的活动语句和该转换后面的活动语句的分析中获得 确定方法的范围就是确定哪些活动语句将包括在方法里 方法的逻辑的文本是用伪码来表示 设计中的交互图 1 分析vs 设计在分析中 我们使用交互图的目的是要发现一组对象在用例场景所表示的过程中是如何协作的 在这个阶段 我们仍忽略了类的职责的确定 以及类的操作和对象之间消息的内涵 在设计中 我们关注编码 我们利用交互图主要是给出在程序运行时将会发生什么的一个抽象的视图 为了实现这点 我们需要增加更多的细节到模型中 如何规定对象的产生和删除如何定义条件性行为和重复性行为如何在不同的使用多对象和包的细节层次上使用交互图然而 记住序列图最大的诱惑是其简洁性 因此要慎重地使用额外的标注 如果你在一个序列图中表示了太多的细节 则它失去了它主要的吸引力 设计中的交互图 2 对象产生和删除在一个用例场景的执行过程中 对象没有必要是固定的 新的对象能被产生 已有的对象能被删除 在一个交互中被产生或删除的对象被称短暂transient对象 不是出现在图形的顶部 这种对象的图标在其产生的地方出现 对象析构的表示是在该对象生命线底部的一个大的X 参见图5 44 对象既能自动析构 也能通过接收来自其它对象的消息来删除 例如 PhoneCall对象可能当打电话者挂机时自动析构 或者被交换台掐断 删除 设计中的交互图 3 对象产生和删除 续 图5 44利用序列图表示了在图5 36中协作图同样的交互活动 我们增加了界面对象的析构 当没有更多的自行车被增加时 控制对象 MaintainBike发送一个destroy 消息到界面对象 MaintainBikeUI destroy 消息仅当条件 nomorebikestoadd 为真时发送 重复我们能利用一个重复子句来规定一个消息被发送多少次 我们也能利用多对象图标来表示消息被发送到许多对象 如果我们要定义一系列的消息被重复 我们能通过将消息块框住 并加上一个重复子句来做到这点 在图5 45中 当有更多的自行车被添加时 在矩形中的任何活动被重复 设计中的交互图 4 条件行为和分支在图5 45中 destroy 消息被条件 nomorebikestoadd 所保证 在消息上放置一个保证意味着仅仅在保证条件中的布尔表达式为真时 消息才会发送 UML没有规定书写条件的形式 因此 自然语言 结构化英语 伪码 OCL 对象约束语言ObjectConstraintLanguage 或者编程语言表达式都是可以接受的 序列图允许我们建模条件分支 即根据条件值来发送不同的消息 图5 46表示了一个系统的一个序列图的部分 为了简化 我们忽略了界面对象和控制对象 设计中的交互图 5 条件行为和分支 续 如果一位顾客以前没有租借自行车 接待员必须将其细节输入到系统中 接待员输入顾客的姓名 如果系统发现了一个 Customer带有匹配的姓名 它显示地址 否则一个新的 Customer被产生 这些消息中仅仅一个能被发送 所以条件的互斥性是非常重要的 表示条件行为能够对一个图中一个以上的可能事件序列进行建模 这意味着我们能画较少的序列图 但其缺点是图形变得更复杂 如果我们的图开始变得太复杂了 则可以用不同的图标来表示不同的事件序列 设计中的交互图 6 并行性序列图也能用了对同步的和异步的消息进行建模 到目前为止 我们遇到的所有消息是同步的 当一个对象发送同步消息时 它必须等待它所调用的对象的响应 因此 发送对象不能继续自己的处理 直到获得了一个响应 这是常见的 因为它在等待数据 到目前为止 在任何给定的时间内 我们仅对一个对象进行处理的情况进行了建模 这不奇怪 因为许多信息系统都是单线程 并且设计运行在单处理器的计算机上 然而 在多线程系统 即在一个设计有多个处理器 以并行方式运行的系统 能够对异步消息进行建模时有用的 当一个对象发送一个异步消息时 它调用了另一个对象的操作而不打断它自己的处理 两个对象能并行地处理 这也被称为并行处理 设计中的交互图 7 并行性 续1 在图5 47中 我们对一个十岁左右的小孩chris在学校度过一天后回家进行建模 他非常饿直接走到电冰箱 没有停止他的脚步 或停止他寻找食物 他告诉他的弟弟打开电视机 以便他能看足球 要求他的小妹妹对他微笑一下 并且将他的运动衫脱到地上 告诉他的妈妈需要洗干净 他明天还要穿 所有这些都是异步消息 他开始三个过程 但没有中止他寻找食物的任务 一个异步消息用半箭头来表示 设计中的交互图 8 并行性 续2 注意在图5 47中的另一个新的表示 即在消息washKit kit 上有一个 bytomorrow 的约束constraint 一个约束是关于它所描述的建模元素的一个简单断言 它能加到大多数建模元素上 约束经常附加到类上 例如 我们能加一个约束 hirelimitthreeweeks 到Hire类 如果我们要提出租借长短的时间限制 区别同步与异步消息的能力意味着序列图能被用来对并行处理进行建模 设计中的交互图 9 禁止细节有时 能够在不同的详细层次上看序列图是有帮助的 UML没有特殊的表示来表明某些细节是隐藏在序列图中 然而 当一个交互图变得太复杂时 我们能用一个包来对有结合性的对象进行编组 然后 这个包能被处理成一个单独的对象 一个包外对象发送到包内任一对象的消息被简单地发送到包 在包内的对象之间的消息被禁止 另一个禁止细节的可以接受的方法是简单地加一个注释到一个图表中 表示在这个图中禁止的细节可以在另外的图中发现 设计中的交互图 10 设计时的序列图在图5 39中的序列图表示在分析模型中已经涉及的出租一辆自行车的过程 因为Wheels是一个非常小的系统 取代引入三个新对象 界面对象 控制对象和集合对象 我们增加一个对象 IssueBikeUI 其结合了界面对象和控制对象的功能 IssueBikeUI控制参与者和系统之间的交互 并且控制对象之间消息传递的主要序列 我们已经改变了Bike类 所以它结合了一个集合类和实体类的功能 Bike类包含一个自行车的数组 它知道每一个 Bikes的标识符 设计中的交互图 11 设计时的序列图 续1 执行序列如下所示 在比这个序列图高的层次中 我们假设接待员已经执行了一个出租自行车的菜单选择操作 这导致一个消息被发送到 IssueBikeUI表示顾客选择的自行车的bike IssueBikeUI将bike 传送到Bike 集合类 其重复通过自行车标识符的表 依次发送消息到每个 Bike直到它发现一个编号同bike 匹配 IssueBikeUI然后发送一个消息到那个 Bike 其显示它自己的细节 以便检查是否发现正确的自行车 IssueBikeUI要求参与者要租借多长时间 收集参与者的响应 然后发送一个消息到 Bike 要求它需要多少费用 Bike显示押金 每天的租金和租借特定天数的费用 设计中的交互图 12 设计时的序列图 续2 执行序列如下所示 续 IssueBikeUI等待来自参与者的响应 以了解是否继续租借交易 参与者响应并带有产生一个新 Customer的要求 IssueBikeUI产生一个新的Customer对象 并用参与者传递的值给其属性赋值 IssueBikeUI在产生一个新的Customer对象的同时 自动产生一个新的Payment对象 IssueBikeUI自动产生一个新的Hire对象 并将起始日期设置成当天的日期 将天数设置成步骤3中确定的值 IssueBikeUI然后要求 Payment计算包括租金的总费用 设计中的交互图 13 设计时的序列图 续3 执行序列如下所示 续 Payment打印一个收据 为了做到这点 它要求它的 Customer以获得姓名和邮政编码 以便这些能在收据上打印 然后 Payment为了总费用要求 Bike 以便这也能打印在收据上 注意在图5 39中的序列图中有两个Bike对象图标 在一个序列图中 类的一个对象有多个表示是允许的 在这个例子中 我们用第一个Bike图标来表示Bike作为一个集合类的作用 用第二个图标来表示单个的 带有匹配bike 的Bike对象 从用例场景到分析阶段序列图 再到设计阶段序列图的变化 图5 48 图5 30用于定义一个设计类图的内部符号 简图 CustomerAccount AccountNumber Integer Balance Currency DateOpened Date CustomerID customer AccountState enum Active Inactive OpenLoan NoOpenLoan CreateAccount Integer CustomerID InitialDeposit GetAccount Integer CustomerID MakeDeposit Currency DespoitAmount MakeWithdrawal Currency WithdrawAmount UpdateAccount Boolen CustomerID DeleteAccount Boolen CustomerID ListLargeAccounts 1 000 000 FindOverdueAccount 图5 31客户帐户设计类的简图形式 图5 32用于定义一个设计类图的内部符号 详图 图5 33客