（软考）系统分析师——面向对象方法

ps:本博客内容只针对博主复习期间对考点的一些总结，内容可能并不全面，还望海涵。也欢迎大家补充和指点错误~~

基本概念

1. 对象：是指一组属性及这组属性上专用操作的封装体。由 对象名、属性、操作（方法） 组成
2. 类：是一组具有相同属性和操作的对象的集合，每个对象都是这个类的一个实例，由类名、属性、操作（方法）组成；类是面向对象类型扩展的重要机制，利用属性和方法将数据和与数据相关的行为封装起来
3. 继承：在某个类的层次关联中不同的类共享属性和操作的一种机制；一个子类有唯一父类，叫单一继承，若有多个父类，叫多重继承；
4. 封装：单位是对象，对象之间只能通过接口进行信息交流，外部不能对对象中的数据随意进行访问； 优点： 减少耦合、类内部实现自由改变、一个类有更清晰的接口
5. 消息：对象间通信的手段，包括 接收对象名、调用的操作名、适当的参数；只告诉接收对象需要完成什么操作，但不指示如何完成，完全由接收者解释
6. 多态性：指同一个操作作用于不同的对象时可以有不同的解释，并产生不同的执行结果；
   • 动态绑定：把过程调用与目标代码的连接推迟到程序运行时进行
   • 静态绑定 ：把过程调用与目标代码的连接放在程序运行前进行

统一建模语言（UML）

UML特点：

• 统一标准、面向对象 、可视化、独立于开发过程、概念明确，表达简洁，结构清晰

UML结构

基本构造块

• 事物：UML中重要的组成部分
• 关系：把事物紧密联系在一起
• 图 ：是很多有相互相关的事物的组

公共机制：是指达到特定目标的公共UML方法

• 规格说明（详细说明）：事物语义的文本描述，是模型真正的核心；
• 修饰：UML为每个事物设置一个记号，可通过修饰来表达更多的信息；
• 公共分类（通用划分）
  • 类与对象
    • 类表示概念
    • 对象表示具体的实体
  • 接口和实现
    • 接口用来定义契约
    • 实现是具体的内容
• 扩展机制
  • 约束：添加新规则来扩展事物的语义
  • 构造型：用于定义新的事物
  • 标记值 ：添加新的特殊信息来扩展事物的规格说明

规则

• UML用于描述事物的语义规则分别是为 事物、关系、图命名；
• 范围：给一个名字以特定含义的语境
• 可见性：怎样使用或看见名字
• 完整性：事物如何正确、一致的相互联系
• 执行：运行或模拟动态模型的含义是什么
• 五个系统视图
  • 逻辑视图：表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集；
  • 进程视图：是可执行线程和进程作为活动类的建模，是逻辑视图的一次执行实例，描述了并发与同步结构
  • 实现视图：对组成基于系统的物理代码的文件和构件进行建模
  • 部署视图：把构件部署到一组物理点上，表示软、硬件的映射和分布结构
  • 用例视图 ：是最基本的需求分析模型

事物（建模元素）：是UML模型中最基本的面向对象的构造块

• 结构事物：属于最静态的部分，代表概念上的或物理上的元素
  • 类：是描述具有相同属性、方法、关系和语义的对象的集合
  • 接口：是指类或构件提供特定服务的一组操作的集合
  • 协作：定义了交互操作，具有结构化、动作化的特性
  • 用例：描述一系列动作，这些动作是对一个特定角色执行，产生值得注意的结果的值
  • 活动类：其对象有一个或多个进程或线程
  • 构件：是物理上或可替换的系统部分，实现一个接口集合
  • 节点：是一个物理元素，代表一个可计算的资源，通常占用一些内存和具有处理能力。
• 行为事物：是UML模型的动态部分，代表时间和空间上的动作
  • 交互（内部活动）：是一组对象在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。
  • 状态机 ：由一系列对象的状态组成
• 分组事物：是UML中组织的部分，模型可以在其中被分解
  • 包 ：一种将有组织的元素分组的机制；是纯粹概念上的东西，只存在于开发阶段
• 注释事物：UML模型的解释部分

关系

UML中的关系

