第4章 软件需求分析与概念模型

合集下载

软件工程需求分析(精品PPT)

软件工程需求分析(精品PPT)
•确定被开发软件系统的系统元素
•将功能和信息结构分配到这些系统元素中 •需求分析的任务
•深入描述软件的功能和性能 •确定软件设计的约束和软件同其它系统元素的接口细节
•定义软件的其它有效性需求
第四页,共七十七页。
需求(xūqiú)分析的具体任务
•需求分析阶段的具体任务:
•确定对系统的综合要求
•系统功能要求
第四章 析根底
软件工程 需求分 (ruǎn jiàn ɡōnɡ chénɡ)
第一页,共七十七页。
第四章 需求分析 根底 (fēnxī)
• 需求(xūqiú)分析的任务与原那么〔重点〕 • 需求分析的任务 • 需求分析的过程 • 软件需求分析的原那么 • 初步需求获取技术 • 需求建模〔重点〕 • 问题抽象、问题分解与多视点分析 • 支持需求分析的快速原型技术 • 需求规格说明书
第二十六页,共七十七页。
教务管理系统调查分析过程 1、认真学习教务管理方面的知识,重点掌握其中
的名词和术语 2、收集目前教务管理方面资料和软件,了解其特
•了解系统的需求 •软件开发是系统开发的一局部,仔细分析研究系统的需求 规格说明,对软件的需求获取是很有必要的
第十六页,共七十七页。
✓需求调查对象
对组织的高层管理者,进行组织管理目标或经营方 针等组织战略问题的调查
对中层的管理者,进行全部业务流的调查 对业务工作人员,进行详细业务信息的调查
✓市场调查 了解市场对待开发软件有什么样的要求;了解市场上 有无与待开发软件类似的系统
第十页,共七十七页。
需求(xūqiú)分析流程
第十一页,共七十七页。
软件需求(xūqiú)分析的原那么
1、需要能够表达和理解问题的信息域和功能域 信息域应包括:

软件设计与体系结构 第四章 面向对象的软件设计方法

软件设计与体系结构 第四章 面向对象的软件设计方法

用户界面设计
用户界面是对于用户的直接表现,直接影响到用
户对软件易用性、友好性的感觉。用户界面包含 两方面内容:
首先要完整地包括用户在使用软件过程中所需的各种 元素,例如窗口、菜单、按钮、输入文本框、选择列 表、提示信息等,缺乏这些元素中的某些将会导致软 件功能无法被用户正常完成; 其次要求具有良好的外观和布局,例如背景颜色、按 钮等元素的位置、选择列表中条目的顺序等,这些因 素的不足可能不会影响软件功能的正确使用,但会给 用户带来不便、迷惑甚至反感。
ATM系统在提供以上服务的过程中,必须满足以下要求 一个顾客可以在最终确认前放弃一项交易 ATM在执行交易过程中将与银行系统进行通信,对是否 允许交易进行验证 ATM为每次成功的交易提供一个打印回执
ATM需要维护一个内部日志,对每次交易进行记录
用例的分析与设计
确定用例—确定场景
从业务需求出发获取参与者(Actor)和场景,对场景进行汇总、分 类、抽象,形成用例 场景是用户与系统之间进行交互的一组具体的动作 获取场景 目标软件有哪些参与者
用例的分析与设计
Startup用例的顺序图描述
用例的分析与设计
Session用例的顺序图描述
用例的分析与设计
Transaction用例的顺序图描述
用例的分析与设计
Withdrawal用例的顺序图描述
概念模型和顶层架构设计
概念模型的设计 标识领域概念模型 分析类:直接服务于用户功能性需求的概念层面的类, 与具体技术没有关系 顶层架构的设计
件进行交互的功能与特性进行封装,使目标软件系统的其余部分
尽右能独立于环境软件。
概念模型和顶层架构设计
ATM系统的概念模型——分析模型图

软件需求分析模板

软件需求分析模板

软件需求分析模板一、引言。

软件需求分析是软件开发过程中至关重要的一环,它涉及到对用户需求的深入理解和准确把握,是软件开发成功的关键之一。

本文档旨在为软件需求分析提供一个模板,以帮助开发团队更好地进行需求分析工作。

二、项目背景。

在进行软件需求分析之前,首先需要了解项目的背景和相关信息。

项目背景包括项目的发起人、项目的目的和目标、项目的范围和预期成果等。

在这一部分,我们需要对项目进行一个整体的描述,以便更好地理解项目的需求和目标。

三、需求描述。

需求描述是软件需求分析的核心内容,它包括功能需求、性能需求、安全需求、界面需求等方面的描述。

在这一部分,我们需要对软件的各项需求进行详细的描述和分析,以便为后续的设计和开发工作提供参考。

四、需求分析。

需求分析是对需求进行深入分析和理解的过程,它包括对需求的可行性分析、优先级分析、风险分析等方面的内容。

在这一部分,我们需要对需求进行全面的分析,以便确定需求的实现方式和优先级,同时对可能存在的风险进行评估和分析。

五、需求确认。

需求确认是对需求进行最终确认和验证的过程,它包括对需求的完整性、一致性、可追溯性等方面的确认。

在这一部分,我们需要对需求进行最终的确认和验证,以确保需求的准确性和完整性,为后续的设计和开发工作奠定基础。

六、总结。

软件需求分析是软件开发过程中至关重要的一环,它直接关系到软件的质量和用户的满意度。

本文档提供了一个软件需求分析的模板,以帮助开发团队更好地进行需求分析工作。

希望本文档能够对软件需求分析工作有所帮助,为软件开发工作的顺利进行提供参考。

第4章 软件需求分析与概念模型

第4章   软件需求分析与概念模型

第四章软件需求分析与概念模型需求分析是软件定义时期的最后一个阶段,其基本任务是回答“系统必须做什么”这个问题。

本章内容主要包括:需求分析的概念,需求分析的基本原则,需求分析的基本任务,结构化分析方法,结构化分析的步骤,数据流图,数据字典,加工逻辑的描述及IDEF的方法。

4.1 基础知识4.1.1 需求分析的概念需求分析是指开发人员要进行细致的调查分析,准确理解用户的要求。

将用户非形式的需求陈述转化为完整的需求定义,再由需求定义转换到相应的形式功能的过程。

需求分析虽处于软件开发过程的开始阶段,但它对整个软件开发过程以及软件成品质量是至关重要的。

4.1.2 需求分析的基本原则为使需求分析的科学化,对软件工程的分析阶段中提出了许多需求分析方法。

在已提出许多软件需求分析与说明的方法中,每一种分析方法都有独特的观点和表示法,但都适用下面的基本原则:(1)可以把一个复杂问题按功能进行分解并可逐层细化。

通常,如果软件要处理的问涉及面太大,关系太复杂就要很难理解。

若划分成若干部分,并确定个部分间的接口,那么就可完成整体功能。

在需求分析过程中,软件领域中的数据,功能和行为都可以划分。

(2)必须能够表达和理解问题的数据领域和功能领域。

数据域包括数据流,数据内容和数据结构。

