努力到处乞讨版()整合了部分期末重点
!!此博客主要为辅助复习,具体还是以课本和PPT为主
后面应该也会更新,欢迎大家补充与交流讨论,祝各位期末4.0!!!!!
此门课程的考察对记忆力要求较高,需要熟悉很多概念,以及极快的写字速度(老师说写不完是很正常的,所以需要边想边写)
题型分布如下
最后一周复习课的大纲,目录也按此复习
目录
数据字典:是模型的核心,它包含了软件使用和产生所有数据的描述
数据流图:用于功能建模,描述系统的输入数据流如何经过一系列的加工变换逐步变换成系统的输出数据流
状态转换图:用于行为建模,描述系统接收哪些外部事件,以及在外部事件的作用下的状态迁移情况
能够叙述:平台基础服务涉及的管理和服务的功能(以数据为中心)
概论虽然没强调,但也可以去看一下系统软件的定义,挑几个模型记一下(比如瀑布模型、喷泉模型、演化模型)
一、需求工程(对应课本ch3、5)
1.1需求规格说明书(需求规约)
需求规格说明书(需求规约)定义
需求规约是分析任务的最终产物,通过建立完整的数据和信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准,给出对目标软件的各种需求。 需求规约作为用户和开发者之间的一个协议,在之后的软件工程各个阶段发挥重要作用。
(补充:是软件开发过程中最重要的一步,不仅是个人的文档,更是约束开发的合同)
8条原则
1.从现实中分离功能,即描述要“做什么”而不是“怎样实现”。
2.要求使用面向处理的规约语言(或称系统定义语言),讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应来定义一个行为模型,从而得到“做什么”的规约。
3.如果被开发软件只是一个基于计算机的系统中的一个元素,那么整个大系统也应包括在规格说明的描述之中。
4.规约必须包括系统运行环境。
5.规约必须是一个认识模型,而不是设计或实现的模型。
6.规约必须是可操作的,利用它能够通过测试用例判断已提出的解决方案是否都能满足规约。
7.规约必须允许不完备性并允许扩充。
8.规约必须局部化和松散耦合。规约所包括的信息必须局部化,这样当信息被修改时,只需修改某个单个的段落(理想情况)。同时,规约应被松散地构造(即松耦合),以便能够很容易地加入和删去一些段落。
1.2数据流图
定义
Data Flow Diagram(简称DFD):描述输入数据流到输出数据流的变换(即加工)过程,用于对系统的功能建模。
基本元素包括:
分解原则
George Miller在著名的论文“神奇的数字7加减2:我们处理信息的能力的某种限制”中指出:人们在一段时间内的短期记忆似乎限制在5~9件事情之内
根据自顶向下逐层分解的思想,将数据流图画成层次结构 每个层次画在独立的数据流图中,加工个数可大致控制在“7加减2”的范围中。
分层数据流图示例—— 资格和水平考试的考务处理系统
因为不考察画图,所以在此不再赘述
总结:画分层数据流图的步骤
1.画系统的输入和输出
2.画系统内部
3.画加工内部
4.重复第3步,直至每个尚未分解的加工都足够简单(即不必再分解)
1.3分析模型
结构化分析模型的定义
数据字典:是模型的核心,它包含了软件使用和产生所有数据的描述
数据流图与数据字典是密不可分的,两者结合起来构成软件的逻辑模型(分析模型)
数据字典由字典条目组成,每个条目描述DFD中的一个元素
数据字典条目包括:数据流、文件、数据项(组成数据流和文件的数据)、加工、源和宿。
数据流图:用于功能建模,描述系统的输入数据流如何经过一系列的加工变换逐步变换成系统的输出数据流
详见1.2
实体—关系图:用于数据建模,描述数据字典中数据之间的关系
状态转换图:用于行为建模,描述系统接收哪些外部事件,以及在外部事件的作用下的状态迁移情况
二、设计工程(对应课本ch4)
软件需求分析解决“做什么”的问题,软件设计过程则解决“怎么做”的问题,这是软件开发过程中最具创新力的一环。
2.1软件的设计规约
定义
通常分概要设计规约和详细设计规约。前者指明软件的组织结构,其内容包括系统环境、设计描述、对每个模块的描述、文件结构和全局数据,还应包括有关软件测试等方面的要求与说明,是面向软件开发者的文档,主要作为项目管理人员、系统分析人员与设计人员之间交流的媒介。后者描述软件各组成部分的内部结构,在前者的基础上加入了各处理过程的算法、算法所涉及的全部数据结构的描述,包括与实现有关的描述,主要作为软件设计人员与程序人员之间交流的媒介。(来源百度词条)
2.2概要设计与详细设计
软件设计是把软件需求变换成软件表示的过程
概要(结构)设计阶段:把软件按照一定的原则分解为模块层次,赋予每个模块一定的任务,并确定模块间调用关系和接口。
详细设计阶段:依据概要设计阶段的分解,设计每个模块内的算法、流程