【系统分析师】系统设计*_系统分析系统设计系统实现-CSDN博客

本文链接：https://blog.csdn.net/Sanayeah/article/details/137961713

文章目录

1、系统设计概述
- 1.1 系统设计主要内容
- 1.2 系统设计方法
2、处理流程设计
3、结构化设计-SD
4、面向对象设计-OOD
5、 "4+1"视图

【系统分析师-系列文章目录】

注：[系统分析师]考试中，系统设计部分，略重点内容

在这里插入图片描述

1、系统设计概述

系统分析阶段解决“做什么”的问题，系统设计阶段解决“怎么做”的问题。
系统设计阶段又称物理设计阶段。其任务是根据系统规格说明书中规定的功能要求》考虑实际条件，具体设计实现逻辑模型的技术方案，也就是设计新系统的物理模型。
主要目的是：绘制系统蓝图、权衡和比较各种技术和实施方法的利弊，合理分配各种资源，构建新系统的详细设计方案和相关模型。

1.1 系统设计主要内容

系统设计的主要内容包括：概要设计和详细设计

概要设计：又称系统总体结构设计。主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，行成软件的模块结构图，即系统结构图。
详细设计：将系统开发的总任务分解成多个基本的、具体的任务，为每个具体的任务选择适当的技术手段和处理方法的过程，称为详细设计。根据任务的不同，详细设计又可以分为多种，如：1、网络设计；2、代码设计；3、输入输出设计；4、处理流程设计；5、数据存储设计；6、用户界面设计；7、安全性和可靠性设计等。

1、概要设计：把系统拆分，系统-子系统-模块-子模块   
				拆分后，模块之间如何衔接，模块间的交互
				= 架构设计（注：结构化设计和架构设计的联系？不同时期的名词！）
2、详细设计：对应单个模块的内部设计

1、网络设计

在这里插入图片描述

2、代码设计

确定编码对象，考察是否有标准代码；
需要确定代码的种类与类型；
编写代码表

3、输入输出设计

输入设计的目的是：确保系统输入的数据的完整性、正确性和一致性。
输入设计的目的是：确保系统输出数据的完整性、正确性和一致性。

输入设计需要遵循的原则：

输入数据最小原则
简单性原则
尽早验证原则
少转换原则

系统输出一般包括中间输出和最终输出，用户关系的是最终输出，最常用的最终输出方式有两种：1.报表输出；2.图形输出。

4、处理流程设计

重点

是系统详细设计的重要组成部分；
主要目的是：确定各个系统模块的内部结构，即内部执行过程，包括局部数据组织和控制流，以及每个具体加工构成和实施细节。

5、数据存储设计

数据的统筹安全
文件的数据结构设计

6、用户界面设计

置于用户控制之下
减轻用户的记忆负担
保持界面的一致性

非重点，考的话，就此页

# 人机界面设计的三大原则
1、置于用户控制之下
2、减少用户的记忆负担
3、保持界面的一致性

# 1、置于用户的控制之下
以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式；
提供灵活的交互；
允许用户交互可以被中断和取消；
当技能级别增加时 可以使交互流水化 并 允许定制交互
使用户隔离内部技术细节；
设计应允许用户和出现在屏幕上的对象直接交互
# 2、减少用户的记忆负担
减少对短期记忆的要求；
建议有意义的缺省；
定义直觉性的捷径；
界面的视觉布局 应该 基于真实世界的隐喻；
以不断进展的方式揭示信息。
# 3、保持界面的一致性
允许用户当当前任务放入有意义的语境；
在应用系列内保持一致性
如 过去的交互模型 已建立起了用户期望，除非有迫不得已的理由，不要去改变它。

7、安全性和可靠性设计

系统运行环境安全性分析和控制
对数据处理的控制

1.2 系统设计方法

主要有两种：

结构化设计方法
面向对象设计方法

补充：两种设计方法的对比！

在这里插入图片描述

2、处理流程设计

