【系统分析师之路】系统分析师必知必会(面向对象篇)

系统分析师必知必会面向对象篇

【系统分析师之路】系统分析师必知必会(面向对象篇)
- 一. 基础知识
- - 1. 用例建模
  - - 1）包含
    - 2）扩展
    - 3）泛化
    - 4）用例规约
  - 2. 多态的定义
  - - 【按实现角度分类】
  - 3. 问题域的定义
  - 4. OOA的基本概念
  - 5. UML基础概念
  - 6. 方法调用与消息机制
  - 7. Java2EE
- 二. 框架与类库
- 三. 4+1视图
- - 1. 用例视图
  - 2. 逻辑视图
  - 3. 进程视图
  - 4. 部署视图
  - 5. 物理视图
- 四. OO测试
- 五. 面向对象设计原则
- - 1）依赖倒置原则
  - 2）里氏替换原则
  - 3）开闭原则
  - 4）接口隔离原则
  - 5）组合复用原则
  - 6）迪米特法则
  - 7）单一职责原则
- 六. UML构成元素
- - 1. 基本组成
  - 2. 构造块----关系
  - - 1）依赖
    - 2）实现
    - 3）泛化
    - 4）关联
  - 3. 构造块----事物
  - - 1）结构事物
    - 2）行为事物
    - - 交互
      - 状态机
    - 3）分组事物
    - 4）注释事物
  - 4. 公共机制
  - - 1）规则说明
    - 2）修饰
    - 3）公共分类
    - 4）扩展机制
- 七. UML图形
- - 1. 定时图
  - 2. 交互概览图
  - 3. 活动图
  - 4. 包图
  - 5. 类图
  - 6. 对象图
  - 7. 构件图
  - 8. 部署图
  - 9. 制品图
  - 10. 通信图
  - 11. 状态图
  - 12. 用例图
  - 【活动图的定义】
  - 【UML五种建模图】
- 八. 面向对象识别设计类
- - 1. 实体类
  - 2. 控制类
  - 3. 边界类

一. 基础知识

类库是一种预先定义的程序库，它以程序模块的形式，按照层次结构，把一组类的定义和实现组织在一起
类属类（泛化）：描述适用于一组类型的通用样板，所处理对象的数据类型尚未确定
用例定义：用例是参与者与系统之间一系列可能的交互行为序列的抽象描述。以实现用户使用。
系统实现特定目标，不涉及细节，强调能做什么，而不是如何去做。用例描述业务场景或事件。用例图用于描述系统与外部系统以及用户之间的交互视图。
类是共享共同属性和行为的对象集合，类图是系统静态对象结构的图形描述。

1. 用例建模

用例模型是由用例图和每一个用例的详细描述—用例规约所组成。RUP中提供了用例规约的模板。
用例建模的首要任务是识别系统中的参与者，用例建模的主要工作是书写用例规约。
用例的三种关系：包含，扩展和泛化。泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。

1）包含

两个以上提取共同行为，比如学习课程和检查权限。
用例“入库管理”和用例“用户登录”之间的关系；用例“出库管理”与用例“用户登录”之间的关系

2）扩展

用例混合多个场景，可能发生多种分支，比如课程测试与充值。
包含关系一定要执行的特征，扩展关系则是一种可选择执行的关系。
用例“査看统计报表”和用例“生成统计报表”之间的关系；

3）泛化

多个用例拥有一种类似的结构和行为，可将共性抽象为父用例。
用例“用户注册”和用例“电话注册”之间的关系；用例“邮件注册”和用例“电话注册”之间的关系。

4）用例规约

用例规约包含的内容：用例名称，简要说明，事件流，非功能需求，前置条件和后置条件，扩展点，优先级。

2. 多态的定义

多态的定义：具有相似功能的不同函数用同一名称实现。
多态分为四类：包含多态，参数多态，过载多态，强制多态。

包含多态
类族中定义不同类中的同名成员函数的多态行为，比如子类型化，即一个类型是另一个类型的子类型。
参数多态
最纯的多态。同一对象，函数，或能以一致的形式用于不同的类型。
过载多态
重载多态，同一运算子被用于表达不同的功能
强制多态
通过语义操作把一个变元的类型加以变换。

【按实现角度分类】

多态又可以分为：编译时多态和运行时多态。

编译时多态
静态联编。在编译过程中确定同名操作的具体操作对象。
运行时多态
动态联编。在程序运行过程中才动态的确定操作所针对的具体对象

3. 问题域的定义

