软件工程
发表于:2024-06-24 |
字数统计: 3.6k | 阅读时长: 12分钟 | 阅读量:

软件工程(28-A7218-13:00)

第一章、软件工程概述

软件工程的定义

软件工程是采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理方法和最先进的软件开发技术结合起来,应用到软件开发和维护的过程中,来解决软件危机问题。

软件危机

软件危机(计算机软件的开发和维护中遇到的严重问题)的表现形式:

  1. 软件成本高

  2. 开发进度难以控制

  3. 工作量估计困难

  4. 软件产品的质量差

  5. 软件进行修改、维护困难

软件工程三要素:

工具、方法、过程。

软件生命周期:

  1. 软件定义
    1.问题定义
    2.可行性分析
    3.需求分析

  2. 软件开发
    1.软件设计
    2.程序编码
    3.软件测试

  3. 运行与维护

常用的开发过程模型

  1. 瀑布模型(自顶向下结构化)阶段:问题定义、需求分析、软件设计、编码、测试、运行和维护。

    • 优点:1.支持开发结构化软件、控制并降低软件开发的复杂度、促进软件开发工程化。;2.为软件开发和维护提供较为有效的管理模式。

    • 缺点:1.实际项目很少按模型给出的顺序进行。;2.不能接受在项目开始阶段的不确定性。;3.客户需要有耐心。;4.流程单一,不能适应需求变化,风险往往出现在后期。

  2. 原型(演化)模型(把主要功能接口做为设计依据)

  3. 螺旋模型(沿着螺线旋转(一个螺旋式周期)),适用于风险较大的复杂项目

  4. 统一过程模型RUP(一个通用的过程框架),使用统一建模语言来制定软件系统的所有蓝图。

    • 特点:1.软件开发是一个迭代的过程。
                 2.软件开发是由用例驱动的。
                 3.软件开发是以架构设计为中心 。

    • 阶段:初始、细化、构造、交付。

    • 核心工作流程:1.业务建模。;2.需求。;3.分析与设计。;4.实现。;5.测试。;6.部署。;7.配置与变更管理。;8.项目管理。;9.环境。

第二章、软件项目管理

项目的三维管理

  1. 时间维

  2. 知识维

  3. 保障维

项目的五个阶段

  1. 启动阶段:用户提出需求,开发人员进行需求分析,确定可行性,编写项目实施计划。

  2. 计划阶段:创建项目范围文档和项目计划,项目范围详细描述项目范围。

  3. 执行阶段:实施阶段意味着项目正在进一步设计、编码、测试,小组成员正在创造项目需要的可交付产品。

  4. 控制阶段:项目经理开始监督小组成员的工作,将项目的进度、任务和预算控制在正常的范围内。

  5. 收尾阶段:项目负责人和用户批准和签署项目,交付产品。项目的收尾阶段标志着项目的正式结束。

软件项目管理涵盖了管理软件产品开发所需的知识、技术及工具。

软件项目管理的目的

软件项目管理的目的是为了按照预定的进度、费用等要求,成功地组织与实施软件的工程化生产,完成软件(产品)的开发和维护任务。

范围包括四个方面

  • 组织管理

  • 成本管理

  • 进度管理

  • 质量管理

项目范围的管理包括

范围计划编制、范围定义、范围确认、范围控制。

风险的分类:项目风险、外来风险。

第三章、需求概述

需求的定义

用户解决问题或达到目标所需要的条件和权能;系统或系统部件要满足合同、标准、规范或其他正式规定文档所要具有的条件或权能。

需求的分类

(按性质):
  1. 功能性需求(系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述)

  2. 非功能性需求

(按层次):
  1. 领域需求

  2. 业务需求

  3. 用户需求

  4. 系统需求

软件需求工程阶段的工作划分

  1. 对问题的识别

  2. 分析与综合

  3. 制定需求规格说明

  4. 需求分析评审

获取需求的方法

  1. 建立联合分析小组

  2. 客户访谈

  3. 问卷调查

  4. 快速原型法

功能建模的方法

  1. 数据流图法

  2. 功能列表法

  3. 原型法

  4. 用例模型(面向对象功能建模,可包括用例图和用例规约)

  5. 用户故事(适用于敏捷开发)

