2020年6月——北京大学《软件工程》笔记_实体看结构关系看度量

1软件工程概述

一、软件的定义

         计算机系统种的程序及其文档。

         程序：计算机任务的处理对象和处理规则的描述。

         文档：为了便于理解程序所需要的阐明性资料。

 

         ●软件是无形的、不可见的逻辑实体

         ●软件是设计开发的，而不是生产制造的

         ●软件在使用过程中没有磨损、老化的问题

         ●软件是定制开发的

         ●软件是复杂的

         ●软件的开发成本高

         ●软件易于复制

 

二、软件的分类

         软件一般分为系统软件、支撑软件和应用软件三类。

 

支撑软件：支撑软件的开发、维护和运行的软件。

 

三、软件开发的含义

         软件开发：实现问题域中的概念和处理逻辑到运行平台的概念和处理逻辑的映射。

 

        

         软件开发的本质：

                  不同抽象层次术语之间的“映射”

                  不同抽象层处理逻辑之间的“映射”

 

         建模是解决问题的一般途径！

 

四、软件工程的目标

         软件工程可定义为三元组：<目标、原则、活动>

                  （1）给出了软件所涉及软件工程的工程要素

                  （2）给出了各要素之间的关系

                  （3）给出了软件工程学科所研究的主要内容

 

         1、目标

                  生产具有正确性、可用性以及开销合宜的产品。

                           真确性：软件产品达到预期功能

                          可用性：软件基本结构、实现及文档为用户可用

                          开销合宜：软件开发、运行的整个开销满足用户要求

         2、活动

                  ——生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。

                  ——主要包括需求、设计、实现、确认和支持等活动。

                          需求：定义问题，即建立系统模型

                          需求获取、需求定义、需求规约、需求验证

 

                          设计：在需求分析的基础上，给出系统的软件设计方案。

                                   总体设计和详细设计

 

五、重新定义软件

         重新定义软件：软件是客观世界中问题空间与解空间的具体描述。

 

         软件=程序+文档

 

六、软件过程

         1、基本概念

                  软件生存周期：软件产品或系统的一系列活动的全周期。从形成概念开始，历经开发、交付使用、在使用中不断修订和烟花，直到最后被淘汰。

 

                  软件生存周期过程（软件过程）：软件生存周期中的一系列相关过程。

 

                  软件过程（Process）：活动的一个集合。

                  活动（Activity）：任务的一个集合。

                  任务（Task）:将输入转换为输出的操作。

 

         2、过程分类

                  （1）基本过程（Primary Process）：是指那些与软件生产直接相关的活动集。

                  （2）支持过程（Supporting Process）：是指有关各方按其目标所从事的一系列支持活动集。

                  （3）组织过程（Institutional process）：是指那些与软件生产组织有关的活动集。

七、软件生存周期模型

         （1）瀑布模型

                  ·软件生存周期各项活动规定为依固定顺序而连接的若干阶段工作

                  ·规定了每一阶段的输入，以及本阶段的工作成果，作为输出传入下一阶段

         （2）增量模型：该模型有一个假设，即需求可以分段，成为一系列增量产品，每一增量可以分别地开发。

                  关于增量模型的几点说明:

                          A）增量模型的优点

                                   作为瀑布模型的第一个变体，具有瀑布模型的所有优点。此外，它还有以下优点:

                                            ①第一个可交付版本所需要的成本和时间是很少的

                                            ②开发由增量表示的小系统所承担的风险是不大的

                                            ③由于很快发布了第一个版本，因此可以减少用户需求的变更

                                            ④允许增量投资，即在项目开始时，可以仅对一个或两个增量投资。

                          B）缺点

                                   如果增量模型不适于某些项目，或使用有误，则有以下缺点:

 

                                   ①如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增彙的不稳定

                                   ②如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布;

                                   ③管理发生的成本、进度和配置的复杂性，可能会超出一些组织的能力。

 

         （3）演化模型

                  是一种有弹性的过程模式，由一些小的开发步组成，每一步历经需求分析、设计、实现和验证，产生软件产品的一个增量。通过这些送代，完成最终软件产品的开发

 

         （4）喷泉模型

                  特征：迭代、无缝

 

 

 

 

2需求

1、需求与需求获取

         一个需求是一个有关“要予构造”的陈述，描述了待开发产品/系统功能上的能力、性能或者其他性质。

 

2、什么样的陈述可以作为需求

         ——需求的基本性质

         ①必要的。是要求的吗？

         ②无歧义的。只能用一种方式解释吗？

         ③可测的。可以对它进行测试吗？

         ④可跟踪的。可以从一个开发阶段到另一个阶段对它进行跟踪吗？

         ⑤可测量的。可以对它进行测量吗？

3、需求的分类

         ①功能需求

                  规约了系统或系统构件必须执行的功能。

         ②性能需求

                  规约了一个系统或系统构件必须具有的性能特性。

         ③外部接口需求

                  规约了系统或系统构件必须与之交互的硬件、软件或数据库元素。

         ④设计约束

         ⑤质量属性

 

4、需求发现

         ①自悟

         ②交谈

         ③观察

         ④小组会

         ⑤提炼

5、需求规约

         一个需求规约是一个软件项/产品/系统所有需求陈述的正式文档，是一个软件产品/系统的概念模型。

        

         1、需求规约的基本性质：

                  ①重要性和稳定性程度

                  ②可修改的

                  ③完整的

                  ④一致的

 

         2、需求规约格式

 

         3、需求规约的作用具作用可概括为：

                 

         第一，是最重要的，作为软件开发组织和用户之间一份事实上的技术合同书;是产品功能及其环境的体现。

         第二，对于项目的其余大多数工作，它是一个管理控制点。

         第三，对于产品的设计，它是一个正式的、受控的起始点。

         第四，是创建产品验收测试计划和用户指南的基础，即基于常求规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述。

 