其中数据流是数据通过一个系统时的变化方式。

功能域则是反映数据流,数据内容和数据结构三方面的控制信息。

(3)建立模型。

所谓模型就是所研究对象的一种表达形式。

因此,模型可以帮助分析人员更好地理解软件系统的信息,功能和行为,这些模型也是软件设计的基础。

在软件工程中著名的结构化分析方法和面对对象分析方法都遵循以上原则。

4.1.3 需求分析的基本任务需求分析的基本任务是要准确地理解旧系统,定义新系统的目标。

为了满足用户需要,回答系统必须“做什么”的问题。

本阶段要进行以下几方面的工作:1..问题明确定义在可行性研究的基础上,双方通过交流,对问题都有进一步的认识。

天津大学软件工程课程教学大纲

天津大学软件工程课程教学大纲

2. Course Description This course presents an introduction to the basic concepts of software, objects of
software engineering, traditional procedure-oriented soft development methods and object-oriented soft development methods, so students can master the method to develop high quality software. By learning the software develop process and process management techniques, students can understand how to conduct software metrics and management, how to take quality assurance activities, so the students can plan and manage software development activities effectively.
《软件工程——理论与实践(第三版)》,Pfleeger.S.L,Atlee.J.M.著,高等教 育出版社,2006 年 9 月。
制定人: 审核人: 批准人: 批准日期:
年月日
TU Syllabus for Software Engineering
Code:
2160288
Semester Hours: 56
Chapter 2 Software Process Software Process Model Component-Based Development Process RUP CMM

软件设计概要设计

软件设计概要设计

顾客交互子系统旳程序构造雏形
(环节六)启发式设计策略优化初始SC图
▪ 使用启发式设计策略,精化所得程序构造
雏形——初始SC图,改良软件质量。
▪ 这一环节与变换分析法相同。
2.4混合构造
▪ 一种大型系统经常是变换型构造和事务型旳混合构造,为
了导出初始SC图,必须同步使用变换映射和事务映射
▪ 下例中,总体是一种变换构造,但是输入途径输入是事务
1.概要设计工具
▪ 层次图和HIPO图 ▪ 构造图
层次图
▪ 层次图用来描绘软件旳层次构造旳图
形工具。 正文加工系统
输入 输出 编辑 加标题 存储 检索 编目录 格式化
添加 删除 插入 修改 合并 列表
IPO图
▪ 层次图中旳每一种模块,均可用一张IPO图来描述。
IPO 图由输入、处理和输出三个框构成,需要时 还能够增长一种数据文件框。IPO图在需求分析阶 段主要用来描述系统旳主要算法。
▪ 在上例中,可能旳修改有:
▪ 输入构造中旳模块"转换成rpm"和"搜集sps"能
够合并;
▪ 模块"拟定加速/减速"能够放在模块"计算mph"
下面,以降低耦合;
▪ 模块"显示加速/减速"能够放在模块"显示mph"
下面。
精化后旳软件构造
模块阐明
▪程序构造旳模块名隐含模块功能,必须为每
个模块写一种简要旳处理阐明,
2.面对数据流旳设计——SD法
▪ 需求阶段对数据流进行分析,生成DFD和
DD
▪ 以此为基础,将DFD经过SD法软件构造。
面对数据流旳设计措施根据数据流图旳特征 定义变换流和事务流两种“映射”,这两种 映射能机械地将数据流图转换为程序构造。

软件工程各章名词解释

软件工程各章名词解释