• 依赖：两个事物之间的语义关系，一个事物发生改变会影响另一个事物的语义；
• 关联：描述对象之间连接的结构关系
• 泛化：一般化和特殊化的关系
• 实现：类之间的语义关系，一个类指定了由另一个类保证执行的契约

用例之间的关系

• 包含关系：《include》；执行基本用例时一定会执行包含用例；可从两个或两个以上的用例中提取公共行为；不为基用例添加新行为；基用例------>被包含用例；被包含用例可以单独执行。
• 扩展关系《extend》；执行基本用例时不一定会执行扩展用例；一个用例明显混合两种或以上的不同场景，即可能发生很多种分支；为基用例添加新行为；被扩展用例------>基用例；被扩展用例不可单独执行。
• 泛化关系：代表一般与特殊的关系（继承）：当父用例能够被使用时，任何子用例也可以被使用；
• 使用关系： 用例执行有先后顺序，是一种在时间上的依赖关系。在使用用例建模系统需求时，两个或多个用例可能执行同样的功能步骤，把这些公共步骤提取成独立的用例，称为抽象用例。抽象用例代表某种程度的复用，是降低用例之间冗余比较好的方式。抽象用例可以被另一个需要使用它的功能用例访问，抽象用例和使用它的用例之间的关系称为使用关系。

泛化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。

类之间的关系

• 关联关系（Association）：类与类之间的联接，使一个类知道另一个类的属性和方法，箭头指向被使用的类
• 依赖关系（Dependency）：是类与类之间的连接，表示一个类依赖于另一个类的定义。例如如果A依赖于B，则B体现为局部变量，方法的参数、或静态方法的调用。箭头指向被依赖的一方，也就是指向局部变量
• 泛化关系（Inheritance）: 类与类之间的继承关系，接口与接口之间的继承，箭头指向父类
• 聚合关系（Aggregation）：是关联关系的一种，是强的关联关系。聚合关系是整体和个体的关系，箭头指向整体
• 组合关系（Composition）：是关联关系的一种，是比聚合关系强的关系。它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期，合成关系不能共享，箭头指向整体
• 实现关系(Realization/Implementation) ：类对接口的实现，箭头指向接口

聚合关系，复合关系属于关联关系

一般关系表现为继承或实现关系(is a)

关联关系表现为变量(has a )

依赖关系表现为函数中的参数（use a）

• 流关系：将一个对象的两个版本以连续的方式连接起来；表示一个对象的值、状态和位置的转换；将类元角色在一次相互作用中连接起来；流的种类包括：变成（同一对象的不同版本）、复制（从现有对象创造出一个新的对象） 两种，使用带箭头的虚线表示。

图形

• 类图：描述一组类、接口、协作和它们之间的关系；类图通过显示出系统的类以及这些类之间的关系来表示系统，是系统静态对象结构的图形描述。
• 对象图：描述一组对象及它们之间的关系；描述了在类图中所建立的事物实例的静态快照；是以真实案例或原型案例角度建立的；也给出了系统的静态设计视图或静态进程视图
• 构件图：描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构；用于表示系统的静态设计实现视图；是类图的变体
• 组合结构图：描述结构化类（例如构件或类）的内部结构，包括结构化类与系统其余部分的交互点；用于画出结构化类的内部内容。
• 用例图：描述一组用例、参与者及它们之间的关系；给出系统静态用例视图；用例图用来描述系统与外部系统以及用户之间的交互视图，强调这个系统是什么而不是这个系统怎么工作。
• 顺序图（交互图）：由一组对象或角色以及它们之间可能发送的消息构成；专注于系统的动态视图；强调消息的时间次序；顺序图用来描述对象按照时间顺序的消息流来建模用例
• 通信图（交互图）：又称协作图，强调收发消息的对象或角色的结构组织；
• 定时图（交互图）又称计时图，强调消息跨越不同对象或角色的实际时间，不仅仅关心消息相对顺序；
• 状态图：描述一个状态机，它由状态、转移、事件和活动组成；给出对象的动态视图；状态图显示出对象可能的状态以及由状态改变导致的转移，把焦点集中在过程中的对象身上
• 活动图：将进程或其他计算的结构展示为计算内部一步步的控制流和数据流；专注于系统的动态视图；活动图用来描述一个业务流程，说明活动之间的依赖关系，把焦点集中在一个单独过程中的动作流程
• 部署图：用来显示系统中软件、硬件的物理架构以及处理节点的组件分布情况；给出体系结构的静态部署视图
• 制品图：描述计算机中一个系统的物理结构；通常与部署图一起使用
• 包图：：描述由模型本身分解而成的组织单元，以及他们的依赖关系
• 交互概览图：是活动图和顺序图的混合物。
  ————————————————————————————
  数据流图：一种描述数据通过系统的流程以及系统实施的工作或处理过程的过程模型
  流程图：以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程