3 结构化分析方法 4结构化设计

1、什么是软件设计的启发规则？有哪些启发规则？

1.改进软件结构提高模块独立性

2.模块规模应该适中

3.深度、宽度、扇出和扇入

         扇入：有多少个上级模块直接调用它（不违背独立性条件下，扇入越大越好）

         扇出：一个模块直接调用的下级模块数

4.模块的作用域在控制域内

                  作用域：一个模块所影响的所有模块

                  控制域：一个模块直接或间接控制的模块

         5.力争降低模块接口的复杂程度

         6.设计单入口单出口模块

         7.模块功能应该可以预测

2、借鉴启发规则，理解将初始软件结构图（MSD）进一步精化的方法

变换型/事务性——确定输入/输出边界（孤立变换中心）——第一级分解（分配控制）——DFD中的每个处理映射成软件结构中一个适当的模块
3、知道接口设计的分类，理解人机交互界面设计的相关问题，用户界面应该具体的特性，界面设计应该遵循的原则

         接口分类：①模块和软件构件之间 ②软件和其他软硬件系统之间 ③软件与用户之间

                  系统接口设计（包括用户界面设计与其他系统的接口设计）由穿过系统边界的数据流定义的。

         用户界面的特性：可用性——灵活性——可靠性（苏老师ppt）

         界面设计原则：一致性，操作步骤少，不要哑播放（有提示音），提供undo功能（反馈，“很多人，我做了，我就做了”），减少人脑记忆负担——提高学习效率

 

 

 

详细设计工具

1.伪码 类程序设计语言PDL，Program Design Language（作为注释，直接插在源程序中间）

2.程序流程图 直观，但缺乏全局观,不能逐步求精 描述模块内部的处理结构，但无数据结构

3.PAD图(problem analysis diagram，问题分析图) 逐步求精 PAD图是一种描述程序逻辑结构的工具

4.N-S图，盒图 逐步求精

5.判定表和判定树表 解决多重嵌套的条件选择

 

 

软件设计规约

3.1什么是软件设计规约 满足系统规约所指定的全部功能及性能要求

3.2软件规约的组成 概要设计规约和详细设计规约

         概要设计规约：

                  （1）系统环境

                  （2）设计描述

                  （3）对每个模块的描述

                  （4）文件结构和全局数据

         面向软件开发者的文档，主要作为软件项目管理人员、系统分析和设计人员之间交流的媒体

                  概要设计规约对应于系统的确认测试

         详细设计规约：

                  （1）各过程的处理算法

                  （2）算法所涉及的全部数据结构的描述

         详细设计规约主要作为软件设计人员与编程人员之间交流的媒体

                  详细设计规约对应于系统的单元测试

         详细设计的任务：

                  定义每个模块的算法和数据格式

3.3设计规约格式

结构化方法总结

         结构化方法的基本原则：

                  1）自顶向下功能分解

                  2）数据抽象

                  3）过程/功能抽象

                  4）模块化

         结构化方法的抽象层：

                  1）需求分析层

                  2）设计层

                  3）实现层

         结构化方法逐渐被面向对象方法所取代，存在问题：

              1）分析阶段和设计阶段的术语空间不一致

              2）解的结构没有保持原系统的结构

              3）捕获的“过程”和“数据”都是易变的

 

软件设计评审

         正式评审、非正式评审

         概要设计评审，从需求到设计数据和体系结构的变换

         详细设计评审，详细设计走查，注重算法的正确性

 

 

 

5UML

5.1面向对象方法

         1引言

                  面向对象方法是一种以对象、对象关系等来构造软件系统模型的系统化方法。

 

                  面向对象方法的世界观：一切系统都是由对象构成的，它们相互作用、相互影响，构成了大千世界的各式各样系统。

 

         UML，统一建模语言

 

 

         ●面向对象不仅仅是一种程序开发方法

                  使用面向对象程序设计语言

                  使用对象、类、继承、封装、消息等基本概念进行编程

 

         ●面向对象是一种软件方法学

                  如何看待软件系统与现实世界的关系

                  以什么观点进行求解

                  如何进行系统构造

 

                          面向对象方法学习什么？

基本知识

         ●清晰、准确、熟练地掌握面向对象方法的主要思想、基本概念与原则

 

面向对象分析（OOA）

面向对象设计（OOD）

         ●了解OOA和OOD的主要概念与操作过程，会应用。

面向对象程序设计（OOP）

         ●了解OOP的基本思想，学会用C++语言实现面向对象的分析与设计方法建立的系统模型。

 

 

5.2UML概述

         UML是一种可视化语言，用于：

                  （1）规约系统的制品——UML适用于对所有重要的分析、设计和实现决策进行详细描述。

                  （2）构造系统的制品——UML描述的模型可于各种编程语言直接相关联。

 

 

 

         表达操作的完整语法格式为：

 [可见性]操作名[(参数表)][:返回类型][｛性质串｝]

其中：

         ①可见性        如同属性的可见性一样，其值可以为：

                  +公有的  可供其它类访问之

                  #受保护的      其子类能访问之

                  -私有的   只有本类的操作才能访问之

                  ~包内的  只有在同一包中声名的类才能访问之。

 

