02 软件开发方法

Posted on Wed, 25 Dec 2024 16:55:08 +0800 by LiangMingJian

1.结构化开发方法 #

1.1 结构化分析 #

• 结构化分析（SA）是指20世纪70年代末，由 Demarco 等人提出的，面向数据流进行需求分析的方法，旨在减少分析活动中的错误，建立满足用户需求的系统逻辑模型。
• 结构化分析的要点是：根据软件内部数据传递、变换的关系，采用自顶向下，逐层分解的方法，经过一系列分解和抽象，建立系统的逻辑模型，将软件系统抽象为一系列的逻辑加工单元，各单元之间以数据流发生关联。
• 结构化分析是软件工程中最早出现的开发方法，特别适合于数据处理领域的问题，但是不适合解决大规模的、特别复杂的项目，且难以适应需求的变化。
• 结构化分析的输出包括数据流图，数据字典以及对应的加工逻辑。

1.2 结构化设计 #

1.3 结构化方法 #

• 结构化方法的指导思想是：自顶向下、逐层分解，它的基本原则是功能的分解与抽象。
• 使用数据流图来描述系统由哪几部分组成，各部分之间有什么联系。
• 使用数据字典来定义各种数据，说明数据流图中每一个图形元素。
• 使用加工规格说明（结构化语言、判定表、判定树）来描述算法逻辑，说明数据流图中不能被再分解的每一个加工。

1.4 结构化建模 #

• 数据流图（DFD）：功能建模，其要素包括加工，数据流，是需求分析阶段的结果，是接口设计的依据。
• 实体联系图（E-R）：数据建模，其要素包括实体类型，属性和联系的方法，是描述现实世界的概念模型。
• 状态-迁移图（STD）：行为建模，其要素包括状态，改变状态的事件，用来描述系统的行为。

1.5 结构化开发工具 #

1.5.1 数据字典 #

• 数据字典是一个存放有数据库所用的有关信息，在数据库设计的初期将数据库中的各类数据的描述集合在一起，用于在开发，维护或者其他需要的时候使用，可以类比成我们现实中的字典。
• 数据字典通常包括：数据项，数据结构，数据流，数据存储，基本加工。
• 数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义来描述数据流和数据存储的逻辑内容。

1.5.2 数据流图 #

• 数据流图（Data Flow Diagram），简称 DFD，它从数据传递和加工角度，以图形方式来表达数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
• 数据流图反映了系统必须完成的逻辑功能，用于功能建模，同时也是接口设计的依据。
• 数据流图具有抽象性，概括性的特征。
• 数据流图的平衡是指：
  • 父图和子图的输入，输出数据流的一致性。
• 数据流图的四要素是指：
  • 外部实体：方框表示，指系统之外与系统有联系的人或事物，表示该系统数据的外部来源和去处。
  • 数据加工：椭圆表示，描述输入数据流到输出数据之间的变换，也就是输入数据流经过什么处理后变成了输出数据。可以使用结构化语言，判定表和判定树来进行描述。
  • 数据存储：使用一组平行线表示，某种数据保存后的逻辑统称，不是指保存数据的物理地点和物理介质。每个数据存储都有一个名字。
  • 数据流：使用带箭头的曲线表示，处理功能的输入 / 输出，箭头表示数据流向。
• 数据流图的层次包括：
  • 顶层图（第0层）只有代表整个软件系统的1个加工，描述了软件系统与外界之间的数据流。
  • 顶层图中的加工经分解后的图称为第1层图(只有1张)。
  • 中间层图中至少有一个加工(也可以有多个)在下层图中分解成一张子图。
  • 处于最底层的图称为底层图，其中所有的加工不再分解成新的子图。
• 数据流图的注意事项包括：
  • 自外向内，自顶向下，逐层细化，完善求精。
  • 必须保持父图与子图的平衡。
  • 隐藏加工细节，简化加工间的关系。
  • 适当取名，避免空洞的名字。
  • 表现的是数据流而不是控制流。
  • 每个加工必须既有输入数据流，又有输出数据流，保持数据守恒。

1.5.3 决策树 #

