中级软考-软件设计师（六）

开发方法（结构化和面向对象）

1.通信图（协作图）

描述的是对象和对象之间的关系，即一个类操作的实现。"协作”作为一个结构事物用于表达静态结构和动态行为的概念组合，表达不同事物相互协作完成一个复杂功能。

2.序列图

序列图的基本元素包括对象、生命线和消息。

 

调用消息用带实心箭头的实现表示，返回消息 用带虚线箭头表示。

3.活动图

用于对系统的动态行为建模的一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。

活动图是一种特殊的状态图，但在状态图中，每条箭线上都会有事件，而活动图不一定有。

活动图一般包括活动状态和动作状态、转换和对象。通常有两种使用活动图的方式。

对工作流建模。

对操作建模。

 

4.类图

展现了一组对象接口、协作和它们之间的关系。类图中通常包括下述内容：类；接口；协作；依赖、泛化和关联关系。类图中也可以包含注解和约束。类图还可以含有包或子系统，二者都用于把模型元素聚集成更大的组块。用于对系统的静态设计视图建模。

聚集关系和组合关系表示更强的关联关系，表示整体和部分的关系，而组合关系的类之间具有相同的生命周期。

通常以下述3种方式之一使用类图。

对系统词汇建模。

对简单协作建模。

对逻辑数据库模式建模。

5.用例图

展现了一组用例、参与者以及它们之间的关系。

用例图通常包括以下内容：

用例；参与者；用例之间的扩展关系(<<extend>>)和包含关系(<<include>>)，参与者和用例之间的关联关系，用例与用例以及参与者与参与者之间的泛化关系。

以图形化的方式描述系统与外部系统及用户的交互。

用于对系统的静态用例视图进行建模。可以用下列两种方式来使用用例图。

对系统语境建模。

对系统需求建模。

包含关系。当可以从两个或两个以上的用例中提取公共行为时，该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。

扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。

泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。

扩展关系和包含关系的区别在于包含关系的子用例离开了基用例就不能执行。

 

6.构件图

展现了一组组件之间的组织和依赖。构件图专注于系统的静态实现视图。它与类图相关，通常把构件映射为一个或多个类、接口或协作。

 

7.包图

展现由模型本身分解而成的组织单元以及其间的依赖关系。包可以拥有其他元素，可以是类、接口、构件、结点、协作、用例和图，甚至是嵌套的其他包。

拥有是一种组成关系，是一种按规模来处理问题的重要机制，也意味着元素被声明在包中，一个元素只能被一个包所拥有，拥有关系的包形成了一个命名空间，其中同一种元素的名称必须唯一。

8.部署图

描述系统中硬件和软件的物理架构，它描述构成系统架构的软件结构、处理器和设备。

9.定时图

强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。

10.静态结构和动态视图

静态结构：主要包括用例图、类图和包图；

动态视图：主要包括活动图、状态图、序列图和协作图。

交互视图主要包括序列图、协作图（通信图）、交互概览图、时序图。

11.统一建模语言(UML)

可视化的建模语言，而不是编程语言，适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具。 它比较适合用于迭代式的开发过程。

UML文档描述了面向对象分析与设计的结果。面向对象分析的第一步是确定问题域。

面向对象分析的任务包含建模系统功能、发现并确定业务对象、组织对象并确定对象间的关系。不包括建模各对象的状态。

面向对象分析的主要活动包括认定并组织对象、描述对象间的相互作用、确定基于对象的操作，不包括面向对象程序设计。

12.UML系统视图描述系统的组织结构。

逻辑视图。从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能。

进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。

实现视图。基于系统的物理代码的文件和构件进行建模。

部署视图。把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。

用例视图。用例视图是最基本的需求分析模型。显示外部参与者观察到的系统功能。

13.UML事物包括：结构事物、行为事物、分组事物、注释事物。

结构事物:通常是UML模型的静态部分，描述概念或物理元素。

行为事物:是UML模型的动态部分，描述了跨越时间和空间的行为。         

分组事物是UML模型的组织部分。在所有的分组事物中，最主要的分组事物是包(Package)。结构事物、行为事物甚至其他分组事物都可以放进包内。包与构件(仅在运行时存在)不同，它纯粹是概念上的(即它仅在开发时存在)。

注释事物是UML模型的解释部分。这些注释事物用来描述说明和标注模型的任何元素。注解是一个依附于一个元素或者一组元素之上，对它进行约束或解释的简单符号。

 