名词解释一个三分 五个十五分第一章 绪论1. 软件2. 文档3. 软件工程4. 软件工程过程5. 软件生存周期6. 软件生存周期模型第二章 软件可行性研究与项目开发计划1. 投资回收2. 纯收人第三章 软件需求分析1. 需求分析2. 数据流3. 数据字典4. 加工5. 数据流图第四章 软件概要设计1. 模块2. 模块化3. 抽象4. 信息隐蔽5. 模块独立性6. 耦合性7. 无直接耦合8. 数据耦合9. 标记耦合10. 控制耦合11. 公共耦合12. 内容耦合13. 内聚性14. 偶然内聚15. 逻辑内聚16. 时间内聚17. 通信内聚18. 顺序内聚19. 功能内聚第五章 软件详细设计1. PAD2. 过程设计语言(PDL)第六章 软件编码1. 程序设计风格2. 程序可移植性第七章 软件测试1. 语句覆盖2. 判定覆盖3. 条件覆盖4. 判定/条件覆盖5. 条件组合覆盖6. 路径覆盖7. 环路复杂性8. 黑盒测试9. 白盒测试10. 驱动模块11. 桩模块12. 单元测试13. 集成测试14. 确认测试15. 调试第八章 软件维护1. 维护2. 校正性维护3. 适应性维护4. 完善性维护5. 预防性维护6. 软件可维护性第九章 软件开发的增量模型1. 原型第十章 面向对象的方法1. 对象2. 类3. 消息4. 方法5. 继承性6. 单重继承7. 多重继承8. 多态性9. 抽象10. 信息隐藏11. 链12. 关联第十一章 软件质量与质量保证1. 软件可靠性2. 效率3. 可维护性4. 可移植性5. 可互操作性6. 适应性7. 可重用性8. 软件设计质量9. 软件程序质量10. 冗余第十二章 软件工程管理1. 软件配置管理2. 软件配置项3. 基线4. 文档第十三章 软件开发环境1. 软件开发环境2. 软件工具3. CASE4. CASE生存期5. CASE工作台软件工程自考名词解释答案第一章 绪论1. 计算机程序及其说明程序的各种文档.2. 文档是有关计算机程序功能,设计,编制,使用的方案或图形资料.3. 用科学知识和技术原理来定义,开发,维护软件的一门学科.4. 软件工程过程规定了获取,供应,开发,操作和维护软件时,要实施的过程,活动和任务.5. 软件生存周期是指一个软件从得出开发要求开始直到该软件报废为止的整个时期.6. 软件生存周期模型是描述软件开发过程中各种活动如何执行的模型.第二章 软件可行性研究与项目开发计划1. 投资回收期就是使累计的经济效益等于最初的投资费用所需的时间.2. 在整个生存周期之内的累计经济效益(折合成现在值)与投资之差.第三章 软件需求分析1. 需求分析是指开发人员要准确理解用户的要求,进行细致的调查分析,将用户非不甘落后将用户非不甘落后 需求陈述转化为完整的需求定义,再由需求定义转换到相应的形式功能规约(需求规格说明)的过程.2. 数据流是数据在系统内传播的路径,因此由一组成分固定的数据项组成.3. 数据字典(Data Dic onary, 简称DD)就是用来定义数据流图中的各个成分的具体含义的,它以一种准确的,无二义性的说明方式为系统的分析,设计及维护提供了有关元素的一致的定义和详细的描述.4. 加工又称为数据处理,是对数据流进行某些操作或变换.5. 数据流图,简称DFD,是SA方法中用于表示系统逻辑模型的一种工具,它以图形的方式描绘数据在系统中流动和处理的过程.第四章 软件概要设计1. 模块在程序中是数据说明,可执行语句等程序对象的集合,或者是单独命名和编址的元素,在软件的体系结构中,模块是可组合,分解和更换的单元.2. 模块化是指解决一个复杂问题自顶向下逐层把软件系统划分成若干模块的过程.每个模块完成一个特定的子功能,所有的模块按某种方法组装起来,成为一个整体,完成整个要求的功能.3. 抽象是认识复杂现象过程中使用的思维工具,即抽出事物本质的共同的特性而暂不考虑它的细节,不考虑其他因素.4. 信息隐蔽指在设计和确定模块时,使得一个模块内包含信息(过程或数据),对于不需要这些信息的其他模块来说,是不能访问的.5. 模块独立性指每个模块只完成系统要求的独立的子功能,并且与其他模块的联系最少且接口简单.6. 耦合性也称块间联系.指软件系统结构中各模块间相互联系紧密程序的一种度量.7. 无直接耦合指两个模块之间没有直接的关系,它们分别从属于不同模块的控制与调用,它们之间不传递任何信息.8. 数据耦合指两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言的值传递.9. 标记耦合指两个模块之间传递的是数据结构,如高级语言的数组名,记录名,文件名等这些名字即为标记,其实传递的是这个数据结构的地址.10. 控制耦合指一个模块调用另一个模块时,传递的是控制变量(如开关,标志等),被调模块通过该控制变量的值有选择地执行块内某一功能.11. 公共耦合指通过一个公共数据环境相互作用的那些模块间的耦合.公共数据环境可是是全程变量或数据结构,共享的通信,内存的公共覆盖区及任何存储介质上的文件,物理设备等(也有将共享外部设备分类为外部耦合).12. 当一个模块直接使用另一个模块的内部数据,或通过非正常口转入另一个模块内部,这种模块之间的耦合为内容耦合.13. 内聚块又称块内联系指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量.14. 偶然内聚指一个模块内的各处理元素之间没有任何联系.15. 逻辑内聚指模块内执行个逻辑上相似的功能,通过参数确定该模块完成哪一个功能.16. 把需要同时执行的动作组合在一起形成的模块为时间内聚模块.17. 通信内聚指模块内所有处理元素都在同一个数据结构上操作(有时称之为信息内聚),或者指各处理使用相同的输入数据或者产生相同的输出数据.18. 顺序内聚指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素的输出就是下一功能元素的输入.19. 功能内聚指模块内所有元素共同完成一个功能,缺一不可.因此模块不能再分割.第五章 软件详细设计1. PAD图指问题分析图(Problem Analysis Diagram),是一咱算法描述工具,它是一种由左往右展开的二维树型结构.PAD图的控制流程为自上而下,从左到右地执行.2. 过程设计语言(Process Design Language,简称PDL),也称程序描述语言(Program Descrip on Language),又称为伪码.它是一种用于描述模块自法设计和处理细节的语言.第六章 软件编码1. 程序设计风格指一个人编制程序时所表现出来的特点,习惯逻辑思路等.2. 指程序从一个计算机环境移值到另一个计算机环境的容易程序.第七章 软件测试1. 语句覆盖是指设计足够的测试用例,使被测程序中每个语句至少执行一次.2. 判定覆盖指设计足够的测试用例,使得被测程序中每个判定表达式至少获得一次”真”和”假”值,从而使程序的每一个分支至少都通过一次.3. 条件覆盖指设计足够的测试用例,使得判定表达工中每个条件的各种可能的值出现一次.4. 判定/条件覆盖标准指设计足够的测试用例,使得判定表达式中的每个条件的所有可能取值至少出现一次,并使每个判定表达式所有可能的结果也至少出现一次.5. 条件组合覆盖是比较强的覆盖标准,它是指设计足够的测试用例,使得每个判定表达式中条件的各种可能的值的组合都至少出现一次.6. 路径覆盖是指设计足够的测试用例,覆盖被测程序中所有可能的路径.7. McCabe定义程序图的环路为程序图中区域的个数.区域个数为边和结点圈定的封闭区域数加上图形外的区域数1.8. 黑盒测试是功能测试又称为功能测试或数据驱动测试.9. 白盒测试是对程序中尽可能多和逻辑路径进行测试,检验内部控制结构和数据结构是否有错,实际的运行状态与预期的状态是否一致.10. 驱动模块是用来模拟被测模块的上级调用模块的模块,功能要比真正的上级模块简单得多,它只完成接受测试数据,以上级模块调用被测模块的格式驱动被模块,接收被测模块的测试结果并输出.11. 桩模块用来代替被测试模块所调用的模块它的作用是返回被测模块所需的信息.12. 单元测试指对源程序中每一个程序单元进行测试,检查各个模块是否正确实现规定的功能,从而发现模块在编码中或算法中的错误.13. 集成测试是指在单元测试的基础上,将所有模块按照设计要求组装成一个完整的系统进行测试,故也称组装测试或联合测试.14. 确认测试又称有效性测试.是为了检查软件的功能与性能是否与需求规格说明书中确定的指标相符合所进行的测试.15. 调试是为了确定错误的原因和位置,并改正错误所进行的工作,因此调试也称为纠错.第八章 软件维护1. 在软件运行/维护阶段对软件产品所进行的修改就是维护.2. 为了识别和纠正错误,修改软件性能上的缺陷,应进行确定和修改错误的过程,这个过程就称为校正性维护.3. 随着计算机的飞速发展,计算机硬件,软件及数据环境在不断发生变化,为了使应用软件适应这种变化而修改软件的过程称为适应性维护.4. 在犯罪分子件运行时期中,用户往往会对软件提出新的功能要求与性能要求.这种增加软件功能,增强软件性能,提高软件运行效率而进行的维护活动称为完善性维护.5. 为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护.6. 软件可维护性是指软件能够被理解,校正,适应及增强功能的容易程度.第九章 软件开发的增量模型1. 软件开发中的原型是软件的一个早期可运行的版本,它反映了最终系统的重要特性.第十章 面向对象的方法1. 对象是人们要进行研究的任何事物,从最简单的整数到复杂的飞机等均可看作对象,它不仅能表示具体的事物,还能表示抽象的规则,计划或事件.2. 具有相同或相似性质的对象的抽象就是类具有相同或相似性质的对象的抽象就是类3. 对象之间进行通信的构造叫做消息.4. 类中操作的实现过程叫做方法,一个方法有方法名,参数,方法体.5. 继承性是子类自动共享父类数据结构和方法的机制这是类之间的一种关系.6. 在类层次中,子类只继承一个父类的数据结构和方法,称为单重继承.7. 在类层次中,子类继承了多个父亲的数据结构和方法,称为多重继承.8. 多态性是指相同的操作或函数,过程可作用于多用户种类型的对象上并获得不同结果.不同的对象收到同一消息可以产生不同的结果,这种现象称为多态性.9. 抽象是指强调实体的本质,内在的属性,忽略一些无关紧要的属性.10. 信息隐蔽是指所有软件部件内部都有明确的范围以及清楚的外部边界每个软件部件都有友好的界面接口,软件部件的内部实现与外部可访问性分离.11. 链表示对象间的物理与概念联结.12. 关联表示类之间的一种关系,就是一些可能的链的集合.第十一章 软件质量与质量保证1. 软件按照设计要求,在规定时间和条件下不出故障,持续运行的程度.2. 为了完成预定功能,软件系统所需的计算机资源和程序代码数量的程度.3. 找到并改正程序中的一个错误所需代价的程度.4. 将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需的工作量.5. 将一个系统耦合到另一个系统所需的工作量.6. 修改或改进一个已投入运行的软件所需工作量的程度.7. 一个软件能再次用于其他相关应用的程度.8. 设计的规格说明书要符合用户的要求.9. 程序要按照设计规格说明所规定的情况正确执行.10. 冗余是指实现系统规定功能是多余的那部分资源,包括硬件,软件,信息和时间.第十二章 软件工程管理1. 软件配置管理,简称SCM,是一组管理整个软件生存期各阶段中变更的活动是一组管理整个软件生存期各阶段中变更的活动2. 软件配置项是软件工程中产生的信息项,它是配置管理的基本单位.3. 基线是软件生存期中各开发阶段的一个特定点,它的作用是把开发各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,以便于检查与肯定阶段成果.4. 文档是指某种数据媒体和其中所记录的数据.在软件工程中,文档用来表示对需求,工程或结果进行描述,定义,规定,报告或认证的任何书面或图示的信息.它们描述和规定了软件设计和实现的细节,说明使用软件的操作命令.第十三章 软件开发环境1. 软件开发环境是相关的一组软件工具集合,它支持一定的软件开发方法或按照一定的软件开发模型组织而成.2. 软件工具是指为支持计算机软件的开发,维护,模拟,移植或管理而研制的程序系统.3. CASE是一组工具和方法的集合,可以辅助软件开发生命周期各阶段进行软件开发.4. 一个组织中的CASE系统从被始需求到完全废弃这一生存期.5. 一个CASE工作台是一组工具集,支持像设计,实现或测试等特定的软件开发阶段.。