• 决策树适用于描述存在多个分支判断的系统。
• 决策树每个内部节点表示一个属性上的测试，每个分支代表一个测试输出，每个叶节点代表一种类别。
• 通过构成决策树来求取净现值的期望值大于等于零的概率，评价项目风险，判断其可行性的决策分析方法，是直观运用概率分析的一种图解法。

1.5.4 用例图 #

• 用例图是编写需求说明时经常用到的需求表达方式，用于向开发、测试同事说明需求中用户与系统功能单元之间的关系。
• 用例图包括参与者，用例，关系三个要素。
• 参与者：不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
• 用例：是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
• 关系：参与者与用例之间的关系主要包括关联、归纳（泛化）、包含、拓展和依赖。

1.5.5 实体联系图（E-R图） #

• 实体联系图是一种提供了实体，属性和联系的方法，用来描述现实世界的概念模型，表示在信息系统中概念模型的数据存储。
• 实体联系图常用于系统设计中的数据建模，用来表示实体与实体间的联系，不表现软件模块的执行过程。

1.5.6 N-S 盒图 #

• 描写软件模块执行过程的一类图。
• 具备展示顺序结构，选择结构和循环结构的能力。

1.5.7 PAD 图 #

• 问题分析图。
• 描写软件模块执行过程的一类图，一种表示程序控制流的结构图。
• 具备展示顺序结构，选择结构和循环结构的能力。

2.面向对象开发方法 #

2.1 概念 #

• 面向对象开发方法分为面向对象的分析（OOA），面向对象的设计（OOD）和面向对象的程序设计（OOP）。
• OOA 是利用抽象构造问题的对象模型。
• OOD 是设计对象和对象之间的关系，如层次和集成；对象之间的通信方式，例如消息。
• OOP 指对系统功能的编码。

2.2 面向对象的分析 #

2.2.1 基于 UML 的面向对象的分析 #

• 面向对象分析一般在软件需求工程中完成，主要形成以下三种类：
  • 边界类：对外部系统环境和内部交互进行建模。
  • 控制类：对控制行为进行建模，多用来实现业务逻辑。
  • 实体类：存储信息和对相关行为进行建模。
• 面向对象分析使用 UML 类图进行结果展示。

2.2.2 UML 的定义 #

• 统一建模语言(Unified Modeling Language，UML)是一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言，是非专利的第三代建模和规约语言。
• UML 是面向对象设计的建模工具，独立于任何具体程序设计语言。

2.2.3 UML 的分类 #

• 结构图（静态建模）包括类图，组合结构体，构件图，部署图和对象图
• 行为图（动态建模）包括活动图，顺序图，通信图，交互概况图，时序图，用例图与状态图。

2.2.4 UML 类图元素图示 #

• 一般类在类图中用矩形框表示，矩形框分为三层：第一层是类名字；第二层是类的成员变量；第三层是类的方法。成员变量以及方法前的访问修饰符用符号来表示：+ 表示 public；- 表示 private；# 表示 protected；不带符号表示 default。

• 抽象类在UML类图中同样用矩形框表示，但是抽象类的类名以及抽象方法的名字都用斜体字表示。

• 接口在类图中也是用矩形框表示，但是与类的表示法不同的是，接口在类图中的第一层顶端用构造型 <<interface>>表示，下面是接口的名字，第二层是方法。此外，接口还有另一种表示法，俗称棒棒糖表示法，就是类上面的一根棒棒糖（圆圈+实线）。圆圈旁为接口名称，接口方法在实现类中出现。

• 包在类图中也是用矩形框表示，但包里面会包含类和接口。

2.2.5 UML 类图关系图示 #

• 实现关系是指接口及其实现类之间的关系。在UML类图中，实现关系用空心三角和虚线组成的箭头来表示，从实现类指向接口。

• 泛化关系（Generalization）是指对象与对象之间的继承关系。如果对象A和对象B之间存在继承关系，对象B是父对象，对象A是子对象。在UML类图中，泛化关系用空心三角和实线组成的箭头表示，从子类指向父类。

