软件开发实习讲义-uml

《软件开发实习讲义-uml》由会员分享，可在线阅读，更多相关《软件开发实习讲义-uml（158页珍藏版）》请在金锄头文库上搜索。

1、引言. 软件工程,软件危机 1.如何开发软件，以满足不断增长的， 日趋复杂的要求。 2.如何维护规模不断庞大的软件产品。 软件工程 软件工程是一门建立在系统化，规范化，数量化等工程原则和方法上的，关于软件开发各阶段的定义，任务和作业的工程学科。包括软件开发技术和软件项目管理,软件工程,1.需求分析阶段 2.系统分析与设计阶段 3.系统实现阶段 4.测试阶段 5.维护阶段,什么是模型？,定义:对问题的书面上的无歧义文字或图形的描述. 最杰出的模型:地图,什么是模型？,简言之，模型是对现实的简化。 （1）一个好的模型包括重要的因素，而忽略不相干的细节。 （2）每一个系统可以从不同的方面使用不同的模

2、型进行描述，因此每个模型都是对系统从语义上近似的抽象。 （3）模型可以是结构的、侧重于系统的组织，也可以是行为的、侧重于系统的动作。,为什么要建模？,软件建模与建模语言,1、模型是软件文档的重要成分 一个开发团队首要关注的不应是漂亮的文档、世界级的会议、响亮的口号或者华丽的源码，而是如何满足用户和项目的需要。 2、建模是软件工程的核心 一个狗窝一间平房一幢大楼 需求模型分析模型设计模型测试模型,建模的目标,通过建模，要实现以下4个目标： （1）便于开发人员展现系统。 可视化visualization （2）允许开发人员指定系统的结构或行为。 详述specification （3）提供指导开发人

3、员构造系统的模板。 构造construction （4）记录开发人员的决策。 文档化documentation,为什么单一视图解决不了问题？,工业化的成功经验是：从多个不同的层次和角度描述一个需要建造的产品。例如，建筑工业有：环境效果图、室内效果图、土建图、结构图、施工图等。,UML (Unified Modeling Language),统一UML最初由Rational软件公司和在这个领域中三个最优秀的方法论学者设计。它代表了这三人的经验和其它行业实践的革命性统一。 建模建模的一个重点是如何理解周围的世界。 语言UML起到了表达和交流知识的目的。,UML 的目标,提供易用的、表现力强的可视化

4、建模语言； 提供可扩展、可定制的核心扩充机制； 不依赖于特定的程序设计语言和开发过程； 提供形式化基础以利于理解建模语言； 促进面向对象工具的市场拓展； 支持高层开发概念（如协同、构架、模式、部件等）； 集成最好的实践经验。,“4+1”视图,各种视图的UML 表示手段,逻辑视图：类图（class diagram）；协同图（collaboration diagram）；序列图（sequence diagram）；状态图（statechart diagram）；活动图（activity diagram）； 进程视图：组件图（component diagram）； 开发视图：组件图； 物理视图：部署

5、图（deployment diagram）； 剧情：用例图（use case diagram）；协同图；序列图。,UML 表示机制的层次结构：,1. 用例图 2. 类图 3. 行为图 3.1. 状态图 3.2. 活动图 3.3. 交互图 3.3.1. 序列图 3.3.2. 协同图,4. 实现图 4.1. 组件图 4.2. 部署图,第一节 用例图,1.1 用例图的概念 1.2 用例图建模技术 1.3 实例图书馆管理系统中的用例图,1.1.1 用例图概述,用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务，用来为系统的功能建模。 用例图最常用来描述系统以及子系统。,用

6、例图,用例图包含6个元素： 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization）,1.1.2 参与者,系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。,参与者的种类：,系统用户 与所建造的系统交互的其他系统 一些可以运行的进程,如何寻找系统的参与者,谁将使用该系统的主要功能 谁将需要该系统的支持以完成其工作 谁将需要维护、管理该系统，以及保持该系统处于

7、工作状态 系统需要处理哪些硬件设备 与系统交互的是什么系统 谁或什么系统对本系统产生的结果感兴趣,参与者间的关系,在用例图中，使用泛化关系来描述多个参与者之间的公共行为。,参与者间的泛化关系示例：,1.1.3用例,用例的概念 外部可见的系统功能单元。 用例的用途是在不揭示系统内部构造的前提下定义连贯的行为，这些行为不但应包含正常使用的各种行为，而且应包括非正常使用时的各种行为。 一个用例代表软件系统功能的划分，代表系统角色和系统的一次交互。 不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。,识别用例,识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系

8、统的。 如何识别用例。 （1）特定参与者希望系统提供什么功能。 （2）系统是否存储和检索信息，如果是，由哪个参 与者触发。 （3）当系统改变状态时，是否通知参与者 （4）是否存在影响系统的外部事件。 （5）哪个参与者通知系统这些事件。,参与者与用例间的关系,关联关系 表示参与者和用例之间进行通信。 不同的参与者可以访问相同的用例。,用例与事件流,事件流是从用户角度描述执行用例的具体步骤。 简要说明：描述用例的作用 前提条件：用例之前必须要满足的条件 主事件流和其他事件流：用例的具体细节 事后条件：用例执行完后必须为真的条件,1.1.4用例间的关系,1 包含关系 2 扩展关系 3 泛化关系,用例

9、间的关系,包含关系 客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。 在具有包含关系的两个用例中，提供者用例不能单独存在，它只能以实例的形式存在于客户用例之中。 包含关系使得一个用例的功能可以在另一个用例中使用。,用例间的关系,扩展关系 扩展用例被定义为基础用例的增量扩展，扩展关系是把新的行为插入到已有用例中的方法。 基础用例提供扩展点以添加新的行为。 基础用例可以独立于扩展用例单独存在。基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。,用例间的关系,泛化关系 父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从