软件设计与体系结构-第四章-面向对象的软件设计方法课件

软件设计与体系结构-第四章-面向对象的软件设计方法课件

l 概念模型与顶层架构设计:
l 在用户需求和相关的业务领域中,概念及概念关系的抽取
l 用户界面设计:
l 设计每个界面中的所有界面元素,确定初步的界面布局,定义用户界面动作对软件系统中设计元
素的要求
l 数据模型的设计:
l 确定设计模型中需要持久保存的类的对象及其属性,定义持久持久存储数据之间的组织方式,并
.
26
概念模型和顶层架构设计
l 边界类: 其职责包括: l 边界控制: l 包括定义数据的格式及内容转换,输出结果的呈现,软件运行过程中界
面的变化与切换等。 l 外部接口: l 实现目标软件系统与外部系统或外部设备之间的信息交流和互操作,主
要关注跨越目标软件系统边界的通信协议 l 环境隔离: l 对目标软件系统与操作系统、数据库管理系统、中间件等环境软件进行
事件流中步骤(1)
l (3)如果账户余额小于取款金额,则显示信息“账户余额不足,请重新输入”,并返回主事件流
中步骤(1)
l (4)顾客在确认取款金额前右以选择取消交易。
l 后置条件: 如果取款成功,系统从账户余额中减去相应数额,并返回等待状态;如果顾客取消交易,
则返回等待状态
.
19
用例的分析与设计
体技术没有关系 l 顶层架构的设计 l 目的: 为后续的分析和设计活动建立一种结构和划分
.
24
概念模型和顶层架构设计
l 关键概念来源: l 为建立以UML类图表示的领域概念模型,首先必须标识关键概念。关键
概念的来源包括: l (1)业务需求描述、用例说明; l (2)业务领域中的相关规范、标准、术语定义。 l (3)反映业务领域知识的既往经验。 l 业务需求描述 l 业务领域中的相关规范、标准、述评呼定义 l 反映业务领域知识的既往经验

软件工程实践指南

软件工程实践指南
概念
01
设计模式是针对常见的设计问题提出的可重复利用的解决方案。
类型
02
常见的设计模式包括创建型模式、结构型模式、行为型模式等。
应用
03
设计模式可以帮助设计者更好地解决设计问题,提高系统的质量和性能。
结构化设计
原理
结构化设计是通过 将系统分解为模块, 确定模块之间的接 口和关系来实测试
语句、分支、路径覆盖等测试
利用工具和脚本 提高效率和准确性
减少人力成本、加快测试进度
提高软件质量
01
确保系统符合需求
验证系统正确性
02
发现系统中的错误、缺陷
保证系统可靠性
03
提高系统稳定性和安全性
软件测试目标
总结
软件测试是确保软件质量的重要环节,通过各种测试方法 可以发现系统中的问题并提高软件的可靠性。黑盒测试、 白盒测试和自动化测试各有优势,综合运用可以更好地保
什么是软件需求?
软件需求是用户对软件系统的期望和要求的描述,是软件 开发的基础。软件需求包括功能需求、非功能需求、用户 需求、系统需求等。需求分析可以采用面向对象分析、数
据流分析等方法。
需求获取
方法
需求可以通过访谈 用户、观察工作流 程、分析文档等方
式获取。
难点
需求获取过程中常 见的困难包括需求 不明确、需求冲突、
结尾
软件质量保障是软件工程中至关重要的一环,通过不断优 化和改进,可以提高软件产品的质量和用户满意度。各种 质量保障方法和工具的应用,能够有效降低软件开发和维
护中的风险,值得开发团队深入研究和实践。
● 06
第六章 总结与展望
软件工程实践的价值
提高软件产品质量

软件工程与软件系统架构设计

软件工程与软件系统架构设计

面向对象设计原则
面向对象设计原则是软件工程中的重要理念,有助于 构建灵活、可维护的系统。单一职责原则要求一个类 只负责一个功能,开放关闭原则要求对扩展开放,对 修改关闭,里式替换原则要求子类能够替换父类,依 赖倒置原则要求依赖抽象而不是具体,接口隔离原则 要求接口要小而专,合成复用原则要求尽量使用组合
析和评估,制定对应的风险应对策略。
团队管理与沟通
团队建设
包括团队组建、角 色分配等
有效沟通
沟通是团队成功的 关键,需要及时、 清晰地传达信息
团队协作
团队成员之间的有 效协作和信息共享
变更控制
识别变更需求 评估变更影响 制定变更计划
变更管理
变更评估
评估变更的必要性 评估变更的风险 评估变更的资源需求
区块链在软件项目管理中的应用日益普及,通过去中 心化的特性,实现了数据的安全和可追溯性。区块链 技术不仅能确保项目数据的完整性,还能提升项目管
理效率。
感谢观看
在本章节中,我们回顾了软件工程与软件系统架 构设计的重要内容,展望了未来的发展趋势。感 谢您的耐心阅读,如果您有任何疑问,欢迎随时 联系我们。祝您在软件工程之路上取得更大的成
变更实施
根据变更计划执行变更 监控变更进度 验证变更结果
质量标准的制定
明确项目的质量目标和标准
质量问题的处理
及时发现并解决软件质量问题
质量保证措施
采取措施确保项目交付符合质量标准
质量管理
总结
软件项目管理是一个复杂的过程,涉及项目计划、 团队管理、变更管理和质量管理等多个方面。只 有严格执行管理流程,不断优化管理方法,才能
软件质量保证
质量标准
制定质量标准
质量评估