• 关联关系（Association）是指对象和对象之间的连接，它使一个对象知道另一个对象的属性和方法。在代码中，关联关系表现为一个对象含有另一个对象的引用。也就是说，如果一个对象的类代码中，包含有另一个对象的引用，那么这两个对象之间就是关联关系。关联关系有单向关联和双向关联。如果两个对象都知道（即可以调用）对方的公共属性和操作，那么二者就是双向关联。如果只有一个对象知道（即可以调用）另一个对象的公共属性和操作，那么就是单向关联。大多数关联都是单向关联，单向关联关系更容易建立和维护，有助于寻找可重用的类。在UML图中，双向关联关系用带双箭头的实线或者无箭头的实线双线表示。单向关联用一个带箭头的实线表示，箭头指向被关联的对象。

• 依赖（Dependency）关系是一种弱关联关系。如果对象A用到对象B，但是和B的关系不是太明显的时候，就可以把这种关系看作是依赖关系。。比如驾驶员和汽车的关系，驾驶员使用汽车，二者之间就是依赖关系。在UML类图中，依赖关系用一个带虚线的箭头表示，由使用方指向被使用方，表示使用方对象持有被使用方对象的引用。当使用方发生变化时，会影响被使用方的含义。

• 聚合（Aggregation）是关联关系的一种特例，它体现的是整体与部分的拥有关系，即 has a 的关系。此时整体与部分之间是可分离的，它们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享，所以聚合关系也常称为共享关系。例如，公司部门与员工的关系，一个员工可以属于多个部门，一个部门撤消了，员工可以转到其它部门。在UML图中，聚合关系用空心菱形加实线箭头表示，空心菱形在整体一方，箭头指向部分一方。

• 组合（Composition）也是关联关系的一种特例，它同样体现整体与部分间的包含关系，即 contains a 的关系。但此时整体与部分是不可分的，部分也不能给其它整体共享，作为整体的对象负责部分的对象的生命周期。这种关系比聚合更强，也称为强聚合。如果A组合B，则A需要知道B的生存周期，即可能A负责生成或者释放B，或者A通过某种途径知道B的生成和释放。例如，人包含头、躯干、四肢，它们的生命周期一致。当人出生时，头、躯干、四肢同时诞生。当人死亡时，作为人体组成部分的头、躯干、四肢同时死亡。在UML图中，组合关系用实心菱形加实线箭头表示，实心菱形在整体一方，箭头指向部分一方。

2.2.6 UML 类图的基本关系 #

• 实现：类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。
• 依赖：两个事物间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
• 继承：一种特殊/一般关系，特殊元素对象可替代一般元素对象。
• 关联：一种结构关系，描述一组链，链是对象间的联系。
• 聚合：一种特殊的类型关联，是整体和部分的拥有关系。
• 组合：一种特殊的类型关联，是整体和部分的包含关系。

2.2.7 UML 类图的应用场景 #

• 对系统的词汇建模。
• 对简单的协作建模。
• 对逻辑数据库模式建模。

2.3 面向对象设计 #

• 面向对象设计是面向对象方法在软件设计阶段应用与扩展的结果。
• 面向对象设计要求将面向对象分析所创建的分析模型转换为设计模型，解决如何作的问题。
• 面向对象设计的原则包括：
  • 开闭原则：软件实体应该对扩展开放，对修改关闭，即尽量在不修改原有代码的情况扩展实体的功能。
  • 里氏替换原则：如果使用基类对象满足要求，那么使用子类一定也可以。
  • 依赖导致原则：抽象不应该依赖于细节，细节应该依赖于抽象，对接口编程，而不是对实现编程，当程序代码在中传递参数时，或者在使用组合或者聚合关系是，尽量使用层次更高的抽象。
  • 组合/聚合复用原则：尽量使用组合和聚合的关系来使用一些原有的对象，使之成为新对象的一部分。
  • 接口隔离原则：使用多个专门的接口，而不是单一的总接口。
  • 最少知识原则（迪米特法则）：软件尽可能的减少和其他实体的相互作用。
• 几种典型的面向对象的开发方法：Coda 方法，Booch 方法和 OMT 方法。