标准建模语言UML在UML中.PPT

UML ——Unified Modeling Language 什么是UML 作为一种语言，UML定义了一系列的图形符号来描述软件系统。 UML是一个通用的可视化建模语言，是用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。 UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域及各种开发工具。 UML的特点 统一的标准 面向对象 概念明确，建模表示法简洁，图形结构清晰，可视化、表示能力强大，容易掌握和使用。 独立于过程。 UML的统一 UML发展 UML由OMG与1997年11月批准为标准建模语言。2003年，2.0版得到了最终的批准。 UML建立在当今国际上最有代表性的三种面向对象方法（Booch方法，OMT方法，OOSE方法）的基础之上。 标准建模语言UML 在UML中，从任何一个角度对系统所作的抽象都可能需要用几种模型图来描述，而这些来自不同角度的模型图最终组成了系统的完整模型。一般而言，我们可以从以下几种常用的视角来描述一个系统： 系统的使用实例：从系统外部的操作者的角度描述系统的功能。 系统的逻辑结构：描述系统内部的静态结构和动态行为，即从内部描述如何设计实现系统功能。 系统的构成：描述系统由哪些程序构件所组成。 系统的并发性：描述系统的并发性，强调并发系统中存在的各种通信和同步问题。 系统的配置：描述系统的软件和各种硬件设备之间的配置关系。 Architecture Views UML 的主要图示构成 标准建模语言UML UML模型图（主要模型）： 用例图 静态图（类图，对象图，包图） 行为图（状态图，活动图） 交互图（顺序图，合作图） 实现图（构件图，配置图） UML——图 Use case diagram Activity diagram Sequence diagram Collaboration diagram Class diagram Statechart diagram Component diagram Deployment diagram 两种分析方法 Use Case Diagram 参与者 Actor Actor—定义 An Actor is someone or something outside the system that interacts with the system. Actor—识别参与者 参与者代表在系统边界之外的真实事物，并不是系统的成分 参与者透过系统边界直接与系统交互，参与者的确定代表着系统边界的确定 交互是有意义的 参与者可以是任何事物 Actor—识别思路 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 时间、气温等内部外部条件 案例1：航空售票系统 需求： 建立一个航空公司的机票预定系统，让客户通过电话或网络买票、改变订票、取消订票、预定旅馆、租车等等。 案例1：航空售票系统 案例2：库存管理系统 某汽车制造厂需要一套库存管理系统，该系统实现的业务：生产工人根据生产计划领取物料，库存操作员根据生产系统的派单准备，交付给领料工人，余料即时归还库房。库房管理人员定期盘点库存，通知供应商供货，对长期积存的货物，申请退货。 识别思路： 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 时间、气温等内部外部条件 用例 Use Case 换句话说： Actor 使用这个系统达到什么目标？ 以用例为核心组织需求 Use Case—定义 对一组动作序列的描述，系统执行该动作序列来为Actor产生一个可观察的结果值。 用例：用户视角的需求组织形式 用例：需求按目标组织 用例：取款 基本路径 用户插入ATM卡 系统要求输入密码 用户输入密码 。。。 。。。 系统显示交易结束 扩展路径 3a. 用户输入密码错误 系统要求重新输入密码 用户重新输入密码 如果重新输入次数大于3，吞卡。 补充说明 连接账户时间小于60秒 在远程失败的情况下，保障可靠的恢复。 Use Case—识别用例 Actor希望系统提供什么功能 系统是否存储和检索信息，如果是，这个行为有哪个Actor触发 当系统改变状态时，通知参与者吗 存在影响系统的外部时间吗 思考：航空售票系统用例 关系 参与者与用例之间 关联关系 用例与用例之间 包含关系 (includ