软件需求分析复习资料

软件需求分析复习资料
复旦大学计算机科学与工程系 软件工程课程 4

计算机系统本身是无用的

������ ������ ������ ������ ������ ������

软件开创了新的可能性

目录
首页
上页
下页
末页

软件需求包括三个不同的层次—业务需求、用户需求和 功能需求(非功能需求)
业务需求( business requirement)反映了 组织机构或客户对系统、产品高层次的目标 要求
原型法
适合于开发方清楚 对于开发方要求较 在以往类似项目应 项目需求但用户方 高 用系统的基础上进 不清楚项目需求的 行少量修改得出一 情况 可运行系统
节省开销 无法满足个性化软 重用建好的领域模 件要求 型,获得新系统需 13 复旦大学计算机科学与工程系 软件工程课程 求
目录 首页 上页 下页 末页

复旦大学计算机科学与工程系 软件工程课程 31
目录
首页
上页
下页
末页
类图

当你考虑如何将问题域对象映射到系统对象, 并进一步细化每个类的属性和操作时,面向对 象技术可以方便需求开发到设计阶段的转换。 类图(class diagram)是用图形方式叙述面向对 象分析所确定的类以及它们之间的关系。 用统一建模语言(UML)的符号为化学制品跟 踪系统的一部分(你所假设的)绘制类图。
末页
业务需求
•业务需求是组织或客户对于系统的高层次目标要求,定义 了项目的远景和范围,即确定软件产品的发展方向、功能 范围、目标客户和价值来源。 •业务需求的内容
–业务:产品属于哪类业务范畴?应该完成什么功能?需要为什么
服务? –客户:产品为谁服务?目标客户是谁?

软件工程教案_4(第四章)

软件工程教案_4(第四章)

耦合强度依赖的因素: 耦合强度依赖的因素:
•一模块对另一模块的引用 •一模块向另一模块传递的数据量 •一模块施加到另一模块的控制的数量 •模块间接口的复杂程度
模块间耦合的类型
低 耦 合 性 无直接耦合
(低耦合) 数据耦合 低耦合)
强 模 块 独 立 性 弱
标记耦合
(中耦合) 控制耦合 中耦合)
外部耦合
§4.3 模块的独立性
4.3.1 模块独立性的概念 模块独立的含义: 模块独立的含义:
模块完成独立的功能 符合信息隐蔽和信息局部化原则 模块间关连和依赖程度尽量小
4.3.2 模块独立性的度量
模块独立性取决于模块的 内部和外部特征。 内部和外部特征。 SD方法提出的定性的度量标准: 方法提出的定性的度量标准: • 模块之间的耦合性 • 模块自身的内聚性
数据耦合举例
开发票 单价 数量 计算水费 金额
(3) 标记耦合(特征耦合) 3) 标记耦合(特征耦合)
如两个模块通过传递数据结构 如两个模块通过传递数据结构
(不是简单数据,而是记录、数组 不是简单数据,而是记录、 等)加以联系,或都与一个数据 加以联系,或都与一个数据
结构有关系, 结构有关系, 则称这两个模块 有关系 间存在标记偶合。 间存在标记偶合。
第四章 软件设计
主要内容: 主要内容: ▲ 软件设计的目标和任务 ▲ 软件设计基础 ▲ 模块的独立性 ▲ 结构化设计方法 ▲ 数据设计及文件设计 ▲ 过程设计
讨论要点
(1)如何将分析模型转换为软件 (1)如何将分析模型转换为软件 设计? 设计? (2)作为软件工程师在软件设计 (2)作为软件工程师在软件设计 方面应使用哪些基本原则和 概念? 概念?
将标记耦合修改为数据耦合举例

软件工程实用案例 第4章 结构化需求分析

软件工程实用案例 第4章 结构化需求分析
2 项目前景 2.1 前景概述 2.2 主要特性
3项目范围 3.1 第一版范围 3.2 后续版本范围 3.3 限制与排除
4项目环境 4.1 操作环境 4.2 涉众 4.3 项目属性
词汇表 参考资料 附录
4.3 需求获取
4.3.3 选择信息的来源
• 1. 涉众
• 包括用户、客户、领域专家、用户替代源(市场人员、销售人员) 等。
4.4 需求分析
4.4.1 过程建模
4.4.1.1 数据流图
3. 分层结构 (3)N层图
图4-12 功能分解示意图
4.4 需求分析
4.4.1 过程建模
4.4.1.1 数据流图
3. 分层结构 (3)N层图
图4-13 食物订货系统的1层图
4.4 需求分析
4.4.1 过程建模
4.4.1.2 微规格说明
正式规定文档所需具有的条件或能力。
(3) 对(1)或(2)所描述的条件或能力的文档化表述。 其中,(1)是从用户角度定义的,(2)是从开发人员、
系统的角度定义的。
4.1 需 求
4.1.2 需求的层次
需求通常体现为三个层次:业务需求、用户需求和系 统需求。
4.1 需 求
4.1.2 需求的层次
4.3 需求获取
4.3.2 定义项目前景和范围
• 1.明确问题
P1 决策者:生产的废品过多。
• 2.发现业务需求
BR1:提供销售订单的准确性,减少因此而产生废品。
BR2:提供销售订单的准确性,在使用后3个月内,减少50%因此而产生 的废品。
4.3 需求获取
4.3.2 定义项目前景和范围
• 3.定义解决方案及系统特性
4.3 需求获取
4.3.4 需求获取的方法

软件工程考核知识点-第4章-软件概要设计

软件工程考核知识点-第4章-软件概要设计

软件工程考核知识点-第4章-软件概要设计4.1 软件概要设计的基本任务在软件需求分析阶段,已经搞清楚了软件“做什么”的问题,并把这些需求通过规格说明书描述了出来,这也是目标系统的逻辑模型。

进入了设计阶段,要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型,即着手实现软件的需求,并将设计的结果反映在“设计规格说明书”文档中,所以软件设计是一个把软件需求转换为软件表示的过程,最初这种表示只是描述了软件的总的体系结构,称为软件概要设计或结构设计。

4.1.1 基本任务1. 设计软件系统结构(简称软件结构)为了实现目标系统,最终必须设计出组成这个系统的所有程序和数据库(文件),对于程序,则首先进行结构设计,具体为:(1)采用某种设计方法,将一个复杂的系统按功能划分成模块。

(2)确定每个模块的功能。

(3)确定模块之间的调用关系。

(4)确定模块之间的接口,即模块之间传递的信息。

(5)评价模块结构的质量。

根据以上内容,软件结构的设计是以模块为基础的,在需求分析阶段,已经把系统分成层次结构。