问题域是指一个包含现实世界事物与概念的领域。这些事物和概念与涉及的系统要解决的问题有关。建议概念模型又称为问题域建模，或域建模，也就是找到代表那些事物与概念的对象

4. OOA的基本概念

OOA描述软件要做什么，而不是需要考虑技术和实现层面的细节。
OOA的结果是OOD的输入，OOD的结果是OOP的输入。
OOA基于用例模型，通过对象建模记录确定的对象，对象封装的数据和行为，以及对象之间的关系。
OOA包括了三个活动：建模系统功能，发现并确定业务对象，组织对象并确定对象间的关系。
OOD是模型驱动和用例驱动的，整个设计过程将OOA阶段所产生的需求模型作为输入，并生成供构建阶段使用的设计模型作为输出。依赖是两个模型元素之间的关系。被依赖的模型元素发生变化就会影响到另一个模型元素。
在OOA的过程中，使用概念模型来详细描述系统的问题域，用类图来表示概念模型。

5. UML基础概念

UML适用于各种软件开发方法，软件生命周期的各个阶段，各种应用领域，各种开发工具。
UML标准并没有定义一种标准的开发过程，但他适用于迭代式开发过程，它是为支持大部分现存的面向对象开发过程而设计的。
UML通用机制中，包用于把元素组织成组，构件是系统中遵从一组接口规范且付诸实现的物理的，可替换的软件模块

6. 方法调用与消息机制

方法调用是同步的，消息机制是异步的。
方法调用是指当某个事件发生的时候，调用某个对象的方法来处理事件。
消息机制是指当某个事件发生的时候，把相关消息发送给某些对象（一个或者多个），相关对象捕获消息后，进行相应的处理。
消息是通过消息总线来发送，支持多个数据的发送者和接收者，更加灵活；而方法调用效率更高。但是消息机制的可靠性更高

7. Java2EE

表现层，业务逻辑层和基础设施层（持久层）这三层组成。
基础设施层应该要保持稳定，要严格区分业务逻辑层和表现层，还有不要在表现层中混杂业务代码。
对象持久化是将内存中的数据以数据库或物理文件的形式，保存到可永久存储的设备

二. 框架与类库

框架和类库都可以被认作是一种基础结构，而我们编写的代码是应用代码。
若是基础代码调用应用代码，则这种基础结构是框架；若是应用代码调用基础代码，则这种基础结构就是类库。
框架它是一个半成品的应用程序，而类库只是一系列可被应用程序调用的类。
类库总是被动调用相应用户的调用请求，框架则会为某一特定目标的实现一个基本，可执行的架构，类库是死的框架是活的。
框架中包含了应用程序，从启动到运行的所有流程。流程中无法预先确定的步骤，留给用户来实现。
程序运行时，框架自动调用用户实现的功能组件。框架是控制倒转原则的完美体现

三. 4+1视图

1. 用例视图

最基本的需求分析模型（用例图，活动图），
项目干系人是用户和开发人员，组件元素是步骤。

2. 逻辑视图

以问题域的词汇所组成的类和对象的集合（类图），主要支持功能需求，即下调提供给最终用户的服务。

3. 进程视图

侧重系统运行特征。可执行线程和进程作为活动类建模，是逻辑视图的一次执行实例。
绘制了所设计的并发与同步结构。（可考虑用协作图，状态图）

4. 部署视图

也叫做开发视图。侧重软件模块的组织和管理。
对组成基于系统的物理代码的文件和组件进行建模。（组件图和类图）

5. 物理视图

把构件部署到一个物理的，可计算的结点上，表示软件到硬件的映射关系及分布结构（部署图）
通常需要考虑到解决系统拓扑结构，系统安装和通信等问题

四. OO测试

面向对象的测试分为了四个层次：算法层，类层，模版层和系统层。

算法层
测试与对象关联的单个操作，由于是测试单个方法，所以相当于传统软件测试中的单元测试。
类层
测试单个对象类
模版层
测试对象集群，测试一组协同工作的类之间的相互作用。
系统层
测试整个面向对象系统

五. 面向对象设计原则

1）依赖倒置原则

上层模块不应该依赖于下层模块，它们共同依赖于一个抽象。
抽象不能依赖于具体，具体依赖于抽象。
它是为了消除两个模块之间的依赖关系，应该在两个模块之间定义一个抽象接口，上层模块调用抽象接口定义的函数，下层模块实现该接口。
简而言之就是要针对接口而不是实现来编程。

2）里氏替换原则

任何基类可以出现的地方，子类一定可以出现。

3）开闭原则

一个软件应当对扩展开放，对修改关闭。

4）接口隔离原则

为客户端提供尽量小的单独接口，而不是提供大的接口