第四章、需求建模

用例是什么

  • 用例描述了在不同条件下,系统对某一项目相关人员的请求所作出的响应,是系统中各相关人员之间就系统行为所达成的契约。

  • 根据参与者作出的请求和请求涉及的条件,系统将执行不同的行为序列,每一行为序列被称之为一个场景。

  • 一个用例是多个不同场景的集合。

用例图

用例图

用例的重要特性

  1. 一个用例是一个自包含的单元。

  2. 一个用例必须由参与者发起。

  3. 用例必须完成一个特定目标。

  4. 一个用例必须终于参与者,使系统保持在稳定状态。

构建用例模型的过程

  1. 获取事件清单

  2. 将事件清单整理到事件表中

  3. 采用用例图描述分析的结果

  4. 对用例进行描述

用例描述的组成部分

  • 用例标识

  • 用例名称

  • 涉及的参与者

  • 用例概述

  • 前置条件(Preconditions)

  • 后置条件(Postconditions)

  • 事件流(Flowof Events)

        •基本流程,不考虑异常;

        •分支流程(Subflows)

用例之间的关系

  • 包含:

  • 扩展

用户故事就是以用户的语言对产品功能(feature)所作的描述。

用户故事的组成:用户(user)、任务(task)、用户执行任务达到的目标(goal)

活动图包括:活动、流程、起始点、终节点、判断、泳道。

第五章、系统分析

系统分析的目的

  1. 初步以面向对象视角理解业务

  2. 对系统内部组成进行初步抽取

  3. 获取系统的初步设计

系统分析的技术

  1. 领域模型

  2. 健壮性分析(通过健壮性分析了解都有哪些对象参与了交互)

  3. 顺序图(通过构建顺序图描述用例场景中对象之间的交互,从而获得分析类图。)

领域模型

第六章、系统设计

软件体系结构

运用设计的基本原则模块化将复杂问题进行分解。

软件体系结构(SoftwareArchitecture)包括构成系统的设计元素的描述、设计元素之间的交互、设计元素的组合模式以及在这些模式中的约束。

构件是具有某种功能的可复用的软件结构单元,表示系统中主要的计算元素和数据存储。

连接是构件间建立和维护行为关联与信息传递的途径。

连接件表示构件之间的交互并实现构件之间的连接。

常见的体系结构风格

  1. 主程序-子程序体系结构(典型)
    优点:

    • 有效地将一个较复杂的程序系统设计任务分解成许多易于控制和处理的子任务。

    缺点:

    • 规模:程序太大,开发太慢,测试越来越困难。

    • 可重用性差、数据安全性差。

  2. MVC模式(模型-视图-控制器)
    不足:

    • 每次请求必须经过“控制器->模型->视图”这个流程,用户才能看到最终的展现的界面。

    • 视图是依赖于模型的。

    • 渲染视图的过程是在服务端来完成的,最终呈现给浏览器的是带有模型的视图页面,性能无法得到很好的优化。

  3. 客户机/服务器体系结构(Client/Server)

  4. 分层体系结构

    • 也称为按服务进行划分。

    • 是另一种实现分离和独立性的方式。

    • 系统按照层次结构组织,每一层向它的上一层提供服务,同时又是它的下层的客户。

    • 系统内的交互限定在邻接层之间。

    • 除了邻接层,一个内部层次对于其他外部层次是隐藏的。

    • 邻接层的关系并不严格。

好的软件体系结构带来的作用

  1. 提高可重用性

  2. 提高可扩展性

  3. 结构简洁

数据库

数据库就是对数据的管理。

业务中包括了对数据的增,删,改,查等操作。

数据管理中包括用户访问权限,持久化,分布式等不同的方案选择。

数据库设计的基本步骤
  1. 需求阶段的数据搜集

  2. 概念结构的设计

  3. 逻辑结构的设计

  4. 物理结构设计

  5. 系统实施

  6. 运行维护

界面设计通用规则

  1. 尽量保持一致性

  2. 为熟练用户提供快捷键

  3. 提供有效反馈

  4. 设计完整的对话过程

  5. 提供简单的错误处理机制

  6. 允许撤销动作

  7. 提供控制的内部轨迹

  8. 减少短期记忆负担

