系统架构设计师 - 软件工程(2)

软件工程

软件工程（13-22分）非常重要
- 软件系统建模
- 系统设计
- - [界面设计 ★★](#界面设计 ★★)
  - 软件设计
  - [结构化设计 ★★](#结构化设计 ★★)
  - [面向对象设计 ★★★★★](#面向对象设计 ★★★★★)

大家好呀！我是小笙，本章我主要分享系统架构设计师 - 软件工程(2)知识，希望内容对你有所帮助！！

软件工程（13-22分）非常重要

软件系统建模

软件系统建模是软件开发中的重要环节，通过构建软件系统模型可以帮助系统开发人员理解系统、抽取业务过程和管理系统的复杂性

软件系统建模优化过程

例题

软件系统建模(Software System Modeling)是软件开发中的重要环节，通过构建软件系统模型可以帮助系统开发人员理解系统、抽取业务过程和管理系统的复杂性，也可以方便各类人员之间的交流。软件系统建模是在系统需求分析和系统实现之间架起的一座桥梁，系统开发人员按照软件系统模型开发出符合设计目标的软件系统，并基于该模型进行软件的维护和改进。请围绕"论软件系统建模方法及其应用"论题，依次从以下三个方面进行论述

说明软件系统开发中常用的建模方法有哪几类？阐述每种方法的特点及其适用范围

1、结构化建模方法 ：结构化建模方法是以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图(DFD)。对于流程较为稳定的系统可考虑结构化建模方法

2、信息工程建模方法（或数据库建模方法） ：信息工程建模方法是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型被称为实体联系图(ERD)。主要用于数据建模

3、面向对象建模方法 ：面向对象建模方法将"数据"：和"过程"集成到被称为"对象"的结构中，消除了数据和过程的人为分离现象。面向对象建模方法所创建的模型被称为对象模型。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML(统一建模语言)。UML定义了几种不同类型的模型图，这些

模型图以对象的形式共建一个信息系统或应用系统，是目前比较常用的建模方法

系统设计

界面设计 ★★

黄金三法则

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

例题

下列关于用户界面设计的叙述中，错误的是 界面交互模型应经常进行修改

界面交互模型应经常进行修改
界面的视觉布局应该尽量与真实世界保持一致
所有可视信息的组织需要按照统一的设计标准
确保用户界面操作和使用的一致性

软件设计

软件设计包括体系结构设计、接口设计、数据设计和过程设计

结构设计：定义软件系统各主要部件之间的关系
接口设计（人机界面设计)：软件内部，软件和操作系统之间以及软件和人之间如何通信
数据设计：将模型转换成数据结构的定义（好的数据设计将改善程序结构和模块划分，降低过程复杂性）
过程设计：系统结构部件转换成软件的过程描述

例题

软件设计包括了四个既独立又相互联系的活动：高质量的 数据设计 将改善程序结构和模块划分，降低过程复杂性； 软件结构设计 的主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系； 人机界面设计 描述了软件与用户之间的交互关系

程序设计数据设计算法设计过程设计
软件结构设计数据结构设计数据流设计分布式设计
数据架构设计模块化设计性能设计人机界面设计

结构化设计 ★★

概要设计（外部设计）：功能需求分配给软件模块，确定每个模块的功能和调用关系，形成模块结构图
详细设计（内部设计）：为每个具体任务选择适当的技术手段和处理方法

结构化设计原则

模块独立（高内聚、低耦合）
保持模块的大小适中
多扇入，少扇出
深度和宽度均不宜过高

模块的四个要素

输入和输出，模块的输入来源和输出去向都是同一个调用者，即一个模块从调用者那取得输入，进行加工后再把输出返回调用者
处理功能，指模块把输入转换成输出所做的工作
内部数据，指仅供该模块本身引用的数据
程序代码，指用来实现模块功能的程序

面向对象设计 ★★★★★

基本过程

设计原则

单一职责原则：设计目的单一的类
开放封闭原则：对扩展开放，对修改封闭
里氏替换原则：子类可以替换父类
依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
接口隔离原则：使用多个专门的接口比使用单一的总接口要好
组合重用原则侧：要尽量使用组合，而不是继承关系达到重用目的
迪米特原则（最少知识原则）：一个对象应当对其他对象有尽可能少的了解

例题

1、最少知识原则（也称为迪米特原则)是面向对象设计原则之一，指一个软件实体应当尽可能少地与其他实体发生相互作用。这样，当一个实体被修改时，就会尽可能少地影响其他的实体。下列叙述中， 在类的结构设计上，每个类都应当尽可能提高对其属性和方法的访问权限 不符最少知识原则

在类的划分上，应当尽量创建松耦合的类
在类的设计上，只要有可能，一个类型应当设计成不变类
在类的结构设计上，每个类都应当尽可能提高对其属性和方法的访问权限
在对其他类的引用上，一个对象对其他对象的引用应当降到最低

设计模式

概念：主要关注软件系统的设计，与具体的实现语言无关

注意：有打钩的表示既可以是类模式，也可以是对象模式，无下划线的表示只是对象模式

创建型模式：创建对象

工厂方法(Factory Method)模式 √

定义了创建对象的接口，它允许子类决定实例化哪个类（动态生成）
抽象工厂(Abstract Factory)模式

提供一个接口，可以创建一系列相关或相互依赖的对象而无需指定它们具体的类（生产成系列对象）
原型(Prototype)模式

允许对象在不了解要创建对象的确切类以及如何创建等细节的情况下创建自定义对象。通过拷贝原型对象来创建新的对象（克隆对象）
单例(Singleton)模式

确保一个类只有一个实例，并且提供了对该类的全局访问入口（单实例）
构建器(Builder)模式

将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示（复杂对象构造）

结构型模式：更大的结构

适配器(Adapter)模式 √

将一个类的接口转换成用户希望得到的另一种接口。它使原本不相容的接口得以协同工作（转换接口）
桥接(Bridge)模式

将一个复杂的组件分成两个独立的但又相关的继承层次结构将类的抽象部分和它的实现部分分离开来，使它们可以独立地变化（继承树拆分）
组合(Composite)模式

创建树型层次结构来改变复杂性，同时允许结构中的每一个元素操作同一个接口。用于表示"整体部分"的层次结构（树形目录结构）
装饰(Decorator)模式

在不修改对象外观和功能的情况下添加或者删除对象功能即动态地给一个对象添加一些额外的职责（动态附加职责）
外观(Facade)模式

子系统中的一组接口提供了个统一的接口（对外统一接口）
享元(Flyweight)模式

可以通过共享对象减少系统中低等级的、详细的对象数目提供支持大量细粒度对象共享的有效方法（汉字编码）
代理(Proxy)模式

为控制对初始对象的访问提供了一个代理或者占位符对象（快捷方式）

行为型模式：交互及职责分配

职责链(Chain of Responsibility）模式

可以在系统中建立一个链，这样消息可以在首先接收到它的级别处被处理，或者可以定位到可以处理它的对象（传递职责）
命令(Command)模式

在对象中封装了请求，这样就可以保存命令，将该命令传递给方法以及像任何其他对象一样返回该命令（日志记录，可撤销）
解释器(Interpreter)模式 √

可以解释定义其语法表示的语言，还提供了用表示来解释语言中的语句的解释器（虚拟机的机制）例如适用于工作流
迭代器(Iterator)模式

为集合中的有序访问提供了一致的方法，而该集合是独立于基础集合，并与之相分离的（数据集）
中介者(Mediator)模式

通过引入一个能够管理对象间消息分布的对象，简化了系统中对象间的通信（不直接引用）
备忘录(Memento)模式

保持对象状态的快照，这样对象可以在不向外界公开其内容的情况下，返回到它的最初状态（游戏存档）
观察者(Observer)模式

为组件向相关接收方广播消息提供了灵活的方法，定义对象间的一种一对多的依赖关系（订阅、广播、联动）
状态(State)模式

允许一个对象在其内部状态改变时改变它的行为（状态变成类）
策略(Strategy)模式

定义一系列算法，把它们一个个封装起来，并且使它们之间可互相替换，从而让算法可以独立于使用它的用户而变化（多方案切换）
模板方法(Template Method)模式 √

提供了在不重写方法的前提下允许子类重载部分方法的方法（框架）
访问者(Visitor)模式

提供了一种方便的、可维护的方法来表示在对象结构元素上要进行的操作（数据与操作分离）

例题

1、设计模式按照目的可以划分为三类，其中， 创建型 模式是对对象实例化过程的抽象。例如 Singleton 模式确保一个类只有一个实例，并提供了全局访问入口； Prototype 模式允许对象在不了解要创建对象的确切类以及如何创建等细节的情况下创建自定义对象； Builder 模式将复杂对象的构建与其表示分离

A 创建型 B 结构型 C 行为型 D 功能型
A Facade B Builder C Prototype D Singleton