5）组合复用原则

要尽量使用组合而不是继承关系达到复用目的

6）迪米特法则

也叫做最小知识法则，一个对象应该对其他对象有尽可能少的了解。

7）单一职责原则

设计目的单一的类
在识别对象的时候，采用名称-动词法：从名词，名词短语中识别对象和属性，从动词，动词短语中识别操作和关联。
在识别对象之后，就要对对象进行筛选，需要删除以下三类名词：对象的同义词，系统范围之外的名词和不具备独特行为的名词。

六. UML构成元素

1. 基本组成

UML由基本构造块，公共机制和规则三方面组成。
其中基本构造块又包括了事物，关系和图三种。
在基本构造块中，图能够表示多个相互关联的事物的集合
规则是构造块如何放在一起的规定，包括了命名、范围、可见性、完整性和执行。

2. 构造块----关系

UML的四种关系：依赖，泛化，关联，实现；
协作定义了交互的操作，是一些角色和其他事物一起工作，提供一些合作的动作，这些动作比事物的总和要大

1）依赖

A变化则引起B变化
依赖是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义

2）实现

一个类实现一个接口
实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约
is-a基于类继承或接口实现，is-a是表达这句话的一种方式：“这个东西是那个东西的一种”。例如：野马是一种马。
has-a关系是基于用法（即引用）而不是继承。换句话说，如果类a中的代码具有对类b实例的引用，则“类a has-a类b”。例如：马有缰绳。

3）泛化

一般事物与特殊种类之间的关系。
继承关系是泛化关系的反关系。

4）关联

两个类实例之间存在某种语义联系，如老师和学校。
包括聚集关系和组合关系。
聚合关系:整体与部分生命周期不同。
组合关系:整体与部分生命周期相同

3. 构造块----事物

UML中的事物也称为建模元素

1）结构事物

通常是模型的静态部分，描述概念或物理元素；
UML有七种结构事物，分别是类，接口，协作，用例，活动类，构件和节点。
2.1）类是描述具有相同属性方法，关系和语义的对象的集合，一个类实现一个或者多个接口：
2.2）接口是指类或构件提供特定服务的一组操作的集合，它描述了类或构件的对外的可见的动作；
2.3）协作定义了交互的操作，是一些角色和其他事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
2.4）用例是用来描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的。
2.5）构件是物理上或可替换的系统部分，它实现了一个接口的集合；
2.6）节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
2.7）活动类的对象有一个或者多个进程或者线程。活动类和类很相似，只是他的对象代表的事物的行为，和其他事物是同时存在的；

2）行为事物

它是UML行为模型中的动态部分，代表时间和空间上的动作。UML有两种主要的行为事物：

交互

交互是指一组对象之间在特定的上下文当中，为达到特定目的而进行的一系列消息交换而组成的动作；
交互中组成动作的对象的每个操作都要详细的列出，包括消息，动作次序，连接；

状态机

状态机由一系列对象的状态组成。

3）分组事物

是UML模型的组织部分，可以把它们看成是个盒子，模型可以在其中进行分解
UML只有一种分组事物，叫做包；包是一种将有组织的元素分组的机制。
与构件不同的是包纯粹是一种概念上的事物，只存在于开发阶段，而构件可以存在于系统的运行阶段。

4）注释事物

是UML模型的解释部分。
这些注释事物用来描述、说明和标注模型的任何元素。

4. 公共机制

公共机制是指达到特定目标的公共UML方法，主要包括规则说明、修饰、公共分类和扩展机制。

1）规则说明

是元素语义的文本描述，它是模型真正的核心；
公共机制中，规则是关于事物语义的细节描述。

2）修饰

UML为每一个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；

3）公共分类

公共分类包括类元和与实体、接口和实现两组公共分类；

4）扩展机制

扩展机制包括约束、构造型、标记值。

七. UML图形

向对象动态分析模型描述系统的动态行为，显示对象在系统运行期间不同时刻的动态交互。其中，交互模型包括顺序图和通信图。其他行为模型还有状态图和活动图。

1. 定时图

定时图是一种新增的、特别适合实时和嵌入式系统建模的交互图，也称为计时图 (Timing Diagram)
计时图关注沿着线性时间轴、生命线内部和生命线之间的条件改变。
它描述对象状态随着时间改变的情况，很像示波器，适合分析周期和非周期性任务。
定时图强调消息跨越不同对象或参与者的实际时间，而不仅仅关心消息的相对顺序。

2. 交互概览图