14.基于UML的关系数据库设计分为4个阶段:

业务用例设计是进行数据库的需求分析，使用用例图等建立业务模型;

逻辑数据模型设计是确定应用系统所需的持久数据，设计出关系数据库中表达持久数据的实体类及其联系，并将它们映射为数据库表和视图等;

物理数据模型设计使用组件图、配置图等设计数据库的物理模型;

物理实现设计根据物理数据模型建立具体数据库环境下的数据库表、视图等。

15.UML的四种关系

依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。

关联描述一组对象之间连接的结构关系。

泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。一般是统称，特殊指特定具体的。

实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的结构。

16.对象的组成部分包括：对象名、状态（属性）、行为（操作）。

17.设计模式 

工厂方法模式(Factory Method)：定义一个创建对象的接口，但由子类决定需要实例化哪一个类。使得子类实例化的过程推迟。

抽象工厂模式(AbstractFactory)：提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类。

生成器模式(Builder)：将复杂类与其构造相分离，使得相同的构建过程能够得出不同的表示。

原型模式(Prototype)：用原型实例指定创建对象的类型，并且通过拷贝这个原型来创建新的对象。

单例模式(Singleton)：保证一个类只有一个实例，并提供一个访问它的全局访问点。

适配器模式(Adapter)：将一个类的接口转换成用户希望得到的另一种接口。既是类结构型模式，又是对象结构型模式。

桥接模式(Bridge)：将类的抽象部分和实现部分分离，使它们独立地变化。

组合模式(Composite)：将对象组合成树型结构以表示“整体-部分”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

装饰器模式(Decorator)：动态地给一个对象添加一些额外的职责，比派生一个子类更加灵活。

外观模式(Facade)：定义一个高层接口，为子系统中的一组接口提供一个一致的外观，从而简化了该子系统的使用。

享元模式(Flyweight)：提供支持大量细粒度对象共享的有效方法。

代理模式(Proxy)：为其他对象提供一种代理以控制这个对象的访问(限制对象访问)。

责任链模式(Chain of Responsibility)：很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。

命令模式(Command)：将一个请求封装为一个对象，从而使得可以用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。

中介者模式(Mediator)：用一个中介对象封装一系列的对象交互。中介者使用的各对象不需要显式的相互调用，从而使其耦合松散。如使一个后端数据数据模型能够被多个前端用户界面连接。

观察者模式(Observer)：定义对象间的一种一对多依赖关系，使得每当一个对象改变状态，则其相关依赖对象皆得到通知并被自动更新。最适合用于发布/订阅消息模型。适用于当一个对象必须通知其他对象，而它又不能假定其他对象是谁，也就是说使所要交互的对象尽量松耦。在Observer模式中，Observer需要维护至少一个Subject对象，一个 Subject对象需要维护多个Observer对象，另外Subject需要通知Observer对象其自身的状态变化。

状态模式(State)：将每一个条件分支放入一个独立的类中，这样就可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。

策略模式(Strategy)：定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。让算法独立于使用它的客户而独立变化。应用场景：需要使用一个算法的不同变体，许多相关的类仅仅是行为有异。

参与者模式(Visitor)：抽象访问者-具体访问者-抽象元素-具体元素-对象结构。

18.适配器模式与桥接模式类似的特征是，都给另一个对象提供了一定程度上的间接性，都涉及到从自身以外的一个接口向这个对象转发请求。

19.中介者模式和观察者模式是相互竞争的模式。

20.软件开发模型大体上可以分为三种类型。

第一种是以软件需求完全确定为前提的瀑布模型。

第二种是在软件开发初始阶段只能提供基本需求时采用的迭代式或渐进式模型，例如喷泉模型、螺旋模型、统一开发过程和敏捷方法等。

第三种是以形式化为基础的变换模型。

21.常见原则

开-闭原则是指一个软件实体应当对扩展开放，对修改关闭；

里氏代换原则是指任何基类型可以出现的地方，子类对象一定可以出现。子类还可以替换父类。

依赖倒转原则就是要依赖于抽象，而不依赖于实现，或者说要针对接口编程，不要针对实现编程。

迪米特原则：一个对象应当对其他对象有尽可能少的了解。

22.结构化方法

