第一节、软件工程概念背景和发展
一、软件工程出现的背景 软件危机的出现， 成本高、工期长、而产生的软件质量低下二、软件工程
应用计算机科学理论和技术以及工程原则和方法，按预约和进度实现满足用户要求的软件产品的工程，或以此为研究对象的科学。
三、软件工程的发展
- 20世纪60--80年代:开发模型、开发方法、支持工具
- 80年代--至今:软件复用技术、软件生产管理
第二节、软件开发的本质
一、软件的概念 软件=程序+文档二、软件开发的本质 不同 抽象层 术语之间的“映射”，以及不同抽象层 处理逻辑之间的“映射”
三、模型的概念 模型是一个抽象。模型是在特定意图下的角度和抽象层次上对物理系统的描述，包含对该系统边界的描述、对系统的各模块以及他们之间关系的语义描述。
四、模型的类别
- 概念模型:描述软件是什么
- 软件模型:实现概念模型的软件解决方案，包括设计模型、实现模型和部署模型。
第三节、需求与需求获取
一、需求的定义 一个需求是有关一个"要与构造”的陈述，描述了待开发产品/系统功能能力、性能参数或其他性质 二、需求的基本性质- 必要的
- 无歧义的
- 可测的
- 可跟踪的
- 可测量的
- 功能需求:是整个需求的主题
- 非功能需求:性能需求、外部接口需求、设计约束和质量属性需求
设计约束:7类接口{ 用户接口、硬件接口、软件接口、通信接口、内存约束、运行约束、地点需求。 }
- 自悟
- 交谈
- 观察
- 小组会
- 提炼
第四节、需求规约（SRS）
一、需求规约的定义（将需求清楚的表现出来） 是一个软件/产品/系统所有需求陈述的正是文档，他表达了软件/产品/系统的概念模型。二、需求规约的性质
- 重要性和稳定性程度:对需求进行分级(那些需要马上处理，哪些可以缓一缓的)
- 可修改的(在一定范围类)
- 完整的:没有遗漏的需求
- 一致的:不存在互斥的需求
- 非形式化的需求规约
- 半形式化的需求规约
- 形式化的需求规约
- 需求规约是软件开发组织和用户之间的一份事实上的技术合同书，是产品功能及其环境的体现。
- 需求规约是一个控制点
- 对于产品/系统的设计，需求规约是正式的、受控的起始点
- 需求规约是创建产品验收计划和用户指南的基础。
第五节、结构化需求分析
- 掌握结构化分析方法(如何建立软件的功能模型)
- DFD
- 数据字典(数据源/数据潭描述)
- 决策数、决策表（数据加工描述）
- 掌握结构化设计方法(技术的角度，建立软件的实现模型)
- 控制结构图、PAD图、N-S图等
- 提供方便通信的机制(即使所处在不同的行业也能够得到有效的沟通)
- 鼓励需求分析人员使用问题空间的术语思考问题、编写文档
- 提供定义系统边界的方法
- 提供支持抽象的基本机制
- 为需求分析人员提供多种可选择的方案
- 提供特定的技术，适应需求的变化
- 数据:客观事物的一种表示
- 信息:具有特定语义的数据(数据是信息的载体)
- 数据流:数据的流动
- 加工:数据变换单元
- 数据存储
- 数据源/数据潭
- 数据流（用箭头表示,箭头指向数据传递方向）
- 加工：(用椭圆表示：椭圆中用动词表示)
- 数据源/数据潭：（用长方形表示）
- 数据存储:(双横线表示)
- 数据流图(DFD图)
一种表示数据变换的图形化工具 - 数据流程图的元素
数据源/数据潭 、数据流、数据存储、数据加工
- 自顶向下、逐步求精
- 将一个系统抽象成为一个整体（构建系统环境图）
- 逐步向下分解，使其每个模块具备相对独立的功能(需要增加处理编号)
1.数据字典：定义了数据流程图中所有数据流和数据存储的数据结构。
2.顺序结构：+
3.选择结构: |
4.重复结构: {}
5.字界: m.....n
建模过程三（加工的描述）
- 判定表
也称为决策表,是一个二维表，说明了每一种条件组合条件的结果。
- 判定树/决策树
- 结构化语言
若逻辑关系比较简单，可以用结构化自然语言来描述。
- 模型的平衡问题
- DFD图与数据字典的一致
- 底层加工的处理逻辑描述，与数据字典一致
- 信息的复杂控制问题
- 上层数据流可以打包
- 下层模块个数：6个左右
- 每个加工的数据流不能太多增加层次
- 审查(65%)
- 单元测试(10%)
- 评估(10%)
- 集成(5%)
第五节、结构化设计
总体分为两个阶段- 总体设计:针对总的系统为对象
- 详细设计:针对系统中的模块
- 总体设计的任务:把系统的功能需求分配到一个特定的软件系统结构中。
- 引入两个概念：
- 模块：软件中具有特定标识的独立成分
- 模块调用:模块之间的使用关系
- Yourdon提出的模块结构图
- 层次图
- 美国IBM公司提出的HIPO图（H：层次图 IPO：输入 处理 输出图）
将DFD图映射为设计层面的模块和模块调用。
- 将DFD图转换成初始的模块结构图
- 基于"高内聚、低耦合"的软件设计原则，通过模块化，将初始的模块结构图转换成为最终的模块结构图。
- 如何将DFD映射模块初级结构图？
1.两种映射方法
- 变换设计
基于变换的数据流程图是一个线性的顺序结构、由输入、输出和变换中心三部分组成 - 事务设计
基于事务的数据流程图中一个事物处理中心，它将输入分为许多相互平行的加工路径，然后根据输入的属性，选择某一加工路径。
- 模块
执行一个特殊任务的一个过程以及相关数据结构。模块通常由两部分组成：模块接口和模块体。 - 模块化的两个问题
- 如何将系统分解为软件模块？
1.“分而治之”和"抽象"
2.自顶向下、逐步求精
3.形成模块层次结构
- 如何设计模块？
- 如何将系统分解为软件模块？
把一个待开发的软件分解成若干个简单的、具有高内聚、底耦合的模块，这一过程称为模块化。
1.模块耦合
耦合是对两个模块之间相互依赖程度的一种度量。模块的依赖程度越大，则其耦合度程度也就越大；反之，模块间的依赖程度越小，则其耦合程度也就越小。
模块间耦合类型
- 内容耦合:一个模块直接修改或操作另外一个模块的数据
- 公共耦合:两个模块共同引用一个全局数据项
- 控制耦合:一个模块向另一个模块传递控制信号
- 标记耦合:一个模块向两个模块传递传递公共参数
- 数据耦合:模块之间通过参数来传递数据
是指一个模块内部各成分相互关联程度的度量。也就是说，内聚是对模块内各处理动作组合强度的一种度量。很显然，一个模块的内聚越大越好。
- 偶然内聚:模块的各成分没有任何关系
- 逻辑内聚:逻辑上相关的、处理放在一起
- 时间内聚:模块内的功能在同一时间完成
- 过程内聚:模块内的处理以特定的次序执行
- 通信内聚:操作同一数据集
- 顺序内聚:一个成分的输出作为另一成分的输入
- 功能内聚:模块的所有成分完成单一的功能
“高内聚、低耦合”
1.改进软件结构，提高软件独立性。模块分解
2.模块规模适中
3.力求深度、宽度、扇出、扇入适中。- 深度:表示其控制的层数
- 宽度:同一层次上模块总数的最大值
- 扇出:一个模块直接控制的下级模块数量
- 扇入:有多少个上级模块直接调用它
- 模块的控制域：这个模块本身以及所有直接或者间接从属他的模块集合
- 模块的作用域:受该模块内一个判断所印象的所有模块的集合。
6.力求模块功能可以预测。
二、详细设计
具体描述模块结构图中的每一模块，即给出实现模块功能的实施机制，包括一组例程和数据结构。
详细设计的目标:将总体设计阶段产生的系统高层结构映射为以相关术语表达的底层结构，也是系统的最终结构。
结构化程序设计方法
是一种基于结构的编程方法，即采用顺序结构、选择结构和重复结构进行编程，其中每一结构只允许一个入口和一个出口。
结构化程序设计的本质是:使程序的控制流程线性化，实现程序动态执行顺序符合静态书写的结构，提高程序的可读性。
详细设计工具
- 程序流程图
程序流程图:程序流程图又称为程序框图，他是历史最悠久使用最广泛的描述过程设计的方法，然而它是用的最混乱的一方法- 盒图(N-S图)
出于要有一种不允许违背程序结构设计精神的图形工具的考虑，Nassi和Shneiderman提出了盒图，又称为N-S图。- PAD图
PAD是问题分析图，自1973年由日本日立公司发明以后，已得到一定程度的推广。他用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易。
- 类程序设计语言PDL
PDL也成为伪码，他是由正文形式表示数据和处理过程的设计工具。
PDL具由严格的关键字外部语法，用于定义控制结构和数据结构
完整准确地描述满足需求规约所要求的所有功能模块，以及伴随功能模块而出现的非功能的机制。设计规约包括概要设计规约和详细设计规约。第六节、UML术语表
UML在方法学中不同的抽象层次
- 需求获取=======>表达模型的工具:用例图
- 需求分析层======>表达模型的工具:类图、交互图
- 设计层==========>表达模型工具:构件图、配置图等
- 类和对象
- 接口
- 协作
- 用况
- 主动类
- 构件
- 制品
- 节点
- 关联
- 泛化
- 实现
- 依赖
- 需求获取
建立用况模型和用况场景 - 需求分析
建立活动图和状态图
类图（建立域模型）
顺序图(实现用况) - 编写需求规格说明书
- 需求验证
- 表达客观事物的术语
- 对象(Object):是系统中用来描述客观事物的一个实体。
- 类(Object):是具有相同属性、操作、关系和语义一组对象的集合
- 表达关系的术语
- 表达组合关系的术语--包
- 变换设计
- 如何将DFD映射模块初级结构图？
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