处理流程设计的任务是设计出系统所有模块以及它们之间的相互关系，并具体设计出每个模块内部的功能和处理过程，为开发人员提供详细的技术资料。
对于处理流程的理解和实现，将直接影响系统的功能和性能。

补充：业务流程分析方法
在这里插入图片描述
补充：业务流程建模方法
Question：业务流程建模是要做什么？
Ans：通过对企业内部各项业务活动的分析、抽象和表达，以图形化的方式展现出企业的业务流程。其主要目的在于提供一个有效的可视化工具，帮助企业更好地理解、分析和管理自身的业务流程，从而实现流程的优化和改进。

# 业务流程建模 - BPM	了解即可
1、标杆瞄准
2、IDEF
3、DEMO
4、Petri网
5、业务流程建模语言
6、基于服务的BPM

只会考选择
在这里插入图片描述

2.1 流程设计概述

1、流程
在这里插入图片描述流程的概念包括： 1）流程定义和 2）流程实例。

流程定义：对业务过程的形式化表示，定义了过程运行中的活动和所涉及的各种信息。
流程实例：也称为工作，是一个流程定义的运行实例，即一次具体的流程操作，如：一次在线测试过程，一次在线支付过程等。

流程设计人员，可以通过流程定义工具来定义流程。流程定义工具可以是独立的软件，也可以是工作流管理系统的一部分。

2、工作流

简单来讲，工作流就是一系列相互衔接、自动进行的业务活动或任务。一个工作流包括一组活动（或任务）及它们之间的相互顺序关系，还包括流程和活动的启动和终止条件，以及对每个活动的描述。

工作流管理是人与计算机共同工作的自动化协调、控制和通信，在信息化的业务过程中，通过在网络上运行相应的软件，使所有活动都处于受控状态。在工作流管理下，可以对工作进行监控，并可以进行工作的指派。

# 上面两段话比较官方，配合个实例来理解
在线教育平台系统中的开通课程流程：
对应需要传递的信息就是课程申请单，
员工填写好课程申请单后可将其发送给上级主管审批，
上级主管审批后可转交培训部门备案，
培训部门成功备案后可转交财务部门，以便核算辅导老师的工资。

整个流程包括多个活动，不同的用户执行不同的活动，
每个活动均有其起始和终止条件

3、活动及其所有者

活动是流程定义中的一个基本要素。
一次活动可以改变流程处理数据的内容、流程的状态，并可能将流程推动到其他活动中去。活动可以由人来完成，也可以是系统自动进行处理（如：通过时间等自动触发的活动）。每个活动均有输入、处理和输出。

活动的所有者是流程的参与者之一（人或其他系统），ta们有权决定该活动是否结束，当活动结束时，可以将活动推动到其他活动中，可能是下一个活动，也可能是前一个活动。
活动的所有者是有权整体控制流程实例执行过程的参与者。通常活动的所有者是流程的发起人，ta们对流程的各项活动都很关注，而且可以整体控制流程实例的执行。如：开通课程流程中中创建课程申请单的员工。

4、工作项

工作项代表流程实例中活动的参与者将要执行的工作。
如：开通课程流程中，某员工创建的一张课程申请单即为一个工作项。

工作流管理系统包括若干工作项，一个参与者也可以对应多个工作项。
通常，在系统实现时，不同的工作项有不同的编号，可以通过编号来快速定位到某一个工作项。

2.2 工作流管理系统-WFMS

工作流管理系统（WorkFlow Management System）通过软件定义、创建工作流并管理其执行。它运行在一个或多个工作流引擎上，这些引擎解释对过程的定义与工作流参与者的相互作用，并根据需要调用其他IT工具或应用。
如：将考勤管理、内部信息交流、工作日报或周报等工作流管理模块集成在一个软件中，即可得到WFMS，这类WFMS即OA系统。

2.2.1 WFMS的基本功能

