前面需求分析阶段给出了角色、用例和业务流程。

设计阶段需要将需求阶段给出的角色、用例和业务流程模型映射到能够被编程语言识别和描述的对象、对象功能和对象行为模型，设计阶段用到的UML模型有类图、活动图、时序图、状态图、部署图、伪代码。

设计阶段需要针对需求阶段给出的角色与用例，规划出对象类。在UML设计模型中，一般将对象类分为边界类、控制类和实体类。

边界类主要用于描述外部参与者与程序之间的交互。例如：角色“程序使用者”同四则运算器的交互行为，其交互行为有“程序使用者”输入算式、查看帮助、退出程序等。

控制类用于描述程序的控制流程。例如：四则运算器开始运行后，需要持续等待用户输入命令或算式，根据用户输入的内容选择不同的流程。

实体类一般用于事物、人员或者一些现实生活中的对象，该类对象有存储数据的要求。例如：如果四则运算器要求区分角色“程序使用者”并存储角色信息时，就需要为角色“程序使用者”建立实体类，以便程序存储每个“程序使用者”的信息。

四则运算器的角色“程序使用者”并没有存储其信息的要求，因此无需为该角色建立实体类。与该角色相关的有三个用例，分别是<算式计算>用例、<退出程序>用例和<查看帮助>用例，该三个用例都有流程控制和外部交互需求，故分别需要为这三个用例建立控制类和边界类。

从设计实用性、编程效率方面考虑，可以将控制类和边界类合并为一个控制类；但从可维护性和扩展性上考虑，分开设计有利于代码结构清晰、并易于扩展四则运算器的功能。具体选择什么样的设计模式，需要根据程序（系统）所处的环境、技术、资源来决定，例如：一个程序（系统）在交付日期已经确定，项目进度紧张，而技术和人力资源又出现问题的情况下，应以设计实用性、编程效率方面考虑，反之则应从可维护性和扩展性上考虑。本节主要用于说明如何根据需求分析归纳类对象，从简单易懂考虑，采用合并设计原则。

类名仍采用V1.0版的“Arithmetic”，类名确定后，需要根据用例及业务流程图归纳类的属性和方法。

从10.1节的用例图和业务流程图分析可知，程序主要涉及到算式、帮助内容、错误信息三部分信息，这三部分信息都有被程序修改内容和获取内容的需要，因此可以归纳为“Arithmetic”类的属性。类的属性不同于类的成员变量，类的属性可以通过get方法获取属性内容，通过set方法设置属性内容。

一般来说，用例图中的子用例都可以归纳为类的方法。例如：10-1节用例<算式计算>的子用例<<输入算式>>、<<计算算式>>、<<扫描算式>>等子用例都可以归纳为类的方法。

 图 10-7 Arithmetic类图

类图说明

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

程序流程控制功能

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

图 10-8 程序控制流程图

算式计算功能

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

图 10-9 算式计算流程图

■ 知识点拨

需求分析给出的角色划分一般可以归纳为实体类，在复杂的应用系统中，角色都有存储数据的需求。例如：10.1节需求分析思考与练习给出的在线电话订餐系统中，就包括顾客、接单员、配餐员等角色，顾客角色的订餐内容、联系电话、到店时间的数据都要存储；接单员和配餐员角色的接单时间、服务质量、配餐信息等也需要存储；需求分析给出的用例可以归纳为控制类，用例包含的子用例可以归纳为其方法或者引用外部类提供的方法；业务流程图涉及到与外部的交互行为可以归纳为界面类。

■ 思考与练习

接10.1节需求分析中思考与练习内容，试着设计顾客、接单员的类图。