《面向对象技术与UML》课程教案

乐山师范学院课程教案系（院）计算机科学学院专业计算机科学与技术课程名称面向对象技术与UML授课对象数信学院10级本科信计班教师项炜职称讲师课程学时642012～2013学年(上)期

课程名称面向对象技术与UML课程编号授课时间2012-2013(上)专业及班级数信学院10本信计班修课人数总学时64学分4课程类型必修课公共基础()专业（学科）基础课(√)专业课()选修课专业限选课（）专业任选课（）全校任选课（）授课方式理论课(√)实践课(√)学时分配课堂讲授32学时；实践环节32学时考核方式考试()考查(√)是否采用多媒体是是否采用双语否使用教材：（名称、作者、出版社及出版时间）《UML面向对象建模基础》，徐锋，中国水利水电出版社，2006教学参考书：（名称、作者、出版社及出版时间）《UML基础与ROSE建模案例》，吴建，人民邮电出版社，2007《Java与UML面向对象程序设计教程》，刘晓冬，清华大学出版社，2008《UML与系统分析设计》，张龙祥，人民邮电出版社，2007《软件工程》，钱乐秋，清华大学出版社，2007教研室审查意见注：表中（）选项请打“√”。

第一章面向对象的概念（4学时）1.1章节目标（教学目的及要求）1、解释面向对象的基本原则2、定义面向对象的基本概念和相关的UML符号3、展示面向对象的威力4、列举一些基本UML建模符号教学内容1.1什么是UML？统一建模语言（UML）是一种通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统工作文档。它记录了与被建系统的有关决策和理解，可用于对系统的理解、设计、浏览、配置、维护以及控制系统的信息。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，旨在统一以往建模技术的经验，吸收当今软件开发的最佳实践从而形成一种标准方法。UML包括语义概念、表示方法和指导规范，提供了静态、动态、系统环境及组织结构的模型。它可被交互式的可视化建模工具所支持，这些工具提供代码生成和报表生成。UML标准并没有定义一种标准的开发过程，但它适用于迭代的开发过程。它是为支持现今大部分面向对象的开发过程而设计的。UML是一种语言；是一种可视化的语言；是一种可用于详细描述的语言；是一种构造语言。是一种文档化的语言；主要用于软件密集型系统。1.2软件工程最佳实践软件工程六个最佳实践（即DevelopIteratively迭代开发、ManageRequirements需求管理、UseComponentArchitectures组件架构、ModelVisually可视化建模(UML)、ContinuouslyVerifyQuality持续质量改进、ManageChange变更管理）与本课程相关三个最佳实践对象技术帮助成就了以下行为：1、迭代开发： 适应需求的变更、逐步加入对象元素和功能的可重用性；2、使用组件为基础的结构： 结构化、组件为基础的开发；3、可视化模型： 容易理解，修改简单。1.3什么是对象技术？什么是面向过程？以算法和数据结构为核心，一段程序代码解决一个或几个问题。什么是面向对象？以客观存在的事物即对象为开发核心，在开发时以类作为对象的框架。一种指导将语言、数据库和其他工具构造在一起的原则。（注释：面向对象是一种新兴的程序设计方法或开发范型paradigm，面向对象运用对象、类、继承、封装、消息等概念来进行程序设计。其基本思想是，从现实世界中客观存在的事物及对象出发来构造软件系统，并在系统构造中尽可能运用人类的自然思维方式。）1.4什么是模型？----模型是现实的简化。模型提供了系统的蓝图。1）什么是模型？为什么要建模？模型是对现实的简化。建模是为了更好地理解正在开发的系统。因为我们不能完整地理解一个复杂系统，所以我们要对它建模。现实世界太复杂，我们的理解力有限。建模一定会进行抽象和简化。2）为什么要建模？建模是为了产生对系统的理解。可视化的理解是最为直观的理解。对于复杂系统，只用一个模型是不够的，需要对系统拆分并使用多个相互关联的模型。对于软件密集型系统，就需要一种语言，它贯穿于软件开发生命周期，并能表达系统体系结构的各种不同视图。建模有四个目标：----帮助我们可视化我们的系统；----允许我们制定我们的系统的结构和行为；----给我们一个构造系统的模板；----记录我们所做的决定；3）建模的原则：选择要创建什么模型，对如何动手解决问题以及如何形成解决方案，有着意义深远的影响。每一种模型你可以在不同的精度级别上表示。最好的模型适于现实相联系的。单个模型是不充分的。对每个重要的系统最好用一组几乎独立的模型去处理。1.5什么是对象？----通常一个对象代表一个实体，不管它是物理实体、概念实体还是软件实体。----一个对象是具有明确界限并封装了状态和行为的统一体。----状态主要表现为属性和关联。----行为主要表现为操作、方法和状态机。1.6什么是模板类型？----根据模板类型中的其他元素定义一个新的元素。Stereotype构造型：属于UML扩展机制之一，它允许用户基于已存在的构造块创建新的适应于用户特定问题的构造块。1.7面向对象的基本原则----抽象区别其他实体最本质的特征。----封装向调用者隐藏了内部（封装），调用者只能依赖接口实现调用。----模块将复杂的整体分割成可以控制的小块，以帮助人们理解复杂的系统。----继承任何等级或排序都可以以树形结构表示。1.8什么是类？类就是一系列（某一类）对象共享相同属性、操作、关联和语义描述。对象是类的实例。1.9什么是属性属性是类中具有名词特性的参数，属性描述了实例中可取值的范围。1.10什么是操作操作能被任何类的实例调用执行、并完成某项实现的功能。1.11什么是多态？使用同一接口隐藏了不同的实现。多态（Polymorphism）在希腊语中意味着“拥有多种形式”。如绘图，图形可以是矩形、圆或曲线，等等。投资，可以是股票、债券或基金，等等。一个接口可能有很多实现，但每一种实现都必须满足接口参数要求。有时，一个实现也可以满足多个基本需求接口。如一个控制器能够控制任何符合这个控制其接口规范的电视机。多态意味着用同一个名字来引用不同的方法。JAVA中提供两种形式的多态：第一种可以通过子类对父类方法的覆盖来实现运行时对态；第二种利用方法重载在同一个类中定义多个同名（但参数不同）的方法，实现编译时多态。1.12什么是接口？1、接口的定义与作用：1）接口是用来描述类或组件提供的操作的集合。2）接口正规化了多态。接口消除了多态的神秘性。3）接口支持“即插即用”的结构。2、接口的表示方法：1）“棒棒糖”表示法（表示接口的存在）2）“类/模板”表示法（表示接口的详情）1.13什么是包？《UML用户手册》：包package是“对元素进行分组的通用机制”。包是分组的通常手法，包可以包含其它模型元素。包可作为管理单元，使模型条理化。包是简单的分组机制，没有语义上的实例。所以包就没有必要一定要需要实现，除非它表示一个目录。1.14什么是子系统？1）子系统的定义和作用：子系统是包（包含其他模型元素）和类（拥有行为）的结合。实现定义在行为中的一个或多个接口。《UML用户手册》：子系统是“提供了一些特定行为的一组元素”。2）子系统组件：组件是设计的物理实现。子系统能够表示设计中的一个组件。1.15什么是组件（构件）？在一个定义良好的系统框架中，宏观的、可以替换的、独立的系统功能。组件可以是：源代码组件、实时运行组件、可被执行的组件。《UML用户手册》component组件：系统中遵从一组接口并提供其实现的物理的、可替换的部分。1.16什么是关联？《UML用户手册》关联association：是一种结构关系，它指明一个事物的对象到另一个事物的对象间的联系。两个或多个类的对象之间的联系。一种结构化的联系，制定了一个对象到另外一个对象的连接。1.17什么是多重性？一定数量的某个类的实例对应另外一个类的实例的数量的范围。《UML用户手册》multiplicity多重性：对集合可能采用技术范围的说明。1.18集合是什么？《UML用户手册》Aggregation聚合：关联的一种特殊形式，它表示聚集（整体）和构件（部分）之间的“整体-部分”关系。《UML用户手册》组合compstion：聚合的一种形式，整体和部件之间具有很强的拥有关系和一致的生存期。1.19什么导航？《UML用户手册》Navigation导航：给定两个类之间的一个简单的、未加修饰的关联，从一个类的对象能够导航到另一个类的对象。除非另有指定，否则关联的导航是双向的。在图形上，把一个关联画成一条实线，它可能有方向，偶尔还在其上有一个标记，而且它经常还含有诸如多重性和角色名这样的修饰。UML有四种关系：依赖、关联、泛化、实现。《UML用户手册》Dependency依赖：两个事物之间的语义关系，其中一个事物（独立事物）的改编将影响到另一个事物（依赖事物）。在图形上，把一个依赖画成一条可能有方向的虚线，偶尔还在其上有一个标记。1.20什么是一般化（泛化）？它们之间是这样的关系：一个类（子类）共享另外一个类（父类）的结构或者行为。一个子类能够从一个（单继承）或者多个（多继承）父类继承。《UML用户手册》generalization泛化：一般/特殊关系，其中特殊元素（子类）的对象可以替换一般元素（父类）的对象。一般化（泛化）就是从子类中提取共性而形成父类；继承则是子类在承接父类的职责和本质（属于共性的关健的属性、操作和关联）的同时，将会产生属于自己的、特殊的个性。1.21什么是实现？《UML用户手册》realization实现：类元之间的一种语义关系，其中一个类元描述一个规格说明，另一个类元保证实现这个规格说明。在两种地方要遇到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用况和实现它们的协作之间。提示是什么？在图像上增加一种注释可以包含更多的信息。1.22本章小结面向对象的四个最基本原则是什么？分别简短阐明一下。对象的概念是什么？类的概念是什么？他们的区别是什么？属性的概念是什么？操作的概念是什么？多态的概念是什么？什么是包？什么是子系统？子系统怎么和包能够关联起来？又怎么和类关联起来？UML语言中有那几种类关系？他们的定义分别是什么？阐明面向对象的效果。什么是模板类型？第二章需求概述（1）（4学时）教授方式：讲课讨论2.1章节目标（教学目的及要求）1、描述了需求中使用的基本概念以及需求对分析和设计产生的影响。2、展示了作为分析和设计起点的需求产出品的阅读以及解释方法。教学内容2.2需求概述的内容（1）简要介绍1、需求概述的内容（1）简要介绍核心概念用例模型术语表补充说明检查点列举2、需求工作的目标包含:提供一种与客户在系统功能方面进行沟通并达成共识的方式使开发者能够更准确的理解系统的需求确定系统的边界提供了对迭代过程中的技术内容进行计划的基础。为系统开发的成本估计提供一个基础定义出系统与用户之间的交互接口（交互界面—确定用户的需求和目的）USDP：统一软件开发过程3、需求的产出:用例模型：角色；用例；用例描述。术语表补充说明2.3需求概述的内容（2）核心概念1、需求概述的内容（2）简要介绍核心概念用例模型术语表补充说明检查点列举2、系统行为是什么？系统行为是系统的活动和对输入进行的响应方式–外界可见的并且可以测试的系统活动系统行为可以使用用例进行描述–用例描述了系统，环境以及系统和环境之间存在的关系。3、用例建模中的核心概念角色表示与系统交互的任何事物（可以是人—用户、也可以是其他系统或设备）用例表示系统执行的一系列动作。这些动作产生对某一角色可见的结果。需求概述的内容（3）用例模型1、需求概述的内容（3）简要介绍核心概念用例模型术语表补充说明检查点列举2、用例模型是什么？用例描述了系统的功能需求模型化表示了系统的功能（用例）和系统的环境（角色）。3、用例模型的优点是什么？交流在系统开发早期就可以明确最后提交产品的功能；确保双方都对需求有准确的了解。标识确定系统与用户群之间的接口需求。验证确保开发团队已完全理解了客户需求。识别与系统交互的角色；界定系统边界和功能；确保即将开的发系统是用户所期望。4、用例描述用例名称概述事件流关系活动图用例图特殊需求前置条件后置条件其他图4、用例事件流一个正常的基本的路径多个可选的路径–正常的可选路径–罕见的可选路径–异常路径5、场景是什么？场景是用例的一个实例。6、活动图是什么？用例模型中的活动图用来描述用例中发生的活动。活动图必须是一个流程图，需要能够描述清楚系统的活动流程以及分支的时机。7、事件流当注册管理员要求关闭注册时，这个用例开始执行。1）首先系统检查注册用例是否在执行。如果正在执行，一条消息应该显示给用户，并且用例结束。如果注册活动在执行，“关闭注册”的活动是无法进行的。2）对于每个课程，系统需要检查是否有一位教授已经申请教授，并且至少有三个学生选该门课。只有这两个条件都满足的话，系统才能够提交这门课以安排课程表。2.5需求概述的内容（4）术语表1、需求概述的内容（4）简要介绍核心概念用例模型词汇表补充说明检查点列举1、词汇表实例：1）选课系统词汇表介绍这个文档定义并解释了问题域中专有的名词，这些解释可以帮助那些对问题领域不太熟悉的用例描述和其他项目文档的阅读者。通常情况下，这个文档可以作为一个非正式的数据字典，用来记录数据的定义。这样可以让用例的描述文档和项目的其他文档能够将注意力更加集中到系统的功能上。2）词汇定义词汇表定义了选课系统中的核心概念。2-1）课程:学校提供的课程。2-2）开设课程：一个学期中学校开设的课程--在一个学期中这将会有若干相同的课程并行开授，你可以在其中选择一个学习。时间的选择需要视课程提供的时间而定。2-3）课程总表:大学所教授的所有课程的列表2.6需求概述的内容（5）补充说明功能可用性稳定性性能可维护性设计约束2.7需求概述的内容（6）检查点列举1、检查点列举:需求:用例模型用例模型描述的容易理解吗？通过研究用例模型，一位客户或开发者可以清楚的了解系统的功能和这些功能之间的联系吗？客户所有的需要都被满足了吗？用例模型包含有一些多余的行为吗？每个用例模型是否都分配到合适的包集合中了？2、检查点列举:需求:角色所有的角色都被识别出了吗？每个角色是否均发生了至少一个用例？每个角色的职能是否单一？角色之间是否需要进一步的拆分和合并？是否存在两个角色，在与同一用例交互时行使着相同的职能？角色的名称是否直观且含义清晰？用户和客户对名称的含义的理解是否一致？3、检查点列举:需求:用例是否每个用例都至少涉及到了一个角色？是否每个用例都和其他用例是独立的？是否有些用例中存在着类似的行为或事件流？每个用例的名字都是唯一，直观并且意义足够明确以免在以后阶段发生混淆吗？是否客户和系统的用户对用例的名称和描述理解相同？4、检查点列表:需求:用例描述用例的执行者是否明确？用例执行的目的是否明确？用例简述是否正确描述了用例的功能用例事件流开始和结束的时机和方式是否明确角色和用例之间的交互序列是否满足了用户的期望？角色交互和信息交换是否明确？是否有用例过于复杂？5、检查点列表:需求:词汇表每一个词汇的定义是否全是清晰和精确的？每一个词汇是否都被使用在了某个用例的描述中？在角色和用例的描述中，每个词汇的含义是否一致？2.8本章小结本章小结：需求总结需求的主要产出是什么？需求的产出有什么用途？用例模型是什么？角色是什么？用例是什么？列举出用例属性的一些例子用例和场景有何不同？附加说明是什么？包含什么内容？词汇表是什么？包含什么内容？第三章分析和设计概述3.1章节目标1、理解分析和设计的核心术语、概念；2、了解分析和设计的实际过程，包括角色、工件和工作流程；3、解释分析和设计的差异。3.2特定情景下的分析和设计分析和设计的目的是：将需求转化为系统设计使系统具有更加健壮的架构是设计和实现环境相匹配，做性能设计商务规则为系统结构提供场景需求规则为分析和设计提供了基本输入测试规则测试了在分析和设计阶段的系统环境规则发展和维护了在分析阶段使用的工件管理原则规划整个项目和每一次迭代（迭代项目中）。3.3分析和设计概述输入：USE-CASE模型（角色、用例、用例描述）、术语表和附加规范（补充说明）。产出：设计模型（作为源代码抽象的模型）展开：设计活动围绕架构的概念展开。架构优先：其可行性和正确性是早期设计迭代周期的主要关注点。通过抽象忽略其细节，展现其主要特征使之具体化。架构不仅为了开发好的设计模型，还将提高实现过程的质量。架构由架构文档记录。架构文档不在这次课程范围，但我们会讨论其内容及如何解释。3.4分析和设计综述（1）核心概念从定义分析和设计工作流程的核心术语及概念开始。1、分析和设计对比（参看幻灯片）关注点不同：分析和设计的差别在于关注点和侧重点。分析的目标：理解问题并建立一个可视化的分析模型，而不去考虑实现的技术细节。分析关注于把功能需求转化为软件中的概念，目的是得到系统中的对象，侧重于行为的封装。以便尽快转入设计及其他阶段。设计的目标：细化分析模型，开发一个设计模型，以便迅速过渡到编码阶段。在设计中，我们必须适应实现环境和分布环境。实现环境是开发者必须满足的环境，它是分布环境中软件的超集和硬件的子集。建模的目标：从一个和现实世界紧密类似的对象模型出发，找出更为普遍的解决方法。由此而创建模拟现实世界的模型，更为强大、能更简单地解决问题。2、分析和设计并不是由下而上或由上而下的分析和设计并不是由下而上或由上而下的。用例从左侧进入并定义一个中间层：分析类。定义的子系统移动到上部，定义的设计类移动到下部。分析可以是上到中、中到上、下到上地移动。不能说哪一个路径更重要，而是必须覆盖所有的路径以保证系统的正确性。所有四种路径同等重要，这就是由上到下或由下到上无法解决问题的原因。3、什么是架构？架构Architecture（体系结构）：一组关于下述问题的重要决定：软件系统的组织方式，构成系统的模型元素和它们接口的选择，以及由这些模型元素之间的协作所描述的行为；这些结构元素和行为元素如何进一步组成较大的系统，以及指导这种组织（这些元素和它们的接口、协作和组合）的结构风格。软件体系结构不仅关注结构和行为，也关注使用关系、功能性、性能、弹性、复用、可理解性、经济和技术约束与折中以及审美考虑。软件架构包含：组成系统的结构元素和它们的接口；元素协作的特定行为；将结构元素和行为元素结合成一个大的子系统；体系结构风格支配了组织结构。架构可以是静态的也可以是动态的。相同系统的架构应该是类似的（已用过的特殊类型）：体系结构=元素+形式+基本原理。基本原理决定一个好架构的核心部分。模式是将元素聚合为某种形式的指导方针。4、架构约束设计和实现架构包括一套整体设计的结论、规则或者设计约束和结构的模式。架构结论是最底层的结论，改变它将带来巨大的影响。架构可以被看作一套核心设计结论的集合。架构是对系统的最初限制，这些限制往往也是最重要的。他们组成了软件设计的最基础的结论。架构为设计提供了一个框架，因此架构也被称作战略式的设计。一个系统架构师的工作就是消除非必须的工作。随着对代码的越发接近，这些工作就会被除去（架构限制着设计、设计限制着实现）。这样做是非常有用的，因为在实现过程中，我们可以增加其他方面（例如，提高质量和性能）的工作。5、软件架构：“4+1视图”模型上面的图表说明了Rational公司用来描述软件架构的模型。不同的组织对架构有不同的看法。在一个指定的项目中，通常有许多投资人，他们对姚开发的系统都有它们自己的看法。我们的目标是为这些不同的投资人提供一个系统来满足他们所关心的，而忽略一些其他的细节。为了满足这些不同的需求，Rational公司定义了“4+1视图”模型。一个架构视图是对系统从特殊观点或者优势来进行简单描述（或抽象），覆盖特定的关注点，并忽略与这个关联联系不紧密的实体。视图是模型的“片段”，而不是所有的系统都需要所有的视图（例如，单一处理器：舍弃分布视图；单一进程：舍弃过程视图；小程序：舍弃实现视图等）。一些项目可以记录所有这些视图，或者附加一些视图。具体视图的数量依赖所开发的系统。这些视图中的每一个，以及用来代表他们的UML符号，将在以后的章节讨论。3.5分析和设计综述（2）分析和设计工作流程仅仅由开发者、活动和工件并不能组成一个进程。我们需要一种描述活动的方法，一些有价值的结果，以及开发者之间的交互结果。工作流程是一个活动序列，而且可以产生能够看得见的价值。在UML术语中，工作流程可以用顺序图、交互图或者活动图来表示。我们使用RUP中的一些活动图。对每一个核心工作流程，都有一个活动图与之对应。这个图说明了工作流程，根据工作流程的细节来描述的。这张幻灯片说明了分析和设计的工作流程。早期的“ElaborationPhase”阶段关注为系统创建一个初始的架构（定义一个备选架构），来为主要的分析阶段提供一个起始点。如果架构已经存在（可以从前期的迭代、项目、或者一个用程序的框架得来），工作的重点就变为细化架构，分析行为和创建一套初始化的元素来提供适当的行为（分析行为）。当初始化的元素定义完之后，它们就要被进一步细化。设计组件和设计实施组件将会产生一套组件，这套组件为了满足系统需要提供了适当的行为。与此并列的是数据库设计。结果是产出在实现阶段进一步细化的一套初始化组件。1、分析和设计活动综述在分析和设计中，我们从USE-CASE模型和设计阶段的辅助规范着手，以作为源代码抽象的设计模型的产出而结束。设计活动以架构概念为中心。在早期迭代设计中，这种架构的产出以及正确性是我们主要的关注点。架构是一个重要工具，使用它不但可以开发一个好的设计模型，而且可以提高系统开发过程中模块的质量。本课程的关注点在设计行为。系统架构是的行为要讨论，但是我们将更多地给出一些架构的结论。架构和设计都将在单独的章节中展开。2、软件架构师的责任软件系统架构师的任务是在整个项目过程中领导和协调技术以及工件。软件系统架构师为每一个架构视图建立全面的结构：分解视图、元素分组、以及这些主要分组间的接口。因此，与其他角色相比，软件系统架构师的观点决定着系统的广度和深度。总的来说，软件系统架构师必须是全面的、成熟的、具有快速掌握问题的丰富经验、良好素质，缺少全部信息时的关键判断。更专业地说，系统架构师或架构师团队中的一员，必须具有以下技能：同时具有解决问题领域和软件工程领域中对需求的彻底理解。如果一个团队具有这些品质就可以在团队中扩散，但至少得有一个软件架构师可以提供一个项目全局性的看法。具有领导才能，以此在技术方面驱动不同的团队，在压力下做出关键的结论，并坚持这些结论。为了更有效，软件系统架构师和项目经理必须紧密合作。软件系统架构师领导技术问题，项目经理领导行政性问题。软件系统架构师必须有权利在技术方面做出决定。具有交流能力，以此获得信任，说服别人，激发别人以及指导别人。软件系统架构师不能被规则所领导，而只需得到项目其他成员的同意。为了更加有效，软件系统架构师必须在项目组中赢得其他人的尊重，包括项目经理、客户、用户团体及管理团队。针对目标并且严格地以结果为前提。软件系统架构师是项目中的技术驱动力量，而不是空想家或梦想家。一个成功的软件系统架构师的职业生涯是在一系列不确定性和压力下的并非最理想的决定。只有那些关注于必须做的事情的人才是项目中这种角色的成功者。3、设计师的责任设计师的任务是定义一个或几个类的职责、操作、属性、关联，决定如何修改它们来满足实现环境。而且设计是的任务可以为一个或更多的包指定职责，或者设计子系统，包含包或子系统中包括的所有的类。设计师必须具有扎实的应用知识，包括：Use-case建模技术；系统需求（Systemrequirements）；软件设计技术，包括面向对象的分析和设计技术，统一建模语言；系统实现时所涉及的技术。附加的，设计师必须：理解软件架构文档中描述的系统架构4、分析和设计是Use-Case驱动的使用案例是一个系统的整个开发过程的基础。优点：简明、简单，能为多数客户理解；帮助实现不同模型的同步。使用案例是推荐用来组织需求的方法。取代将需求列出，用一种讲述某人如何使用系统来组织它们。这样做，你得到了一个更为全面和一致的需求。你可以更好地理解从用户的观点来讨论需求的重要性。通常很难从一个传统的对象系统的模型，说明一个系统是否按照预期的设想工作。这种情况的出现是由于在系统执行特定任务的时候缺少一个通用的线索。使用案例正是这种线索，因为它们定义了一个系统执行时的行为。使用案例不是“传统”的面向对象的一部分，但它们的作用已经变得越来越重要，进一步强调的事实是使用案例是UML的一部分。5、什么是Use-Case实现根据对象的相互交互，一个Use-Case实现描述的是设计模型中一个指定的用例是如何实现的。一个Use-Case实现将Use-Case模型中的用例和设计模型中的类及关联紧密联系起来。一个Use-Case实现指出了那些类必须来实现一个Use-Case。在UML中，Use-Case实现是传统的交互。一个交互的符号是包含一个交互的名字的省略符号。一个Use-Case实现的符号是交互符号的点线。在设计模型中的一个Use-Case实现可以追溯到Use-Case模型中的用例。关联关系是从Use-Case的相互关联中而来。通过UML工具，Use-Case的实现可以用很多表达交互关系环境的图形来描述（实现Use-Case及其关系的类/对象-类图），还有交互图（这些类/对象是怎么完成用例的——协作图和序列图）。使用多少种类和多少数量的图形是由项目究竟需要多少交互图才能够完整描述，和开发需要多少指导来决定的。6、迭代过程中的分析和设计本课程假定开发者使用迭代过程。记住每一次完成过程工作流程序列就叫做一次迭代。因此，从一个开发者的观点看，软件生命周期是连续迭代过程，一次迭代就是软件开发的一个增量。在一个迭代分析和设计工作流程时，一个使用案例将是最基本的输入工件。经过分析和设计工作流程中一连串的活动，开发团队将创建一个联合的Use-Case实现来描述一个特定的使用案例是如何实现的。3.6本章小结分析和设计阶段的主要目的是什么？输入和产出是什么？列举并简要描述一下架构的“4+1”视图。分析和设计的区别是什么？什么是系统架构？第四章架构分析4.1章节目标解释架构设计的目的，及其在生命周期的什么时期执行。说明一个典型的架构模式和一套分析机制，以及他们如何影响架构。说明用以支持架构决策的基本原理和需要考虑的事项。说明如何阅读和理解架构设计的结果：架构层及其关系关键抽象概念分析机制章节目标在软件架构上，清晰说明系统结构（包/构件），以及他们集成（相互作用的基本机制和模式）的方式。在架构分析中，进行了初步的工作，包括定义片/块及其关系，并用依赖关系将这些片/块组织成有明确界限的层。4.2工作环境中的架构分析架构分析是定义备选架构中的一个活动。架构模式和习惯用语取得一致。将片/块组织成有明确界限的层。从需求中识别出分析类，以详细描述架构。架构分析在精化阶段早期进行，这项活动由架构设计师或架构租来进行。如果架构风险较低，架构分析可以跳过。4.3架构分析概述目的：定义一个备选架构定义系统的架构模式、关键机制和建模约定。定义重用策略。为策划过程提供输入。输入工件：用例模型补充约规词汇表设计模型参考架构前景文档项目详细指南软件架构文档生成工件：软件架构文档设计模型部署模型4.4架构分析步骤（1）核心概念1、核心概念定义子系统的高级结构确定分析机制确定关键抽象创建用例实现检查点2、什么是架构：“4+1视图”模式。逻辑视图将在确定设计机制中详细介绍。进程视图将在运行时架构中讨论。实施视图不在分析与设计课程中讨论3、什么是包？包是一种通用分组机制，用于将元素组成组。包是一种模型元素，它包含其它模型元素。包能被用于--组织并开发模型--作为一个配置管理的单元3、包关系：依赖包可以使用依赖关系来关联另一个包。依赖的含义：--Supplier包的变化可能影响Client包，Client包必须重新编译和测试。--Client包不能被独立使用，因为它依赖Supplier包。4、避免循环依赖包的分层结构需要非循环的。如果出现循环依赖，可将循环依赖中的一个包，分解成两个较小的包，来避免循环依赖。4.5架构分析步骤（2）定义子系统的高级结构在软件开发生命周期的早期，确定建模约定很重要，项目中每个人都应当使用。建模约定确保了构架和设计的表现形式在跨团队和迭代时是一致的。1、模式和框架模式：--提供在一个环境下共同问题的一个共同解决方案。分析/设计模式--提供一个狭窄范围技术问题的一个解决方案。--提供一个解决方案的一部分，或难题的一部分。框架--确定解决问题的通用方法。--提供一个概要解决方案，其详细内容可能是分析/设计模式。2、模式和框架的进一步说明模式是把来自经验的知识系统化。模式提供了使用模型解决实际问题的优秀样例，不论是你自己提出的模式还是使用他人的模式。框架是一个宏观架构。框架提供了构件运行的环境。框架提供了基础结构，如通信机制、分布机制、错误处理、事务支持，等等。允许构件以可预见的方式执行和共存。（见下页J2EE架构示意图）框架可以是持久性的，可以针对特定领域。比如SAP公司就有专门针对制造业和金融业的框架。框架在范围和规模上与分析/设计模式不同，它允许在问题域缺少很多细节时给出的一个通用的、宏观的解决方案或架构。在此基础上的进一步工作，则需要应用不同的分析/设计模式使之进一步丰富和细化。3、什么是设计模式？设计模式是对一个共同设计问题的解决方案。--说明一个共同的设计问题。--说明对此问题的解决方案。--讨论应用此模式的结果和评定比较。设计模式提供了重要成功设计的能力。设计模式被收集和编录在许多出版物和媒介上。使用设计模式提高开发效率和可维护性，提供了好的设计方法、设计用语和设计样例。应当熟悉一些通用的设计模式及其处理的问题和处理方法。设计模式在UML中作为参数化协作杯模型化，它包括结构侧重面和行为侧重面。结构侧重面是类，其实例实现模式及其关系（静态视图）。行为侧重面说明实例如何协作（通常是发送消息）以实现模式（动态视图）。参数化写作时协作的一个模版。模版参数通常被用于为一个特定用途而调整协作。这些参数不一定是抽象集，这取决于它们是如何在设计中应用的。4、什么是架构模式架构模式表达了对软件系统基础结构的一个组织大纲。它提供了一套预定义的框架模式，详细说明了他们的职责，并包括组织他们之间关系的规则和指南等。层：在层模式中应用被分为不同的抽象层次。层的范围从高端的特定应用层到低端的实施/特定技术层。模型-视图-控制器：在MVC模式中，应用被分为三个部分：模型、视图和控制器。管道和过滤器：在管道和过滤器模式中，数据在流动中进行处理，通过管道从一个过滤器到另一个过滤器。每个过滤器是一个处理步骤。黑板：在黑板模式中独立的专业应用协作产生一个解决方案，工作在一个共同数据结构上。架构模式可以在一起工作，即一个实际的软件架构可以同时应用多个架构模式。上面列出的架构模式包含了系统特征、性能特征以及进程和分布架构。5、典型分层方法应用程序层；特定业务层；中间件层；系统软件层。6、架构模式：层环境：需要分解的大系统。问题：必须在不同抽象层处理问题的系统，如硬件控制问题；常见服务问题。编写能处理所有层次上问题的垂直构件完全没有必要，甚至不得不在不同构件中处理。影响：构件的某些部分是可以替换的。构件中的变化不会传递（波动）。相似的职责应归为一组。构件大小----复杂构件应进行必要的分解。解决方案：将系统分为构件组，并使构件组形成层叠结构。使上层只使用下层（绝不使用上层）提供的服务。尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非中间件层添加通过构件）。严格的分层架构规定设计元素（类、构件、包、子系统）只能使用下层提供的服务。服务包括事务处理、出错处理、数据库访问等等。7、分层考虑事项层常常用于不同种类服务间缝中概念边界，提供有益的抽象，使设计更易于理解。通常只有一个应用程序层。即，领域层的数量取决于问题域和解决空间的复杂性。如果领域中已经有先前构建的系统，有由较小的互操作系统构成的复杂系统，和/或各设计团队之间尤其需要共享信息的系统。为明确起见，可以将业务专用层分成几个层。在架构分析中，我们关注于较高层（应用程序和业务专用层）。较低层（基础层和厂商专用层）将在包含已有设计元素中详细说明。8、架构层建模架构层可以使用构造型包建模。可在Rose中用《layer》构造型包来表示。层说明可以放在包规格说明的document字段中。9、模型的高层结构上面的例子包括了课程注册系统的应用程序和业务专用层。应用程序层包含了专用于课程注册系统的设计元素。我们期望多个应用程序共享一些核心抽象和公共服务。这些已经封装入业务服务层，应用程序是可以访问的。业务服务层包含的专用业务元素，可用于多个应用程序。4.6架构分析步骤（3）确定分析机制架构应当是简单的，但不应过分简单。它应当通过标准抽象和机制来提供标准行为。因而，设计一个软件框架的关键因素就是机制的定义和选择。设计员通过机制给对象以“生命”。在架构分析中，待开发软件的分析机制是十分重要的。分析机制集中和定位在系统的非功能需求上（也就是需要永久性、可靠性和性能），并将对非功能需求的支撑直接并入架构。分析机制被用于在分析过程中向设计人员提供复杂行为的简短表示，从而减少分析的复杂性并提高分析的一致性。通过这些机制，可以使分析工作集中于将功能性需求转换成软件概念，而不必细究那些需要用来支持功能但却不是功能核心的相对复杂的行为。1、什么是分析机制？为了更好地理解什么是分析机制，我们必须去理解什么是架构机制。架构机制是一项关于常规标准、方针和实践的战略决策。它是一个项目应当标准化的课题的实现。项目的每个人都应当以相同的方式使用这些概念，并重用相同的机制执行操作。一个架构机制描述了针对一个经常发生的问题的一种通用解决方案。它可能是结构模式、行为模式，或者两种都是。架构机制是系统所要求的功能和如何实现此功能间的一个重要的组合部分。对架构机制的支持需要构置在架构上。架构机制被架构师所调整。架构师选择机制，通过构造和集成它们以进行确认，验证它们的工作，并持续将它们加入系统设计的其余部分。2、架构机制的三个种类。有三种架构机制：分析机制（概念）；设计机制（具体）；实施机制（实际）。它们之间的唯一差别就是精细程度。分析机制以与实现无关的方式捕捉解决方案的关键部分。它们或者提供一个领域相关类或者构件的特定行为，或者符合类和/或构件间协作的实现。它们可能作为一个框架被实现。例如永久性、进程间通信、错误或故障处理、通知和消息的传递机制，其例子不胜枚举。设计机制更具体一些。它假定一些实施环境的一些细节，但并不约束于一个特定实施（一个实施机制）。实施机制详细说明了机制的准确实现。实施机制一定是一个确定技术，影响它的是实施语言、销售商或其它因素。在一个设计机制中，会选择一些专用技术（如数据库）。然而在一个实施机制中，将选择一些更专用的技术（如Oracle或Sybase）。对分析机制实施的全部策略必须被构置在架构中。在讨论设计和实施机制时，将讨论有关确定设计机制的更多内容。3、为什么使用分析机制？分析机制代表常见问题的解决模式。这些机制可能表示结构模式或行为模式，也可能表示这两者。它们用于在分析过程中向设计人员提供复杂行为的简短表示，从而减少分析的复杂性并提高分析的一致性。分析机制主要用于在架构的中层或低层作为更复杂技术的“占位符”。当在架构机制中将分析机制用作“占位符”时，可以尽量避免机制行为的细节分散架构工作的重点。通过这些机制，可以使分析工作集中于将功能性需求转换成软件概念，而不必细究那些需要用来支持功能但却不是功能核心的相对的复杂性。分析机制通常源于对一个或多个架构或分析模式的实例化。永久性提供了分析机制的例子。一个永久性对象是在创建它的程序消亡后仍然逻辑存在的对象。在对象生存期，用例、进程生存期或系统关闭和启动等方面的需要确定了在对象永久性方面的需要。永久性是一种特别复杂的机制。在分析过程中，我们不希望因细究如何达到永久性而分散工作的重点。这就导致了“永久性”分析机制的出现。它使我们在谈及永久性对象和分析永久性机制的需求时，不必考虑永久性机制的确切功能或工作方式。分析机制通常与问题与无关（但不一定总是无关），而属于“计算机科学”的概念。所以，它们通常占据架构的中层及更低层。它们为与领域相关的类或构件提供特定的行为，或者对应于类和构件之间、类与类之间、或构件与构件之间协作关系的实施。4、分析机制举例分析机制或者提供一个领域相关类或构件的特定行为，或者符合类和/或构件间协作的实现。分析机制的一些例子在这张幻灯片上。这个列表并不详尽。通信机制的例子包括进程间通信（IPC）和节点间通信（远程进程或PRC）.PRC包括通信和分布。当一个人以“模式”进行通信时，机制或许更容易讨论。因此进程间通行模式与分布模式进行交互、产生PRC模式。这个过程给我们提供了一种实现远程IPC的方式。5、分析机制特征举例分析机制特性分析一些系统的非功能性需求。永久性：对于其实例可能会具有永久性的所有类，我们需要确定：粒度：保持永久性所需要的对象大小的范围。容量：保持永久性所需要的对象数量。持续时间：所需的对象保留时间。访问机制：如何唯一的地标识并检索给定对象。访问频率：对象是否大致保持很定不变？它们是否经常更新？可靠性：对象是否应当在进程、处理器或者整个系统崩溃后继续存在？进程间通信：有些模型元素需要在与其他进程或线程中执行的对象、构件或服务进行通信，对于所有这些模型元素，我们需要确定：反应时间：进程之间的通信速度必须是多快？同步性：通信同步。消息大小：指定大小范围可能比单个大小值更恰当。协议：控制流量、缓存及其他。安全性：数据粒度：包级、类级、属性级。用户粒度：单一用户、角色/组。安全规则：基于数据值，和基于数据算法，以及基于用户数据和数据算法。授权：读、写、创建、删除，执行其它操作。6、说明分析机制说明分析机制的过程如下：画一张用户类到分析机制的图。将所有分析机制集中在一张列表上。相同的分析机制可能会以不同的名字出现，跨越不同的用例实现，或跨越不同的设计人员。举例来说：storage、persistency、database和repository都可以参照一个永久性机制。Inter-process、communication、messagepassing或remoteinvocation都可以参照一个进程间通信机制。确定分析机制的特性。识别潜在设计、确定用于证明每个分析机制合格的关键特性。7、例子：课程注册分析机制永久性。分布。安全性。遗留接口。4.7架构分析步骤（4）确定关键抽象概念确定问题域的关键抽象。建立“词汇表”。关键抽象是系统必须处理的核心概念。例子：在课程注册系统中教授学生课程课程目录课程安排4.8架构分析步骤（5）创建用例实现一个用例实现代表了一个用例的设计观点（思路、思想）。它是一个组织模型元素，用于将一定数量的工件进行分组。用例与用例实现是分离的，因此你可以独立地管理每一个，并更改用例设计，而不会影响到用例的基线。对于用例模型内的每个用例，带有“实现”构造型的依赖关系的设计模型中都存在一个用例实现。1、复审：什么事用例实现？一个用例实现是设计模型中一个特殊用例的表达式。它描述了协作对象方面的用例。一个用例实现将用例模型的用例和设计模型联系在一起。一个用例实现说明了每个用例必须用那些类来实现。在UML中，用例实现就是构造型协作。协作的符号是一个包含协作名字的椭圆。用例实现的符号是协作符号的虚线版。设计模型中的一个用例实现可被追踪到用例模型中的一个用例。一个实现关系就是从用例实现画到它实现的用例的带箭头的虚线。在UML中，一个用例实现可以使用一组图（顺序图、协作图和类图）来表示，这些图模拟协作（实现用例及它们关系的类/对象----类图）的环境，和它们的协作交互（这些类/对象是如何相互影响以执行用例的----协作图和顺序图）。要使用的这些图的数量和类型，取决于需要什么来提供一个协作和项目应用指南。2、用例实现的价值：用例形成了大多数早期分析和设计工作的主要集中点。为了能够在需求中心活动和设计中心活动间转换，用例实现扮演了桥梁的角色，提供了一种对设计模型到用例模型的逆行追踪行为的方式，也组织了围绕用例概念的设计模型中的协作。用例模型中的每个用例，都在设计模型中创建一个用例实现。用例实现的名称应当与其关联的用例一样，并且应当建立从用例实现到其关联用例的一个追踪依赖。4.9架构分析步骤（6）检查点4.10本章总结