②操作名

    ・操作名一般是一动词或动词短语，通常以小写字母开头，左对齐

    ・如果操作名是动词短语，除第一个词外，其余每个词的第一个字母为大写，例如 isempty0

    ・若操作是一个抽象操作，则以斜体字表示之。

 

5.3接口

         ——体现功能抽象

         （1）定义：

                  接口（interface）是一组操作的集合，其中每个操作描述了类或构件的一个服务。

         （2）接口的基本作用：模型化系统中的“接缝”，即

                  ①通过声明一个接口，表明一个类、构件、子系统提供了所需要的、且与实现无关的行为；

                  ②表明一个类、构件、子系统所要得到的、且与实现无关的行为。

         （3）接口的表示

                  ①可以使用带有分栏和关键字<<interface>>的矩形符号来表示接口。

 

                  ②可以用小圆圈来表示接口：

 

5.4协作

         ——体现行为结构抽象

         协作是一组类、接口和其他元素的群体，它们共同工作以提供比各组成部分的总和更强的合作行为。

 

5.5用况（use case）

         ——体现功能抽象

         是对一组动作序列的描述，系统执行这些动作产生对特定的参与者一个有值的、可观察的结果。

 

         2点说明：

                  ①用况用于模型化系统中的行为。一个用况描述了系统的一个完整的功能需求。

                  ②用况是用过协作予以细化的。

 

5.6主动类

         ——体现并发行为的抽象

         是一种至少具有一个线程的类，因此它能够启动控制活动。

 

5.7构件

         构件是系统中逻辑的并且可替换的成分，它遵循并提供了一组接口的实现。

 

5.8制品

         是系统中物理的、可替代的部件

 

5.9节点

         是在运行时存在的物理元素，通常它表示一种具有记忆功能力和处理能力的计算机资源。

 

5.10包

         为了组织类目，控制信息组织和文档组织的复杂性，UML引入了术语-包。

                  包是模型元素的一个分组。一个包本身可以被嵌套在其他包中，并且可以含有子包和其他种类的模型元素。

 

5.11表达关系的术语

         在UML中，提供了4种关系，表达类目之间的关系，以构造一个结构良好的UML模型。

                  ①关联

                  ②泛化

                  ③实现

                  ④依赖

 

         ①关联

                  定义：关联是类目之间的结构关系，描述了一组具有相同结构、相同语义的链（links）。

 

 

聚合：一种特殊形式的关联，表达一种“整体/部分”关系。即一个类表示了一个大的事物，它是由一些小的事物（部分）组成的。

 

组合：如果整体类的实例和部分类的实例具有相同的生命周期，这样的聚合称为组合。

 

         ②泛化

                  泛化是一般性事物（称为超类或父类）和它的较为特殊种类（称为子类）之间的一种关系，又是称为“is-a-kind-of”关系。

 

         ③实现

         定义：实现是类目之间的一种语义关系，其中一个类目规约了保证另一个类目执行的契约。

 

         在以下2个地方会使用实现关系：

                  ●接口与实现它们的类和构件之间

                  ●用况与实现他们的协作之间

 

         表示：

 

 

         ④依赖

                  定义：依赖是一种使用关系，用于描述一个事物（如类Window）使用另一事物（如Event）的信息和服务。

 

 

5.12静态模型表达工具——类图

         一、UML为不同抽象层提供了6种可对系统静态部分建模的图形工具

                  ①类图

                          类图显示了类(及其接口)、类的内部结构以及与其他类的联系。是面向对象分析与设计所得到的最重要的模型。

                  ②构件图

                          在转入实现阶段之前，可以用它表示如何组织构件。构件图描述了构件及构件之间的依赖关系。

                  ③组合结构图

                          组合结构图展示了类或协作的内部结构

                  ④对象图

                          展示了一组对象以及它们之间的关系。用对象图说明在类图中所发现的事物的实例的数据结构和静态快照。

                  ⑤部署图

                          部署图展示运行时进行处理的结点和在结点上生存的制品的配置。部署图用来对系统的静态部署视图建模

                  ⑥制品图

                          展示了一组制品以及其间依赖关系。利用制品图可以对系统的静态实现视图建模。

 

         ①类图：类图显示了类（及其接口）、类的内部结构以及与其他类的联系，是面向对象分析和设计所得到的最重要的模型。

                  作用：可视化的表达系统的静态结构模型。

 

         二、UML为不同抽象层提供了7种可对系统动态部分建模的图形工具。

                  ①用况图：需求模型

                          用况图是表现一组Use cases、Actors以及它们之间的关系的图。

 

用例图和数据流图？

    用例图是参与者（Actor）、用例（Use cases）以及它们之间关系的图，用以表达系统的各种形态。用例图的主要包含六个抽象，即主题（Subject）、用例（Use cases）、参与者（Actor）、依赖、关联、泛化。

    用例图属于面向对象的分析方法的产物，主要是对系统内信息和操作的抽象分类，先将事物分类后，再考虑它们的功能和属性。已经这些类之间的相互关系。用例图更加面向于问题解决的方式和目的。

 

    数据流图属于结构化的分析方法的产物，是将系统的功能模块化，然后自顶向下、逐步求精式的完善系统中各个模块的具体功能。各模块之间的关系在接口设计时才全盘考虑，而用例图是在系统建模时考虑各个类之间关系。

 

什么是用例建模？

    用例建模的策略：

        ①通过标志参与者，建立系统语境。

        ②考虑参与者对系统行为的需求，并把这些需求作为用况。

        ③提取用况的公共行为，形成泛化结构；分解异常行为，放入新的用况。

        ④各种关系模型化。

        ⑤通过注解、约束给出用况的非功能需求。

 