设计阶段,以需求分析的结果为依据,从实现的角度进一步划分为模块,并组成模块的层次结构。

软件结构的设计是概要设计关键的一步,直接影响到下一阶段详细设计与编码的工作软件系统的质量及一些整体特性都在软件结构的设计中决定。

2.数据结构及数据库设计对于大型数据处理的软件系统,除了控制结构的模块设计外,数据结构与数据库设计也是很重要的。

(1)数据结构的设计逐步细化的方法也适用于数据结构的设计。

在需求分析阶段,已通过数据字典对数据的组成、操作约束、数据之间的关系等方面进行了描述,确定了数据的结构特性,在概要设计阶段要加以细化,详细设计阶段则规定具体的实现细节。

在概要设计阶段,宜使用抽象的数据类型。

(2)数据库的设计数据库的设计指数据存储文件的设计,主要进行以下几方面设计:①概念设计。

在数据分析的基础上,采用自底向上的方法从用户角度进行视图设计,一般用ER模型来表示数据模型,这是一个概念模型。

软件项目管理案例教程(第4版)-第4章

软件项目管理案例教程(第4版)-第4章

4.2.4 需求文档
需求文档作用
使用对象
需求文档的作用
软件项目客户 了解软件项目能够提供的软件产品,检查软件需求是否满足需要
项目管理人员 根据需求文档制定项目的开发计划和软件过程,初步预测资源的使用
软件开发人员 理解要开发的产品及具体要开发的内容 软件测试人员 验证软件系统是否满足了预期的要求 软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系
需求验证的内容:
(1)有效性检查
对于每项需求,首先必须证明它是正确有效的,确实能解决用户面对的问题。
(2)一致性检查
在需求文档中,需求不应该冲突,即对同一系统功能不应出现不同的描述或相互矛盾的约束。 当两条需求不能同时满足时,则定义二者是不一致的。 采用形式化的需求规格说明可以用软件工具验证需求的一致性。
自动化
实现级->设计级->功能级->需求级
4.1.4 需求工程
需求工程目标:
通过对问题及其环境的理解建立分析模型,在完全理解用户需求的基础上用SRS表达用户需 求
建立分析模型:它包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及 设计约束
编写SRS:按照软件组织定义的SRS大纲,采用某种需求描述语言来完成
这家人承诺:杯子做好后会有高额的酬谢。
爱斯基摩人不断摇头,决定一分钱也不付给你。
4.1.1 软件需求概念
客户不知道自己要什么
客户:塑料杯、木头杯、还是橡胶杯,我也不知道!
客户知道自己要什么,但表达不清
客户提要求:使用时要能适应北极的环境。
我们经常会对客户的要求产生错误的理解
我们的理解:他一定要一个结实的杯子!
潜在缺陷

SE(4)

SE(4)

4.5 需求分析最佳实践
4.5.4 UML需求分析技术 基于用例模型进行需求分析的主要步骤如下: 1. 2. 3. 4. 5. 6. 7. 分析需求的质量属性。 确定各需求条目的优先级,选取优先分析的用例。 精化领域概念模型。 用例分析。 构造状态图、活动图。 构建快速原型。 评审分析模型。
4.5 需求分析最佳实践
4.2 软件需求与需求过程
4.2.2 需求工程
用UML活动图表示的需求工程中单个子过程的工作流
单次子过程中的缺陷追踪及返工
4.2 软件需求与需求过程
4.2.2 需求工程
Elicitation Analysis
Commitment Planning
Commitment Acceptance
SSS SSDD SRS SDD
成本效益分析:该项目的投资规模较小,但是可以大大提高 教学管理,方便教务人员、教师和学生开展课程相关的教学与 管理,投入小,效益大。 长远利益分析:系统能够有效记录课程教学的相关信息,能 够便于未来实施有效的教学监督、管理与改革。 技术可行性分析:该系统采用成熟的系统开发技术,技术可 行。 综上所述,该系统是可行的。
4.5 需求分析最佳实践
4.5.2 需求建模基础
课程注册管理系统的对象模型示例
4.5 需求分析最佳实践
4.5.2 需求建模基础
[
<
]
[ 初始 开放
>=
] 关闭
[ 2:00]
取消
动态模型示例
4.5 需求分析最佳实践
4.5.3 流行的需求分析方法论
(1)结构化分析方法 结构化分析方法(Structured Method,结构化方 结构化分析方法 法)是强调开发方法的结构合理性以及所开发软件 的结构合理性的软件开发方法。

D第四章需求模型及PowerDesigner实现

D第四章需求模型及PowerDesigner实现

清华大学出版社
软件分析建模与PowerDesigner实现 2010.4
4.7需求与设计对象的导入与导出> 把设计对象导入到RQM中 ▪ 在列表中选择要导入的设计对象。
清华大学出版社
软件分析建模与PowerDesigner实现 2010.4
4.7需求与设计对象的导入与导出> 把设计对象导入到RQM中 ▪ 选择一个RQM模型的需求
清华大学出版社
软件分析建模与PowerDesigner实现 2010.4
4.8 RQM与MS Word文档的信息交换>把Word文档导入到RQM中
导入设置完成窗口
清华大学出版社
软件分析建模与PowerDesigner实现 2010.4
4.8 RQM与MS Word文档的信息交换>把Word文档导入到RQM中
清华大学出版社
软件分析建模与PowerDesigner实现 2010.4
4.1建立RQM的方法
需求特性窗口
清华大学出版社
软件分析建模与PowerDesigner实现 2010.4
4.1建立RQM的方法> RQM中的包
▪ 包(Package)与操作系统中的文件夹十分相似,包中可以 存放RQM中的各类视图。当RQM中包含很多内容时,为 便于管理和理解,可以把RQM划分成几个包,每个包表 示不同的任务或主题 。
4.6需求与设计对象的连接>在需求上连接设计对象 ▪ 单击窗口上部的Add Links to Design Objects工具
清华大学出版社
软件分析建模与PowerDesigner实现 2010.4
4.6需求与设计对象的连接>在需求上连接设计对象
▪ 在Model框中选择一个模型,在第二个下拉列表框中选择该模型的一 个图形,在列表中选择设计对象前面的复选框。单击OK,则所选择 的设计对象出现在Traceability Links页上,在Link Type列中选择 Undefined、Specification document、Test object、Design object、 Development Planning等五种类型之一。

软件开发项目管理

软件开发项目管理

计划是否落实 是
出访组团登记

