面向对象技术与uml课程教案

面向对象技术与uml课程教案内容摘要：

)《 面向对象技 术与 UML》课程教学教案 (项炜 ) 11 ? 是否客户和系统的用户对用例的名称和描述 理解 相同。 检查点列表 : 需求 : 用例描述 ? 用例的 执行者 是否明确。 ? 用例执行的 目的 是否明确。 ? 用例简述是否正确描述了用例的 功能 ? 用例 事件流 开始和结束的时机和方式是否明确 ? 角色和用例之间的交互序列是否 满足 了用户的期望。 ? 角色交互和信息交换是否 明确。 ? 是否有用例过于 复杂。 检查点列表 : 需求 : 词汇表 ? 每一个词汇的 定义 是否全是清晰和精确 的。 ? 每一个词汇是否都 被使用 在了某个用例的描述中。 ? 在角色和用例的描述中，每个词汇的含义是否 一致。 本章小结 本章小结： 需求总结 ? 需求的主要产出是什么。 ? 需求的产出有什么用途。 ? 用例模型是什么。 ? 角色是什么。 ? 用例是什么。 列举出用例属性的一些例子 ? 用例和场景有何不同。 ? 附加说明是什么。 包含什么内容。 ? 词汇表是什么。 包含什么内容。 第三章 分析和设计概述 章节目标 理解分析和设计的核心 术语 、 概念 ； 了解分析和设计的 实际 过程 ，包括角色、工件和工作流程； 解释分析和设计的 差异。 特定情景下的分析和设计 分析和设计的目的是： ? 将需求 转化 为系统设计 ? 使系统具有更加健壮的 架构 ? 是设计和实现环境相匹配，做性能设计 ? 商务规则为系统结构提供 场景 ? 需求规则为分析和设计提供了基本 输入 ? 测试规则测试了在分析和设计阶段的系统 ? 环境规则发展和维护了在分析阶段使用的工件 ? 管理原则规划整个项目和每一次迭代（迭代项目中）。 20202020(上 )《 面向对象技 术与 UML》课程教学教案 (项炜 ) 12 分析和设计概述 ? 输入 ： USECASE 模型（角色、用例、用例描述）、术语表和附加规范（补充说明）。 ? 产出 ：设计 模型（作为源代码抽象的模型） ? 展开 ：设计活动围绕架构的概念展开。 架构优先：其可行性和正确性是早期设计迭代周期的主要关注点。 通过抽象忽略其细节，展现其主要特征使之具体化。 架构不仅为了开发好的设计模型，还将提高实现过程的质量。 架构由架构文档记录。 ? 架构文档不在这次课程范围，但我们会讨论其内容及如何解释。 分析和设计综述（ 1）核心概念 ? 从定义分析和设计工作流程的核心术语及概念开始。 分析和设计对比（参看幻灯片） ? 关注点不同 ：分析和设计的差别在于关注点和侧重点。 ? 分析的目标 ：理解问题并建立一个可视化的分 析模型，而不去考虑实现的技术细节。 分析关注于把功能需求转化为软件中的概念，目的是得到系统中的对象，侧重于行为的封装。 以便尽快转入设计及其他阶段。 ? 设计的目标 ：细化分析模型，开发一个设计模型，以便迅速过渡到编码阶段。 在设计中，我们必须适应实现环境和分布环境。 实现环境是开发者必须满足的环境，它是分布环境中软件的超集和硬件的子集。 ? 建模的目标 ：从一个和现实世界紧密类似的对象模型出发，找出更为普遍的解决方法。 由此而创建模拟现实世界的模型，更为强大、能更简单地解决问题。 分析和设计并不是由下而上或由上而下的 ? 分析 和设计并不是由下而上或由上而下的。 ? 用例从左侧进入并定义一个中间层：分析类。 ? 定义的子系统移动到上部，定义的设计类移动到下部。 ? 分析可以是上到中、中到上、下到上地移动。 不能说哪一个路径更重要，而是必须覆盖所有的路径以保证系统的正确性。 ? 所有四种路径同等重要，这就是由上到下或由下到上无法解决问题的原因。 什么是架构。 ? 架构 Architecture（体系结构）：一组关于下述问题的重要决定：软件系统的组织方式，构成系统的模型元素和它们接口的选择，以及由这些模型元素之间的协作所描述的行为；这些结构元素和行为元素 如何进一步组成较大的系统，以及指导这种组织（这些元素和它们的接口、协作和组合）的结构风格。 软件体系结构不仅关注结构和行为，也关注使用关系、功能性、性能、弹性、复用、可理解性、经济和技术约束与折中以及审美考虑。 ? 软件架构包含：组成系统的结构元素和它们的接口；元素协作的特定行为；将结构元素和行为元素结合成一个大的子系统；体系结构风格支配了组织结构。 ? 架构可以是静态的也可以是动态的。 ? 相同系统的架构应该是类似的（已用过的特殊类型）：体系结构 =元素 +形式 +基本原理。 ? 基本原理决定一个好架构的核心部分。 ? 模式是将元素 聚合为某种形式的指导方针。 架构约束设计和实现 ? 架构包括一套整体设计的结论、规则或者设计约束和结构的模式。 20202020(上 )《 面向对象技 术与 UML》课程教学教案 (项炜 ) 13 ? 架构结论是最底层的结论，改变它将带来巨大的影响。 ? 架构可以被看作一套核心设计结论的集合。 ? 架构是对系统的最初限制，这些限制往往也是最重要的。 他们组成了软件设计的最基础的结论。 ? 架构为设计提供了一个框架，因此架构也被称作战略式的设计。 ? 一个系统架构师的工作就是消除非必须的工作。 随着对代码的越发接近，这些工作就会被除去（架构限制着设计、设计限制着实现）。 这样做是非常有用的，因为在实现过程中，我们可以增 加其他方面（例如，提高质量和性能）的工作。 软件架构：“ 4+1 视图”模型 ? 上面的图表说明了 Rational 公司用来描述软件架构的模型。 ? 不同的组织对架构有不同的看法。 在一个指定的项目中，通常有许多投资人，他们对姚开发的系统都有它们自己的看法。 我们的目标是为这些不同的投资人提供一个系统来满足他们所关心的，而忽略一些其他的细节。 ? 为了满足这些不同的需求， Rational 公司定义了“ 4+1 视图”模型。 一个架构视图是对系统从特殊观点或者优势来进行简单描述（或抽象），覆盖特定的关注点，并忽略与这个关联联系不紧密的 实体。 视图是模型的“片段”，而不是所有的系统都需要所有的视图（例如，单一处理器：舍弃分布视图；单一进程：舍弃过程视图；小程序：舍弃实现视图等）。 ? 一些项目可以记录所有这些视图，或者附加一些视图。 具体视图的数量依赖所开发的系统。 ? 这些视图中的每一个，以及用来代表他们的 UML 符号，将在以后的章节讨论。 分析和设计综述（ 2）分析和设计工作流程 ? 仅仅由开发者、活动和工件并不能组成一个进程。 我们需要一种描述活动的方法，一些有价值的结果，以及开发者之间的交互结果。 工作流程是一个活动序列，而且可以产生能够看得见的价 值。 ? 在 UML 术语中，工作流程可以用顺序图、交互图或者活动图来表示。 我们使用 RUP中的一些活动图。 对每一个核心工作流程，都有一个活动图与之对应。 这个图说明了工作流程，根据工作流程的细节来描述的。 ? 这张幻灯片说明了分析和设计的工作流程。 早期的“ Elaboration Phase”阶段关注为系统创建一个初始的架构（定义一个备选架构），来为主要的分析阶段提供一个起始点。 如果架构已经存在（可以从前期的迭代、项目、或者一个用程序的框架得来），工作的重点就变为细化架构，分析行为和创建一套初始化的元素来提供适当的行为（分 析行为）。 ? 当初始化的元素定义完之后，它们就要被进一步细化。 设计组件和设计实施组件将会产生一套组件，这套组件为了满足系统需要提供了适当的行为。 与此并列的是数据库设计。 结果是产出在实现阶段进一步细化的一套初始化组件。 分析和设计活动综述 ? 在分析和设计中，我们从 USECASE 模型和设计阶段的辅助规范着手，以作为源代码抽象的设计模型的产出而结束。 ? 设计活动以架构概念为中心。 在早期迭代设计中，这种架构的产出以及正确性是我们主要的关注点。 架构是一个重要工具，使用它不但可以开发一个好的设计模型，而且可以提高系统开 发过程中模块的质量。 ? 本课程的关注点在设计行为。 系统架构是的行为要讨论，但是我们将更多地给出一20202020(上 )《 面向对象技 术与 UML》课程教学教案 (项炜 ) 14 些架构的结论。 架构和设计都将在单独的章节中展开。 软件架构师的责任 软件系统架构师的任务是在整个项目过程中领导和协调技术以及工件。 软件系统架构师为每一个架构视图建立全面的结构：分解视图、元素分组、以及这些主要分组间的接口。 因此，与其他角色相比，软件系统架构师的观点决定着系统的广度和深度。 总的来说，软件系统架构师必须是全面的、成熟的、具有快速掌握问题的丰富经验、良好素质，缺少全部信息时的关键判断。 更专业地说，系统 架构师或架构师团队中的一员，必须具有以下技能： ? 同时具有解决问题领域和软件工程领域中对需求的彻底理解。 如果一个团队具有这些品质就可以在团队中扩散，但至少得有一个软件架构师可以提供一个项目全局性的看法。 ? 具有领导才能，以此在技术方面驱动不同的团队，在压力下做出关键的结论，并坚持这些结论。 为了更有效，软件系统架构师和项目经理必须紧密合作。 软件系统架构师领导技术问题，项目经理领导行政性问题。 软件系统架构师必须有权利在技术方面做出决定。 ? 具有交流能力，以此获得信任，说服别人，激发别人以及指导别人。 软件系统架构师不能 被规则所领导，而只需得到项目其他成员的同意。 为了更加有效，软件系统架构师必须在项目组中赢得其他人的尊重，包括项目经理、客户、用户团体及管理团队。 ? 针对目标并且严格地以结果为前提。 软件系统架构师是项目中的技术驱动力量，而不是空想家或梦想家。 一个成功的软件系统架构师的职业生涯是在一系列不确定性。