WFMS将业务流程中工作如何组织与协调的规则抽象出来，在WFMS的协助下，开发人员遵循一定的变成接口和约定，就可以开发出更具灵活性的事务处理系统，用户无需重新开发即可更改工作流程，以适应业务流程的变更。

WFMS的基本功能具体体现在以下几个方面：

对工作流进行建模：即定义工作流。包括具体的活动和规则等。所创建的模型是同时可以被人和计算机所"理解"的，工作流对应现实世界的业务处理过程，不能改变真实业务的处理逻辑；
工作流执行：遵循工作流模型来创建和执行实际的工作流，即通过WFMS可以执行多个工作项；
业务流程的管理和分析：监控和管理执行中的业务（工作流）。例如：进度完成情况和数据所处的状态、工作分配与均衡情况等。

2.2.2 WFMS的组成

# 工作流参考模型（workflow reference model），包含六个基本模块
1、工作流执行服务
2、工作流引擎
3、流程定义工具
4、客户端应用
5、调用应用
6、管理监控应用

这六个模块，被认为是WFMS最基本的组成部分。

在这里插入图片描述

2.3 流程设计工具

在处理流程设计过程中，为了更清晰的表达过程规则说明，陆续出现了一些用于表示处理流程的工具，这些工具包括三类：

图形工具：程序流程图、IPO图、盒图、问题分析图、判定树
表格工具：判定表
语言工具：过程设计语言

总述
在这里插入图片描述

程序流程图-PFD

# 要规范！
# PFD中只能包括五种基本控制结构，任何复杂的PFD都应由这5种基本控制结构组合或嵌套而成
1、顺序
2、选择
3、多分支选择
4、当型循环 do-while
5、直到型循环 do-until

在这里插入图片描述

IPO图

由IBM公司发起并逐步完善的一种流程描述工具。
系统分析阶段产生的数据流图DFD 经转换和优化后形成的系统模块结构图的过程中将产生大量的模块，分析与设计人员应为每个模块写一份说明，即可用IPO图来对每个模块进行表述。
IPO图用来描述每个模块的输入、输出和数据加工。
在这里插入图片描述

N-S图（盒图）

使用方框代替传统的PFD。
类似PFD，也包括五种控制结构，分别是顺序型、选择型、WHILE循环型、UNTIL循环型和多分支选择型，任何一个N-S图都是这五种基本控制结构的相互组合与嵌套的结果。
在这里插入图片描述在N-S图中，过程的作用域明确，它没有箭头，不能随意转移控制；
而且，容易表示嵌套和层次关系；
并具有强烈的结构化特征。

但是当问题复杂时，N-S图可能很大。

问题分析图-PAD

PAD（Problem Analyse Diagram）是继PFD和N-S图之后，又一种描述详细设计的工具，也是一种支持结构化程序设计的图形工具。

PAD也是支持五种基本控制结构，并允许递归使用。

在这里插入图片描述

PAD的执行顺序是从最左边的主干线的上端节点开始，自上向下依次执行。每遇到判断或循环，就自左向右进入下一层，从表示下一层的纵线上端开始执行，直到该纵线的下端，再返回上一层的纵线转入处，如此继续。

PAD具有清晰的逻辑结构，标准化的图形等优点，更重要的是，它引导设计人员使用结构化程序设计方法，从而提高程序的质量。

过程设计语言

过程设计语言（Process Design Language）也称结构化语言或伪代码

PDL用于描述模块中算法和加工逻辑的具体细节，以便在开发人员之间比较精确的进行交流。语法规则一般分为外层语法和内层语法，外层语法描述结构，内层语法描述操作。

PDL仅仅是对算法或加工逻辑的一种描述，不可执行。

判定表

对于具有多个相互联系的条件和可能产生多种结果的问题，用结构化语言描述，则显的不够直观和紧凑，此时，可以使用判定表（Decision Table）来描述。

判定表采用表格形式来表达逻辑判断问题，表格划分为四部分