结束
出访团组基本情况 登记表
否 否
护照登记表?
是否本单位人员 是
是否需要 办理护照
是 申请护照
护照管理
签证管理
chapter__4
结束
申请出国 护照事项表
护照卡?
申请出国 签证事项表?
58
本章要点
一、软件需求定义 二、软件需求管理过程 三、需求建模的基本方法
原型方法 结构化分析法 面向对象的用例分析法 功能列表法 其他
chapter__4
20
需求规格
需求分析工作完成的一个基本标志是形成 了一份完整的、规范的需求规格说明书
需求规格说明书的编制是为了使用户和软 件开发者双方对该软件的初始规定有一个 共同的理解,使之成为整个开发工作的基 础。
chapter__4
21
软件需求规格说明的原则
从现实中分离功能,即描述要“做什 么”而不是“怎样实现”
平均值
4.5 4.3 4.2 4.1 4.1 3.9 3.8
3.8 3.6 3.6
9
本章要点
一、软件需求定义 二、软件需求管理过程 三、需求建模的基本方法 四、案例分析
chapter__4
10
软件需求管理过程
软件需求管理的过程
需 求 需求获取 确 认
需求验证
需求分析 编写需求规格
需求变更
需求的隐含错误 需求不明确、含糊 用户不断增加需求、变更需求 用户刁难 开发人员的镀金
chapter__4
3
本章要点
一、软件需求定义 二、软件需求管理过程 三、需求建模的基本方法 四、案例分析
chapter__4

软件工程功能分析与概念模型

软件工程功能分析与概念模型
① 用例图的图符 —— 表示活动 (例:增删改表示成用例) ② 活动图的图符 —— 表示用例 (例:功能∕事务分解关系表示成活动) ③ 多过程通过多入口组合在一张图上, 但过程间的活动无关联
同步条
同步条:表示引入的信息流同时到达, 引出的信息流被同时触发
初始化
显示
测量
信息流、数据流、信号流
信息流:连接各活动并表示活动间的控制转移
数据流:连接活动与其I/O对象 信号流:连接收发信号与对象
泳道
泳道进一步描述完成活动的对象,并聚合一组活动。活动图是 另一种描述交互的方式,描述采取何种动作,做什么(对象状态 改变),何时发生(动作序列),以及在何处发生(泳道)。 泳道也是一种分组机制。 顾 客 售 货 库 房
适应; 可用泳道技术对同层活动进行活动状态与轨迹分组;
建模要点
活动图对功能分解层次的覆盖关系 ① 活动分割关系:子功能—活动 子功能—活动—动作 ② 每个底层用例可展开为一张活动图 (由单个用例中的相关活动序列组成) ③ 单个活动:由不可再分的相关动作序列组成
用例的活动图表示
1.2.4 常见问题分析
若一个用例中有完全不同的事件流最好把它分解成不同的用例常见问题审查与分析用例表示活动操作或状态用例表示活动操作或状态会员输入用户名验证用户名和密码会员登录include常见问题审查与分析用例表示系统活动用例表示系统活动查询订单建立数据库连接执行sql语句includeinclude常见问题审查与分析用例表示数据的增删改查用例表示数据的增删改查删除用户修改用户增加用户管理员查询用户常见问题审查与分析管理员用户管理管理员用户管理增加用户extend12活动图121活动图的作用122活动图基本概念123活动图建模过程124常见问题分析121活动图的作用活动模型用活动图表示活动模型用活动图表示一种观点认为活动图是一种特殊的状态图一种观点认为活动图是一种特殊的状态图活动图
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第四章软件需求分析与概念模型需求分析是软件定义时期的最后一个阶段,其基本任务是回答“系统必须做什么”这个问题。

本章内容主要包括:需求分析的概念,需求分析的基本原则,需求分析的基本任务,结构化分析方法,结构化分析的步骤,数据流图,数据字典,加工逻辑的描述及IDEF的方法。

4.1 基础知识4.1.1 需求分析的概念需求分析是指开发人员要进行细致的调查分析,准确理解用户的要求。

将用户非形式的需求陈述转化为完整的需求定义,再由需求定义转换到相应的形式功能的过程。

需求分析虽处于软件开发过程的开始阶段,但它对整个软件开发过程以及软件成品质量是至关重要的。

4.1.2 需求分析的基本原则为使需求分析的科学化,对软件工程的分析阶段中提出了许多需求分析方法。

在已提出许多软件需求分析与说明的方法中,每一种分析方法都有独特的观点和表示法,但都适用下面的基本原则:(1)可以把一个复杂问题按功能进行分解并可逐层细化。

通常,如果软件要处理的问涉及面太大,关系太复杂就要很难理解。

若划分成若干部分,并确定个部分间的接口,那么就可完成整体功能。

在需求分析过程中,软件领域中的数据,功能和行为都可以划分。

(2)必须能够表达和理解问题的数据领域和功能领域。

数据域包括数据流,数据内容和数据结构。

其中数据流是数据通过一个系统时的变化方式。

功能域则是反映数据流,数据内容和数据结构三方面的控制信息。

(3)建立模型。

所谓模型就是所研究对象的一种表达形式。

因此,模型可以帮助分析人员更好地理解软件系统的信息,功能和行为,这些模型也是软件设计的基础。

在软件工程中著名的结构化分析方法和面对对象分析方法都遵循以上原则。

4.1.3 需求分析的基本任务需求分析的基本任务是要准确地理解旧系统,定义新系统的目标。

为了满足用户需要,回答系统必须“做什么”的问题。

本阶段要进行以下几方面的工作:1..问题明确定义在可行性研究的基础上,双方通过交流,对问题都有进一步的认识。

所以可确定对问题的综合需求。

这些需求包括:功能需求,性能需求,环境需求和用户界面需求。

另外还有系统的可靠性,安全性,可移植性和可维护性等方面的需求。

双方在讨论这些需求内容时一般通过双方交流,调查研究来获取,并达到共同的理解。

2.导出软件的逻辑模型分析人员根据前面获取的需求资料,要进行一致性的分析检查,在分析,综合中逐步细化软件功能,划分成各个子功能。

同时对数据域进行理解,并分配到各个子功能上,以确定系统的构成及主要成分。

最后要用图文结合的形式,建立起新系统的逻辑模型。

3.编写文档通过分析确定了系统必须具备的功能和性能,定义了系统中的数据,描述了数据处理的主要算法。

应该把分析的结果用正式的文件(“需求规格说明书”)记录下来,作为最终软件的部分材料。

4.1.4结构化的分析方法在结构化方法的发展历程上,它是随着结构化程序设计(Structured Programming,简称SP)方法的提出、结构化设计和结构化程序设计。

它也是一种实用的软件开发方法。

在应用这种方法中,根据某种原理,应用一定的工具,按照特定步骤工作的软件开发方法。

它遵循的原理是自顶向下、逐步求精,使用的工具有数据流图(DFD)、数据字典、判定表、判定树和结构化语言等。

4.1.5结构化分析的步骤1.建立现行系统的物理模型通过了解现行系统的工作过程,对现行系统的详细调查,收集资料。

将看到的、听到的、收集到的信息和情况使用图形或文字描述出来。

也就是用一个模型来反映自己对现行系统的理解,如画系统流程图(后面介绍)。

这一模型包含了许多具体因素,反映现实世界的实际情况。

2.抽象出现行系统的逻辑模型要构造新的逻辑模型就要去掉物理模型中的非本质的因素(如物理因素),抽取出本质的因素。

所谓本质的因素是系统固有的、不依赖环境变化而变化的因素,任何实现均这样做。

非本质的因素不是固有的,随环境不同而不同,随实现不同而不同。