交互概览图（Interaction Overview Diagram）
是UML 2.0新增的交互图之一，它是活动图的变体
描述业务过程中的控制流概览，软件过程中的详细逻辑概览，以及将多个图进行连接，抽象掉了消息和生命线。

3. 活动图

活动图专注于描述系统的动态视图。它对系统的功能建模持别重要，并强调对象间的控制流程。
它将进程或其他计算结构展示为计算内部的控制流和数据流，主要用来描述系统的动态视图。
泳道在UML活动图中区分了负责活动的对象，它明确地表示了哪些活动是由哪些对象进行的。

4. 包图

包图（package diagram）
包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系

5. 类图

类图描述一组类，接口，协作和它们之间的关系。

6. 对象图

一组对象以及它们之间的关系。
对象图描述了在类图中所建立的事物实例的静态快照。

7. 构件图

构件图描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部内容。
构件图用于表示系统的静态设计实现视图。
对于由小的部件构建大的系统来说，构件图是很重要的，构件图是类图的一个变体。一个封装的类和它的接口。

8. 部署图

部署图描述对运行时的处理节点及在其中生存的构建的配置。
部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图，软硬件之间的映射。

9. 制品图

系统的物理结构

10. 通信图

它也叫协作图。它也是一种交互类型的图。
它强调收发消息的对象或参与者的结构组织。

11. 状态图

它是用来描述一个状态机，它由状态，迁移，事件和活动组成。
状态图给出了对象的动态视图。
它对于接口，类或协作的行为建模尤为重要。
而且它强调事件导致的对象行为，这非常有助于对反映式系统建模，状态转换变迁。

12. 用例图

系统与外部参与者之间的交互
####【顺序图VS协作图】
顺序图和协作图统称为交互图。顺序图着重体现交互的时间顺序，协作图着重体现交互对象间的静态连接关系。
顺序图精确表达用户与系统之间复杂交互过程。
顺序图用于描述进出系统的复杂交互过程。
顺序图用于描述进出系统的信息流。
顺序图和协作图同构的，可以相互转换。
顺序图着重体现对象间消息传递的时间顺序，顺序图允许直观的表示出对象的生存期，生存期内对象可以对输入消息作出响应，并且可以发送消息。
箭头指明消息的类型，消息用消息名和参数来标识。
协作图：用于描述相互合作的对象间的交互关系和链接关系。
顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构。

【活动图的定义】

用于表示系统中各种活动的次序，它的应用非常广泛，即可用来描述用例的工作流程。也可以用来描述类中某个方法的操作行为。常用于表示业务流程，对系统功能的建模。强调对象之间的控制流。
####【活动图VS状态图】
活动图是由状态图变化而来，活动图依据对象状态的变化里捕获动作。活动图中一个活动结束后将立即进入下一个活动，状态图中状态的变迁可能需要事件的触发。主要用于系统功能建模。
状态图注重于由事件驱动的系统的变化状态，活动图注重于从活动到活动的控制流。
活动图是状态机的一种特殊情况，其中全部或大多数状态是活动状态，并且全部或大多数状态转换时，通过源状态中活动的完成来触发。
活动图适应状态机的全部特征。活动图和状态图在对一个对象的生命周期建模时，都是有用的。
注：数据流图和流程图是结构化方法中的概念。
####【活动图VS传统的流程图】
程序流程图明确的指定了每个活动的先后顺序，而活动图只描述了活动和必要的工作顺序。
流程图限于顺序进程，而活动图支持并发进程。
活动图是支持面向对象的，而流程图是面向过程的。

【UML五种建模图】

用例图：描述用例和参与者之间的关系，它对系统行为的组织和建模相当重要。
交互图：包括顺序图，通信图（与顺序图只是排版不同），定时图。顺序图是描述对象按照时间顺序的消息流。
活动图：也叫基本活动图，泳道活动图，交互概览图。
状态图：显示一个由状态，转换，事件和活动组成的状态机，强调一个对象按事件次序发生的行为。

八. 面向对象识别设计类

识别设计类是面向对象设计过程中的重要工作
设计类表达了类的职责，即该类所担任的任务。

1. 实体类

它映射了需求中的每个实体，保存需要存储在永久存储体中的信息。
例如商品，订单，注册用户，送货信息，购物车等都是实体类。

2. 控制类

控制类是用来控制用例工作的类。
用于对一个或几个用例所持有的控制行为进行建模。
例如：订单结算，订单支付，备货，出货，一般是由动宾结果的短语转化而来的。

3. 边界类

用来封装在用例内外流动的信息或数据流。
例如：浏览器，购物车，商品页面信息，订单信息录入页面和订单表单都属于边界类。