用例建模和数据流图的关联？

    用例建模和数据流图的关联，数据流图中我们需要根据各部分操作的相近程度，对系统进行模块划分。用例图中需要分解用况，提取公共行为，形成泛化结构。在原理上，这方面式相互关联的。

 

 

                  ②状态图：当对象的行为比较复杂时可用状态图作为辅助模型描述对象的状态及其状态转移，从而更准确地定义对象的操作。

                  ③活动图：注重从活动到活动的控制流，可用来描述对象的操作流程，也可以描述一组对象之间的协作行为或用户的业务流程

                  ④顺序图：注重于消息的时间次序。可用来表示一组对象之间的交互情况

                  ⑤通信图：注重于收发消息的对象的组织结构。可用来表示一组对象之间的交互情况。

                  ⑥交互概观图：用于描述系统的宏观行为，是活动图和顺序图的混合物

                  ⑦定时图：用于表示交互，它展现了消息跨越不同对象成角色的实际时间，而不仅仅关心消息的相对顺序

 

 

5.13UML总结

         ①对“自顶向下”的建模人员来讲：

                  ——提供了跨越问题空间到目前“运行平台”之间丰富的建模元素。基于给定的术语，可确定不同抽象层次，支持“概念模型”和“软件建模”。

 

         ②对“自底向上”的设计思想交流来讲：

                  ——提供了表达系统结构模型和行为模型的图形化工具。

 

5.14系统行为（交互）的建模工具-顺序图

         定义：顺序图是一种交互图，即由一组对象以及这些对象之间的关系（通信）组成，其中还包含这些对象之间被发送的消息。

                  顺序图所包含的内容：

                          ①交互各方：角色或对象

                          ②交互方式：同步或异步

                          ③交互内容：消息

 

5.15系统行为（生命周期）的建模工具-状态图

         定义：状态图是显示一个状态机的图，其中强调了从一个状态到另一个状态的控制流。

         状态分类：初态、终态和正常态。

 

6面向对象分析

6.1识别类、属性和操作

         1、研究问题域和用户的需求

                  （1）研究用户需求、明确系统责任

                          阅读、交流、调查、记录和整理

 

                  （2）研究问题域

                          亲临现场调查，掌握第一手的资料

                          听取问题域专家的见解

                          阅读与问题域有关的材料

                          借鉴相同或类似问题域已有的系统开发经验及文档

 

                  （3）确定系统边界

         2、策略与启发

                  （1）考虑问题域

                          人员

                          组织

                          物品

                          设备

                          抽象事物

                          事件

                          文件

                          结构

                  （2）考略系统边界

                          人员

                          设备

                          外系统

                  （3）审查与筛选

 

 

6.2识别属性

(1)策略与启发

按常识这个对象应该有哪些属性?(例如人的姓名、职业、地址等)

 

