需求分析映射到UML设计类图

1、设计阶段需要将需求阶段给出的角薄本窭煌色、用例和业务流程模型映射到能够被编程语言识别和描述的对象、对象功能和对象行为模型，设计阶段用到的UML模型有类图、活动图、时序图、状态掬研疔缎图、部署图、伪代码。设计阶段需要针对需求阶段给出的角色与用例，规划出对象类。在UML设计模型中，一般将对象类分为边界类、控制类和实体类。边界类主要用于描述外部参与者与程序之间的交互。例如：角色程序使用者同四则运算器的交互行为，其交互行为有程序使用者输入算式、查看帮助、退出程序等。控制类用于描述程序的控制流程。例如：四则运算器开始运行后，需要持续等待用户输入命令或算式，根据用户输入的内容选择不同的流程。实体类一般用于事物、人员或者一些现实生活中的对象，该类对象有存储数据的要求。例如：如果四则运算器要求区分角色程序使用者并存储角色信息时，就需要为角色程序使用者建立实体类，以便程序存储每个“程序使用者”的信息。四则运算器的角色程序使用者并没有存储其信息的要求，因此无需为该角色建立实体类。与该角色相关的有三个用例，分别是<输入算式>用例、<算式求解>用例和<查看答案>用例，该三个用例都有流程控制和外部交互需求，故分别需要为这三个用例建立控制类和边界类。从设计实用性、编程效率方面考虑，可以将控制类和边界类合并为一个控制类；但从可维护性和扩展性上考虑，分开设计有利于代码结构清晰、并易于扩展四则运算器的功能。具体选择什么样的设计模式，需要根据程序（系统）所处的环境、技术、资源来决定，例如：一个程序（系统）在交付日期已经确定，项目进度紧张，而技术和人力资源又出现问题的情况下，应以设计实用性、编程效率方面考虑，反之则应从可维护性和扩展性上考虑。本节主要用于说明如何根据需求分析归纳类对象，从简单易懂考虑，采用合并设计原则。类名仍采用V1.0版的“Arithmetic”，类名确定后，需要根据用例及业务流程图归纳类的属性和方法。用例图和业务流程图分析可知，程序主要涉及到算式、帮助内容、错误信息三部分信息，这三部分信息都有被程序修改内容和获取内容的需要，因此可以归纳为“Arithmetic”类的属性。类的属性不同于类的成员变量，类的属性可以通过get方法获取属性内容，通过set方法设置属性内容。一般来说，用例图中的子用例都可以归纳为类的方法。

2、类图设计完成后，根据设计的需要，可能还需要设计活动图、时序图、状态图、部署图等。其多用于复杂的程序（系统）进一步理顺业务活动、流程、事件、部署等设计需要。本程序结构简单，无需再设计活动图，类图设计完成后，基本就可以进入编码了。

3、程序流程控制功能程序启动运行后，首先显示帮助内容，向用户提示程序的使用方法。然后循环等待用户输入，用户输入完成后，程序根据用户输入的选择不同的分支执行程序。若输入的内容为quit，则执行退出程序分支；若输入的内容为help，则执行显示帮助程序分支；若不是前两项内容，则执行算式计程序分支。分支执行完毕，继续等待用户输入。程序控制流程如下图所示：

4、算式计算功能计算算式并返回计算结果，计算前先对算式做语法判断，若算式语法错误，返回错误信息，终止计算功能。若算式语法正确，计算算式并返回计算结果。算式计算流程如下图所示：