10、父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为。 体现了用例共同行为和特殊行为的关系。,用例间的关系,1.2 用例图建模技术,1.2.1 对语境建模 1.2.2 对需求建模,1.2.1 对语境建模,识别系统外部的参与者。 将类似参与者组织成泛化的结构层次。 在需要加深理解的地方，为每个参与者提供一个构造型。 将参与者放入到用例图中，并说明参与者与用例之间的通信路径。,1.2.2 对需求建模,识别系统的外部参与者来建立系统的语境。 考虑每一个参与者期望的行为或需要系统提供的行为。 把这些公共的行为命名为用例。 确定提供者用例和扩展用例。 对这些用例、参与者和它们之间的关系建模。 用

11、注释修饰用例。,1.3 实例图书馆管理系统的用例图,1.3.1 确定系统涉及的总体信息 1.3.2 确定系统的参与者 1.3.3 确定系统的用例 1.3.4 图书馆管理系统的用例图,1.3.1 确定系统涉及的总体信息,读者： 借书 还书 书籍预定,1.3.1 确定系统涉及的总体信息,图书馆管理员： 书籍借出处理 书籍归还处理 预定信息处理,1.3.1 确定系统涉及的总体信息,系统管理员： 增加书目 删除或更新书目 增加书籍 减少书籍 增加读者帐户信息 删除或更新读者帐户信息 书籍信息查询 读者信息查询,1.3.2 确定系统的参与者,首先分析系统所涉及的问题领域和系统运行的主要任务： 分析使用该

12、系统主要功能部分的是哪些人。 谁将需要该系统的支持以完成其工作。 系统的管理者与维护者。,1.3.2 确定系统的参与者,图书馆管理系统的参与者： 读者（借阅者） 图书馆管理员 图书馆管理系统维护者,1.3.3 确定系统的用例,1. 借阅者请求服务的用例 2. 图书馆管理员处理借书、还书等的用例 3. 系统管理员进行系统维护的用例,1. 借阅者请求服务的用例,登录系统 查询自己的借阅信息 查询书籍信息 预定书籍 借阅书籍 归还书籍,2. 图书馆管理员处理借书、还书的用例,处理书籍借阅 处理书籍归还 删除预定信息,3. 系统管理员进行系统维护的用例,查询借阅者信息 查询书籍信息 增加书目 删除或更

13、新书目 增加书籍 删除书籍 添加借阅者帐户 删除或更新借阅者帐户,1.3.4图书馆管理系统的用例图,1. 借阅者请求服务的用例图 2. 图书馆管理员处理借书、还书的用例图 3. 系统管理员进行系统维护的用例图,1. 借阅者请求服务的用例图,2. 图书馆管理员处理借书、还书的用例图,3. 系统管理员进行系统维护的用例图,第二节 类图,2.1 类图的概念 2.2 类图建模技术 2.3 实例图书馆管理系统的类图,2.1 类图的概念,描述类、接口、协作及它们之间关系的图。 显示系统中各个类的静态结构。,2.1.1 概述,类图的元素 类（Class） 接口（Interface） 协作（Collabora

14、tion） 依赖关系（Dependency） 泛化关系（Generalization） 关联关系（Association） 实现关系（Realization）,2.1.2 类,面向对象系统组织结构的核心。 对一组具有相同属性、操作、关系和语义的对象的抽象。 包括名称部分（Name）、属性部分（Attribute）和操作部分（Operation）。,2.1.2 类,1 名称 2 属性 3 操作 4 职责 5 约束 6 注释,类-名称,应该来自系统的问题域。 应该是一个名词，且不应该有前缀或后缀。 分为简单名称和路径名称。,类-属性,描述了类在软件系统中代表的事物（即对象）所具备的特性。 类可以有

15、任意数目的属性，也可以没有属性。 在UML中，类属性的语法为：,类-属性,1. 可见性 2. 属性名 3. 类型 4. 初始值 5. 属性字符串,类-属性-可见性类型：,公有（Public） “” 私有（Private）“” 受保护（Protected）“”,类-属性-名,每个属性都必须有一个名字以区别于类中的其他属性。 属性名由描述所属类的特性的名词或名词短语组成。 单字属性名小写，如果属性名包含了多个单词，这些单词要合并，且除了第一个单词外其余单词的首字母要大写。,类-属性-类型,简单类型： 整型 布尔型 实型 枚举类型 系统中的其他类,类-属性-初始值,目的： 保护系统的完整性，防止漏掉

16、取值或被非法的值破坏系统的完整性。 为用户提供易用性。,类-属性-属性字符串,指定关于属性的其他信息。 任何希望添加在属性定义字符串值但又没有合适地方可以加入的规则，都可以放在属性字符串里。,类-操作,对类的对象所能做的事务的抽象。 一个类可以有任意数量的操作或者根本没有操作。 返回类型、名称和参数一起被称为操作签名。 在UML中，类操作的语法为：,类-操作,1. 可见性 2. 操作名 3. 参数表 4. 返回类型 5. 属性字符串,类-操作-可见性,类型： 公有（Public） “” 私有（Private） “” 受保护（Protected） “” 包内公有（Package） “”,类-操作-名,用来描述所属类的行为的动词或动词短语。 单字操作名小写，如果操作名包含了多个单词，这些单词要合并，并且除了第一个单词外其余单词的首字母要大写。,类-操作-参数表,一些按顺序排列的属性定义了操作的输入。 是可选的，即操作不一定必须有参数才行。 定义方式：“名称：类型”。 若存在多个参数，