*在当前的问题域中，对象应该有哪些属性?(例如商品的条形码

 

*根据系统责任，这个对象应具有哪些属性?(持卡人的使用地点)

 

*建立这个对象是为了保存和管理哪些信息?

 

*对象为了实现操作的功能，需要增设哪些属性?

 

*对象是否需要一个专设的属性描述其状态？

 

*用什么属性表示聚合和关联?

 

 

6.3识别操作

         区别对象行为的类型

                  （1）系统行为

                          例：创建、删除、复制、转存

                  （2）对象自身的行为——算法简单的操作

                          例：读、写属性

                  （3）对象自身的行为——算法复杂的操作计算或监控

 

 

6.4识别对象之间的关系

 

         1、识别继承（泛化）关系的策略

                  （1）学习当前领域的分类学知识

                  （2）按常识考虑事务的分类

                  （3）使用继承的定义

                          使用两种思路去发现继承关系:
                                   (a)一种思路是把每个类看作是一个对象集合，分析这些集合之间的包含关系，如果一个类是另一个类的子集(例如“职员”是“人员＂的子集，“轿车”是“汽车＂的子集)，则它们应组织到同一个一般-特殊关系中。

                                   (b)看一个类是不是具有另一个类的全部特征，这又包括以下两种情况

                                            ・一种是建立这些类时己经计划让某个类继承另一个类的全部属性与操作，现在应建立继承关系来落实

                   ・另一种是起初只是孤立地建立每个类，现在发现一个类中定义的属性与操作全部在另一个类中重新出现，此时应考虑建立继承关系，把后者作为前者的特殊类，以简化其定义。

 

                  （4）考察属性与操作的适用范围

                          对系统中的每个类，从以下两个方面考略它们的属性与操作

                                   ・看一个类的属性与操作是否适合这个类的全部对象。

                ・检查是否有两个（或更多）的类包含有一些共同的属性与操作。

 

 

6.5识别关联

         一、识别关联策略

                  （1）识别对象之间的静态联系

 

                  （2）识别关联的属性与操作

 

                  （3）分析并表示关联的多重性

 

                  （4）进一步分析关联的性质

 

         二、命名与定位命名

                  关联可用动词或动宾结构

 

 

6.6识别聚合

 

         1、识别聚合的策略

                  (1)物理上的整体事物和它的组成部分

                          例:机器、设备和它的零部件

                  (2)组织机构和的下级组织及部门

                          例:公司与子公司、部门

                  (3)团体(组织)与成员

                          例:公司与职员

                  (4)一种事物在空间上包容其它事物
                          例:生产车间与机器

                  (5)抽象事物的整体与部分

                          例:学科与分支学科、法律与法律条款

                  (6)具体事物和它的某个抽象方面

                          例:人员与身份、履历

                  (7)在材料上的组成关系

                          例如，面包由面粉、糖和酵母组成，汽车是由钢、塑料和玻璃组成。

 

 

         2、审查与筛选

                  (1)是否属于问题域?

                          例:公司职员与家庭

                  (2)是不是系统责任的需要?

                          例:公司与工会

                  (3)部分对象是否有一个以上的属性?

                          例:汽车与轮胎(规格)

                  (4)是否有明显的整体部分关系?

                          例:学生与课程

 

 

6.7识别依赖

         依赖是一种使用关系，用于描述一个事务（如Window）使用另一个事物（如类Event）的信息和服务。

 

6.8面向对象分析（Object-Oriented Analysis，OOA）

         1、OOA的基本任务

                  运用面向对象方法，对问题域(被开发系统的应用领域)和系统责任(所开发系统应具备的职能)进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，找出描述问题域和系统责任所需的类和对象，定义这些类和对象的属性和操作，以及它们之间所形成的各种关系。最终目的是产生一个符合用户需求，并能够直接反映问题域和系统责任的OOA模型及其规约。

 

         2、OOA模型

                  对象层：给出所有问题域和系统责任有关的对象，用类表示

 

                  特征层：定义每个类的属性和操作

 

                  关系层：描述对象之间的关系

 

         3、OOA过程

                 

 

 

 

7面向对象设计

 

面向对象设计（OOD）

         定义：面向对象设计（OOD）就是在OOA模型的基础上运用面向对象方法进行系统设计，目标是

产生一个符合具体实现条件的OOD模型。

 

OOD过程：

         逐个设计OOD模型的四个部分

                  问题域部分的设计

                  人机交互部分的设计

                  数据驱动部分的设计

                  数据接口部分的设计

 

 

第一部分：问题域部分的设计

 

如何进行问题域部分的设计？

         1、继续运用OOA的方法——概念、表示法及策略

         2、使用OOA结果，并加以修改——需求的变化，新发现的错误

         *3、使用OOA结果，并进行补充与调整

                  （1）为复用设计与编程的类而增加结构

                  （2）增加一般类以建立共同协议

                  （3）按编程语言调整继承

                  （4）提高性能

                  （5）为实现对象永久存储所做的修改

                  （6）为编程方便增加底层细节

 

 

为什么需要问题域部分的设计？

         ①在OOA阶段只考虑问题域和系统的责任，OOD则要考虑与具体实现有关的问题，需要对OOA结果的补充与调整。

         ②使反映问题域本质的总体框架和组织结构长期稳定，而细节可变。

 

 

第二部分 人机交互部分的设计

 

一、人么是人机交互部分？

         系统中负责人机交互部分（由一些对象类构成），突出人如何命令系统以及系统如何向用户提交信息。

 

二、为什么需要人机交互部分呢？

         为了隔离GUI的变化对问题域部分的影响。

 

三、人机交互部分的需求分析

         1、分析与系统交互的人——人员活动者

         2、从use case分析人机交互

                  （1）从use case抽取人交互内容及过程

                  （2）人机交互细化

         3、命令的组织

四、人机界面的设计准则

         使用简单

         一致性

         启发性

         减少人脑记忆的负担

         减少重复性的输入

         容错性

         及时反馈

         防止灾难性的错误

 

 

 

 

8面向对象编程

一、程序设计范型（Programming Paradigm）

关于计算机系统的思考方法。体现了一类语言的主要特点。（蔡希尧）

在面向对象编程中，程序员认为程序是一系列相互作用的对象，而在函数式编程中一个程序会被看作是一个无状态的函数计算序列。（维基百科）

 

面向过程设计范型：

中心思想——程序设计主要是过程设计

决定所需的过程，设计过程的算法

关键:过程调用

 

模块化程序设计范型：

基本思想——信息隐蔽，需求与求解方法分离，相关的数据结构与算法结合在一个模块中，与其它模块隔离，使其它模块不能随便访问——有了封装的思想

例如: Modula-2

 

其它程序设计范型：

结构化程序设计，函数式程序设计，逻辑程序设计等

 

面向对象是一种新的程序设计范型——是在上述范型基础上发展起来的增加了类和继承，用类创建对象实例

 

思想方法：

从客观存在的事物出发构造软件系统

运用人类日常思维方式

 

主要特点：

使用对象、类、继承、封装、聚合、关联、消息、多态性等基本概念来进行程序设计。

 

二、面向对象的编程语言（OOPL）

1、基本特性

语言元素能够支持——

类的定义

对象的静态声明或动态创建

属性和操作的定义

继承、聚合、关联和消息的表示

 

语言机制类机制——

封装机制

继承机制

 

高级特性：

多态、多继承的表示和支持机制

 

2.发展历史及语言谱系

3.类别

 

纯面向对象语言

例如: Smalltalk、 Eiffel

较全面地支持O0概念

强调严格的封装

 

混合型面向对象语言

例如:C++、 Objective-c、 Object Pascal

在一种非OO语育基础上护充00成分

对封装采取灵活策略

 

结合人工智能的面向对象语言

例如: Flavors、 LOOPS、Clos

 

4、语言+类库+编程环境

 

 

三、为实现00模型选择编程语言

在OOD完成之后，选择什么编程语言实现OOD模型?

1、一般原则

*基本原则——语言的选择完全从实际出发

         主要考虑成本、进度、效率等实际因素

 

*OOPL是实现OOD的理想语言

         它使源程序能很好的对应OOD模型

 

*带有类库、编程环境、权限管理的OOPL更好。

 

*用非OO语言也能实现OOD模型缺乏O0机制的保证和支持，
         但若自觉遵循一定的原则，可以保持某些OO风格。

 

2、编程语言的评价标准

(1)能否描述类和对象

         是否提供封装机制?对封装有无可见性控制?

 

(2)能否实现一般-特殊结构

         支持多继承、单继承还是不支持继承?

         支持多继承时，是否能解决命名冲突?

         是否支持多态?

 

(3)如何实现整体-部分结构

         用什么实现?如何表示多重性?

 

(4)如何实现属性和操作

         用什么表示属性?

         用什么描述操作?

         有无可见性控制?

         能否描述约束?

         是否支持动态绑定（Dynamic Binding）？

 

(5)如何实现关联和消息通讯

         用什么实现关联?如何表示多重性?如何实现消息通讯?

 

(6)其它可考虑的因素(反映于具体的语言版本)

         是否带有可视化编程环境是否带有类库

         能否支持对象的永久存储

 

注释:

绑定:一个对象(或事物)与其某种属性建立某种联系的过程。如:一个变量与其类型或值建立联系，一个进程与一个处理器建立联系等。——《计算机科学技术百科全书(第二版)》

 

在计算机语言中有两种主要的绑定方式：

静态绑定发生于数据结构和数据结构间，程序执行之前。静态绑定发生于编译期，因此不能利用任何运行期的信息。它针对函数调用与函数的主体，或变量与内存中的区块。

 

动态绑定则针对运行期产生的访问请求，只用到运行期的可用信息。在面向对象的代码中，动态绑定意味着决定哪个方法被调用或哪个属性被访问，将基于这个类本身而不基于访问范围。

 

 

四、几种典型的面向对象的编程语言的简介

1、C++

①是C语言的超集

②是一种混合型的OOPL，保持C语言的高效率、可移植，与C兼容使广大程序员容易接受

③采用强类机制

④支持动态绑定

⑤是目前使用最广的OOPL

 

（1）类和对象

类Class            对象Object

对象的创建和删除：

         创建：构造函数——类名（），（C++规定，每个类必须有默认的构造函数，没有构造函数就不能创建对象）

         删除：析构函数——~类名（），（析构函数的定义：析构函数也是特殊的类成员函数，它没有返回类型，没有参数，不能随意调用，没有重载，只有在类对象的生命期结束的时候，由系统自动调用。）

 

静态对象（从程序开始执行到退出）

         创建：类名    对象名

         删除：程序退出时

 

动态对象（显示地创建和删除）

         创建：对象指针 = new类名（参数）

         删除：delete 对象指针

 

（2）一般一特殊结构

基类-派生类(Base- derived class)

         支持单继承和多继承

         用命名空间( namespace)解决命名冲突

         支持多态和重载

         在继承的同时可定义被继承内容的可见性

 

（3）整体-部分结构(聚合)

         用指针或嵌套对象( nested object)实现聚合，用指针数组或指针链表等实现多重性。

 

2、Java

 

Java不使用指针，解释执行

 

Java对分布式和客户/服务器结构的支持，提供了丰富的类库和方便有效的开发环境，并提供了语言级的多线程、同步原语和并发控制机制。

 

(1)类和对象

定义类的关键字:Class
封装机制:有

对象的创建和删除构造函数:类名()

终止函数: finalize()

对象的静态声明和动态创建类似于C++

 

(2)属性和操作

属性:实例变量、类变量

可见性: private、 protected、 public和 friendly

操作:实例方法、类方法

可见性:同属性

 

(3)继承

超类/子类支持重载和多态

 

(4)关联、聚合

可用对象引用实现关联或聚合

 

五、用非OO编程语言事先OOD模型

1过程语言一一以C为例

(1)类，对象→无可以用结构定义对象，可通过指针说明应该有哪些函数(不封装)

(2)一般-特殊→无

         可把一般结构嵌入特殊结构

(3)整体一部分→指针、嵌套的结构

(4)属性与操作→变量、函数

(5)关联→指针;消息→函数调用

 

 

 

9敏捷开发方法

敏捷开发概述

一、概念

敏捷软件开发，又称敏捷开发，是一种应对快速变化的需求的一种软件开发能力。

 

敏捷软件工程是 推崇“让客户满意和软件的早期增量发布，小而高度自主的项目团队，非正式的方法，最小化软件工程产品以及整体精简开发”的哲学理念和一系列开发指南的综合。

 

二、敏捷（Agile）联盟

         一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则。

敏捷联盟宣言：

         个体和交互             胜过                 过程和工具

         可以工作的软件            胜过                 面面俱到的文档

         客户合作                 胜过                 合同谈判

         响应变化                 胜过                 遵循计划

三、敏捷原则

———这是敏捷实践区别于重过程的特征所在

1)最优先要做的是：通过尽早地、持续地交付有价值的软件来使客户满意。——获取有质量软件的理念

 