软件设计的通用原则

  1. 为改变而设计(产生一个能适应或可以很容易被改变的系统。)

  2. 关注点分离(模块独立性)

  3. 信息隐藏(隐藏一个模块的实现细节来降低对软件系统其他部分的影响。)

  4. 高内聚(内聚性模块或子系统内部的依赖程度)

  5. 低耦合(耦合是两个模块或子系统之间依赖关系的强度)

  6. 隔离可变性(改变不影响系统其他部分)

  7. 保持简单和直接

内聚

  • 偶然内聚(设计者随意决定将无关系的几个功能组合在一个模块中)

  • 逻辑内聚(把逻辑上相似的功能结合到一个模块中)

  • 时间内聚(在某一时间同时执行的任务放在同一模块中)

  • 过程内聚(遵循的步骤顺序有关的操作)

  • 通信内聚(所有操作都在相同的数据上进行)

  • 顺序内聚(所有的动作都作用在相同的数据结构上,而且一个成分的输出作为另一个成分的输入,这些处理必须依序执行)

  • 功能内聚(各部分是为了完成一个确定的功能存在于一个模块中的)

耦合

  • 内容耦合(一个模块访问另一个模块边界中的数据或控制,这种耦合是内容耦合也是最强的耦合)

  • 公共耦合(访问同一个公共数据环境(全局数据结构、共享的通信区、内存的公共覆盖区等)

  • 外部耦合(一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是通过参数表传递该全局变量的信息)

  • 控制耦合(模块与模块之间传递的参数是控制决策作用的。中级别的耦合度。)

  • 标记耦合(当模块与模块之间传递的参数是数据结构的一部分时。是数据耦合的变体)

  • 数据耦合(模块与模块之间需要通过常规的参数表访问,数据通过该列表传递,传递的数据是简单类型的)

  • 非直接耦合(两个模块式不同模块的从属模块,相互之间无关因而没有直接耦合发生)

降低模块间耦合度的原则

  • 尽量使用数据耦合

  • 少用控制耦合

  • 限制公共耦合的范围

  • 坚决避免使用内容耦合

设计总原则(高内聚低耦合)

  • 使每个模块执行一个功能

  • 模块间传递数据型参数

  • 模块间共用信息尽量少

第七章、对象设计

类的设计原则

  1. 单一职责原则(SRP,类的职责要单一)

  2. 开闭原则(OCP,对可变性封装)

  3. 依赖倒转原则(DIP,针对接口编程。)

  4. 里氏替换原则(LSP如何进行继承)

  5. 接口隔离原则(ISP,恰当的划分角色和接口)

  6. 合成复用原则(CARP,尽量使用合成/聚合、不使用继承)

  7. 最少知识原则(LoD,不要跟陌生人说话)

第八章、软件实现

类之间的关系

编码规范

命名、注释、格式。

第九章、软件测试

软件测试的目的和原则

测试的目的是设计测试用例,以最小的代价、在最短时间内系统地发现各种不同类型的错误。

黑盒测试(功能测试)

黑盒测试(功能测试)通过测试来检验每个功能是否都能正常使用。

等价类划分是把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据作为参数用例。

边界值分析其重点在于验证输入或参数的边界条件是否能够正常工作。这种测试方法特别关注于测试输入值的最小值、最大值以及临界值。

白盒测试(结构测试)

百盒测试是证明每种内部操作和过程是否符合设计规格和要求。

黑盒测试与白盒测试的区别

黑盒测试更关注软件功能是否符合规格说明,而白盒测试更关注软件内部逻辑的完备性和正确性。

第十章、软件维护

软件部署作用

  • 保障软件系统的正常运行和功能实现。

  • 简化部署的操作过程,提高执行效率。

  • 同时还必须满足软件用户在功能和非功能属性方面的个性化需求。

软件维护的意义

  • 提高客户对软件产品的满意度。

  • 保持现有系统的价值。

软件维护的分类

  • 改正性维护

  • 适应性维护

  • 完善性维护

  • 预防性维护

软件维护过程

软件维护准备、接受并响应维护要求、执行软件维护。

上一篇:
MySQL-Linux
下一篇:
Cpp