左上部分为条件说明；
左下部分为行动说明；
右上部分为各种条件的组合情况说明；
右下部分为各条件组合情况下相应的活动
C1~C3为条件；
A1~A4为行动；
1-8为不同条件的组合；
T为条件满足，F为条件不满足；
Y为该条件组合下的行动。

判定树

也是用来表示逻辑判断问题的一种常用的图形工具。
常用树来表达不同条件下的不同处理流程，比语言、表格的方式更直观。
判定树的左侧（称为树根）为加工名，中间是各种条件，所有的行动都列于最右侧。

在这里插入图片描述

3、结构化设计-SD

结构化设计是一种面向数据流的方法，它以SRS和SA阶段产生的数据流图和数据字典等文档为基础，是一个自顶向下的、逐步求精和模块化的过程。

SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段。

其中概要设计的主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用的关系；详细设计的主要任务是为每个模块设计实现的细节。

3.1 模块结构

1、信息隐蔽和抽象

信息的隐蔽原则要求采用封装技术，将程序模块的实现细节隐藏起来，对于不需要这些信息的其他模块来说是不能访问的，使模块接口尽量简单。按照信息隐蔽的原则，系统中的模块应该设计为"黑盒"，模块外部只能使用模块接口说明中给出的信息，例如：操作和数据类型。

模块之间相互独立，既易于实现，也易于理解和维护。

抽象原则要求抽取事物最基本的特性和行为，忽略非本质的细节，采用分层次抽象的方式可以控制软件开发过程的复杂性，有利于软件的可理解性和开发过程管理。通常，抽象层次包括过程抽象、数据抽象和控制抽象。

2、模块化

在SD方法中，模块是实现功能的基本单位，一般具有功能、逻辑和状态三个基本属性：

功能：描述该模块"做什么"。
逻辑：描述模块内部"怎么做"
状态：该模块使用时的环境和条件。

在描述一个模块时，必须按模块的外部特性和内部特性分别描述。

外部特性：指模块的模块名、参数表和给程序乃至整个系统造成的影响；
内部特性：指完成模块功能的程序代码和仅供该模块内部使用的数据。

对于模块的外部环境，如调用该模块的上级模块，只需要了解这个模块的外部特性就足够。

软件设计阶段，通常是先确定模块的外部特性，然后再确定它的内部特性。

模块划分的原则：

模块大小要适中：过大导致系统分解不充分，内部可能包括不同类型的功能；过小导致系统的复杂度增加，模块之间调用过于频繁。一般控制到1-2页纸之内，或代码行数为50-200行之间。
模块的扇入和扇出要合理：扇出指调用下级模块；扇入指调用上级模块。一般来讲，顶层模块扇出比较大，中间模块扇出比较小，底层模块有大扇入。要多扇入，少扇出—多调用上级的（复用），少调用下级（复杂度），一般为3-4，不应该超过7。
深度和宽度适当：深度表示软件结构中模块的层数，如果层数过多，肯可能有些模块设计的过于简单；宽度是软件结构同一个层次上的模块总数的最大值。一般来讲，宽度越大系统越复杂，对宽度影响最大的因素就是模块的扇出。

3、耦合

耦合表示模块之间联系的程度。

紧密耦合：表示模块之间的联系非常强；
松散耦合：表示模块之间的联系比较弱；
非耦合：表示模块之间没有任何联系，是完全独立的。

在这里插入图片描述

对于模块之间耦合的强度，主要依赖于一个模块对另一模块的调用、一个模块对另一个模块传递的数据量、一个模块施加到另一个模块的控制的多少，以及模块之间接口的复杂程度。

4、内聚

内聚表示模块内部各成分之间的联系程度，是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做目标单一的一件事情。

在这里插入图片描述

内聚高，使得模块的可理解性和维护性大大增强。

5、模块类型

在这里插入图片描述

3.2 系统结构图-SC

系统结构图（Structure Chart）也称模块结构图。它是软件概要设计阶段的工具，反映系统功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总体结构。