运用抽象原则对物理模型进行认真的分析,区别本质因素和非本质因素,去掉非本质因素,形成现行系统的逻辑模型。

这种逻辑模型反映了现行系统“做什么”的功能。

3.建立目标系统的逻辑模型有了现行系统的逻辑模型后,就将目标系统和现行系统逻辑进行分析、比较其差异,即在现行系统的基础上决定变化的范围,把那些要改变的部分找出来,将变化的部分抽象出一个加工,这个加工的外部环境及输入输出就确定了。

然后对“变化的部分”重新分解,分析人员根据自己的经验,采用自顶向下逐步求精的分析策略,逐步确定变化的部分的内部结构,从而建立目标系统的逻辑模型。

4.进一步补充和优化目标系统的逻辑模型只是一个主体,为了完整地描述目标系统,还要做一些补充。

补充的内容包括它所处的应用环境及它与外界环境的相互联系;说明目标系统的人机界面;说明至今尚未详细考虑的环节。

如出错处理、输入输出格式、存储容量和响应时间等性能要求与限制。

4.1.6数据流图数据流图(Data Flow Diagram,简称DFD)是结构化分析的最基本的工具。

数据流图描述系统的分解,即描述系统由哪几部分组成,各部分间有什么联系等。

它以图形的方式描绘数据在系统中流动和处理的过程。

由于它只反映系统必须完成的逻辑功能,所以它是一种功能模型。

数据由数据流、加工、数据存储、数据源点或终点四种基本成分组成。

(1)数据流。

数据流是数据在系统内传播的路径,由一组成分固定的数据项组成。

除了与数据存储间的数据流不用命名外,数据流应该用名词或名词短语命名。

(2)加工。

加工也称为数据处理,数据处理也称为变换,是对数据进行处理的单元。

(3)数据存储。

数据存储为数据处理提供数据处理所需要的输入流或为数据处理的输出数据流提供储存“仓库”。

数据存储指暂时保存的数据,它可以是数据库文件或任何形式的数据组织。

(4)数据源点和终点。

数据源点和终点是软件系统外部环境中的实体(包括人员、组织或其他软件系统),统称外部实体。

它们是为了帮助理解系统界面而引入的,一般只出现在数据流图的顶层图中,表示了系统中数据的来源和去处。

有时为了表达较为复杂的问题的数据处理过程,用一张数据流图是不够的。

要按照问题的层次结构进行逐步分解,并以一套分层的数据流图反映这种结构关系。

4.1.7数据字典数据字典(Data Dictionary,简称DD)是用于数据的信息的集合,是对数据流图中包含的所有元素的定义的集合。

它定义了数据流图中的数据各加工。

它是数据流条目、数据存储条目、数据项条目和基本加工条目的汇集。

数据字典用来定义数据流图中的各个成分的具体一致的定义和详细的描述。

它和数据流图共同构成了系统的逻辑模型,是“需求说明书”的主要组成部分。

数据字典有以下4类条目:数据流、数据项、数据存储及基本加工。

其中数据项是组成数据流和数据存储的最小元素。

数据流图中的源点、终点不在系统之内,故一般不在数据字典中说明。

4.1.8加工逻辑的描述描述加工逻辑一般用以下三种工具:结构化语言、判定表、判定树。

(1)结构化语言。

结构化语言介于自然语言和形式化语言之间的一种类自然语言。

结构化语言语法结构包括内外两层。

内部语法则比较灵活,可以使用数据字典中定义过的词汇、易于理解的一些名词、运算符和关系符,可以使用数据字典中定义过的词汇、易于理解的一些名词、运算符和关系符;外层语法具有较固定的格式,设定一组符号如IF、THEN、ELSE、DO WHILE…ENDWHILE、DO CASS…ENDASS等,用于描述顺序、选择和重复的控制结构。

(2)判定表。

判定表也是在设计中常用的技术。

在有些情况下,数据流图中的某个加工的一组动作依赖于多个逻辑条件的取值。

这时,用自然语言或结构化语言都不易清楚的描述出来,而用判定表就能够清楚的表示复杂的条件组合与应做的动作之间的对应关系判定表(Decision Table)是判定树表格形式,包括四部分:条件定义、条件组合、动作定义和条件组合下的动作。

判定表的结构如图4-1所示。

条件定义条件组合动作定义条件组合下的动作图4-1(3)判定树。

判定树是判定表的变形,一般情况下它比判定表更直观,且易于理解和使用。

上述三种描述加工逻辑的工具各有优缺点,对于顺序执行和循环执行的动作,用结构化语言描述;对于存在多个条件复杂组合的判定问题,用判定表和判定树。

判定树较判定表直观易读,判定表进行逻辑验证较严格,能把所有的可能性全部都考虑到。

可将两种工具结合起来,先用判定表做底稿,在此基础上产生判定树。

4.1.9 IDEF 方法IDEF方法是用于进行复杂系统分析和设计的方法,是在结构化分析与设计技术的基础上提出来的。

它在集成化的计算机辅助制造的工程项目中特别有效。

IDEF是ICAM Definitiond 的缩写。

IDEF方法分为三部分:(1)IDEF0:由于集成化的计算机辅助制造项目中,系统分析与设计的重点是活动与联系。

因此这种方法用来描述系统的功能活动及其联系,建立系统的功能模型。

(2)IDEF1:在集成化的计算机辅助制造项目中,信息的活动与联系也是分析与设计的重点。

所以它用来描述系统的信息及其联系,建立系统的信息模型。

(3)IDEF2:用来进行系统模拟,建立系统的动态模型。

系统的IDEF0功能模型的分析方法,反映系统“做什么”的功能。

用IDEF0方法建立功能模型的基本方法有4步:(1)确立建模的范围、观点及目的。

(2)建立系统的内外关系图——A-0图。

该图用来抽象地描述所研究的问题及其边界或数据接口。

(3)建立顶层图——A0图。

把A-0图分解为3~6个主要部分便得到A0图,它清楚地表达了A-0图在同样信息范围内的细节。

(4)建立低层次的图形。

按照自顶向下的方法,从A0图开始逐层分解,建立一系列的活动图形,直到最低层为止。

4.2单元练习4.1.2填空题1.需要分析的基本任务是要准确的定义_____,为了满足用户的需要,回答系统必须____的问题。

2.在需求分析阶段,首先进行问题识别,即双方确定对问题的综合需求,这些需求包括:____、____、_____、_____。

另外还有可靠性、安全性、保密性、可维护性等方面的需求。

3.数据流图有四个基本成分:_________、_________、_________、_________。

4.在进行可行性研究和计划以后,如果确认开发一个新的软件系统是必要的而且是可能的,那么就进入_________阶段。

5.数据字典中的加工逻辑主要描述该加工的_________,即实现加工的策略,而不是实现加工的细节,它描述如何把输入数据流变量变换为输出数据流的_________。

6.需求分析是指,开发人员要准确理解_________,进行细致的_________,将用户非形式的需求陈述转化为_________,再由_________转换到相应的形式功能规约(需求规格说明)的过程。

相关文档
最新文档