前言
第5章对应的内容选择题和案例分析都会进行考查，这一章节属于技术的内容，学习要以教材为准。
目录
5.1 软件工程定义
5.2 软件需求
5.2.1 需求的层次
5.2.2 质量功能部署
5.2.3 需求获取
5.2.4 需求分析
5.2.5 需求规格说明书
5.2.6 需求变更
5.2.7 需求跟踪
5.3 软件设计
5.3.1 结构化设计
5.3.2 面相对象设计
5.3.3 统一建模语言
5.3.4 设计模式
5.1 软件工程定义
软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。
软件工程由方法、工具和过程3个部分组成。
5.2 软件需求
5.2.1 需求的层次
需求是多层次的，包括业务需求、用户需求和系统需求，不同层次的需求从目标到具体，从整体到局部，从概念到细节。
①业务需求
业务需求是指反映组织机构或用户对系统、产品高层次的目标要求，从总体上描述了为什么要达到某种效应，组织希望达到什么目标。
②用户需求
用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务和想要达到的结果，这构成了用户原始需求文档的内容。
③系统需求
系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和约束等。
▲功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。功能需求通常是通过系统特性的描述表现出来的。所谓特性，是指一组逻辑上相关的功能需求，表示系统为用户提供某项功能(服务)，使用户的业务目标得以满足。
▲非功能需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和合约，是指系统必须具备的属性或品质，又可细分为软件质量属性(易用性、可维护性、效率等)和其他非功能需求。
▲约束是指对开发人员在软件产品设计和构造上的限制，常见的有设计约束和过程约束。（例如：必须采用安全可靠的自主知识产权的数据库系统，必须运行在开源操作系统之下等。）
5.2.2 质量功能部署
质量功能部署(Quality Function Deployment, QFD)，即通过多种角度对产品的特点进行描述，从而反映产品功能，是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为3类，分别是常规需求、期望需求和意外需求。
▲常规需求。用户认为系统应该做到的功能或性能，实现得越多，用户会越满意。
▲期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
▲意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性)，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以(出于成本或项目周期的考虑)选择不实现任何意外需求。
5.2.3 需求获取
需求获取是开发者、用户之间为了定义新系统而进行的交流，需求获取是获得系统必要的特征，或者是获得用户能接受的、系统必须满足的约束。如果双方所理解的领域内容在系统分析、设计过程出现问题，通常在开发过程的后期才会被发现，将会使整个系统交付延迟，或者上线的系统无法或难以使用，最终导致项目失败。例如，遗漏的需求或理解错误的需求。
5.2.4 需求分析
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。需求分析的关键在于对问题域的研究与理解。
1 结构化分析
结构化分析（Structured Analysis，SA）方法给出一组帮助系统分析人员产生功能规约的原理与技术，其建立模型的核心是数据字典。围绕这个核心，有3个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。在实际工作中，一般使用实体关系图（E-R图）表示数据模型，用数据流图（Data Flow Diagram，DFD）表示功能模型，用状态转换图（State Transform Diagram,STD)表示行为模型。
▲数据模型：实体关系图（E-R图）主要描述实体、属性，以及实体之间的关系；
▲功能模型：数据流图DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能；
▲行为模型：状态转换图STD通过描述系统的状态和引起系统状态转换的事件，指出作为特定事件的结果将执行哪些动作。
结构化分析通常包含以下步骤:分析业务情况，做出反映当前物理模型的DFD；推导出等价的逻辑模型的DFD；设计新的逻辑系统，生成数据字典和基元描述;建立人机接口，提出可供选择的目标系统物理模型的DFD;确定各种方案的成本和风险等级，据此对各种方案进行分析;选择一种方案;建立完整的需求规约。
概念模型也称为信息模型，它是按用户的观点来对数据和信息建模，也就是说，把现实世界中的客观对象抽象为某一种信息结构，这种信息结构不依赖于具体的计算机系统，也不对应某个具体的数据库管理系统。逻辑模型是在概念模型的基础上确定模型的数据结构，目前主要的逻辑模型有层次模型、网状模型、关系模型、面向对象模型和对象关系模型。物理模型是在逻辑模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。
DFD需求建模方法也称为过程建模和功能建模方法。DFD建模方法的核心是数据流，从应用系统的数据流着手，以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流。DFD方法由以下4种基本元素（模型对象）组成：数据流、处理/加工、数据存储和外部项。
建立DFD图的目的是描述系统的功能需求。DFD方法利用应用问题域中数据及信息的提供者与使用者、信息的流向、处理和存储这4种元素描述系统需求，建立应用系统的功能模型。具体的建模过程及步骤如下：明确目标，确定系统范围；建立顶层DFD图；构建第一层DFD分解图；开发DFD层次结构图；检查确认DFD图。
数据字典（Data Dictionary）是一种用户可以访问的记录数据库和应用程序元数据的目录。数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述，其目的是对数据流图中的各个元素做出详细的说明。简而言之，数据字典是描述数据的信息集合，是对系统中使用的所有数据元素定义的集合。数据字典最重要的作用是作为分析阶段的工具。任何字典最重要的用途都是供人查询，在结构化分析中，数据字典的作用是给数据流图上的每个元素加以定义和说明。换句话说，数据流图上所有元素的定义和解释的文字集合就是数据字典。数据字典中建立的严密一致的定义，有助于改进分析员和用户的通信与交互。
2 面相对象分析
面向对象的分析(0biect-OrientedAnalvsis，OOA)方法能正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。
OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。OOA模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务)组成。在这种方法中定义了两种对象类之间的结构，分别是分类结构和组装结构。分类结构就是所谓的一般与特殊的关系;组装结构则反映了对象之间的整体与部分的关系。
OOA的基本原则主要包括抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制和行为分析。
▲抽象：是从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征。抽象是形成概念的必要手段。抽象是面向对象方法中使用最为广泛的原则。抽象原则包括过程抽象和数据抽象两个方面。数据抽象是OOA的核心原则，它强调把数据（属性）和操作（服务）结合为一个不可分的系统单位（对象），对象的外部只需要知道它做什么，而不必知道它如何做。
▲封装：把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。
▲继承：特殊类的对象拥有其对应的一般类的全部属性与服务，称作特殊类对一般类的继承。在OOA中运用继承原则，在特殊类中不再重复地定义一般类中已定义的内容，但是在语义上，特殊类却自动地、隐含地拥有一般类（以及所有更上层的一般类）中定义的全部属性和服务。继承原则的好处是能够使系统模型比较简练、清晰。
▲分类：把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则运用于对象描述时的一种表现形式。
▲聚合：又称组装，其原则是把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。
▲关联：关联是人类思考问题时经常运用的思想方法，即通过一个事物联想到另外的事物。能使人发生联想的原因是事物之间确实存在着某些联系。
▲消息通信：这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。通过消息进行通信是由于封装原则而引起的。在OOA中要求用消息连接表示出对象之间的动态联系。
▲粒度控制：一般来讲，人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。因此需要控制自己的视野，即考虑全局时，注意其大的组成部分，暂时不考虑具体的细节，考虑某部分的细节时则暂时撇开其余的部分。这就是粒度控制原则。
▲行为分析：现实世界中事物的行为是复杂的，由大量的事物所构成的问题域中，各种行为往往相互依赖、相互交织。
OOA大致遵循如下5个基本步骤: 确定对象和类；确定结构；确定主题；确定属性；确定方法。
5.2.5 需求规格说明书
软件需求规格说明书(Software Requirement Specification,SRS)是在需求分析阶段需要完成的文档，是软件需求分析的最终结果，是确保每个要求得以满足所使用的方法。编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，任何规模和性质的软件项目都不应该缺少。
在国家标准《计算机软件文档编制规范》（GB/T8567）中，提供了一个SRS的文档模板和编写指南，其中规定SRS应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。
有必要对于SRS的正确性进行验证，以确保需求符合良好特征。需求验证也称为需求确认，其活动需要确定的内容包括：SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征；SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的；需求是完整的和高质量的；需求的表示在所有地方都是一致的；需求为继续进行系统设计、实现和测试提供了足够的基础。在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。
5.2.6 需求变更
① 变更控制过程
② 变更策略
常见的需求变更策略主要包括：
所有需求变更必须遵循变更控制过程；
对于未获得批准的变更，不应该做设计和实现工作；
应该由项目变更控制委员会决定实现哪些变更；
项目风险承担者应该能够了解变更的内容；
绝不能从项目配置库中删除或者修改变更请求的原始文档；
每一个集成的需求变更必须能跟踪到一个经核准的变更请求。
目前存在很多问题跟踪工具，这些工具用来收集、存储和管理需求变更。问题跟踪工具也可以随时按变更状态分类报告变更请求的数目和实现情况等。
③ 变更控制委员会
变更控制委员会（Change Control Board，CCB）是项目所有者权益代表，负责裁定接受哪些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。变更控制委员会可能包括如下方面的代表：产品或计划管理部门；项目管理部门；开发部门；测试或质量保证部门；市场部或客户代表；用户文档的编制部门；技术支持部门；桌面或用户服务支持部门；配置管理部门。
变更控制委员会应该有一个总则，用于描述变更控制委员会的目的、管理范围、成员构成、做出决策的过程及操作步骤。总则也应该说明举行会议的频度和事由等。管理范围描述该委员会能做什么样的决策，以及哪一类决策应上报到高一级的委员会。过程及操作步骤主要包括制定决策、交流情况和重新协商约定等。
制定决策。制定决策过程的描述应确认： ①变更控制委员会必须到会的人数或做出有效决定必须出席的人数； ②决策的方法，例如投票、一致通过或其他机制；③变更控制委员会主席是否可以否决该集体的决定等。变更控制委员会应该对每个变更权衡利弊后做出决定：“利”包括节省的资金或额外的收入、增强的客户满意度、竞争优势、减少上市时间等；“弊”是指接受变更后产生的负面影响，包括增加的开发费用、推迟的交付日期、产品质量的下降、减少的功能、用户不满意度等。
交流情况。一旦变更控制委员会做出决策，相应的人员应及时更新请求的状态。
重新协商约定。变更总是有代价的，即使拒绝的变更也因为决策行为（提交、评估、决策）而耗费了资源。当项目接受了重要的需求变更时，为了适应变更情况，要与管理部门和客户重新协商约定。协商的内容可能包括推迟交付时间、要求增加人手、推迟实现尚未实现的较低优先级的需求，或者质量上进行调整等。
5.2.7 需求跟踪
需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有正向跟踪和逆向跟踪两种方式。
正向跟踪：检查SRS中的每个需求是否都能在后继工作成果中找到对应点；
逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。跟踪能力是优秀SRS的一个特征，为了实现可跟踪能力，必须统一地标识出每一个需求，以便能明确地进行查阅。
5.3 软件设计
软件设计的目标是根据软件分析的结果，完成软件构建的过程。需求阶段解决“做什么”的问题，而软件设计阶段解决“怎么做”的问题。从方法上来说，软件设计分为结构化设计与面向对象设计。
5.3.1 结构化设计
结构化设计（Structured Design，SD）是一种面向数据流的方法，其目的在于确定软件结构。它以SRS（软件需求规格说明书）和SA（结构化分析）阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐层分解、逐步求精和模块化的过程。SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构。从管理角度讲，其分为概要设计和详细设计两个阶段。概要设计又称为总体结构设计，它是开发过程中很关键的一步，其主要任务是确定软件系统的结构，将系统的功能需求进行模块划分，确定每个模块的功能、接口和模块之间的调用关系，形成软件的模块结构图，即系统结构图。在概要设计中，将系统开发的总任务分解成许多个基本的、具体的任务，而为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。详细设计的主要任务是为每个模块设计实现的细节，根据任务的不同，详细设计又可分为多种，例如，输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等。
1 模块结构
在结构化设计SD中，这种功能分解就是将系统划分为模块，模块是组成系统的基本单位，它的特点是可以自由组合、分解和变换，系统中任何一个处理功能都可以看成一个模块。
①信息隐藏与抽象。信息隐藏原则要求采用封装技术，将程序模块的实现细节（过程或数据等）隐藏起来，对于不需要这些信息的其他模块来说是不能访问的，使模块接口尽量简单。按照信息隐藏的原则，系统中的模块应设计成“黑盒”，模块外部只能使用模块接口说明中给出的信息，如操作和数据类型等。模块之间相对独立，既易于实现，也易于理解和维护。抽象原则要求抽取事物最基本的特性和行为。
②模块化。在SD方法中，模块是实现功能的基本单位，它一般具有功能、逻辑和状态3个基本属性。其中，功能是指该模块“做什么”，逻辑是描述模块内部“怎么做”，状态是该模块使用时的环境和条件。
③耦合。耦合表示模块之间联系的程度。紧密耦合表示模块之间联系非常强，松散耦合表示模块之间联系比较弱，非直接耦合则表示模块之间无任何直接联系。模块的耦合类型通常分为7种，根据耦合度从低到高排序如下所示。
④内聚。内聚表示模块内部各代码成分之间联系的紧密程度，是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做目标单一的一件事情。模块的内聚类型通常也可以分为7种，根据内聚度从高到低排序如下所示。
一般来说，系统中各模块的内聚越高，则模块间的耦合就越低，但这种关系并不是绝对的。耦合低使得模块间尽可能相对独立，各模块可以单独开发和维护；内聚高使得模块的可理解性和维护性大大增强。因此，在模块的分解中应尽量减少模块的耦合，力求增加模块的内聚，遵循“高内聚、低耦合”的设计原则。
2 系统结构图
系统结构图（Structure Chart，SC）又称为模块结构图，它是软件概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总体结构。在系统分析阶段，系统分析师可以采用SA方法获取由DFD（数据流图）、数据字典和加工说明等组成的系统的逻辑模型；在系统设计阶段，系统设计师可根据一些规则，从DFD中导出系统初始的SC。
详细设计的主要任务是设计每个模块的实现算法、所需的局部数据结构。详细设计的目标有两个：实现模块功能的算法要逻辑上正确；算法描述要简明易懂。详细设计必须遵循概要设计来进行。详细设计方案的更改，不得影响到概要设计方案；如果需要更改概要设计，必须经过项目经理的同意。详细设计应该完成详细设计文档，主要是模块的详细设计方案说明。设计的基本步骤如下:分析并确定输入/输出数据的逻辑结构；找出输入数据结构和输出数据结构中有对应关系的数据单元；按一定的规则由输入、输出的数据结构导出程序结构；列出基本操作与条件，并把它们分配到程序结构图的适当位置；用伪码写出程序。
详细设计的表示工具有图形工具、表格工具和语言工具。
①图形工具。利用图形工具可以把过程的细节用图形描述出来。具体的图形有业务流程图、程序流程图、问题分析图（Problem Analysis Diagram， PAD）、NS流程图（由Nassi和Shneiderman开发，简称NS）等。
业务流程图：是一种描述管理系统内各单位、人员之间的业务关系、作业顺序和管理信息流向的图表。
程序流程图：又称为程序框图，是使用最广泛的一种描述程序逻辑结构的工具。它用方框表示一个处理步骤，用菱形表示一个逻辑条件，用箭头表示控制流向。其优点是结构清晰，易于理解，易于修改；缺点是只能描述执行过程而不能描述有关的数据。
NS流程图：也称为盒图或方框图，是一种强制使用结构化构造的图示工具。其具有以下特点：功能域明确，不可能任意转移控制，很容易确定局部和全局数据的作用域，很容易表示嵌套关系及模板的层次关系。
PAD图：是一种改进的图形描述方式，可以用来取代程序流程图，比程序流程图更直观，结构更清晰。最大的优点是能够反映和描述自顶向下的历史和过程。PAD提供了5种基本控制结构，并允许递归使用。包括：顺序型、选择型、多分支选择型、WHILE重复型和UNTIL重复型。
②表格工具。可以用一张表来描述过程的细节，在这张表中列出了各种可能的操作和相应的条件。
③语言工具。用某种高级语言来描述过程的细节，例如伪码或PDL （Program Design Language）等。PDL也可称为伪码或结构化语言，它用于描述模块内部的具体算法，以便开发人员之间比较精确地进行交流。语法是开放式的，其外层语法是确定的，而内层语法则不确定。外层语法描述控制结构，它用类似于一般编程语言控制结构的关键字表示，所以是确定的。内层语法描述具体操作，考虑到不同软件系统的实际操作种类繁多，内层语法因而不确定，它可以按系统的具体情况和不同的设计层次灵活选用。
◆ PDL的优点：可以作为注释直接插在源程序中；可以使用普通的文本编辑工具或文字处理工具产生和管理；已经有自动处理程序存在，而且可以自动由PDL生成程序代码。
◆ PDL的不足：不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时不如判定树清晰简单。
5.3.2 面相对象设计
面向对象设计（Object—OrientedDesign，OOD）是OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。在OOD中，数据结构和在数据结构上定义的操作算法封装在一个对象之中。由于现实世界中的事物都可以抽象出对象的集合，所以OOD方法是一种更接近现实世界、更自然的软件设计方法。OOD的主要任务是对类和对象进行设计，这是OOD中最重要的组成部分，也是最复杂和最耗时的部分。其主要包括类的属性、方法，以及类与类之间的关系。OOD的结果就是设计模型。对于OOD而言，在支持可维护性的同时，提高软件的可复用性是一个至关重要的问题，如何同时提高软件的可维护性和可复用性，是OOD需要解决的核心问题之一。
在OOD中，可维护性的复用是以设计原则为基础的。常用的OOD原则包括：
①单职原则：一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
②开闭原则：对扩展开放，对修改封闭。
③里氏替换原则：子类可以替换父类，即子类可以扩展父类的功能，但不能改变父类原有的功能。
④依赖倒置原则：要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现编程。
⑤接口隔离原则：使用多个专门的接口比使用单一的总接口要好。
⑥组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。
⑦迪米特原则（最少知识法则）：一个对象应当对其他对象有尽可能少的了解。其目的是降低类之间的耦合度，提高模块的相对独立性。
在OOD中，类可以分为3种类型:实体类、控制类和边界类。
①实体类映射需求中的每个实体，是指实体类保存需要存储在永久存储体中的信息。学员类和课程类，它们都属于实体类。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。通常情况下，实体类一定有属性，但不一定有操作。
②控制类是用于控制用例工作的类，一般是由动宾结构的短语（“动词+名词”或“名词+动词”）转化来的名词。控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系统执行用例的时候，就产生了一个控制对象，控制对象经常在其对应的用例执行完毕后消亡。通常情况下，控制类没有属性，但一定有方法。
③边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。常见的边界类有窗口、通信协议、打印机接口、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来处理。边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更分隔开，使这些变更不会对系统的其他部分造成影响。通常情况下，边界类可以既有属性也有方法。
5.3.3 统一建模语言
从总体上来看，统一建模语言UML的结构包括构造块、规则和公共机制3个部分。
UML有3种基本的构造块，分别是事物（thing）、关系（relationship）和图（diagram）。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
规则是构造块如何放在一起的规定。
公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。
①UML中的事物
UML中的事物也称为建模元素，包括结构事物(Structural Things)、行为事物(BehavioralThings，也称动作事物)、分组事物(Grouping Things)和注释事物(Annotational Things，也称注解事物)。这些事物是UML模型中最基本的OO(面向对象)构造块。
②UML中的关系
UML用关系把事物结合在一起，主要有4种关系：依赖、关联、泛化和实现。
▲依赖（Dependency）。依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
▲关联（Association）。关联是指一种对象和另一种对象有联系。
▲泛化（Generalization）。泛化是一般元素和特殊元素之间的分类关系，描述特殊元素的对象可替换一般元素的对象。
▲实现（Realization）。实现将不同的模型元素（例如，类）连接起来，其中的一个类指定了由另一个类保证执行的契约。
③UML2.0中的图
④UML视图
UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说，就是指逻辑视图、进程视图、实现视图、部署视图和用例视图这5个系统视图。
①逻辑视图。逻辑视图也称为设计视图，它用系统静态结构和动态行为来展示系统内部的功能是如何实现的，其侧重点在于如何得到功能。它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
②进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
③实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
④部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
⑤用例视图。用例视图是最基本的需求分析模型。它从外部角色的视角来展示系统功能。
另外， UML还允许在一定的阶段隐藏模型的某些元素、遗漏某些元素，以及不保证模型的完整性，但模型要逐步地达到完整和一致。
5.3.4 设计模式
设计模式是前人经验的总结，它使人们可以方便地复用成功的软件设计。当人们在特定的环境下遇到特定类型的问题，采用他人已使用过的一些成功的解决方案，一方面可以降低分析、设计和实现的难度，另一方面可以使系统具有更好的可复用性和灵活性。设计模式包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。
◆ 根据处理范围不同，设计模式可分为类模式和对象模式。
类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系；
对象模式处理对象之间的关系，这些关系在运行时刻变化，更具动态性。
◆ 根据目的和用途不同，设计模式可分为创建型（Creational）模式、结构型（Structural）模式和行为型（Behavioral）模式3种。
创建型模式主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等；
结构型模式主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等；
行为型模式主要用于描述类或对象的交互以及职责的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。
至此，本文分享的内容就结束啦！🌺🌺🌺🌺🌺🌺🌺🌺🌺
