1.过程模型：
瀑布模型
描述：
按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
适用情形：
需求是预知的；
软件实现方法是成熟的；
项目周期较短。
优点：
可使开发人员采用规范的方法；
严格地规定了每个阶段必须提交的文档；
要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
缺点：
只能通过文档了解产品，不经过实践的需求是不切实际的。
快速原型模型
描述：
是快速建立起来的可以在计算机上运行的程序，它所能完成的功能是最终产品能完成的功能的一个子集。
适用情形：
需求多变
陌生领域产品开发
优点：
克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
这种模型适合预先不能确切定义需求的软件系统的开发。
缺点：
所选用的开发技术和工具不一定符合主流的发展；
快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。
增量(渐增)模型
描述：
把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
适用情形：
适用于需求经常改变的软件开发过程。
如果在项目既定的商业要求期限之前不可能找到足够的开发人员，在这种情况下，增量模型显得特别有用。
优点：
人员分配灵活，刚开始不用投入大量人力资源，先推出核心产品。
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品。
缺点：
软件体系结构必须是开放的。
模型本身是自相矛盾的。整体——独立构件。
不同的构件并行地构建有可能加快工程进度，但可能有无法集成到一起的风险。
螺旋模型
描述：
使用原型及其他方法来尽量降低风险。把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。
适用情形：
特别适用于庞大、复杂并具有高风险的系统。
适用于内部开发的大规模软件项目。
优点：
主要优势在于它是风险驱动的。
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；
减少了过多测试或测试不足所带来的风险；
缺点：
采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
过多的迭代次数会增加开发成本，延迟提交时间。
喷泉模型
描述：
是典型的面向对象生命周期模型。 “喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。为避免使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程(例如，快速原型模型或图中的中心垂线)作为总目标。
适用情形：
适用于面向对象的软件开发过程。
优点：
该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。
多次反复地增加或明确目标系统，而不是本质性的改动，降低错误的可能性。
缺点：
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不利于项目的管理。
要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
案例
例1：要开发某个突破性的产品，规模很大，所需的开发技术先进，风险较大，且市面上尚未有类似产品，用户尚未对其形成完整的预期，团队人员充足。
答案：螺旋模型
在这个例子中，由于要开发的是一个突破性的产品，规模很大，所需的开发技术先进，风险较大，且市面上尚未有类似产品，用户尚未对其形成完整的预期，因此螺旋模型的风险驱动特性非常适合这种情况。在每个螺旋周期中，团队可以不断对需求和风险进行分析，并通过迭代的方式逐步完善产品。
例2：要开发的系统类似于某个团队之前已经做过的某个项目，只是规模更大复杂性高一点，需求已经有用户写成文档。
答案：瀑布模型
由于当前项目的需求已经以文档形式存在，且项目与之前的项目类似（只是规模更大、复杂性更高），因此可以认为项目的需求是预知的，并且可能已经有成熟的软件实现方法可以参考。选择瀑布模型（Waterfall Model）是合理的。
例3：辅导员张老师 为了方便管理学生，他委托学生小明帮助他开发一个学生管理系统，用来管理他所带的班级的学生信息，该系统仅供张老师一个人使用，系统功能不是很复杂。张老师对自己需要的系统功能有了明确的认识，并且他本身也对软件开发有一定程度的了解，与小明的沟通过程非常的顺利。在这种情况下，如果你是小明，你会选用哪种过程模型？
答案：瀑布模型
由于张老师对系统功能有了明确的认识，且本身对软件开发有一定程度的了解，与小明的沟通也非常顺利，因此选用瀑布模型（Waterfall Model）是合适的。同时对于张老师的学生管理系统来说，由于需求明确且项目规模不大，瀑布模型可以确保开发过程的有序进行，同时降低由于需求不明确或频繁变更带来的风险。张老师和学生小明之间的沟通顺畅也保证了需求分析的准确性和完整性，从而进一步增强了瀑布模型在该项目中的适用性。
例4：张扬是某大学软件技术专业的学生，在寒假中，他为他的邻居开发了一个小型的超市管理系统。他的邻居从来不懂软件开发，也不知道超市管理系统应该是什么样的。那么你建议张扬采用哪种过程模型呢 ？
答案：快速原型模型
因为邻居不懂软件开发，对超市管理系统的需求可能不明确或者会在开发过程中有所变化。快速原型模型允许开发人员快速创建一个可以运行的系统原型，这样邻居可以直接看到并操作这个系统，从而更容易地提供反馈，明确或调整需求。
例5：假设要求你开发一个软件，该软件的功能是读入的浮点数开平方，所得到的结果应该精确到小数点后4位。一旦实现并测试完之后，该产品将被抛弃。你打算选用哪种软件生命周期模型？请说明你做出选择的理由。
答案：瀑布模型
对这个软件的需求很明确，实现开平方功能的算法也很熟悉，因此，无须通过原型来分析需求也无需用原型来验证设计方案。此外，一旦实现并测试完之后，该产品将被抛弃，因此也无须使用有助于提高软件可维护性的增量模型或带风险分析的螺旋模型来开发该软件
简述可行性研究的步骤
可行性研究的步骤
明确系统的目标
分析研究现行系统
设计新系统的高层逻辑模型
获得并比较可行性的方案
写可行性研究报告
可行性研究报告大纲
在软件测试实现阶段，选择合适的开发语言很重要，请说明如何选择软件系统开发语言
项目的规模和复杂度：对于小型、简单的项目，可以选择易学易用的编程语言，如Python等；对于大型、复杂的项目，则需要选择具备高性能和可扩展性的语言，如Java、C++等。
开发团队的技术栈：开发团队的技术栈也是选择语言的重要因素，团队成员要熟练掌握所选语言的语法和特性，这有利于提高开发效率和保证软件质量。
平台和环境要求：不同的平台和环境要求可能需要使用不同的编程语言和工具，如Web应用可能需要使用JavaScript等。
技术支持和社区：在选择开发语言时，需要考虑其技术支持和社区资源是否充足，是否有活跃的开发者社区，以便及时获取相关技术支持和解决问题。
功能级数据流图
银行计算机储蓄系统的工作过程大致如下：储户填写的存款单或取款单由业务员输入系统，如果是存款则系统记录存款人姓名、住址（或电话号码）、身份证号码、存款类型、存款日期、到期日期、利息及密码（可选）等信息，并印出存单给储户；如果是取款而且取款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并打印出利息清单给储户。
- 用数据流图描绘本系统的功能
2.用e-r实体-联系图描绘系统中的数据对象。
UML用例图中泛化、实现、扩展与依赖关系
1. 泛化（Generalization）
【泛化关系】：是一种继承关系, 表示一般与特殊的关系, 它指定了子类如何特化父类的所有特征和行为. 例如：老虎是动物的一种, 即有老虎的特性也有动物的共性.
【箭头指向】：带三角箭头的实线，箭头指向父类
2. 实现（Realization）
【实现关系】：是一种类与接口的关系, 表示类是接口所有特征和行为的实现.
【箭头指向】：带三角箭头的虚线，箭头指向接口
3. 关联（Association)
【关联关系】：是一种拥有的关系, 它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子
关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量
【箭头及指向】：带普通箭头的实心线，指向被拥有者
上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。
上图为自身关联
4. 聚合（Aggregation）
【聚合关系】：是整体与部分的关系, 且部分可以离开整体而单独存在. 如车和轮胎是整体和部分的关系, 轮胎离开车仍然可以存在.
聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
【代码体现】：成员变量
【箭头及指向】：带空心菱形的实心线，菱形指向整体
5. 组合(Composition)
【组合关系】：是整体与部分的关系, 但部分不能离开整体而单独存在. 如公司和部门是整体和部分的关系, 没有公司就不存在部门.
组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期
【代码体现】：成员变量
【箭头及指向】：带实心菱形的实线，菱形指向整体
6. 依赖(Dependency)
【依赖关系】：是一种使用的关系, 即一个类的实现需要另一个类的协助, 所以要尽量不使用双向的互相依赖.
【代码表现】：局部变量、方法的参数或者对静态方法的调用
【箭头及指向】：带箭头的虚线，指向被使用者
依赖关系（Dependency）
依赖关系是一种表示两个用例之间的弱关系。它通常表示一个用例在执行过程中可能使用或影响另一个用例。依赖关系在UML用例图中通常以虚线和带箭头的线表示，箭头指向被依赖的用例。
举例
例如，在一个图书管理系统中，有一个用例“借书”，另一个用例是“检查库存”。这里，“借书”用例在执行过程中可能需要依赖“检查库存”用例，以确认所需图书的可用性。
扩展关系（Extend）
扩展关系是一种表示一个用例（扩展用例）在某些条件下扩展另一个用例（基本用例）功能的关系。这种关系通常用于表示可选的、非必须的功能。在UML用例图中，扩展关系通常以虚线和带箭头的线表示，箭头指向被扩展的基本用例。
举例
例如线购物系统，基本用例是“购买商品”，而“使用优惠券”是一个扩展用例。在某些情况下（例如用户选择使用优惠券），基本用例的流程会被扩展用例“使用优惠券”所扩展。
区分依赖和扩展
虽然依赖和扩展在表现形式上相似（都是虚线和箭头），但它们表达的意义和用途有显著差异：
依赖关系强调的是一种使用或影响关系。它表示一个用例在其执行过程中可能会用到另一个用例的功能。
扩展关系则表示在特定条件下，一个用例的行为可以被另一个用例扩展或增强。
各种关系的强弱顺序：
泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
下面这张UML图，比较形象地展示了各种类图关系：
6.耦合，内聚
耦合性
耦合性也叫块间联系，指软件系统结构中各模块间相互联系紧密程度的一种度量。
模块之间联系越紧密，其耦合性就越强，模块的独立性则越差，模块间耦合的高低取决于模块间接口的复杂性，调用的方式以及传递的信息。
内聚性
内聚性也叫块内联系，指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。内聚性是对一个模块内部各个组成元素之间相互结合的紧密程度的度量指标。
模块中组成元素结合的越紧密，模块的内聚性就越高，模块的独立性也就越高。理想的内聚性要求模块的功能应明确、单一，即一个模块只做一件事情。
耦合有以下几种，下面将耦合性由弱到强依次列出（独立性由强到弱）
（1）非直接耦合(Nondirect Coupling)
如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强。
（2）数据耦合(Data Coupling)
如果一个模块访问另一个模块时，彼此之间是通过数据参数(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的，则称这种耦合为数据耦合。由于限制了只通过参数表传递数据，按数据耦合开发的程序界面简单、安全可靠。因此，数据耦合是松散的耦合，模块之间的独立性比较强。在软件程序结构中至少必须有这类耦合。
（3）印记耦合(Stamp Coupling)
如果一组模块通过参数表传递记录信息，就是标记耦合。事实上，这组模块共享了这个记录，它是某一数据结构的子结构，而不是简单变量。这要求这些模块都必须清楚该记录的结构，并按结构要求对此记录进行操作。在设计中应尽量避免这种耦合，它使在数据结构上的操作复杂化了。如果采取“信息隐蔽”的方法，把在数据结构上的操作全部集中。
（4）控制耦合(Control Coupling)
如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。这种耦合的实质是在单一接口上选择多功能模块中的某项功能。因此，对所控制模块的任何修改，都会影响控制模块。另外，控制耦合也意味着控制模块必须知道所控制模块内部的一些逻辑关系，这些都会降低模块的独立性。
（5）外部耦合(External Coupling)
一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。例如C语言程序中各个模块都访问被说明为extern类型的外部变量。外部耦合引起的问题类似于公共耦合，区别在于在外部耦合中不存在依赖于一个数据结构内部各项的物理安排。
（6）公共耦合(Common Coupling)
若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。 这种耦合会引起下列问题：
所有公共耦合模块都与某一个公共数据环境内部各项的物理安排有关，若修改某个数据的大小，将会影响到所有的模块。
无法控制各个模块对公共数据的存取，严重影响软件模块的可靠性和适应性。
公共数据名的使用，明显降低了程序的可读性。
公共耦合的复杂程度随耦合模块的个数增加而显著增加。若只是两个模块之间有公共数据环境，则公共耦合有两种情况。
若一个模块只是往公共数据环境里传送数据，而另一个模块只是从公共数据环境中取数据，则这种公共耦合叫做松散公共耦合。若两个模块都从公共数据环境中取数据，又都向公共数据环境里送数据，则这种公共耦合叫做紧密公共耦合。只有在模块之间共享的数据很多，且通过参数表传递不方便时，才使用公共耦合。否则，还是使用模块独立性比较高的数据耦合好些。
（7）内容耦合(Content Coupling)
——耦合性最高，这是最差的设计
如果发生下列情形，两个模块之间就发生了内容耦合。
一个模块直接访问另一个模块的内部数据；
一个模块不通过正常入口转到另一模块内部；
两个模块有一部分程序代码重叠(只可能出现在汇编语言中)；
一个模块有多个入口。
在内容耦合的情形，所访问模块的任何变更，或者用不同的编译器对它再编译，
都会造成程序出错。好在大多数高级程序设计语言已经设计成不允许出现内容
耦合。它一般出现在汇编语言程序中。这种耦合是模块独立性最弱的耦合。
内聚有以下几种，下面将内聚性由弱到强依次列出（独立性由弱到强）
（1） 偶然内聚：
模块中的代码无法定义其不同功能的调用。但它使该模块能执行不同的功能，这种模块称为巧合强度模块。
（2） 逻辑内聚：
这种模块把几种相关的功能组合在一起， 每次被调用时，由传送给模块参数来确定该模块应完成哪一种功能
（3） 时间内聚：
把需要同时执行的动作组合在一起形成的模块为时间内聚模块。
（4） 过程内聚：
构件或者操作的组合方式是，允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。
（5） 通信内聚：
指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据。
（6） 顺序内聚：
指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一功能元素的输入。即一个模块完成多个功能，这些模块又必须顺序执行。
（7） 功能内聚：
这是最强的内聚，指模块内所有元素共同完成一个功能，联系紧密，缺一不可。
内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系。耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。
程序讲究的是低耦合，高内聚。就是同一个模块内的各个元素之间要高度紧密，但是各个模块之间的相互依存度却要不那么紧密。
软件设计应追求尽可能松散，如何避免强耦合这样模块。之间的联系越小模块的。独立性就越强，对于模块的测试维护就越加容易。所以建议尽量使用数据耦合，少用控制耦合，限制公共耦合，完全不用内容耦合
软件设计应追求尽可能松散，如何避免强耦合这样模块。之间的联系越小模块的。独立性就越强，对于模块的测试维护就越加容易。所以建议尽量使用数据耦合少用控制耦合限制公共耦合完全不用内容耦合
内聚和耦合是密切相关的，同其他模块存在高耦合的模块意味着低内聚，而高内聚的模块意味着该模块同其他模块之间是低耦合。在进行软件设计时，应力争做到高内聚，低耦合。
利用衡量模块独立性的两个标准耦合性和内聚性(模块划分时应尽量做到高内聚、低耦合，提高模块独立性)判断设计方案优劣。
数据字典
eg1：某宾馆的电话服务如下：可以拨分机号和外线号。分机号从7201到7209；拨外线需要先按9，然后是市话号码或长话号码；长话号码是由区号和市话号码组成的；区号是44、55中任意一个号码；市话号码是由局号和分局号组成的；局号可以是455、466、888、552中任意一个号码；分局号是长度为4的数字串。请写出在数据字典中，电话号码的数据条目的定义及组成。
电话号码 = [分机号|外线号]
分机号 = [7201 | 7202 | 7203 | 7204 | 7205 | 7206 | 7207 | 7208 | 7209]
外线号 = 9+[市话号码|长话号码|]
长话号码 = 区号 + 市话号码
区号 = [44 | 55 ]
市话号码 = 局号 + 分局号
局号 = [455|466|888|552]
分局号 =4{数字}4
数字 =[0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
eg2：北京某高校可用的电话号码有以下几种分类：校内电话由4位数字组成，第一位数字不是0；校外的电话又分为本市电话和外地电话两类，拨校外电话需先拨0，若是本市电话则借着拨8位数字（第一位不是0），若是外地电话则再拨3位区码再拨8位电话（第一位不是0）
用定义数据的办法定义上述电话号码：
电话号码 = [校内电话 | 校外电话]
校内电话 = 非零数字 + 3位数字
校外电话 = [本市号码 | 外地号码]
本市号码 = 数字0 + 8位数字
外地号码 = 数字0 + 3位数字 + 8位数字
非零数字 = [1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9]
数字0 = 0
3位数字 = 3 {数字}3
8位数字 = 非零数字 +=7位数字
7位数字 = 7{数字}7
数字 = [0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
3{数字}3 与 1{数字}3之间的差别在于，第一个的意思是固定长度为3的数字串，第二个是长度为1到3这个范围内的数字串
黑白盒
白盒测试黑盒测试的定义
在解释白盒测试黑盒测试的区别之前，我们需要对二者的概念进行简要了解。
什么是白盒测试？
白盒测试（White-box testing）也称为结构测试或透明盒测试，它需要测试人员了解软件的内部结构和实现细节。测试人员使用代码分析和代码覆盖等技术来评估软件的内部运行情况，并查找可能存在的缺陷。白盒测试的目标是发现软件中的逻辑错误、代码缺陷、性能问题和安全漏洞，以确保软件在各种异常和边界情况下的可靠性和稳定性。
什么是黑盒测试？
黑盒测试（Black-box testing）也称为功能测试，它不需要测试人员了解软件的内部结构和实现细节。测试人员只需要关注软件的输入和输出，以验证软件是否符合预期行为。黑盒测试的目标是发现软件中的功能错误、性能问题、安全漏洞和其他不符合要求的问题，以确保软件在正常使用条件下的可靠性和稳定性。
白盒测试黑盒测试的区别
具体来说，白盒测试黑盒测试的区别包括以下方面：
① 测试目标
黑盒测试主要是针对软件的外部行为进行测试，也就是测试软件是否满足用户需求和规格说明书中的要求。其测试目标是检查软件的功能是否正确、是否易于使用、是否容错；
白盒测试主要是针对软件的内部结构进行测试，也就是测试软件的代码是否正确、是否符合编码规范、是否容错。其测试目标是检查软件的正确性、性能、可维护性。
② 测试方法
黑盒测试主要采用功能测试、性能测试、安全测试等方法，测试人员主要通过输入不同的数据、操作不同的功能等方式，检查软件在不同情况下的行为和反应；
白盒测试主要采用结构测试、单元测试、集成测试等方法，测试人员主要通过检查代码实现和逻辑结构的正确性、代码覆盖率等方式，对软件内部进行全面测试和检查。
③ 测试人员
黑盒测试通常由测试人员负责，测试人员不需要了解软件的内部实现，只需要根据用户需求和规格说明书等进行测试；
白盒测试通常由开发人员和测试人员共同负责，测试人员需要了解软件的内部实现，熟悉编程语言和开发环境等。开发人员需要编写测试用例、调试程序、修复错误等。
④ 测试时机
黑盒测试通常在软件开发后的集成测试阶段进行，即测试人员在测试完单元测试和集成测试后对整个软件进行功能测试、性能测试等。
白盒测试通常在软件开发的早期阶段进行，即开发人员在编写代码时进行单元测试和集成测试，确保代码实现的正确性和逻辑结构的正确性。
白盒测试黑盒测试的本质区别
测试的关注对象不同
分层数据流图
其主要功能描述如下：
1. 每门课程都有3到6个单元构成，每个单元结束后会进行一次测试，其成绩作为这门课程
的平时成绩。课程结束后进行期末考试，其成绩作为这门课程的考试成绩。
2. 学生的平时成绩和考试成绩均由每门课程的主讲教师上传给成绩管理系统。
3. 在记录学生成绩之前，系统需要验证这些成绩是否有效。首先，根据学生信息文件来确
认该学生是否选修这门课程，若没有，那么这些成绩是无效的;如果他的确选修了这门课
程，再根据课程信息文件和课程单元信息文件来验证平时成绩是否与这门课程所包含的
单元相对应，如果是，那么这些成绩是有效的，否则无效。
4. 对于有效成绩，系统将其保存在课程成绩文件中。对于无效成绩，系统会单独将其保存
在无效成绩文件中，并将详细情况提交给教务处。在教务处没有给出具体处理意见之前，
系统不会处理这些成绩。
5. 若一门课程的所有有效的平时成绩和考试成绩都已经被系统记录，系统会发送课程完成
通知给教务处，告知该门课程的成绩已经齐全。教务处根据需要，请求系统生成相应的
成绩列表，用来提交考试委员会审查。
6. 在生成成绩列表之前，系统会生成一份成绩报告给主讲教师，以便核对是否存在错误。
主讲教师须将核对之后的成绩报告返还系统。
7. 根据主讲教师核对后的成绩报告，系统生成相应的成绩列表，递交考试委员会进行审
查。考试委员会在审查之后，上交一份成绩审查结果给系统。对于所有通过审查的成
绩，系统将会生成最终的成绩单，并通知每个选课学生。
画顶层图
我们先不看给出的图，凭借题目给出的信息自己画图，先是顶层图，画顶层图步骤有3步：
- 将软件系统看作加工，
2.确定外部实体，
3.画出数据流
找到题目中的软件系统，题目第一句就可以看到“成绩管理系统”
浏览题目一遍，不难找出所有外部实体
根据各个外部实体与软件系统进行的交互操作，可以得到数据流
与题目给出的图对比
【问题1】的答案就已经出来了，很明显E1为考试委员会，E2为主讲教师，E3为学生，E4为教务处。
画0层图
接下来是画0层图，0层图作画步骤：
1.细分顶层图的加工
2.数据流连接加工
再次从头开始看全文，看到第3句，
在记录学生成绩之前，系统需要验证这些成绩是否有效
这里之前是被我们忽略掉的，在画顶层图时，这里算作总的成绩管理系统的加工，现在需要细分成绩管理系统了，我们就需要把此系统的功能提取出来——命名为“验证成绩”的加工。
继续往后看，到第4句
对于有效成绩，系统将其保存在课程成绩文件中。对于无效成绩，系统会单独将其保存在无效成绩文件中，并将详细情况提交给教务处。
这里我们又看到系统的两个功能，“保存课程成绩文件”与“保存无效成绩文件”，也就是两个加工。
继续看到第5句
若一门课程的所有有效的平时成绩和考试成绩都已经被系统记录，系统会发送课程完成通知给教务处，告知该门课程的成绩已经齐全。教务处根据需要，请求系统生成相应的成绩列表
前面的“系统会发送课程完成通知给教务处”，明显是数据流而不算作是功能，后面的“请求系统生成相应的成绩列表”才体现出功能，我们命此加工为“生成成绩列表”。
直到最后的一句
“系统将会生成最终的成绩单，并通知每个选课学生。”
可见又是一个加工，我们命名为“生成成绩单”
下面要做是补全数据流
所有这些加工实质就是整体的软件系统的加工，所以可以先把顶层图的数据流照搬过来
这里注意每条数据流要对应好加工，图中省略了外部实体，这没关系。
然后加上数据存储文件
画到这一步并没有完，有部分数据流并没表示出来，比如保存课程成绩文件与保存无效成绩文件的数据输入还有生成成绩单的数据输入流，但没关系，解第二题足够了，若把所有数据流加上那第三题就迎刃而解了。
【问题2】答案
D1就是学生信息文件夹
D2为课程单元信息文件
D3为课程信息文件
D4为课程成绩文件(图中我命名为了 有效成绩文件)
D5为无效成绩文件
第一次画就是上图那样不能掌握布局所以很乱，第二次画时根据这张图规划好布局就可以画得更工整了
【问题3】
第一条数据流：由说明的第5条可知，生成成绩列表时，是需要从课程成绩文件中获取信息的，“课程成绩文件”是图中的D4。而D4和加工4之间并没有数据流，因此这就是一条缺失的数据流。
第二条数据流：生成成绩单时是需要学生信息的。且不符合数据输入输出平衡(文末有相关知识)，加工5应该从D1中获取相应的信息，这样就找到了第二条数据流。
第三条数据流：说明的第7句告诉我们，只有“对于所有通过审查的成绩，系统将会生成最终的成绩单，并通知每个选课学生”。也就是说，从成绩列表到成绩单的生成是有条件的。这意味着，在加工4和加工5之间应该存在一条数据流，这就是第3条数据流。
所以完整的0层图应如下图所示
数据流图转化为软件结构图
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