2)即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。——关于态度的声明

 

3)经常交付可工作的软件，其时间间隔可以是几周到几个月。交付的时间间隔越短越好。——项目规划的理念（涉及如何处理文档和软件项目开发之间的关系）

 

4)在整个项目开发期间，业务人员和开发人员必须天天在一起工作。——团队组成和精神问题

 

5）不断激励开发人员，开展项目的有关工作。给他们提供所需要的环境和支持，并信任他们能够完成所承担的工作。——“领导”的含义-涉及管理功能

 

6)在团队内部，最有效果的、最有效率的传递信息的方法，就是面对面的交谈。——获取开发信息(需求、技术信息和项目信息等)的途径

 

7)首要的进度度量标准是工作的软件。——进度度量的理念

 

8)敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。——项目“持续发展”的能力

 

9)不断关注优秀的技能和设计，增强敏捷能力。——提高敏捷能力的一种途径

 

10)简单是根本的。——使未完成的工作最小化的艺术

 

11)最好的体系结构、需求和设计，出自自己组织的团队。——团队观念————一种软件项目管理的理念。

 

12)每隔一段时间，团队对如何才能有效的工作进行反省，然后对自己的行为进行适当的调整。自我调整和适应。

 

注:以上12条是敏捷开发的实践原则。实践的语义比过程更宽泛，包扩活动以及与活动相关的人和基础设施。

 