由结构化分析、结构化设计、结构化程序设计构成，它是一种面向数据流的开发方法。

结构化分析是用数据流图来建立系统的功能模型，从而完成需求分析工作。

结构化方法的核心思想是"自顶向下，逐步分解”。

特别适合于数据处理领域的问题，但是不适合解决大规模的、特别复杂的项目，且难以适应需求的变化。

23.通用多态又分为参数多态和包含多态；特定的多态分为过载多态和强制多态。

参数多态：采用参数化模板，通过给出不同的类型参数，使得一个结构有多种类型。

包含多态：同样的操作可用于一个类型及其子类型(注意是子类型，不是子类)。包含多态一般需要进行运行时的类型检查。

过载多态：同一个名(操作符、函数名)在不同的上下文中有不同的类型，程序设计语言中基本类型的大多数操作符都是过载多态的。

强制多态：程序设计语言中基本类型的大多数操作符，在发生不同类型的数据进行混合运算时，编译程序一般都进行强制多态。

24.根据信息流的特点，可将数据流图分为变换型数据流图和事务型数据流图，其对应的映射分别称为变换分析和事务分析。

在规模较大的实际系统中，其数据流图往往是变换型和事务型的混合结构，此时可以把变换分析是事务分析应用在同一数据流图的不同部分。

25.类

实体类的对象表示现实世界中真实的实体，如人物等。

接口类(边界类)的对象为用户提供一种与系统合作交互的方式，分为人和系统两大类，其中人的接口可以是显示屏、窗口、Web窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统，或者从其他系统接收数据。

控制类的对象用来控制活动流，充当协调者。

26.对象的状态标识了该对象的所有属性以及每个属性的当前值。

27.面向对象分析过程中，从给定需求描述中选择名词短语来识别对象。

28.Lisp是函数式程序设计语言。

29.结构化开发方法中，过程设计主要包含对数据结构和算法的设计。

30.对象之间通过消息传递方式进行通信。

31.在进行面向对象设计时，采用设计模式能够复用相似问题的相同的解决方案。

32.模型

类型	特征
瀑布模型	结构化方法。开发阶段性、需求明确、文档齐全、风险控制弱
原型模型	迭代方法。分为原先开发与目标软件开发。需求不明确
螺旋模型	迭代方法。瀑布模型与原型(演化)模型结合体。适合于大型、复杂、风险项目
喷泉模型	面向对象方法。复用好、开发过程无间隙、节省时间
v模型	开发与测试结合
变换模型	适合于形式化开发
智能模型	适合于基于规则的专家系统
快速应用开发RAD	基于构件的开发方法。用户参与、开发或复用软件、模块化要求高，不适合新技术
RUP/UP	用例驱动、架构为中心、迭代、增量
可重用构建模型	基于构件的开发方法。开发或复用软件

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

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

模块的耦合类型通常分为7种，根据耦合度从低到高排序如下表所示。

耦合类型	描述
非直接耦合	两模块无直接关系，联系完全通过主模块的控制和调用
数据耦合	借助参数表传递简单数据
标记耦合	通过参数表传递记录信息(数据结构)
控制耦合	传递的信息中包含用于控制模块内部逻辑的信息
外部耦合	访问同一全局变量(非全局数据结构)，不是通过参数表传递
公共耦合	访问同一个公共数据环境(如全局数据结构、共享通信去、公共内存)
内容耦合	不通过正常入口直接访问另模块的内部数据，代码重叠，模块有多个入口

34.内聚

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

模块的内聚类型通常也可以分为7种，根据内聚度从高到低的排序如下表所示。

内聚类型	描述
功能内聚	完成单一功能,各部分协同工作,缺一不可
顺序内聚	处理元素相关,且顺序执行
通信内聚	所有处理元素集中在一个数据结构的区域上
过程内聚	处理元素相关,必须按特定的次序执行
瞬时内聚	任务必须在同一时间间隔内执行
逻辑内聚	完成逻辑上相关的一组任务
偶然内聚	完成一组没有关系或松散关系的任务

35.在“模型一视图一控制器”(MVC)模式中， 视图主要表现用户界面，模型用来描述核心业务逻辑。

36.父图与子图的平衡是指父图的输入/输出数据流与子图的输入/输出数据流一致，有时看起来不一致，但是经过查验数据字典可能发现是一致的。

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

38.JavaScript属于Web客户端脚本语言。

39.状态图