面向对象分析（OOA）——“做什么”

• 直接以问题域中客观存在的事物或概念识别为对象，建立分析模型
• 用对象的属性和服务分别描述事物的静态特征和行为
• 保留问题域中事物之间关系的原貌
• 问题域是一个包含现实世界事物与概念的领域
• 面向对象分析基于用例模型，通过对象建模记录确定的对象、对象封装的数据和行为以及对象之间的关系
• 面向对象分析包括3个活动：
  • 建模系统功能
  • 发现并确定业务对象
  • 组织对象并确定其关系

用例模型：找出用户需求，具体描述出来

• 构件用例模型需要经历三个阶段：
  • 识别参与者，参与者是系统之外与系统进行交互的任何事物
  • 合并需求获得用例
    • 业务用例：描述业务具体工作流，着重于业务操作；
    • 系统用例 ：设计范围是计算机系统设计范围；是一个参与者与计算机系统一起实现一个目标；着重于要设计的软件系统；
  • 细化用例描述
    • 用例建模的主要任务是书写用例规约，不是画图
    • 其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流、扩展事件流）、后置条件等，其他还包括非功能需求、用例优先级等。

从用户观点对系统进行用例建模捕获用例后并不意味着分析的结束，还要对需求进行深入研究，获取关于问题域本质内容的分析模型

分析模型（描述应用领域）

• 分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及如何保持通信实现系统行为（动态模型）
• 建立分析模型的基本活动
  • 发现领域对象，定义概念类
  • 识别对象的属性
  • 识别对象的关系，包括建立类的泛化关系、对象的关联关系
  • 为类添加职责
  • 建立交互图

面向对象设计（OOD）——“怎么做”

• 面向对象设计是模型驱动和用例驱动的，整个设计过程将面向对象分析阶段所产生的需求模型作为输入，并生成供构建阶段使用的设计模型作为输出
• 面向对象设计的基本思想包括抽象、封装、可扩展性，其可扩展性是通过对象继承和多态来实现。
• 对象持久化是将内存中的数据以数据库或物理文件的形式保存到可永久存储的设备中
• 基本准则
  • 模块化、抽象、信息隐藏、高内聚和低耦合
• 设计原则
  • 单一职责原则(SRP)：实现类要职责单一，处理的事情太多，不利于重用；
  • 开放-封闭原则(OCP)：对扩展开发，对修改关闭；
  • 里氏替换原则(LSP)：与继承有关，是继承复用的基础，是对开闭原则的补充，是对实现抽象化的具体步骤的规范，反映父类与子类之间的关系，子类可扩展父类功能，但不能改变父类原有功能。【不能破坏继承体系】
  • 依赖倒置原则(DIP)：面向接口编程，不要面向实现编程。
  • 接口隔离原则(ISP)：尽量将臃肿庞大的接口拆分成更小和更具体的接口，让接口只包含客户感兴趣的方法；【设计接口要精简单一】
  • 组合重用原则(CRP)/组合/聚合复用原则(ARP)：多用组合/聚合复用，少用继承复用；
  • 最少知识法则(LKP)（迪米特原则）(LoD) ：两个实体通过第三方进行通信，目的是降低类之间的耦合度，提高模块的相对独立性。

面向对象测试

• 面向对象测试与传统测试模式最主要的区别：
  • 面向对象的测试更关注对象而不是完成输入/输出的单一功能；
  • 测试可以在分析与设计阶段就先行介入，使测试更好地配合软件生产过程并为之服务。
• 面向对象测试的优点：
  • 更早的定义出测试用例，帮助系统分析员和设计师更好理解需求并保证需求是可测试的
  • 早期介入降低成本
  • 尽早编写测试用例便于开发人员和测试人员对需求的理解保持一致
  • 面向对象的测试模式更注重于软件的实质