在系统分析阶段，系统分析师采用SA方法获得由DFD、数据字典和加工说明等组成的系统逻辑模型；在系统设计阶段，系统分析师，可以根据一些规则，从DFD中导出系统初始SC。

常用的SC主要有三种：

变换型
事务型
混合型

3.2.1 SC的组成

SC包括模块、模块之间的调用关系、模块之间的通信和辅助控制符号等4各部分。

模块：用矩形表示，框中标注模块的名字，对于已定义或已开发的模块，可以使用双纵边矩形框表示。
模块之间的调用关系：上下布局，箭头相连，指向被调用的模块。
模块之间的通信：用调用关系的长箭头旁边的短箭头表示，注明传递的内容。
辅助控制符号：当模块A有条件的调用模块B时，箭头的起点标菱形；模块A反复调用模块C，在调用关系的连线上增加一环状箭头

在这里插入图片描述

3.2.2 变换型SC

在这里插入图片描述

3.2.3 事务型SC

在这里插入图片描述

3.2.4 混合型SC

有时间完善，就是变换型和事物型的整合。

4、面向对象设计-OOD

4.0 面向对象设计的基本过程

在这里插入图片描述

面向对象设计（Object-Oriented Design，OOD）是一种软件设计方法，
它以对象和类为基础，通过抽象、封装、继承和多态等概念来描述和组织系统的结构和行为。
下面是常见的面向对象设计过程：
1、需求分析：
2、系统设计：在系统设计阶段，设计者需要综合各种因素来制定系统的整体架构。
	这包括确定系统的模块组织结构、模块之间的关系和交互方式。
	面向对象设计中，设计者通常会根据需求分析的结果，将系统分解为一系列相互协作的对象和类，确定它们的属性、方法和关系。
3、类设计：在类设计阶段，设计者根据系统需求和系统设计的目标，将对象和类进一步细化，并详细定义它们的属性和方法。
	这包括确定类的成员变量、方法以及它们之间的关系（如继承关系、关联关系、聚合关系等）。
	类设计要求设计者具备良好的抽象能力和领域知识，以便能够准确地捕捉系统的实体和行为。
4、行为设计：在行为设计阶段，设计者将关注对象和类的行为（方法）的具体实现。
	这包括定义方法的算法、流程和逻辑，以及确定方法之间的调用关系和协作方式。
	行为设计涉及到应用适当的设计模式和算法来实现系统的功能和需求。
5、界面设计：界面设计是面向对象设计过程中的重要一步，它关注用户与系统之间的交互界面。
	设计者需要创建易于使用、直观和美观的用户界面，以提供良好的用户体验。
	界面设计涉及到定义用户界面元素、布局、交互方式和视觉风格等。
6、测试和验证：在设计过程的各个阶段，测试和验证是必不可少的。
	设计者需要编写测试用例和测试脚本，以验证设计的正确性和功能的有效性。
	通过测试和验证，可以及早发现和修复设计中的问题，确保设计的质量和可靠性。
7、迭代和优化：面向对象设计是一个迭代的过程，设计者需要不断地从用户反馈和系统运行情况中汲取经验，进行迭代和优化。
	随着设计的不断演进，设计者可以改善系统的可维护性、可扩展性和性能。

面向对象设计是模型驱动和用例驱动的，整个设计过程将OOA阶段产生的需求模型作为输入，并生成供构建阶段使用的设计模型作为输出。

OOD是OOA方法的延续，基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。

在OOD中，数据结构和在数据结构上定义的操作算法封装在一个对象中。

由于现实世界中的事物都可以抽象出对象的集合，所以OOD方法是一种更接近现实世界、更自然的系统设计方法。

4.1 设计软件类

类封装了信息和行为，是面向对象的重要组成部分，它是具有相同属性、方法和关系的对象集合的总称。
在系统中，每个类都具有一定的职责，职责是指类所担任的任务。
在系统设计过程中，类可以分为三类：实体类、控制类、边界类。