四、极限编程

         极限编程（eXtreme Programming，简称XP），是敏捷方法中最显著的一个。它由一系列简单却相互依赖的实践组成。

1、极限编程包含的实践

（1）客户作为团队的成员

         含义：客户与开发人员一起紧密的工作，相互了解所面临的问题，并共同解决之。

（2）“用户素材”（user stories）

         含义：为了了解与项目需求有关的内容，采用“用户素材”（user stories）——需求谈话时的助记工具。

（3）短的交付周期

         含义：每隔两周，就交付一次可工作的软件。

（4）验收测试

         作用：通过验收测试，捕获用户素材的有关细节。

         编写时间：要在实现该用户素材之前或实现该用户素材期间进行编写。

         编写工具：编写验收测试，使用能够让它们自动、反复运行的某种脚本语言。

（5）结对编程

         含义：共同设计、共同编写、功劳均等，以促进知识在全队的传播。

（6）测试驱动的开发

         含义：首先对产品的某一功能编写一个单元测试。由于该功能还不存在，因此它一定会运行失败。然后编写这一功能的代码，使该测试得以通过。

益处:为了测试用例通过而编写代码，这样的代码称为可测试的代码。优点是:由于要独立对它进行测试，因此可激励解除模块之间的耦合，使模块之间具有低的耦合

（7）集体所有权

（8）持续集成

 

2、极限编程过程

 

五、敏捷设计

1、问题提出

         为了应对需求变化，设计应尽力避免以下问题：

         （1）僵化性：难以对软件设计进行改动。

         （2）脆弱性：进行一个改动时，程序的许多地方就可能出现问题。

         （3）粘固性：一部分的设计中包含了对其他部分有用的成分。设计难以复用。

         （4）粘滞性：

                  ①软件粘滞性：

                  ②环境粘滞性：

         （5）不必要的复杂性：设计中包含了当前没有用的成分

         （6）不必要的复制：滥用“剪切”和“粘贴”等鼠标动作。

         （7）晦涩性：模块难于理解。

 

 

2、防止软件腐化的基本途径

         简言之，以变应变，尽力避免出现以上设计问题。进一步说

(1)团队几乎不进行预先(up- front)设计，因此不需要一个成熟的初始设计

 

(2)团队通过多次使用单元测试和验收测试，支持系统的设计尽可能的干净、简单，使设计保持灵活性和易于理解性

(3)灵活、持续地改进设计，以便使每次迭代结束时所生成的系统具有满足那次迭代需求的设计。

 

3、采用敏捷设计的方法

包括：

         使用一些设计原则，以保持软件是灵活的、可维护的

         掌握一些设计模式（MVC模式），以便针特定问题权衡这些原则。

 

3、采用敏捷设计的方法

敏捷设计是一个应用原则、模式和实践的过程，其间不断改普软件结构，保持系統设计在任何时间都尽可能的简单、千净(主要是指边界清楚，结构良好)和富有表现力，即：

         它的功能        对于用户来说，通过直观、简单的界面呈现出恰当特征的程序。

         它的内部结构        对于软件设计者来说，通过简单、直观的划分，使其具有最小耦合的内部结构。

         创造过程        对于开发人员来说，每周都会取得一些重大进展，并生产出无缺陷代码的具有活力的团队过程。

 

六、一种敏捷过程模型——Scrum

         Scrum有三个阶段：

                  规划纲要阶段：建立大致的项目目标和设计软件体系结构

                  一系列的冲刺循环，每个循环开发出一个系统增量

                  项目结束阶段总结项目，完善需要的文档，如系统帮助用户手册并总结从项目中获得的经验。

 

 

 

 

10软件测试

10.1件测试的定义和目标

         软件测试：检测和评价软件以确定其质量的过程和方法，即评价软件或程序的属性和能力，以确定它是否满足所需结果的过程与方法。

 

软件测试可分为静态分析和动态测试

 

静态分析：只是检查和审阅

动态测试：运行和使用软件

 

软件测试目标：

(1)预防错误

(2)发现错误

 

10.2软件测试与软件调试的区别

         软件调试：发现所编写软件中的错误，确定错误的位置并加以排除，使之能由计算机或相关软件正确理解与执行的方法与过程。

 

软件测试和软件调试的主要区别：

(1)测试从一个侧面证明程序员的“失败”，而调试是为了证明程序员的正确。

 

(2)测试以已知条件开始，使用预先定义的程序，且有预知的结果，不可预见的仅是程序是否通过测试。调试一般是以不可知的内部条件开始，除统计性调试外，结果是不可预见的。

 

(3)测试是有计划的，并要进行测试设计；而调试是不受时间约束的推理过程。

 