• 测试的4个层次：
  • 算法层：测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试；
  • 类层：测试封装在同一个类中的所有方法与属性之间的相互作用，可认为是面向对象测试中所特有的模块（单元）测试
  • 模板层（主题层）：测试一组协同工作的类或对象之间的相互作用，相当于传统测试中的子系统测试
  • 系统层：把各个子系统组装成完整的面向对象软件系统，在组装过程中同时测试
• 面向对象系统的单元测试
  • 方法层次的测试：类似于传统软件测试中对单个函数的测试
    • 等价类划分测试
    • 组合功能测试
    • 递归函数测试
    • 多态消息测试
  • 类层次的测试
    • 不变式边界测试
    • 模态类测试
    • 非模态类测试
  • 类树层次的测试
    • 多态服务测试
    • 展平测试

设计模式

• 设计模式的组成
  • 模式名称、问题、解决方案、效果
  • 设计模式分类：(*表示关于类的，其他是关于对象的）
    • 创建型
      • 抽象工厂模式(Abstract Factory)：提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类；
      • 工厂方法模式(Factory Method)*：定义一个创建对象的接口，但由子类决定需要实例化哪一个类；工厂方法使得子类实例化的过程推迟；
      • 生成器模式(Builder)：：将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示；
      • 原型模式(Prototype)：用原型实例指定创建对象的类型，并通过拷贝这个原型来创建新的对象
      • 单子模式(Singleton)：保证一个类只有一个实例，并提供一个访问它的全局访问点
    • 结构型
      • 适配器模式(Adapter)*：将一个类的接口转换成用户希望得到的另一种接口，使原来不相容的接口得以协同工作；
      • 桥模式(Bridge)：将类的抽象部分和它的实现部分分离开来，使它们可以独立地变化；
      • 组合模式(Composite)：将对象组合成树形结构以表示”整体-部分“的层次结构，使得用户对单个对象和组合对象的使用具有一致性
      • 装饰模式(Decorator)：动态地给一个对象添加一些额外的职责，它提供了用子类扩展功能的一个灵活的替代，比派生一个子类更加灵活
      • 外观模式(Facade)：定义一个高层接口，为子系统中的一组接口提供一个一致的外观，从而简化了该子系统的使用
      • 享元模式(Flyweight)：提供支持大量细粒度对象共享的有效方法；
      • 代理模式(Proxy)：为其他对象提供一种代理以控制这个对象的访问；
    • 行为型
      • 职责链模式(Chain of Responsibility)：通过给多个对象处理请求的机会，减少请求的发送者与接收者之间的耦合；将接收对象链接起来，在链中传递请求，直到有一个对象处理这个请求
      • 命令模式(Command)：将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化，将请求排队或记录请求日志，支持可撤销的操作；命令模式是对命令的封装，将发出命令的责任和执行命令的责任分割开，委派给不同的对象，以实现发送者和接收者完全解耦，提供更大的灵活性和可扩展性
      • 解释器模式(Interpreter)*：给定一种语言，定义它的文法表示，并定义一个解释器，该解释器用来根据文法表示解释语言中的句子；
      • 迭代器模式(Iterator)：提供一种方法来顺序访问一个聚合对象中的各个元素，而不需要暴露该对象的内部表示
      • 中介者模式(Mediator)：用一个中介对象来封装一系列的对象交互，使各对象不需要显示的相互调用，从而实现低耦合，还可以独立的改变对象间的交互
      • 备忘录模式(Memento)：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，从而可以在以后将该对象恢复到原先保存的状态
      • 观察者模式(Observer)：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所以依赖于它的对象都会得到通知并自动更新
      • 状态模式(State)：允许一个对象在其内部状态改变时改变它的行为；
      • 策略模式(Strategy)：定义一系列算法，把它们一个个封装起来，并且使它们之间可互相替换，从而让算法可以独立于使用它的用户而变化
      • 模板模式(Template Method)*：定义一个操作中的算法骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤；
      • 访问者模式(Visitor)：表示一个作用于某对象结构中的各元素的操作，使得在不改变各元素的类的前提下定义作用于这些元素的新操作。