第五章用例分析5.1章节目标1、用例分析的目的；何时执行？2、确定执行用例事件流的类。3、将用例行为分配给类，确定这些类的职责。4、开发用例实现，在所确定类的实例间构建协作模型。在用例分析中，首先确定初始类----分析类。将职责分配给它们，注意架构机制的使用。用例分析活动开发的关键模型元素：分析类和初始用例实现，将在后续的分析设计活动中被改进。5.2工具环境中的用例分析用例分析––––分析行为。初始架构已经定义，和软件需求一起作为输入指导和服务于用例分析活动。构架层及其职责，可能影响分析类的定义和职责分配。用例实现说明分析如何协作，以执行用例。用例实现将在用例设计模型中改进。5.3用例分析概述用例分析有设计员执行，每个用例实现进行一次迭代。目的：确定执行用例事件流的类。将用例行为分配给这些类。确定类的职责、属性和关联。记录架构机制的使用情况。5.4用例分析步骤以上是用例分析的步骤。复审用例描述，发掘足够多的细节。研究用例事件流，确定分析类，将用例职责分配给分析类，模型化分析类间的关系。将分析类的职责文档化。确保以开发的分析模型是一致的。5.5用例分析步骤（1）补充用例说明补充用例描述5.6用例分析步骤（2-1）对每一个用例实现从用例行为中查找类对需求更详细描述，并文档化，以确定候选分析类。从用例中查找行为，是为了确定备选的分析类（行为模型元素）。1、复审：类强调相关性。排除其它特性。一个类由三部分组成：类名；属性（结构）；操作（行为）。2、复审：用例实现理解用例实现中类的职责、角色以及如何交互，用以改进类的职责和接口。3、分析类：达成执行的第一步寻找分析类的候选集是系统转换的第一步。分析类代表早期的概念模型，它将不断被改进。分析类是“原型类”，其本质是“行为族”，经过改进和组合形成分离类、合并类、构件或子系统。4、从用例行为中查找类从三种角度识别类：系统与角色的边界（边界类）；系统使用信息（实体类）；系统的控制逻辑（控制类）。5、什么是分析类分析类是系统对象模型的“第一稿”，主要处理功能需求。三种类型：边界类；实体类；控制类。6、什么是边界类边界类是接口和系统外部事物的中间体。通常由三种边界类：用户界面类；系统接口类；设备接口类。初步建议：每对角色/用例考虑一个边界类。7、边界类角色边界类用于对系统环境与其内部运作之间的交互进行建模的类。边界类对系统中依赖于环境的那些部分进行建模。边界类用于隔离外部环境与内部机制之间的相互影响。边界类的生命周期长于或等于用例实例的生命周期。8、查找边界类考虑外部事件的来源，确保可检测。初步识别建议：每对角色/用例一个边界类（以后可以考虑删节或合并）。9、指南：边界类（关注职责、不究细节）不必注重细节考虑。用户界面类：关注展示给用户的信息；不必注重界面细节。系统和设备接口：关注必须定义的协议，不关注协议如何实现；可直接从接口定义派生。10、什么是实体类？系统的关键抽象。实体类显示了系统的逻辑树结构，提供了另一个了解系统的视点，有助于理解系统为用户提供的服务内容。发现实体类：词汇表（需求阶段）；业务领域模型（业务建模）；用例事件流（需求阶段）；关键抽象（架构分析）；行为分析（用例分析）。11、一个实体类角色实体类通常表示了系统的永久信息存储。实体类的主要职责是存储和管理系统中的信息。实体对象通常是系统的、甚至超系统范围的，而不是专属于某个用例。实体对象独立于环境（角色）。12、什么是控制类？用例行为协调器：如事物管理，资源协调，出错处理。控制类有效地将边界对象和实体对象分开，让系统更能适应边界内的变更。控制类还将用例特有行为与实体对象分开，提高实体对象的复用性。控制类提供的行为，有如下特点：------独立与环境。------确定用例的控制逻辑（事件顺序）和事务。------几乎不因实体结构或行为变更而变更。------协调实体类之间的行为。------执行方式具有多态性（事件流具有多种状态）。初始确定控制类，每个用例只能创建一个控制类，进一步分析时发现更多用例的共性时，再增加、删除或合并使用控制类。13、一个控制类角色（起的作用、担任的任务）一个控制类是用于对一个或多个用例所特有的控制行为进行建模的类。控制对象控制其它对象、协调它们的行为。控制类封装了用例的特有行为。控制类能表示系统动态行为，从处理主要任务和控制流的角度，帮助理解系统。系统执行用例时，产生控制对象，通常在用例执行完毕时控制对象消亡。15、总结：分析类每个用例实现都有一个或多个类图与它们的关系一起描述其参与类。这些图有助于确保用例实现中跨子系统边界的一致性。这样的类图被称为“参与类视图”：ViewofParticipatingClasses(VOPC)。5.7用例分析步骤（2-2）对每一个用例实现将用例行为分配给类“将用例行为分配给类”的目的是：按照协作分析类表述用例行为。确定分析类的职责。1、将用例行为分配给类通过用例事件流，确定为必要行为负责的分析类，准确给出被应用的时间。交互图用角色来显示于系统的交互，若有多个角色，将它们保持在图的外围。2、指南：将职责分配到类边界类：接口；控制类：事件流；实体类：永久性数据。那个类拥有执行职责的数据？----一个类拥有，将职责放在这个类；----多个类拥有，则：将职责交给一个类，并对其它类的增加一个关系（OO原则：数据和操作在一起）；创建一个新类，将职责交给它，并对需要执行职责类增加关系；将职责发起那个在控制类，并对需要执行职责类增加关系。注意：增加关系必须考虑模型的全面影响；尽可能重用已有的类，确认没有近似职责的类时，才创建新类。3、序列图剖析按时间顺序描述对象间的交互（用“生命线”和消息显示）。4、协作图剖析通过对象间的连接（关系）和相互发送消息，来显示参与交互的对象。。对象间的实线表示连接，通过连接实现交互或导航。消息使对象间的通信，它传达信息并期望活动随之发生。在连接旁带有标记的箭头表示消息，箭头的编号表示消息的顺序。用消息指向的目标对象的操作代替消息的名称，表明消息将会激发的操作。5、一个协作图并不充分将大多数事件流模型化，确保参与类操作的所有需求都被确定。从最通用和最重要的事件流（基础流）开始，然后说明变体（如异常流）。常见的异常流：出错处理；超时处理；错误输入处理等。可选流：系统下一步做什么；后续事件流依赖于存储的属性值或关系；后续事件流依赖于处理数据的类型。6、协作图VS.序列图两者表达相似的信息，以不同的方式显示；可捕捉用例事件流语义，帮助确定对象、类、接口和职责；帮助确认架构。协作图强调一组对象结构上的协作，提供了关系模式和控制更清晰的图画，有利于理解给定对象的所有影响，更适合于过程设计。序列图显示消息的顺序，更适合实时规约和复杂场景。时间维度更易理解、操作和参数更易展示、易于管理大量对象。序列图和协作图都允许捕捉用例事件流的语义；帮助确定对象、类、接口和职责；帮助确认构架。**************************************************2007-4-55.8用例分析步骤（3-1）对每一个得到的分析类说明职责此时，分析类已经确定，职责也已分配。说明分析类的职责。将分析类的内容文档化。1、说明职责对象可执行的操作。对象保留并提供给其它对象的知识。职责从消息中得到。类职责分析可用下面两种方式之一文档化：命名约定；文本描述。2、总结分析类每个用例实现都有一个或多个类图与它们的关系一起描述其参与类。这些图有助于确保用例实现中跨子系统边界的一致性。这样的类图被称为“参与类视图”：ViewofParticipatingClasses(VOPC)。3、维护一致性，期待什么？一个类存在互不相干的职责时，可将其分成两个或多个类。几个类有相似职责时，合并它们。只有一项职责的类，应对其必要性进行验证。类发生变更，必须更新交互图。5.9用例分析步骤（3-2）对每一个得到的分析类说明属性与关联关联：说明分析类依赖的其它类。说明该类必须了解的其它类中的事件。属性：说明分析类负责维护的信息。1、复审：什么是属性？属性被用来存储信息，它们是没有职责的原子事物。属性应当是名词；属性类型来源于领域。2、查找属性可能的属性来源：领域知识；需求；词汇表；业务模型；领域模型。信息本身才是重要的，而不是它的位置。如果信息有复杂行为，或被多个类共享，此时应将信息作为一个分离类被模型化。3、什么是关联？关联表示不同类的对象之间的结构，它在一段时间内将多个类的实例连接在一起。4、查找关系协作图中相互连接的对象或类，存在关联。自反关联，即递归关联。5、什么是聚合？聚合是一种特殊的关联，它表明了“整体/部分”的关系。6、关联或聚合？当“部分”游离于“整体”时，整体显得不完全时才使用聚合。当类与类之间的关系并非明显的“整体/部分”关系时，用关联，不用聚合。犹豫不决时，用关联、不用聚合。关联还是聚合，与建模的问题与有关。如整车经销和零配件经销的车和门。7、什么是角色（起的作用、担任的任务）？一个类在关联中承担的“任务”，即该类在关联中扮演的角色。8、复审：多重性（第一章翻译为“多样性”）关联类两端可关联对象数量的描述。9、多重性意味着什么？一个对象可以拥有另一个对象关系数量的上限和下限。为0的下限说明这个关系可选的，反之则是必须的。*说明数量是未知的。10、例子：多重关联两个类之间可以有多个关联，但应当表示不同的关系和担任不同的角色（职务）；而不是仅仅引起不同的操作。如果两个类之间有多个关联，则必须分别命名，以示区别和说明。多重关联必须仔细检查；一个类的一个实例与另一个类的多个分离实例连接，多重关联才是有效的。5.10用例分析步骤（3-3）对每一个得到的分析类限定分析机制限定分析机制的目的：确定类使用的分析机制（如果有的话）；提供更多关于类应用分析机制的信息。对每一个分析机制，应限定其特性、给定其适用范围、指出其不确定性。分析机制的特性往往并不十分精确，但很有价值，应当与类一起文档化。1、复审：为什么使用分析机制？减少分析的复杂性，提高分析的一致性。分析机制通常与问题领域无关（并不总是无关），属于“计算机科学”的概念。通常占据架构的中低层。如永久性、进程间通信、出错或故障处理、消息传递等处理机制。2、说明分析机制在架构分析中，确定和说明分析机制。方法：将所有分析机制收集在一张列表上；画一张类和分析机制图；确定分析机制的特性。5.11用例分析步骤（4）统一分析类现在必须复审我们的工作，确保转到构架活动前，尽可能地完全和一致。统一分析类的目的是确保每个分析类表示一个单一的、明确定义的概念，而不会出现职责重叠。1、统一分析类过滤分析类，确保创建数量最小的新概念。不同的用例将贡献给（使用）相同的类。一个类可参与多个（任意数量）用例。所以，必须检查每个类的一致性。合并行为相似或表现相同的类。合并说明相同属性的实体类，即使其行为不同；聚合合并类的行为。更新类和更新用例的“补充”说明同步。更新需求则应受控，因为需求是与客户的契约，任何变化都必须验证和控制。2、评估“用例分析”结果验证分析类是否满足系统的功能需求。验证分析类及其职责，是否与它们支持的协作一致。5.12用例分析步骤（5）检查点1、检查点：分析类类是合理的吗？每个类名都清楚地反映了它所扮演的角色了吗？类是否表示了一个单一的、明确定义的抽象？所有属性和职责在功能上是连接在一起的吗（任何属性和关系冗余，或不被用例实现需要，则应删除之）？类提供了必要的（用例实现和其它类要求的）行为了吗？类应当满足需求规格说明书中，对类的所有需求。2、检查点：用例实现所有主流和/或子流，包括异常流都已经被处理了吗？所有的对象都已经被发现了吗？所有行为都已经被明确分配给参与对象了吗？行为已经被分配到正确的对象上了吗？有几个交互图时，它们的关系是清洗和一致的吗？5.13本章总结用例分析的目的是什么？什么是分析类？说出三种钩造型的名称，并描述它们。什么是用例实现？描述分配职责给分析类的一些注意事项。用例分析期间，应当产生多少交互图？第六章确定设计元素6.1章节目标1、说明确定设计元素的目的，及其在生命周期何处执行。2、对分析类的交互进行分析，并确定设计模型元素：1）设计类2）子系统3）子系统接口确定设计元素执行了什么，但不描述执行过程是怎样实现的。通过理解用以支持构架决策的基本原理、考虑事项和约束构架设计完成的框架，进而理解系统构架。6.2在环境中确定设计元素确定设计元素是改进构架过程（工作流）的一个活动。架构分析过程的活动中定义了系统的层（集中于上层）；用例分析中，分析了需求和系统行为，并将职责分配到类（分析类）。确定设计元素过程中，分析类将被改进成设计元素（设计类、子系统和子系统接口）。用例分析关心“做什么”；架构活动关心“怎么做”（设计）；构架就是选择。6.3确定设计元素概述目的：对分析类的交互进行分析，以确定设计元素（设计类、子系统和子系统接口）。输入：补充约规；项目详细指南；软件构架文档；分析类；分析模型；设计模型。输出：设计模型元素----类；包；子系统。6.4确定设计元素步骤本章（确定设计元素）将要进行的活动：确定类和子系统；确定子系统接口；更新设计模型结构；检查点。6.5确定设计元素步骤（1）确定类和子系统确定类和子系统的目的是改进分析类，使之成为适当的设计元素。分析类将可能被扩充、推倒、合并，甚至删除；很少在设计过程中保持不变。1、从分析类到设计元素分析类将被改进为设计元素：比如设计类或子系统。决定哪个分析“类”是真正的类，哪些是子系统，哪些是既存的构件，根本不需要再进行“设计”。创建了设计类和子系统必须命名并简短描述，原始分析类的职责应当转移到新创建的子系统。已经确定的设计机制应当被连接到设计元素。2、确定设计类如果分析类是简单的，并已经表示了一个简单逻辑抽象，则可以直接一对一地影射为一个设计类。通常实体类可以在设计过程中保持相对完整。一般而言，分析类和设计元素之间有一个多对多的映射。比如，一个分析类可以成为设计模型中的：一个简单类；一个类的一部分；一个聚合类（聚合中的部分可能没有被明确模型化）；同一个类继承而来的组类；一组功能相关的类（例如，一个包）；一个子系统；一个关系。分析类间的一个关系，可以设计成设计模型中的一个类。一个分析类部分可以被硬件实现，而不必在设计模型中建模。分析类也可以被映射为以上的任何组合。3、复审：包和类什么是类？什么是包？4、将包中的设计类分组封装标准可基于不同因素：配置单元（提交单元）；开发队伍中的资源分配（子项目）；反映用户类型（子系统）；表示系统使用的既存产品和服务（子系统）。5、封装技巧：边界类如果系统接口可能进行相当大的更改，边界类应被放置在一个或多个单独的包中。一旦更改，将只会影响这些包，而不致波及其它。如果接口不会有较大更改，则应将边界类与功能相关的实体类和控制类放置在一起。如果实体类和控制类变化，就很容易看出哪些边界类受影响。6、封装技巧：功能相关类确定功能是否相关类的标准：----一个类的行为和/或结构发生变化，使得另一个类必须相应地变化。----一个类的删除，影响其他类。----两个对象进行大量的消息交互，或以复杂的方式通信（交互），这两个对象就可能在功能上相关。----如果某个边界类的功能是显示一个特定的实体类，这个边界类就可能与该实体类功能相关。----如果两个类与同一个actor交互，或受到同一个actor变更的影响，这两个类就可能功能相关。----两个类之间存在某些关系。----一个类创建另一个类的实例。确定何时不应将两个类放在同一个包中的标准：----与不同actor相关的两个类，不应放在同一个包中。----一个可选类和一个必选类，不应放在同一个包中。7、包依赖关系：包元素的可见性包中元素的可见性与类的属性和操作的可见性相同：允许其它包（或类）访问该包（或类）元素。（可见性即可访问性）UML定义了三种可见性：----Public （公共）：符号：+，外部均可访问。----Protected（保护）：符号：#，可以被其拥有包，以及从其拥有包继承的包所访问。----Private （私有）：符号：-，只能被其拥有包中的类所访问。一个包的公共元素组成了包的接口。包的依赖关系就是对包公共元素的依赖关系。包的可见性提供了对OO封装原则的支持。8、包耦合度：提示不应进行交叉耦合（相互依赖）包的依赖只能指向同层或下层，不能指向高层。通常，不能跳层依赖，除非依赖行为在所有层之间都是共通的，或仅用于简化各层之间的传递操作调用。包不应依赖子系统，而只能依赖其它包或接口。9、复审：子系统和接口子系统是同时具有包（可包含其它元素）和类（具有行为）的语义的模型元素，用带有《》标记的包来表示，它将实现定义其行为的一个或多个接口。接口是一个模型元素，它确定了有一个分类器（类、子系统或构件）提供的一组行为（一组操作）。实现是两个分类器之间的语义关系，一个分类器服务于其它分类器同意承担的契约。接口是从一个包的公共类到外部（通过包含这个包的子系统）的一个规范的抽象。外部只能通过接口和子系统通信，子系统也只能通过接口接受外部信息并将响应结果传递到外部。子系统中所有类都是私有的，不能从外部直接访问。10、子系统和接口（续）接口封装了子系统的实现细节，并将其与构架的其余部分隔离开来。接口所确定的操作被子系统所包含的一个或多个元素实现。接口提供了实现它的分类器必须支持的行为族。接口和实现的分离，例证了OO概念的模块性和封装性。（和抽象类不同，接口不提供缺省行为，所以接口不是抽象类）。一个接口，可以被一个或多个子系统实现。实现统一接口的子系统可以互换。这样，只要接口保持不变，子系统的内容和内部行为可以完全自由地更改。11、包与子系统对比子系统： 包：----提供行为（通过接口）。 ----不一定提供行为。----完全封装其行为。 ----不一定完全封装其行为。----易于替代。 ----不完全封装就不易替代。12、子系统使用方法子系统可被用来将系统划分成若干部分，这些部分可以是：----被定制、被配置、或被提交----被开发，只要接口保持不变----被部署，跨越一组分布式计算节点----被修改，而不破坏系统的其它部分子系统可被用于：----将系统划分成单元，其中可以提供对关键资源的受限安全性----表示设计中既存产品或外部系统（例如，构件）13、确定子系统：提示查看对象（类）协作：如果一组协作类仅仅相互协作就可以产生明确定义的结果集，那么就将它们封装在一个子系统中。查看可选性：如果协作建模的行为，可以被删除、升级、或选择替代的特性，那么就将它们封装在一个子系统中。查看系统的用户界面（用户接口）：创建“水平”子系统（边界类和相关实体类在不同的子系统中）或“垂直”子系统（边界类和相关实体类在同一个子系统中），取决于用户界面和实体类的耦合度。查看主角（actor）：使用不同的actor划分功能，因为每个actor都可以独立地修改需求。查看类之间的耦合和聚合：将高度耦合的类组成子系统，沿着弱耦合线进行分离。查看替代：一个分离子系统的一个特殊性能的不同级别服务（例如高、中、低），它们实现同一个接口。查看分布：如果特殊的功能必须存在于一个特殊节点，确保子系统功能映射在一个单一的节点。查看挥发度：你应尽量把你期望修改部分封装在同一个（或尽可能少）的子系统中。14、候选子系统可能发展为子系统的分析类：----提供复杂服务和/或程序的类----金融应用软件中的信用或风险评估引擎----商业应用软件中基于规则的评估引擎----大多数应用软件中的安全授权服务----边界类，包括用户界面和外部系统接口设计中的既存产品或外部系统（例如，构件），系统所使用的可在一个子系统中表示的产品包括：----通信软件（中间件，COM/CORBA）----数据库访问支持（RDBMS）----类型和数据结构（堆栈、列表、队列）----通用程序（数学库——算法库）----专业应用软件产品（计费系统、日程安排系统）接口（提供了接口的子系统）和实现之间必要的解偶。15、确定子系统如果分析类相当复杂，其行为不能由单个类独自承担，应将该分析类映射到设计子系统。使用设计子系统来封装这些行为，客户不必知道子系统的内部设计。可以首先确定子系统的接口，而其接口实施的设计细节则可在子系统设计阶段进行。是否要将某些事物发展成一个子系统，常常由架构师的知识和经验所决定。6.6确定设计元素步骤（2）确定子系统接口接口通常定义子系统的操作集。接口就是子系统行为的声明，它将这些行为在子系统内的实现分离，从而完成对子系统的封装。1、确定接口确定子系统，首先必须确定其职责。基于子系统的职责来确定其接口。将职责分组，每组作为一个候选接口。为每个职责确定一个操作、及其使用参数和返回值。分析候选接口、职责和操作，寻找相似点、重新组成接口，并尽可能复用现有接口。定义接口依赖关系。将接口映射到子系统：建立子系统和接口间的实现关系。将接口打包：独立于子系统对接口进行管理和控制，依照其职责划分接口。2、接口指南接口名：名称简洁、反映接口在系统中的作用。接口描述：说明接口的职责。操作定义：每个接口应提供一个唯一的、定义明确的操作集；操作名称应反映操作结果；说明操作什么、以及所有参数（包括返回结果）类型。接口文档：接口所定义的行为被表示为操作集，并按以上要求给出说明。3、例子：设计子系统和接口计费系统和课程目录系统在用例分析中是两个边界类。由于其功能复杂且由外部系统实现，故设计成两个子系统和与之对应的接口。完成了从分析类到设计元素的映射。4、建模约定：子系统和接口《subsystem》包、《subsystemproxy》类和以I作为命名首字符的接口。5、例子：子系统环境：CourseCatalogSystem子系统环境包括：子系统、接口、代理类、依赖和实现关系以及任何子系统关系。6、例子：子系统环境：BillingSystem子系统环境包括：子系统、接口、代理类、依赖和实现关系以及任何子系统关系。6.7确定设计元素步骤（3）确定复用机会确定复用机会是一个重要的构架步骤。复用会带来极大的好处，但必须对系统行为有较好理解和确定设计元素工作基本清晰之后统筹考虑。1、确定复用机会目的：根据现有子系统和/或构件的接口确定可以在哪些地方复用。步骤：1）寻找相似接口；2）修改新确定的接口，以增强匹配性；3）将被选接口替换成现有接口；4）将备选子系统映射到现有构件。2、可能复用的机会被开发系统内部：识别跨包和子系统的共性。被开发系统外部：商业上可得到的构件；先前开发的应用软件构件；反向设计构件。3、对系统的内部复用的机会发现和寻找设计元素的共性：开发公共元素或构件。力求实现设计元素的通用性：为今后的复用及需求的变更考虑。建立以复用为目的的构件库（不断积累、分类管理）。6.8确定设计元素步骤（4）更新设计模型结构1、复审：典型分层方法应用层；业务规则层；中间件层；