（4）测试是一个发现错误、改正错误、重新测试的过程。而调试是一个推理过程。

 

(5)测试的执行是有规律的，而调试的执行往往要求程序员进行必要推理以至知觉的“飞跃”。

 

(6)测试经常是由独立的测试组在不了解软件设计的条件下完成的；而调试必须由了解详细设计的程序员完成。

 

(7)大多数测试的执行和设计可由工具支持，而调试时，程序员能利用的工具主要是调试器。

 

 

10.3软件测试技术

         白盒测试：

                  白盒测试也称结构测试或逻辑驱动测试，它是知道产品的内部工作过程，可通过测试来监测产品内部动作是否按照规格说明书的规定正常进行。

                  白盒测试有：逻辑覆盖、基本路径测试

 

                  路径测试：执行所有可能的穿过程序控制流程路径。

 

                  语句测试：至少执行程序中所有语句一次。如果遵循这一规定，则我们说达到了100%语句覆盖率。

                          语句覆盖是最弱的逻辑覆盖准则。

                          发现不了判断中逻辑运算符出现的错误。

 

                  分支测试：至少执行程序中每一分支一次。如果遵循这一规定，则我们说达到了100%的分支覆盖率。

                  分支覆盖还不能保证一定能查出在判断的条件中存在的错误。

 

                  条件组合测试：设计足够的测试用例，使每个判定中所有可能的条件取值组合至少执行一次。如果遵循这一规定，则我们说就实现了条件组合覆盖。

 

 

         黑盒测试:

                  黑盒测试，也称功能测试或数据驱动测试，已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。

 

 

                  黑盒测试主要方法：等价类划分、边界值分析、因果图、错误推测等。

 

 

10.4软件测试过程模型

         简化注重程序的控制结构——形成“白盒”测试

         简化注重程序的处理结构———形成“黑盒”测试

 

10.5软件设计的原则

         （1）所有测试都应当追溯到用户需求。

         （2）在测试工作开始前，要进行测试计划的设计。

         （3）穷举测试是不可能的。

         （4）为了尽可能发现错误，应由独立的第三方来测试（有商机）。

         （5）测试应从小规模开始，逐步转向大规模。

         （6）测试只能保证尽可能多地发现错误，无法保证能够发现所有错误。

 

10.6软件测试步骤

         （1）单元测试

         （2）集成测试

         （3）确认测试（有效性测试）

         （4）系统测试

 

 

11软件项目管理

第一章 软件项目管理概述

1、项目管理

         1.1项目的定义和特性

                  项目：为创造一件独特的产品、一项服务或者一种结果而进行的临时性努力。

 

                  项目特性：

                           项目有一个独特的目的。

                           项目是临时性的。

                           项目需要随着发展而逐步进行细化

                           项目需要各种各样来自不同领域的资源

                           项目应该有一位主要客户或项目发起人

                           项目包含不确定性

 

         1.2项目管理发展史

                  项目管理是在项目活动中运用知识、技能、工具和技术，以满足项目的需要。

 

         1.3项目管理发展的重要产物

 

         1.4项目管理的定义

                  项目管理是指“在项目活动中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人的需要和期望。”

 

         1.5项目管理的要素

                  一个项目成功与否，能否抓住项目管理的要素是关键。项目管理的要素包括项目的范围、进度、成本和质量。

 

                           范围：在项目管理中也成为工作范围，是指为了完成项目目标必须完成的所有工作。

 

                           进度：不仅说明了完成项目工作范围内所有工作需要的时间，也规定了每个活动具体开始时间和结束时间。

 

                           成本：完成项目需要的所有资金，包括人力资源成本、原材料成本、设备租金、分包费用和咨询费用等。

 

                           质量：指项目满足明确或隐含需求的程度，一般通过定义工作范围中的可交付物的标准来明确定义。

 

                  项目的目标就是按照指定的成本和进度交付具有一定质量的指定范围的产品。

 

         1.6项目的生命周期

                  概念→发展→实现→收尾

 

2、软件项目管理

         2.1软件项目管理的定义

                  软件项目管理是为了软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。

 

                  软件项目管理的对象是软件工项目，它所涉及的范围覆盖了整个软件工程过程。为了使项目能够按照预定成本、进度、质量顺利完成，需要对软件项目的工作范围、可能遇到的风险、需要的资源(人力、物力)、要实现的任务、经历的里程碑、花费的工作量(成本)、进度的安排、质量的标准等进行分析和管理。

 

CMM和ISO900

●软件的质量取决于用来开发和改进它的过程的质量。——说明了产品和过程的关系

 

●如果你迷路了，那么即使你有一张地图也是没有用的。——说明要进行过程改进，必须对现有的过程有所了解，特别是存在的问题有客观的认识

 

●软件过程改进并不是目的地，它只是一个旅程。——说明过程改进是一个持续的过程

 

CMM (the Capability Maturity Model for software)，软件能力成熟度模型

 

过程是生产产品的机制。不论是过程改善还是能力确定，均需要过程评估，而过程评估通常基于已提出的一些评估模型。

 

 

第十章    软件开发工具与环境

1、计算机辅助软件工程CASE（Computer-Aided Software Engineering）

 

CASE是一组工具和方法的集合。是辅助软件开发的任何计算机技术，其含义为：

                  在软件开发/维护中，提供计算机辅助支持

                  在软件开发/维护中，引入工程化的方法

2、CASE工具

         狭义地说，是一类特殊的软件工具，用于辅助开发分析、测试、维护另一种计算机程序/文档

         广义地说，是除了OS之外的所有软件工具的总称。