1 / 61

3. 软件设计与 UML 简介

3. 软件设计与 UML 简介. 目录. 3.1 面向对象的分析 3.2 UML 简介 3.3 UML 常用的图 用例图 类图 交互图、状态图、包图. 3.1 面向对象的分析. 分析面临的主要问题. • OOA 与 OOD 的界限 • 对问题域和系统责任的理解 • 人与人之间的交流 • 需求的不断变化 • 软件复用的要求. OOA 与 OOD 的界限.

alayna
Télécharger la présentation

3. 软件设计与 UML 简介

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 3.软件设计与UML简介

  2. 目录 • 3.1 面向对象的分析 • 3.2 UML简介 • 3.3 UML常用的图 • 用例图 • 类图 • 交互图、状态图、包图

  3. 3.1 面向对象的分析 分析面临的主要问题 • OOA与OOD的界限 •对问题域和系统责任的理解 •人与人之间的交流 •需求的不断变化 •软件复用的要求

  4. OOA与OOD的界限 • OOA：运用面向对象方法，对问题域和系统责任进行分析和理解，找出描述问题域和系统责任所需的对象，定义对象的属性和操作以及对象之间的关系，建立一个符合问题域，满足用户需求的OOA模型。 • OOA不考虑与系统具体实现有关的因素，而将其留给OOD去处理，因此OOD包括两方面的工作： 1）根据实现条件对OOA模型作某些必要的修改和调整。 2）针对具体实现条件，建立人机界面、数据存储和控制驱动等模型。

  5. 问题域和系统责任 • 软件分析人员必须尽快了解和明确： • 1）问题域---被开发系统的应用领域，现实世界中， 要求系统处理的业务范围。 • 2）系统责任---所开发的系统应该具备的功能。 • 问题域不等于系统责任，但它们有很多重合部分 问题域 系统责任 金融业务 个人储蓄 代发工资 收费业务 贷款业务 办公管理 数据备份

  6. 人与人之间的交流 • 交流包括三部分人员之间： • 1）开发人员与用户（需求方） • 2）开发人员之间 • 3）开发人员与管理人员 • •交流工具包括谈话和文档 • 用户文档，技术文档，管理文档

  7. 需求的不断变化 • 树立“需求变化是绝对的”的观念，从分析到设计，始终注意“易维护修改”这一原则。 • 需求变化时，最容易变化的是系统功能。在面向对象方法中，最容易变化的成分是对象中的操作，其次是对象间的交互与协作，第三是对象的属性。对象本身是相对稳定的。 • 隐蔽内部操作，抽取高层类，可以使系统稳定且易于应对需求变化。

  8. 3.2 UML简介 • UML中文：统一建模语言 • UML全称：Unified Modeling Language • UML是一种定义良好、易于表达、功能强大的建模语言 • UML使用图形和文字来传递信息

  9. UML是什么 中国公民 身份证 姓名 性别 民族 出生日期 住址 编号 签发日期 有效期限 签发单位 1 0..* 银行卡 1 1 卡号 开户行地址

  10. UML能为我们做什么 • UML可以做软件需求分析 • UML可以做软件开发设计 • UML可以做系统部署设计 • UML也适用非软件领域的系统建模如企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。

  11. UML的发展和工具 • UML 1.0是在1997年完成 • UML 2.0是在2003年完成 • UML还在不断的完善和发展中 • 能绘制UML图形的工具主要有 Rational Rose PowerDesigner MS Visio ArgoUML StarUML

  12. 概述 • 用例图 • 静态图（类图，对象图，包图） • 行为图（状态图，活动图） • 交互图（顺序图，协作图） • 实现图（组件图，部署图）

  13. 用例图 用例图描述系统提供的功能单元。 • 参与者 • 用例 • 关联关系 • 依赖关系 • 继承关系

  14. 用例图 老师在线答疑系统需求描述 • 一个用于老师和学生之间进行即时沟通的系统。 • 系统由老师使用的老师端，学生使用的学生端和一个有公网地址的登陆服务端组成。 • 老师登陆系统后会在老师列表中出现，并显示出他的专业、姓名、专长和状态是否忙等信息。也可以看到其他所有登录的老师的信息。 • 学生登陆后可以看到所有已经登录的老师列表。 • 学生可以选择一个不忙的老师进行问题咨询，和选择的老师建立连接后就可以通过语音加白板和老师进行交流。此时其他学生将看到该老师处于忙的状态。

  15. 用例图

  16. 用例图

  17. 类图 类图表示不同的实体（人、事物和数据）之间的关系；换句话说，它显示了系统的静态结构。 • 类 • 聚合 • 继承

  18. 类图 • 通信协议中的数据包定义

  19. 类图 • 老师和学生类的抽象

  20. 类图 • 学生登陆类图

  21. 类图 • 老师登陆类图

  22. 包图 包图能将复杂系统拆分成多个简单的系统。 • 包 • 依赖

  23. 包图 系统的顶层包结构

  24. 包图 老师在线答疑系统包结构图

  25. 状态图 状态图表示某个类所具有的不同状态和状态转移时的触发条件。 • 状态 • 转移

  26. 状态图 • 老师在线状态图

  27. 活动图 活动图用来描述工作的流程，对并行的工作流程能很好的支持。 • 活动 • 转移 • 同步

  28. 活动图 老师登陆系统

  29. 顺序图 顺序图用来描述对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。 • 对象 • 消息

  30. 顺序图 • 学生登陆系统顺序图

  31. 协作图 协作图用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图和协作图都用来描述对象间的交互关系，但侧重点不一样。顺序图着重体现交互的时间顺序，协作则着重体现交互对象间的静态链接关系。 • 对象 • 链接

  32. 协作图 学生登陆协作图

  33. 组件图 组件图显示软件组件之间的依赖关系。一般来说，软件组件就是一个实际文件，可以是源代码文件、二进制代码文件和可执行文件等。可以用来显示编译、链接或执行时构件之间的依赖关系 • 组件 • 依赖

  34. 组件图 老师在线答疑系统组件图

  35. 部署图 配置图显示系统运行时刻的结构，显示系统不同的组件在何处物理地运行，以及它们将如何彼此通信 • 结点 • 连接

  36. 部署图 老师在线答疑系统部署图

  37. 面向对象的分析模型 目标：用规范的面向对象图表和文字来描述所要建造的软件系统，以便在用户与系统分析人员之间达成共识，同时使后续工作得以继续。 内容： 需求描述 Use Case 用况图 基本模型 Class类图 辅助模型 Sequence 交互图 Collaboration 协作图 State Transition 状态转换图 Component 包图 对象层 关系层 特征层 详细说明

  38. 面向对象的分析过程 建立Use Case 建立Class 发现对象 详细说明 原型开发 定义属性与服务 建立结构与连接 定义：顺序图、 协作图、状态图 分析过程中各个步骤不要求按固定顺序进行。所以，面向对象的分析步骤经常被叫做“活动”。

  39. 3.3 UML常用图 • 用例图（Use Case） 作用：用于对系统的功能，以及与系统进行交互的外 部事物建模。 目的：通过寻找与系统交互的外部事物，说明他们与系统如何交互，可以使用户和开发者，对系统的理解达成共识。 建立Use Case，从系统边界入手： 系统边界，是指系统成分与系统以外事物的分界。而系统暂时是由一条边包围起来的未知空间，因此，建立Use Case是从与未来系统进行交互的人员、设备或其他系统开始的，称之为“参与者”。

  40. 参与者定义：一个参与者定义了一组在功能上密 切相关的使用角色。当一个事物与系统交互时，该事物可以扮演这样的角色。 例1： 例2： 信息录入角色 检查商品角色 信息利用修改角色 验证顾客信用卡角色 商场收款员 操作员 打印报告角色 收银角色 参与者可以请求系统提供服务，也可以接受系统的要求，并做出响应。参与者不是系统的一部分，它们位于系统之外。

  41. 参与者继承关系定义：如果一组参与者有共同的性质，把这些性质抽取在一个参与者中，这组参与者再从中继承。参与者继承关系定义：如果一组参与者有共同的性质，把这些性质抽取在一个参与者中，这组参与者再从中继承。 例： 表示： 客户和网站职员对系统的请求是部分相同的。 网站访问者 客户 网站职员

  42. 如何识别参与者？ 从人员、设备和外部系统三个方面考虑。 设备不包括系统内容设备，如显示器、键盘、鼠标等标准接口设备，而是指系统之外的系统使用设备，例如：传感器、受控马达等。 一些指导性策略： • 谁是系统的启动者？ • 怎样使用系统？ • 系统的责任是什么？ • 哪些参与者具有共同的行为？

  43. 用例定义：一个用例描述系统的一项功能，把这样的功能描述为一组动作序列，为参与者产生可观察的结果，其中的每个序列表示参与者与系统本身的一次交互。用例定义：一个用例描述系统的一项功能，把这样的功能描述为一组动作序列，为参与者产生可观察的结果，其中的每个序列表示参与者与系统本身的一次交互。 用例（CASE）要点： • 用来描述系统外在的、可见的功能需求； • 只描述做什么，不描述怎么做； • 多数是由参与者发起的动作，但也有由系统发起的动作。例如：异常情况处理。

  44. 用例只描述做什么，而不应描述怎么做。 做什么 怎么做 怎么做 做什么 数据检索 插入卡 计算 输入密码 成绩统计 提取现金 排序 输入金额 …… ……

  45. 用例之间存在三种关系： • 包含关系《include》：描述用例间具有的重复行为 • 扩展关系《extend》 ： 描述用例间可选的公用行为 • 继承关系 ：用例间的继承关系描述 《include》 《extend》 成绩登记 密码验证 制定定单 请求目录 《extend》 《include》 成绩统计 检索定单 发货处理 农副产品发货处理

  46. 用例说明： 对有必要说明事件的用例，可以给出详细的说明。 收款 输入本次收款的命令； for顾客选则商品 输入商品号； if 选择商品多于一件 商品数量+1 end if 检索商品名称及单价 减商品存量 if 商品存量低于下限 告警商品存量不足 end if …… 收款

  47. 捕获用例的原则 1）一个用例只描述一个功能，但用例功能不能 太笼统。 太笼统的系统功能划分 企业信息系统 生产管理 供销管理 人事管理

  48. 2）一个用例是在一个相对完整的时间段中发生 的，应尽量避免一个用例涉及多个时间段。 3）一个参与者可以对应多个用例，一个用例也可以对应多个参与者。 参与者与用例 销售业务 不在一个时间段的用例 销售人员 客户信息查询 订货与退货管理 销售部经理 日结算

  49. 4）用例不是界面，界面也不是用例。一个用例可以对应多个界面，一个界面也可能对应多个用例。4）用例不是界面，界面也不是用例。一个用例可以对应多个界面，一个界面也可能对应多个用例。 订单处理系统用例 查看订货目录 定单 界面 客户 订货 取消订单 签定合同 界面 客户代理 查询订单状态 签定合同 职员 汇总销售报表 计算运费

  50. 用例表示举例：研究生教务系统 对登录、选课，以及查学分功能用例描述的四种表 示，描述了四种不同的工作方式。 用例图1： 《 include 》 选课 研究生 登录 《 include 》 查学分 说明研究生在登录后，有两个功能是被反复使用的。两个功能作为登录主程序的从属功能，并且都是必须要执行的功能。从处理逻辑上看有问题。

More Related