4.1.1 实体类

案例题很喜欢考概念

实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息。
EXAMPLE：在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。
实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都要。

实体类是对用户来说最有意义的类，通常采用业务领域术语命名。

在用例模型向领域模型转化中，一个参与者一般对应于实体类，通常可以从SRS中的那些与数据库表对象的名词着手来寻找实体类。
通常情况下，实体类一定有属性，但不一定有操作。

4.1.2 控制类

案例题很喜欢考概念

控制类是控制用例工作的类。用于对一个或几个用例所特有的控制行为进行建模，控制对象通常控制其他对象。
控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关。
当系统执行用例的时候，就产生一个控制对象，控制对象经常在其对应的用例执行完毕后消亡。
通常情况下，控制类没有属性，但一定有方法。
EXAMPLE：用例“身份验证”可以对应一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。

4.1.3 边界类

案例题很喜欢考概念

边界类用于封装在用例内、外流动的信息或数据流。
边界类位于系统与外界的交接处，包括：所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。
要寻找和定义边界类，可以检查用例模型，每个参与者和用例的交互至少要有一个边界类，边界类使参与者能与系统交互。
EXAMPLE：常见的边界类有：窗口、通信协议、打印机接口、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来处理。
边界类用于系统接口与系统外部进行交互；边界对象将系统与外部环境的变更分隔开，使这些变更不会对系统的其他部分造成影响。通常情况下，边界类既有属性也有方法。

4.2 对象持久化与数据库

在面向对象开发方法中，对象只能存在于内存中，而内存不能永久保存数据，如果要永久保存对象的状态，需要进行对象的持久化，对象持久化是把内存中的对象保存到数据库或可永久保存的存储设备中。

在多层软件设计和开发中，为降低系统的耦合度，一般会引入持久层（Persistence Layer），即专注于实现数据持久化应用领域的某个特定系统的一个逻辑层面，将数据使用者和数据实体相关联，持久层的设计实现了数据处理层内部的业务逻辑和数据逻辑的解耦。

目前，关系数据库仍旧是使用最为广泛的数据库，如DB2、Oracle、SQL Server等，关系数据库存放的是关系数据，即用二维表格表示的数据，它是非面向对象的。

对象和关系数据其实是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。

内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，将对象持久化到关系数据库中，需要进行对象/关系的映射（Object/Relation Mapping，ORM），这是一项非常重要且繁琐耗时的工作。

主流的持久化框架技术

CMP：容器管理持久化 Container-Managed Persistence，基于EJB技术
Hibernate：是ORM的解决方案
iBatis：是ORM的解决方案，小巧，易上手
JDO：Java Data Object Java数据对象

4.3 面向对象设计的原则

大概了解即可

4.3.1 单一职责原则

设计目的单一的类，一个类只负责一个功能领域中的相应职责。

单例模式
享元模式
命令模式
职责模式
备忘录模式

4.3.2 开放-封闭原则

对扩展开放，对修改封闭。

工厂方法模式
抽象工厂模式
适配器模式
状态模式

4.3.3 里氏替换原则

子类可以替换父类

原型
建造者
观察者
解释器

4.3.4 依赖倒置原则

要求依赖于抽象，而不是具体的实现；针对接口编程，而不针对具体的实现编程。

桥接模式
装饰模式
访问者模式
策略模式

4.3.5 迪米特原则

要求一个软件实体应当尽可能少的与其他实体发生交互作用。

外观
代理
中介者

4.3.6 组合重用原则

尽量使用组合，不使用集成；继承会有子类和父类的强依赖关系，不符合低耦合原则。

组合
模版方法
迭代器

4.4 设计模式

4.4.0 设计模式概述

1、软件模式与设计模式

软件模式是将模式的一般概念用于软件开发领域，即软件开发的总体指导思路或参照样板。

软件模式包括设计模式、架构模式、分析模式和过程模式等，软件生存周期的各个阶段都存在着被认同的模式。在软件模式领域，目前研究最为深入的是设计模式。

