程序员第六期全程建模之软件设计指南-管理类软件示例4.doc

程序员第六期 全程建模之软件设计指南管理类软件示例撰稿 高 展摘要：本文在上期需求分析基础上，阐述如何使用“全程建模”方法进行软件的总体设计与详细设计，力求全面利用业务分析、需求定义的成果，推导软件设计方案，大幅度减少设计差错，全面提高软件设计自动化水平。一 软件设计，烫手的山芋1 现象自从人类步入工业文明以来，无论哪一个行业都躲不开产品设计必要环节。可笑的是，中国软件开发在方面无论从观念上还是在行动上落后了230年。1772年，著名社会学家亚当.斯密在国富论（the wealth of the nations）中指出，分工是工业文明高度发达的根本原因。以建筑业为例，天才建筑大师贝律明设计的北京香山饭店，堪称凝固的音乐，可是泥瓦匠活还是由普普通通的民工组成的工程队来干，建筑业的成功充分地体现了各种资源的有效组合的结果。反观软件行业，没人专做需求分析，没人专做软件设计，没人专做软件测试，几乎成为软件公司上上下下的“共识”，大家有一千个理由专注于编程。后果是软件开发强烈依赖发挥（实际上是发散），质量得不到有效的控制，各种资源极大浪费。如果说软件公司一点设计工作没做是有点冤枉：一张粗糙的软件系统框架，一幅马马虎虎的接口关系图，寥寥几页的程序流程图。究竟谁在糊弄谁，谁也不想搞明白，反正最后是费了牛劲才能把软件拼凑出来，能否蒙混过关只有天晓得。2 原因我们可以以下三个方面分析为什么没人愿意踏踏实实坐下来把软件设计做好。首先从社会大环境来看，中国工业化进程缓慢，封建意识浓厚，从国民整体意识上就缺乏分工协作的基本常识；其次从个体小环境来看，中国的高等教育做的是知识灌输的工作，缺乏职业教育精神，没有工程化教育的目标，培养的人才往往是四体不勤，五谷不分；最后从具体运作来看，软件公司或者搭草台班子唱戏应付差事，或者占山为王打打杀杀不亦乐乎，很难静下心来考虑设计软件这种“苦累”差事。3 出路全程建模提倡软件设计由需求分析推导而来，而用户对软件的需求则紧密结合业务活动本身，这一点深刻反映了开发管理软件的根本理念：源于管理、用于管理。全程一体化建模的原理可以总结成下面的镜子模型： 图 1镜子模型在这种全程镜像一体化建模思想指导下，软件设计自动化变得切实可行。从实际效果来看，对定制软件来说，直接根据实际企业模型得到的总体设计自动化程度为90%，详细设计为70%，对产品软件来说，首先要假设一个标准的企业模型，在此基础上，总体设计自动化程度将能达到80%，详细设计将能达到60%。另外，毫不夸张地讲，无论多么大软件系统，如果不包括可行性论证过程，需求定义只需几个小时就可以填空方式完成。二 软件设计的要点1 主要内容从开发过程来看，软件设计包括总体设计、详细设计这两大部份，其中总体设计主要包括系统结构设计、系统流程设计、系统接口设计、全局数据结构设计、硬件配置设计、集成测试设计，详细设计包括模块设计、本地数据结构设计、报表设计、屏幕设计。2 模块化是设计的根本原则软件工程的核心思想是模块化。实际上，模块化的方法是所有工程领域的基本方法，如机械工程的零部件、建筑工程的砖瓦和预制件，其优势显而易见：一方面，模块化设计降低了系统的复杂性，便于修改，另一方面，推动了系统各个部分的并行开发，提高生产效率。模块独立性是模块化的基石，独立化程度越高，模块化的优势就越发明显。模块独立性可以从两个角度来测量：模块间的耦合性、模块中的内聚性。一般说来，松耦合、强内聚是模块独立程度高的标志。耦合性由小到大分为七级：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合；内聚性由强到弱的级别也为七级：功能内聚、信息内聚、通信内聚、过程内聚、逻辑内聚、巧合内聚。限于篇幅，有关模块独立性的详细论述请参见有关软件工程教材。3 照猫画虎使设计水到渠成经验告诉我们，如果只从软件角度实现模块化，难度是很大的。幸运的是管理制度运行良好的企业为我们提供了很好的设计素材：组织结构的分工合理体现了模块的独立性，业务流程的通畅体现了模块便于协调使用，业务单证的完整清晰体现模块间信息交流准确无误。在此基础上，全程镜像一体化建模使设计方案一步到位，水到渠成：组织结构的分工合理保证了软件模块的独立性，业务流程的通畅保证了软件模块便于协调使用，业务单证的完整清晰保证了软件模块间数据通信准确无误。三 总体设计1 系统级结构设计在本刊上期需求分析基础上，我们只保留结构树节点盒子的下半部分，所谓软件结构就“自动推导”出来了，如图2所示。一般来讲，这种推导出来的系统结构可以作为设计的第一个版本，对于定制软件而言，软件结构的变化体现为增加纯计算机处理过程，如显示背景、初始化变量、释放空间等；对于产品软件而言，将另行撰文讨论如何以组件化的方式调整软件结构。建模工具PlayCASE能够自动生成有关“系统/功能字典”，从文字角度完整描述相应的系统/功能节点。图 2 系统级结构2 系统级流程设计同样，我们只保留本刊上期需求分析事件流图中节点盒子的下半部分，所谓的软件流程就“自动推导”出来了，如图3所示。图 3 系统级流程3 系统级接口设计软件开发发生混乱的很大一部分原因是系统之间的接口含混不清：需要的信息没人给，送出的信息不知道谁要。全程建模使用“数据汇总图”描述系统接口，建模工具PlayCASE自动从事件流图提取事件携带的数据形成数据汇总图，从而使系统间的接口清晰明了，准确无误。图4描述了“总经理查询子系统”、“业务管理子系统”、“财务子系统”之间的数据接口的关系：图 4 系统级接口4 全局数据结构设计对于管理软件来说，全局数据是各个应用子系统共享的基础数据，这些数据绝大部分由大型DBMS来管理。全局数据结构设计主要指的是全局数据库设计，主要包括基表设计、视图设计、存储过程设计、触发器设计等，其中基表和视图可由PlayCASE自动生成具体的SQL语句：基表DDL(数据定义语言)由构件生成，视图的DDL由计算链生成。这里的基表、视图首先直接来源于业务分析得到的构件，根据这些原始的构件的内容及其之间的关系，先进行基表设计，包括数据库范式设计（消除多对多关系、确保达到第三范式）、关键字设计、字段类型设计、字段长度设计、取值范围设计等；视图设计使用计算链进行，包括字段引用设计、字段运算关系设计、字段约束关系设计等。PlayCASE能够自动生成有关基本表的字典“实体属性表”。图 5 基表和视图的设计以及DDL的生成5 硬件配置设计硬件配置设计包括计算机配置设计、网络拓扑设计，如图6的配置图所示，包括了硬件参数、运行软件、用户的描述。图 6 计算机与网络拓扑设计6 集成测试设计顺序图在业务分析阶段用于验证业务流程的通畅性，在设计阶段可以直接利用这种图进行子系统集成时的测试设计工作，测试流程如图7所示：图 7 销售流程的测试设计四 详细设计1 模块设计模块设计的主要包括输入/输出参数设计，模块逻辑过程设计。在美国80%的软件公司使用伪代码来进行模块设计，而在日本80%的软件公司使用PAD（问题分析图Problem Analysis Diagram）来进行模块设计，全程建模方法提供了直接以PAD进行模块设计的直观手段，同时PlayCASE提供了从PAD自动生成伪代码，以便于程序代码直接结合。图8表示了PAD与伪代码结合的结果。图 8 PAD与伪代码2 本地数据结构设计本地数据是一个子系统自身使用的数据，它与全局数据的划分是不是绝对的。对于存放在DBMS的本地数据而言，其数据结构设计方法与全局数据相同，最好也在总体设计阶段进行；对于程序中使用的内存数据，全程建模方法提供了C+/Java的设计class方法，限于篇幅这里不再展开讨论。3 报表设计这部分的工作是在需求定义阶段的报表定义基础上，描述报表的每一栏目与数据库表/视图的哪个具体字段挂接。图 9 报表栏目与数据库表/视图的挂接4 屏幕设计 这部分的工作是在需求定义阶段的屏幕定义基础上，描述FORM中的每一界面元素与数据库的哪个具体字段挂接，其方式与报表设计类似。五 生成软件框架根据上述全局数据结构与本地数据结构设计结果，PlayCASE可以分别自动生成数据库基本表、数据库视图、C+/Java类的声明体。图5表示了PlayCASE由构件与计算链定义而自动生成的基本表、视图的SQL脚本语句。六 与传统数据库设计的对应关系传统数据库设计主要包括三视图设计：概念视图设计、逻辑视图设计、物理视图设计，全程建模方法使用构件图来支持三视图设计，同时强烈推荐与现实世界直接相关的概念视图应当在业务分析阶段完成，逻辑视图设计、物理视图应当在总体设计阶段完成。七 如何支持CMMCMM为建模提供了行动大纲，建模保证了CMM的内容充实可靠。下表简要地归纳了全程建模方法对CMM主要工作的支持。 CMM级别特点关键过程域全程建模的支持要点1初始级软件的过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决个人努力。管理是反应式（消防队员）2可重复级建立了基本的项目管理过程来跟踪费用、进度和功能特性。制订了必要的过程纪律，能重复早先类似应用项目并取得成功需求管理软件项目计划软件项目跟踪和监督软件子合同管理软件质量保证软件配置管理3已定义级已