图2.3 计算机储蓄系统的实体-联系图
5.答：从问题陈述可知，本系统的数据源点是“病人”和“护士”，他们分别提供生理信号和要求病情报告的信息。进一步分析问题陈述，从系统应该“定时记录病人情况以形成患者日志”这项要求可以想到，还应该有一个提供日期和时间信息的“时钟”作为数据源点。
从问题陈述容易看出，本系统的数据终点是接收警告信息和病情报告的护士。 系统对病人生理信号的处理功能主要是“接收信号”、“分析信号”和“产生警告信息”。此外，系统还应该具有“定期取样生理信号”、“更新日志”和“产生病情报告”的功能。
为了分析病人生理信号是否超出了医生规定的安全范围，应该存储“患者安全范围”信息。此外，定时记录病人生理信号所形成的“患者日志”，显然也是一个数据存储。
本系统的基本系统模型如图2.4所示，图2.5是本系统的功能级数据流图。
图2.4 患者监护系统的基本系统模型
图2.5 患者监护系统的功能级数据流图
6.答：本系统的数据源点和终点都是文件管理员，他既向系统提供修改信息，又接收系统生成的修改报告。
系统功能主要有：接收修改信息，读主文件，校核记录，修改原始记录和产生报告。注意，问题陈述中所描述的“系统安装记录号把修改信息顺序排列好”，是具体的实现方法。在数据流图中无须描述具体实现方法，因此，在本系统的数据流图中不需要包含“排序”功能。类似地，“文件管理员把修改信息穿孔在卡片上，系统读入穿孔卡片上的信息”，是系统接收修改信息的具体方法。在数据流图中无须描绘这个具体的实现方案，因此，在本系统的数据流图中不需要包含“穿卡片”和“读卡片”的功能。
本系统包含的数据存储是：修改信息，主文件和修改后的主文件。 图2.6是本系统的基本系统模型，图2.7是功能级数据流图。
图2.6 主文件修改系统的基本系统模型
图2.7 主文件修改系统的功能级数据流图
7.答：电话号码=[校内电话号码│校外电话号码] 校内电话号码=非零数字+3位数字 校外电话号码=[本市号码│外地号码] 本市号码=数字零+8位数字
外地号码=数字零+3位数字+8位数字 非零数字=[1│2│3│4│5│6│7│8│9] 数字零=0
3位数字=3{数字}3
8位数字=非零数字+7位数字 7位数字=7{数字}7
数字=[0│1│2│3│4│5│6│7│8│9]
8.答：从问题陈述可知，复印件的状态主要有“闲置”、“复印”、“缺纸”和“卡纸”。引起状态转换的事件主要是“复印命令”、“完成复印命令”、“发现缺纸”、“装满纸”、“发生卡纸故障”和“排除了卡纸故障”。
图2.8所示状态转换图描绘了复印机的行为。
图2.8 复印机的状态图
9.答：Lookup操作的Z规格说明如图2.9所示。
图2.9 Lookup操作的Z规格说明
上面给出的Z规格说明指出：t是二维整数表，t＇是执行查表操作后的二维整数表；l？是输入（即要查找的整数），r！是查表操作得到的结果，它也是整数。
图2.9所示Z格的下半部分准确地说明了查表操作应该得到的结果： ● 若输入l？不在表t的定义域中，则输出r！是0，而且表t保持不变；
● 若输入l？在表t的定义域中，则输出r！是表t中l？所映射成的那个整数，而且表t保持不变；
为什么需要在Z规格说明中指出，查表结果保持表t不变呢？试想，如果在Z规格说明中没有提出这项要求，则在查找过程中修改了表t的实现方案（可能这样做编程更方便些），也是符合规格说明的。但是，这样的实现方案是用户不能接受的。
10.答：该有穷状态机的初态是“等待字符串输入”。在初态若接收到字符+、或字符-、或二进制位，则进入“输入尾数”状态；在初态若接收到其他字符，则进入终态“非浮点二进制数”。在“输入尾数”状态若接收到二进制位，则保持该状态不变；若接收到字符E，则进入“等待输入指数”状态；若接收到其他字符，则进入终态“非浮点二进制数”。在“等待输入指数”状态若接收到字符+、或字符-、或二进制位，则进入“输入指数”状态；若接收到其他字符，则进入终态“非浮点二进制数”。在“输入指数”状态若接收到二进制位，则保持该状态不变，若输入其他字符，则进入终态“非浮点二进制数”；若输入结束，则进入终态“浮点二进制数”。
综上所述，判断输入的字符串是否是浮点二进制数的有穷状态机如图2.10所示。
图2.10 判断浮点二进制数的有穷状态机
仔细研究图2.10所示的有穷状态机可以发现，它还有不够严格的地方。有兴趣的读者请进一步改进它，画出更严格的、与浮点二进制数定义完全一致的有穷状态机。
11.答：通常，结构化分析过程包括问题定义、可行性研究和需求分析3个阶段。下面分别叙述这3个阶段的分析过程。
(1)问题定义
从何处着手解决财务科长提出的问题呢？立即开始考虑实现工资支付系统的详细方案并动手编写程序，对技术人员无疑是很有吸引力的。但是，在这样的早期阶段就考虑具体的技术问题，却很可能会使我们迷失前进的方向。会计部门（用户）并没有要求在学校自己的计算机上实现工资支付系统，仅仅要求研究这样做的可能性。后者是和前者很不相同的问题，它实际上是问，这样做预期将获得的经济效益能超过开发这个系统的成本吗？换句话说，这样做值得吗？
优秀的系统分析员还应该进一步考虑，用户面临的问题究竟是什么。财务科长为什么想研究在自己的计算机上实现工资支付系统的可能性？询问财务科长后得知，该校一直由会计人员计算计算工资并编制财务报表，随着学校规模扩大工作量也越来越大。目前每个月都需要两名会计紧张工作半个月才能完成，不仅效率低而且成本高。今后学校规模进一步扩大，人工计算工资的成本还会进一步提高。
因此，目标是寻找一种比较便宜的生成工资明细表和各种财务报表的办法，并不一定必须在学校自己的计算机上实现工资支付系统。财务科长提出的要求，实际上并没有描述应该解决的问题，而是在建议一种解决问题的方案。这种解决方案可能是一个好办法，分析员当然应该认真研究它，但是也还应该考虑其他可能的解决方案，以便选出最好的方案。良好的问题定义应该明确地描述实际问题，而不是隐含地描述解决问题的方案。
分析员应该考虑的另一个关键问题，是预期的项目规模。为了改进工资支付系统最多可以花多少钱呢？虽然没人明确提出来，但是肯定会有某个限度。应该考虑下述3个基本数字：目前计算工资所花费的成本，新系统的开发成本和运行费用。新系统的运行费用必须低于目前的成本，而且节省的费用应该能使学校在一个合理的期限内收回开发新系统时的投资。