软件工程中的各种图例
软件工程复习(数据流图与ER图)
通不过时出纳员告知的"检查出的问题"、通过检验后的"取款信息"、" 付款通知"、付给储户的"现款"以及日历提供的"提款时间信息"
2
例1:数据流E1 帐卡检验出的问题 Nhomakorabea1
检验
E2 存折
储户
存折 现款
存折 取款单
3
付款
取款信息
2
登录
付款通知
日历
3
例2：数据流
• （10）请根据下列需求，画出“教育基金会的捐助 资金管理系统”的最终数据流程图。
• 现需研制一个“教育基金会的捐助资金管理系统”。 请用数据流图的方法进行分析和建模，要求如下：
例5 E-R图
• 某公司拟开发一多用户电子邮件客户端系统，部分功能的初步需求分析结果 如下：
• （1）邮件客户端系统支持多个用户，用户信息主要包括用户名和用户密码， 且系统中的用户名不可重复。
• （2）邮件帐号信息包括邮件地址及其相应的密码，一个用户可以拥有多个 邮件地址 （如userl＠）。
• ⑴由捐助者向基金会提出捐助请求，经身份确认后 被接受，对捐助人进行登记并授予捐助证书，捐款 存入银行。
• ⑵由教育单位提出用款申请，在进行相应的合法性 校验和核对相应的捐款储备后做出支出。
• ⑶每月给基金会的理事会一份财政状况报表，列出 本月的收入、支出情况和资金余额。
软件工程各种图的画法考试必备
1 •完成患者监护系统功能级的数据流图、实体联系图、软件结构图★fl--.1riB.w3.2总体结构和模块外部设讣软件结构图2 •网上书店系统，其外部用户主要有游客、会员和管理员。
其中，游客进行注 册后，可以成为系统的会员，会员享有订购图书及订单和书籍等信息查询的功能， 管理员可对系统的各种信息进行管理和维护。
根据上述描述，请画出网上书店系. 统的：①基本系统模型（第0层）；②功能级的数据流图（第1层）；③底层的订 购图书数据流图。
*血見汕幼悄般的致峯編11〔和|八『！ W打印病措报告Fht-'i发出警报 分析信号更新日志定时获取 土理信息惠者生理信息 憲者监护系统监护处理 输出信息安佥范国基本鬲嫌横! y 1第眼）——、 \ \ \ \ \ \— r游需「——4甘T.—■1 55 世哙: 管理------------------------ :■:----------------------I n —IJ 尸尸|... —-------------------------- : --------------------------1 •把如下统计空格程序的Jackson 图改画为等价的程序流程图和盒图2、用Jackson 图描述下述的一列火车的构成：一列火车最多有两个火车头。
只有一个火车头时则位于列车最前面，若还有第二 个火车头时，则第二个火车头位于列车的最后面。
火车头既可以是内燃机车也可 以是电气机车。
车厢分为硬座车厢、硬卧车厢和软卧车厢等 3种。
硬座车厢… 在所有车厢的前面部分，软卧车厢在所有车厢的后面部分。
此外，在硬卧车厢和 软卧车厢之间还有一节餐车。
火乍F 刖 车头1.饮用水自动销售系统的工作过程大致如下：如果投入 1元硬币，则自动放水艾件不是文件屋。
慷一个宇符串 换行’输岀字符串，换行统计空格数并输岀 取下一个宇符串 按行，输岀空格总数ft*电“燃气一节"硬肪盒團（N~S 團）5升；如果投入5角硬币，放水2.5升；如果选择1元，投入2个伍角的硬币，也可放水5升。
软件工程各种图结构
调用模块 A,B,C
2. 结构图的绘制 • 学生成绩管理系统的结构图
概要设计方法
结构化方法 • 结构化方法又称面向数据流设计方法(Structured
Design，SD)。 • 设计步骤是先根据系统数据流图建立系统逻辑模型，
再进行结构设计。 1. 建立系统逻辑模型 （１）变换型数据流 （２）事务型数据流
如： 成绩单＝学号＋姓名＋1{课程名＋成绩}3
• 也可写为 成绩单＝学号＋姓名＋ {课程名＋成绩}
数据字典与图形工具
• 数据字典与图形工具应相辅相成、互相配 合，既要互相补充又要避免冗余。
• 系统分析员在编写数据字典和使用图形工 具时应遵守一些约定
需求分析举例
•
概要设计
软件结构设计的图形工具
盒图 盒图是Nassi和Shneiderman提出的，又称N_S图。
1. 盒图的符号
将下述含有GOTO语句的用程序流程图，改为N_S图。
学生成绩管理系统的 N-S 图。
PAD 图
基本符号
学生成绩管理系统的 PAD 图
判定表
1. 判定表的组成 • 左上部列出所有条件。 • 左下部列出所有可能做的工作。 • 右上部每一列表示各种条件的一种可能组合，所有列
画出学生成绩管理 系统的 IPO 图。
数据字典
• 数据字典(Data Dictionary ，DD) 是对实体-关系图、状态转换图和数据流图中出现的 所有数据对象、属性、关系、状态、数据流、文件、 处理等元素的定义的集合。
数据字典的内容 • １. 数据元素 • ２. 数据流 • ３. 数据存储 • ４. 数据处理
数据代码设计
软件工程,论文 用例图 需求分析 项目流程图 实例图 RE图 属性图讲解
药品管理系统1.简要这次是C#考试答辩程序改写有不足望老师见谅:经过市场调研，初步了解到药品销售管理系统在现实生活中的应用，现行的医药管理系统在现实中的应用主要是药品的收费管理和药品销售的账目管理，药品的库房管理（药品的进库，药品的出库）其中，最常用的是，销售管理和库房管理。
此系统操作性相对简单，只要对电脑有一定操作基础的人员都可以使用，系统对用户的提示性较好，可以提醒和引导用户对系统的操作。
本课题通过对现行医药管理信息系统的组织结构，业务流程，数据库等进行研究，分析系统的实际运行情况，并提出新的逻辑设计方案，以此来完善改进现有的系统，这对于医药企业提高经营管理具有一定的积极意义。
2.简要说明本用例是一个医药超市管理系统，只有管理员和销售员有管理权限，其中管理员和销售员可以对自己的密码进行修改。
用用自己的管理账号对医药进行管理，进货销售等等。
3需求3.1医药销售管理系统需求分析以往到药店购买药品的时候，销售人员都要手写单据和人工结账，而且每天都要统计当日的销售额，月末要统计一个月的销售额，所以要管理大量的单据，而且在统计的时候需要大量的时间，并且是人工操作，比较容易出错。
医药管理系统的出现，使得这一切变得简单起来。
以往需要算一个小时的账目现在只需点一下鼠标就可以得到，而且得到的结果还是精确的，不用担心有错误，用电脑代替人脑计算，为使用者节省了大量时间。
另外消费者也得到了便利，因为键盘录入取代了手写的单据增加了效率，在我们购买药品的时候也就方便了起来。
信息管理系统的出现，改变了企业的管理模式，药品销售管理系统则改变了医药行业的管理模式。
在当今医药行业，一套好的销售管理系统成为众多企业的得力助手。
3.2 医药销售管理系统数据库医药销售管理系统是基于网络应用，根据医药销售系统的长期开发研究经验和各医药公司现实中存在的实际业务情况，完全采取面向对象的系统开发方法，进行严格设计而成的专业医药销售管理软件。
软件工程用例图
第5页/共27页
用例图的构成要素
2. 参与者间的关系
• 由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主 要是泛化关系（或称为“继承”关系）。
第18页/共27页
使用Rose创建用例的步骤说明
2. 识别参与者
• 对于一个学校来说，最重要的就是教育学生成才，所以我们首先要考虑到的参与者就是 学生。
• 要给学生上课，必然就需要教师。教师负责教育学生、并且在日常管理中可以查询学生 的基本信息、查询学生的考试成绩。
• 作为一个学校，除了教师和学生，还有不可或缺的就是校领导。为了便于校领导掌握学 校的基本情况，加强对学校的管理导.
改教学心得。 (3)系统管理员负责对网站页面的维护，审核不法课件和不法教学信息，批准用户注册。
第24页/共27页
练习题
（1）学生需要登录“远程网络教学系统”后才能正常使用该系统所有 功能。如果忘记密码，可以通过“找回密码”功能找回密码。登录 后学生可以浏览课件、查找课件、下载课件、观看教学视频，请画 出学生参与者的用例图。
第20页/共27页
使用Rose创建用例的步骤说明
• 教师参与用例录入 成绩、修改成绩、 保存成绩、查询成 绩、删除成绩和登 录。学生参与用例 登录和查询成绩。 因为修改成绩和录 入成绩的时候都要 保存成绩，所以将 保存成绩抽象出来 作为单独的一个用 例。用例录入成绩、 修改成绩和用例保 存成绩之间是包含 关系，用例找回密 码和用例登录之间 是扩展关系。
• 系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使 用系统边界进行区分开来。我们把系统边界以外的同系统相关联的其他部分，称之为系统环境。
软件工程---UML动态分析-活动图
Make Plan
entry/ SetGoal
2020/5/4
26
动作流
与状态图不同，活动图的转换一般都不需要特 定事件的触发。
一个动作状态执行完本状态需要完成的动作后 会自发转换到另外一个状态。
2020/5/4
27
动作流
一个活动图有很多动作或者活动状态，
活动图通常开始于初始状态，然后自动转换到 活动图的第一个动作状态，一旦该状态的动作 完成后，控制就会不加延迟地转换到下一个动 作状态或者活动状态。
7
活动图与流程图的区别
⑴ 流程图着重描述处理过程，它
的主要控制结构是顺序、分支 和循环，各个处理过程之间有 严格的顺序和时间关系
找饮料 [ 发现咖啡 ]
活动图描述的是对象活动的顺序
把咖啡放入 滤器
关系所遵循的规则，它着重表 将滤器放入 现的是系统的行为，而非系统 机器
的处理过程。
往容器里加 水
开机器
活动图着重表现从一个活动到另一个活动的控制流， 是内部处理驱动的流程。
找饮料
[ 发现咖啡 ]
[ 没有咖啡 ] [ 发现可乐 ]
把咖啡放入 滤器
往容器里加 水
拿茶杯
拿可乐
将滤器放入 机器
[ 没有可乐 ]
开机器 冲咖啡
倒咖啡
喝饮料
2020/5/4
12
活动的图形表示
在UML中，活动表示成圆角矩形，与状态的圆角矩 形相比，活动的矩形的圆角更柔和，看上去接近椭 圆。
不能中断，一直运行到结束。 ⑶ 动作状态是瞬时的行为，它所占用的处理时
间极短，有时其至可以忽略。
2020/5/4
19
动作状态
动作状态有如下特点：
软件工程---状态图
语法形式： exit/动作名
3.内部转移---Do动作（do action），用于标 记内部活动，用来指定处于该状态时执行的 动作。 语法形式： do/动作名
内部转移不会改变对象的状态，内部转移在 入口动作执行完毕后开始执行。
4. 还可以添加其他事件和动作
event用来指定当特定事件触发时发生指定动 作，但此事件不会激发状态的改变，属于内部 活动。
（2）中间状态----由一个带圆角的矩形表示。
内部活动
注意：由于入口动作和
与状态相关的动作
出口动作是隐式地激活， 因此它们既没有参数也
在一个状态中允许有多个动作。没有守卫条件。
1.入口动作 （entry action），用来指定进入状态时
发生的动作。
语法形式： entry/动作名 2.出口动作（exit action），用来指定离开该状态时
状态图
状态和状态图 状态图的组成 转换的种类 状态图建模技术
用例图（功能模型）： 从用户的角度描述系统能提供哪些功能。
• 结构模型视图（静态）： 类图：描述系统的静态结构； 对 象图：描述系统在某个时刻的静态结构； 包图：将类分组成更高层次的静态结构。
• 行为模型视图（动态） 顺序图：按时间顺序描述系统元素之间的交互； 协作图：从时间和空间的顺序描述系统元素之间的交互； 状态图：描述系统元素对事件的响应引起的状态转换； 活动图：描述系统元素的活动。
图 带有历史指示器的软件安装过程状态图
2.2 转换（转移）
转换用带箭头的直线表示，一端连接源状态即转 出的状态，箭头一端连接目标状态即转入的状态。
转移连接了源状态和目标状态。但需要各种条件 才能激活转移。这些条件包括事件、监护条件和 动作。
软件工程课件之第4章用例和用例图
4.2.3 泛化关系
借阅者
.9 泛化关系
4.2.4 分组关系
在一些用例图中，用例的数目可能很多，这时就需要把 这些用例组织起来。这种情况在一个系统包含很多子系 统时就会出现。另一种可能就是，当你按顺序和用户会 谈，收集系统需求时，每个需求必须用一个单独的用例 来表达，这时就需要某种方式来对这些需求进行分类。
4.1.1 参与者
例如，在“图书管理系统”中，可以认为“读者”是 “学生读者”和“教师读者”的泛化，而“学生读者” 还可以具体化为“本科生读者”和“研究生读者”；同 样，“图书管理员”也是“采购员”、“ 编目员”及 “借阅人员”的泛化。图4.3表示出了参与者之间的泛 化关系。
4.1.1 参与者
“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
4.2.2 扩展关系
借阅者
<<include>>
还书
<<extend>>
查询图书 交罚款
图4.8 扩展关系
区别与联系：
联系：都是从现有的用例中抽取出公共的那部分信息
，作为一个单独的用例，然后通过不同的方法来重用这 个公共的用例，以减少模型维护的工作量。
因此，在“图书管理系统”中“借阅者”和“系统管理 员”都是参与者。
4.1.1 参与者
【例4-1】客户给销售员发来传真订货， 销售员下班前 将当日订货单汇总输入系统。谁是系统的参与者？
分析：根据参与者的定义可知，此系统的参与者是销售 员。
4.1.1 参与者
【例4-2】在需求分析中常见的权限控制问题，一般的 用户只可以使用一些常规的操作，如查询等，而管理员 除了常规操作之外还需要进行一些系统管理工作，如一 些关键数据的增加、删除、修改等，操作员既可以进行 常规操作又可以进行一些配置操作。
《软件工程》第3章用例图及其应用
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
UML各种图总结-精华
UML各种图总结-精华UML（UnifiedModelingLanguage）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。
一、基本概念如下图所示，UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。
静态图分为：用例图，类图，对象图，包图，构件图，部署图。
动态图分为：状态图，活动图，协作图，序列图。
1、用例图（UseCaseDiagrams）：用例图主要回答了两个问题：1、是谁用软件。
2、软件的功能。
从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。
2、类图（ClassDiagrams）：用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。
在UML类图中，常见的有以下几种关系:泛化（Generalization）,实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。
各种关系的强弱顺序：泛化=实现>组合>聚合>关联>依赖2.1.泛化【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。
例如：老虎是动物的一种，即有老虎的特性也有动物的共性。
2.2.实现【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。
2.3.关联【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。
双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量2.4.聚合【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
软件工程-e-r图
软件工程-e-r图软件工程中的 ER 图在软件工程领域，ER 图（EntityRelationship Diagram，实体关系图）是一种极其重要的工具，它用于对系统中的数据进行建模和可视化表示。
对于软件开发人员来说，理解和掌握 ER 图的绘制与应用是至关重要的。
ER 图的核心元素包括实体、属性和关系。
实体可以看作是系统中需要关注和处理的对象，比如在一个学生管理系统中，“学生”和“课程”就是两个实体。
属性则是用来描述实体的特征，比如“学生”实体可能具有“学号”“姓名”“年龄”等属性。
而关系则反映了不同实体之间的关联，常见的关系类型有一对一、一对多和多对多。
以一个图书馆管理系统为例，“图书”和“读者”是两个重要的实体。
“图书”实体可能具有“书号”“书名”“作者”“出版年份”等属性；“读者”实体可能有“读者编号”“姓名”“联系方式”等属性。
它们之间存在着各种关系，比如“读者”与“图书”之间是多对多的关系，因为一个读者可以借阅多本图书，而一本图书也可以被多个读者借阅。
绘制 ER 图时，通常使用矩形表示实体，椭圆表示属性，菱形表示关系。
通过线条将这些元素连接起来，并在关系线上标注关系的类型和约束条件。
清晰准确的 ER 图能够帮助开发人员更好地理解系统的数据结构和业务逻辑，从而为后续的数据库设计和软件开发提供坚实的基础。
ER 图在软件工程中的作用不可小觑。
首先，它有助于在系统设计的早期阶段明确系统的数据需求。
通过与相关人员（如用户、业务分析师等）的沟通和交流，绘制出反映实际业务情况的 ER 图，可以避免在开发过程中因为数据理解不一致而导致的错误和返工。
其次，ER 图为数据库设计提供了直观的蓝图。
根据 ER 图，可以确定数据库中的表结构、字段类型、主键和外键等。
这样能够确保数据库的设计合理、高效，满足系统的数据存储和查询需求。
再者，ER 图便于团队成员之间的沟通和协作。
不同背景的人员（如开发人员、测试人员、项目经理等）都可以通过查看 ER 图快速了解系统的数据模型，从而更好地协同工作，提高开发效率。
软件工程-论文-用例图-需求分析-项目流程图--实例图---RE图--属性图
药品管理系统1。
简要这次是C＃考试答辩程序改写有不足望老师见谅：经过市场调研，初步了解到药品销售管理系统在现实生活中的应用，现行的医药管理系统在现实中的应用主要是药品的收费管理和药品销售的账目管理,药品的库房管理（药品的进库，药品的出库）其中，最常用的是，销售管理和库房管理。
此系统操作性相对简单，只要对电脑有一定操作基础的人员都可以使用，系统对用户的提示性较好，可以提醒和引导用户对系统的操作。
本课题通过对现行医药管理信息系统的组织结构，业务流程,数据库等进行研究,分析系统的实际运行情况，并提出新的逻辑设计方案，以此来完善改进现有的系统，这对于医药企业提高经营管理具有一定的积极意义.2.简要说明本用例是一个医药超市管理系统，只有管理员和销售员有管理权限，其中管理员和销售员可以对自己的密码进行修改。
用用自己的管理账号对医药进行管理，进货销售等等.3需求3。
1医药销售管理系统需求分析以往到药店购买药品的时候，销售人员都要手写单据和人工结账，而且每天都要统计当日的销售额，月末要统计一个月的销售额,所以要管理大量的单据，而且在统计的时候需要大量的时间，并且是人工操作，比较容易出错。
医药管理系统的出现，使得这一切变得简单起来。
以往需要算一个小时的账目现在只需点一下鼠标就可以得到，而且得到的结果还是精确的，不用担心有错误，用电脑代替人脑计算,为使用者节省了大量时间。
另外消费者也得到了便利，因为键盘录入取代了手写的单据增加了效率,在我们购买药品的时候也就方便了起来.信息管理系统的出现,改变了企业的管理模式，药品销售管理系统则改变了医药行业的管理模式。
在当今医药行业，一套好的销售管理系统成为众多企业的得力助手。
3。
2 医药销售管理系统数据库医药销售管理系统是基于网络应用,根据医药销售系统的长期开发研究经验和各医药公司现实中存在的实际业务情况,完全采取面向对象的系统开发方法,进行严格设计而成的专业医药销售管理软件。
软件工程之数据流图实例
第十四页,共三十一页。
质量(zhìliàng)管理子系统---装配检测
后续动作动作：对产品做检测 报表：18装配(zhu与āng产pèi品)检相测关记录
来源(láiyuán)还有待于后续的文档？
第十五页,共三十一页。
生产管理子系统---生产方案(jìhuà)汇 总
后续动作(dòngzuò)动作(dòngzuò)：生产
方案进度汇总 报表：11与生生产产方方案案有进关度汇总表
与库存有关
根据生产(shēngchǎn)方案进行汇总
根据库存汇总
第十六页,共三十一页。
生产(shēngchǎn)管理子系统---配件加工
后续动作动作：产品所需配件的加工情况 报表：12车间(chējiān)加工配件清单
总体流程的分析,将各个数据、动作串起来 (qǐ lái)
确定每一个动作要完成,需要哪些前序条件, 哪些数据〔文件〕,谁操作,生成什么文件
画出顶层数据流图 进一步精化,画下一层数据流图 分析数据间关系,画E-R图
第五页,共三十一页。
总体流程 的分析 (liúchéng)
目的：将各个数据、动作串起来 原则：抓大放小 方法：
2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四2021年11月25日星期四读命令复印重加载纸诊断问题闲置与读命令相关非卡纸与读命令相关卡纸与完成问题相关满和开始与复印相关复印与读命令相关与读命令相关28
软件工程-第15章第3节图文模板
版本 1.1.1
版本 1.1.2
4
5
15.3.3 版本控制
软件工程过程中某一阶段的变更，均要引起软件配 置的变更，这种变更必须严格加以控制和管理，保 持修改信息，并把精确、清晰的信息传递到软件工 程过程的下一步骤。 变更控制包括建立控制点和建立报告与审查制度。 对于一个大型软件来说，不加控制的变更很快就会 引起混乱。因此变更控制是一项最重要的软件配置 任务，变更控制的过程如图15.8所示。其中“检出”
15.3.2 软件配置项
(9) 数据库描述(模式和文件结构、初始内容)。 (10) 用户手册。 (11) 维护文档(软件问题报告、维护请求和工程 变更次序)。 (12) 软件工程标准。 (13) 项目开发小结。 此外，许多软件工程组织把配置控制之下的软件
15.3.3 版本控制
软件配置实际上是一动态的概念，它一方面随着软 件生存期向前推进，SCI的数量在不断增多，一些 文档经过转换生成另一些文档，并产生一些信息； 另一方面又随时会有新的变更出现，形成新的版本。 系统不同版本的一种表示如图15.7所示，在这个版 本演变图中各个结点是一个完全的软件版本。软件 的每一个版本都是SCI(源代码、文档及数据)的一 个收集，且各个版本都可能由不同的变种组成。
15.3.3 版本控制
图的右边具体说明一个简单的程序版本：它由1，
2，3，4和5版本使用单色显示器
版本
版本
时使版本用。版本因此版，本 可以1.3 定义1.4版本的两个变种1 。
1.0
1.1
1.2
版本
版本
2
3
此演变图显示了
2.0
2.1
变种
软件的修改情况
15.3.1 基线
系统工程 需求分析 软件设计 程序编写
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
我们通常都是对图形化的东西情有独钟，我们小时候的启蒙教育基本上也都是从图形化开始的，我们曾经看过的连环画、漫画、看图识字等等。
因为图形能将一个抽象的东西具体化、形象化，图形化的表述能将一个用文字语言无法表达清楚或很难表达的观点、事物、科学概念等清晰的呈现出来。
这就是为什么我们相比晦涩难懂文字更喜欢形象生动的图形的原因。
软件工程导论作为软件工程中非常重要的一门课程，通常因为其偏文科性、理论性、概念性而得不到人们的重视，但幸运的是在软件工程导论中有我们非常易于接受、理解的东西——图，否则我们自己会把自己害得很惨（软件工程导论真的很重要哦！）。
软件工程导论中一般把软件的开发分为八个阶段：１.问题定义２.可行性研究３.需求分析４.总体设计（概要设计）５.详细设计６.编码和单元测试７.综合测试８.软件维护。
下面我们就说说各个阶段中与图的难解难分。
１.问题定义
问题定义阶段主要是根据用户的需求来定义用户需要解决的问题，用户要实现哪些功
能。
２.可行性研究
可行性研究阶段就是看是否有一种使其在最小的代价，尽可能短的时间内，利益最大化的情况下解决问题的方案。
这个阶段的分析主要涉及以下几个图形工具。
2.1系统流程图
系统流程图是描述系统物理模型的一种传统工具。
它是表达数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。
系统流程图形象的呈现了软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。
2.2数据流图
数据流图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
如果说系统流程图能让用户更好的明白系统的功能，那么数据流图则让用户更加明白系统的工作原理。
2.3数据字典
数据字典就是数据的信息的集合，也可以说就是对上面提到的数据流图中的所有元素的定义的集合。
数据字典的主要作用就是在软件的分析与设计阶段方便我们查阅不甚了解的数据的描述信息。
３.需求分析
需求分析阶段主要确定系统必须做什么。
比如用户对系统的要求，确定目标系统所有的功能，确定系统运行的硬件和软件环境，系统性能要求，出错处理要求，接口需求,验证软件需求等等。
3.1E-r图
E-r图的主要作用就是把用户的数据要求用可视化的图形呈现出来。
3.2状态转换图
状态转换图说白了就是系统的行为建模，就是通过描述系统的状态以及引起状态变化的事件来表示系统的行为，将系统运行时详细的状态变化呈现给用户。
3.3层次方框图
层次方框图像用户呈现的是数据的层次结构。
3.4Warnier图
Warnier图的作用和层次方框图的作用基本相同，只不过Warnier图的描述手段更多。
3.5IPO图
IPO图是输入、处理和输出图的简称，它清楚的描述了输入数据、处理数据、输出数据之间的关系。
４.总体设计
需求分析阶段已经确定了系统要做什么的问题，而总体设计就是要弄明白怎么做的问题，总体设计的目的就是从宏观上概括的说系统应该怎样实现，具体一点就是要明确系统有哪些模块组成，以及这些模块之间的关系是怎样的。
4.1层次图
层次图是用来描述软件的层次结构的。
4.2HIPO图
HIPO图 = 层次图+输入+处理+输出
4.3结构图
结构图和层次图类似，都是描述软件结构的图形工具。
５.详细设计
详细设计阶段就是在总体设计的基础上要确定怎样具体的详细的实现系统所要求的功能，要对系统进行精确的描述。
5.1程序流程图
程序流程图是对程序控制流程的直观描述。
5.2盒图
出于要有种不允许违背结构设计精神图形工具考虑Nassi和shneiderman提出了盒图又称为N—S图。
5.3问题分析PAD图
PAD图就是用二维树形结构图来表示程序的控制流。
６.编码和单元测试
编码和单元测试阶段主要是对详细设计阶段的详细描述给以具体的实现和模块的测试。
７.综合测试
综合测试包括对系统的各个组件和功能的测试，要求覆盖软件系统的各个功能点，并根据被测软件的需求测试软件的性能、易用性等方面的内容，达到对软件全方面测试的目的。
８.软件维护
软件维护阶段是软件生命周期中最后的一个阶段，也是最长的一个阶段，软件维护主要任务是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改，修改时应充分利用源程序。
修改后要填写程序改登记表，并在程序变更通知书上写明新旧程序的不同之处。