设计模式是一套被反复使用、多数人知晓的、经过分类编目、代码设计经验的总结，使用设计模式的目的是为了提高代码的可重用性，让代码更容易被他人理解，保证代码的可靠性。

2、设计模式的关键元素

设计模式包括模式的名称、问题、目的、解决方案、效果、实例代码和相关合计模式等基本要素，其中的关键4个有：

模式名称
问题
解决方案
效果

4.4.2 设计模式分类

考点：1.某种设计模式的应用场景 2.设计模式的分类

简而言之：
创建型模式：就是处理对象的创建，怎么创建对象
结构型模式：就是类和对象如何组合，怎么搭配，怎么组合到一起
行为型模式：就是类和对象之间能做啥，能有啥操作

4.4.2.1 创建型模式

核心在：对象怎么创建

这类模式处理对象的创建，试图根据实际情况使用合适的方式创建对象。
它们通过以某种方式控制对象的创建来解决问题。
创建型模式主要由两个主导思想构成：一是将系统使用的具体类封装起来，二是隐藏这些具体类的实例创建和结合的方式。

在这里插入图片描述

4.4.2.2 结构型模式

关注类和对象的组合

它们采用继承、聚合等方式组合类与对象，形成一个更大的结构，以达到某种设计目的。

在这里插入图片描述

4.4.2.3 行为型模式

偏动态一些

这类模式涉及对象和类之间的交互及职责分配。
它们不仅描述对象和类的模式，还描述它们之间的通信模式。

补充多态说明[考题]
1.不同的对象收到同一消息可以产生完全不同的结果，这一现象叫多态；
2.多态有几种不同的形式。
3.一个子类的对象同时又属于父类，它继承了父类的一切属性，这种多态称为包含多态；
4.同一个算子在不同的表达式中可能有不同的操作意义，称为过载多态；
5.编译程序根据上下文判断算子的操作意义，称为：算子鉴别

5、 "4+1"视图

“4+1视图” 多用于软件分析和设计

# 了解即可
# 核心：用例视图
# 考点：每个视图对应的角色、以及是做什么的

1、逻辑视图 - Logical View  系统[分析/设计]人员
	 - 从系统的功能角度描述系统内部如何实现其功能
	 - 显示 系统的组件、类、接口以及它们之间的关系
	 - 反映软件系统的功能情况，一般用【类图】
2、实现视图/开发视图 - Implementation View / Development View  程序员
	 - 关注软件开发环境下实际模块的组织
	 - 一个良好的开发视图应能够找到所有代码和二进制交付件，并显示它们与逻辑架构元素的关系。
3、部署视图 - Deployment View / Physical View  系统和网络工程师
	 - 也称：物理视图、拓扑试图
	 - 关注软件到硬件的映射以及系统的分布式特性
4、进程视图 Process View / Behavioral View   系统集成人员
	 - 也称：行为视图、过程视图
	 - 关注系统各个组件和模块之间的通信时序、数据的输入输出
	 - 描述程序执行时的【并发】状态，以及如何协同工作实现功能。
	 - 一般用【时序图和流程图】
5、用例视图  Use Case View / Scenario View  最终用户
	 - "核心视图"
	 - 从外部参与者的视角描述系统的功能。
	 - 显示系统的参与者与系统功能用例之间的关系。
	 - 反映系统的最终用户需求和交互设计。
	 - 是其他四个视图的冗余，用于整合和展示系统的整体功能。

原题
在RUP[统一过程开发]中采用4+1视图模型来描述软件系统的体系结构，4+1视图包括：逻辑视图、实现视图、进程视图、部署视图和用例视图。
1、分析人员和测试人员关系的是系统的行为，因此会侧重于用例视图；
2、最终用户关系的是系统的功能，因此会侧重于逻辑视图；
3、程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图；
4、系统集成人员关系的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重进程视图；
5、系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会更侧重部署视图。