《程序员第六期：全程建模之软件设计指南 -管理类软件示例 4》由会员分享，可在线阅读，更多相关《程序员第六期：全程建模之软件设计指南 -管理类软件示例 4（5页珍藏版）》请在金锄头文库上搜索。
1、1程序员第六期 全程建模之软件设计指南管理类软件示例撰稿 高 展摘要：本文在上期需求分析基础上，阐述如何使用“全程建模”方法进行软件的总体设计与详细设计，力求全面利用业务分析、需求定义的成果，推导软件设计方案，大幅度减少设计差错，全面提高软件设计自动化水平。一 软件设计，烫手的山芋1 现象自从人类步入工业文明以来，无论哪一个行业都躲不开产品设计必要环节。可笑的是，中国软件开发在方面无论从观念上还是在行动上落后了 230 年。1772 年，著名社会学家亚当.斯密在国富论 （the wealth of the nations）中指出， 分工 是工业文明高度发达的根本原因。以建筑业为例，天才建筑大师
2、贝律明设计的北京香山饭店，堪称凝固的音乐，可是泥瓦匠活还是由普普通通的民工组成的工程队来干，建筑业的成功充分地体现了各种资源的有效组合的结果。反观软件行业，没人专做需求分析，没人专做软件设计，没人专做软件测试，几乎成为软件公司上上下下的“共识” ，大家有一千个理由专注于编程。后果是软件开发强烈依赖发挥（实际上是发散） ，质量得不到有效的控制，各种资源极大浪费。如果说软件公司一点设计工作没做是有点冤枉：一张粗糙的软件系统框架，一幅马马虎虎的接口关系图，寥寥几页的程序流程图。究竟谁在糊弄谁，谁也不想搞明白，反正最后是费了牛劲才能把软件拼凑出来，能否蒙混过关只有天晓得。2 原因我们可以以下三个方面分
3、析为什么没人愿意踏踏实实坐下来把软件设计做好。首先从社会大环境来看，中国工业化进程缓慢，封建意识浓厚，从国民整体意识上就缺乏分工协作的基本常识；其次从个体小环境来看，中国的高等教育做的是知识灌输的工作，缺乏职业教育精神，没有工程化教育的目标，培养的人才往往是四体不勤，五谷不分；最后从具体运作来看，软件公司或者搭草台班子唱戏应付差事，或者占山为王打打杀杀不亦乐乎，很难静下心来考虑设计软件这种“苦累”差事。3 出路全程建模提倡软件设计由需求分析推导而来，而用户对软件的需求则紧密结合业务活动本身，这一点深刻反映了开发管理软件的根本理念： 源于管理、用于管理 。全程一体化建模的原理可以总结成下面的镜子
4、模型：需 求 功 能 过 程 数 据 管 理 制 度 组 织 结 构 业 务 流 程 业 务 数 据 管 理 软 件 软 件 结 构 软 件 流 程 软 件 数 据 实 物 镜 子 镜 像 图 1 镜子模型在这种全程镜像一体化建模思想指导下，软件设计自动化变得切实可行。从实际效果来看，对定制软件来说，直接根据实际企业模型得到的总体设计自动化程度为 90%，详细设计为 70%，对产品软件来说，首先要假设一个标准的企业模型，在此基础上，总体设计自动化程度将能达到 80%，详细设计将能达到 60%。另外，毫不夸张地讲，无论多么大软件系统，如果不包括可行性论证过程，需求定义只需几个小时就可以填空方式完
5、成。二 软件设计的要点1 主要内容从开发过程来看，软件设计包括总体设计、详细设计这两大部份，其中总体设计主要包括系统结构设计、系统流程设计、系统接口设计、全局数据结构设计、硬件配置设计、集成测试设计，详细设计包括模块设计、本地数据结构设计、报表设计、屏幕设计。22 模块化是设计的根本原则软件工程的核心思想是模块化。实际上，模块化的方法是所有工程领域的基本方法，如机械工程的零部件、建筑工程的砖瓦和预制件，其优势显而易见：一方面，模块化设计降低了系统的复杂性，便于修改，另一方面，推动了系统各个部分的并行开发，提高生产效率。模块独立性是模块化的基石，独立化程度越高，模块化的优势就越发明显。模块独立性
6、可以从两个角度来测量：模块间的耦合性、模块中的内聚性。一般说来，松耦合、强内聚是模块独立程度高的标志。耦合性由小到大分为七级：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合；内聚性由强到弱的级别也为七级：功能内聚、信息内聚、通信内聚、过程内聚、逻辑内聚、巧合内聚。限于篇幅，有关模块独立性的详细论述请参见有关软件工程教材。3 照猫画虎使设计水到渠成经验告诉我们，如果只从软件角度实现模块化，难度是很大的。幸运的是管理制度运行良好的企业为我们提供了很好的设计素材：组织结构的分工合理体现了模块的独立性，业务流程的通畅体现了模块便于协调使用，业务单证的完整清晰体现模块间信息交流准
7、确无误。在此基础上，全程镜像一体化建模使设计方案一步到位，水到渠成：组织结构的分工合理保证了软件模块的独立性，业务流程的通畅保证了软件模块便于协调使用，业务单证的完整清晰保证了软件模块间数据通信准确无误。三 总体设计1 系统级结构设计在本刊上期需求分析基础上，我们只保留结构树节点盒子的下半部分，所谓软件结构就“自动推导”出来了，如图 2 所示。一般来讲，这种推导出来的系统结构可以作为设计的第一个版本，对于定制软件而言，软件结构的变化体现为增加纯计算机处理过程，如显示背景、初始化变量、释放空间等；对于产品软件而言，将另行撰文讨论如何以组件化的方式调整软件结构。建模工具 PlayCASE 能够自动
8、生成有关“系统/ 功能字典” ，从文字角度完整描述相应的系统/功能节点。小 型 进 销 存 系 统 A0 总 经 理 查 询 子 系 统 A1业 务 管 理 子 系 统 A2业 务 经 理 子 系 统 A2.1销 售 管 理 子 系 统A2.采 购 管 理 子 系 统A2.3仓 库 保 管 子 系 统A2.4货 物 出 库 模 块 A2.4.1 出 库 单 核 对 模 块C2.4.1.保 管 帐 记 账 模 块A2.4.1.2逐 条 填 写 出 库 明 细C2.4.1.2.1商 品 编 号 填 写 模 块A2.4.1.2.实 际 出 库 数 量 填 写 模块A2.4.1.2.3库 存 数 量
9、充 减 模 块A2.4.1.2.4OutputDate := NowA2.4.1.2.5保 管 员 签 字A2.4.1.2.6退 回 出 库 单 A2.4.1.3货 物 入 库 模 块 A2.4.2盘 点 计 模 块 A2.4.3财 务 管 理 子 系 统 A3图 2 系统级结构2 系统级流程设计同样，我们只保留本刊上期需求分析事件流图中节点盒子的下半部分，所谓的软件流程就“自动推导”出来了，如图 3 所示。3客 户 总 经 理 查 询 子 系 统 A1业 务 管 理 子 系 统 A2供 应 商 财 务 管 理 子 系 统 A3当 前 层 次 业 务 /工 作 种 类 ：1.销 售 2.采 购
10、 3.财 务 核 算订 货 订 单发 货 发 货 清 单采 购 采 购 清 单供 货 供 货 清 单交 货 款订 单发 货 清 单了 解 采 购 情 况了 解 销 售 情 况提 供 收 款 凭 证销 售 发 票上 报 采 购 情 况采 购 日 报上 报 销 售 情 况销 售 日 报交 发 货 单发 货 单 (财 务 联 )通 知 到 款了 解 财 务 状 况上 报 财 务 状 况客 户 小 型 进 销 存 系 统 A0供 应 商 对 外 业 务 /工 作 种 类 ： 1.销 售 2.采 购订 货 订 单发 货 发 货 清 单采 购 采 购 清 单供 货 供 货 清 单交 货 款订 单发 货 清
11、 单提 供 收 款 凭 证销 售 发 票图 3 系统级流程3 系统级接口设计软件开发发生混乱的很大一部分原因是系统之间的接口含混不清：需要的信息没人给，送出的信息不知道谁要。全程建模使用“数据汇总图”描述系统接口，建模工具 PlayCASE 自动从事件流图提取事件携带的数据形成数据汇总图，从而使系统间的接口清晰明了，准确无误。图 4 描述了“总经理查询子系统” 、 “业务管理子系统” 、 “财务子系统”之间的数据接口的关系：客 户 供 应 商 总 经 理 查 询 子 系 统 A1业 务 管 理 子 系 统 A2 财 务 管 理 子 系 统 A3发 货 单 (财 务 联 )订 单发 货 清 单
12、订 单发 货 清 单 销 售 发 票供 货 清 单 采 购 清 单 采 购 日 报销 售 日 报图 4 系统级接口4 全局数据结构设计对于管理软件来说，全局数据是各个应用子系统共享的基础数据，这些数据绝大部分由大型 DBMS来管理。全局数据结构设计主要指的是全局数据库设计，主要包括基表设计、视图设计、存储过程设计、触发器设计等，其中基表和视图可由 PlayCASE 自动生成具体的 SQL 语句：基表 DDL(数据定义语言) 由构件生成，视图的 DDL 由计算链生成。这里的基表、视图首先直接来源于业务分析得到的构件，根据这些原始的构件的内容及其之间的关系，先进行基表设计，包括数据库范式设计（消除
13、多对多关系、确保达到第三范式） 、关键字设计、字段类型设计、字段长度设计、取值范围设计等；视图设计使用计算链进行，包括字段引用设计、字段运算关系设计、字段约束关系设计等。PlayCASE 能够自动生成有关基本表的字典 “实体属性表” 。视 图 “销 售 日 报 ”设 计 ：=SELECT 订 单 .商 品 代 码 , 发 货 单 .发 货 日 期FROM 订 单 , 发 货 单WHERE -Joined Conditions(订 单 .商 品 代 码 = 发 货 单 .商 品 代 码 ) AND (订 单 .商 品 名 称 图 5 基表和视图的设计以及 DDL 的生成5 硬件配置设计4硬件配置
14、设计包括计算机配置设计、网络拓扑设计，如图 6 的配置图所示，包括了硬件参数、运行软件、用户的描述。单总 经 理 查 询 子 系 统数 据 库 服 务 器单 P3 90M 256M RAM 40 G HD100M以 太 网WAN 单销 售 管 理 子 系 统 单仓 库 保 管 子 系 统保 管 员图 6 计算机与网络拓扑设计6 集成测试设计顺序图在业务分析阶段用于验证业务流程的通畅性，在设计阶段可以直接利用这种图进行子系统集成时的测试设计工作，测试流程如图 7 所示：客 户 业 务 管 理 子 系 统A2 财 务 管 理 子 系 统 A31.1: 订 货订 单 1.3: 交 货 款订 单发 货
15、 清 单1.2: 发 货1.4: 提 供 收 款 凭 证销 售 发 票2.1: 通 知 到 款图 7 销售流程的测试设计四 详细设计1 模块设计模块设计的主要包括输入/输出参数设计，模块逻辑过程设计。在美国 80%的软件公司使用伪代码来进行模块设计，而在日本 80%的软件公司使用 PAD（问题分析图 Problem Analysis Diagram）来进行模块设计，全程建模方法提供了直接以 PAD 进行模块设计的直观手段，同时 PlayCASE 提供了从 PAD 自动生成伪代码，以便于程序代码直接结合。图 8 表示了 PAD 与伪代码结合的结果。Module Name:保 管 帐 记 账 模
16、块Input Parameters:出 库 单 (准 备 提 货 )Output Parameters:出 库 单 (销 售 联 )Iner Data(Variables & Used Tables):Pseudo Code Body:BEGIN / 逐 条 填 写 出 库 明 细 FOR 第 一 个 TO 最 后 DO BEGIN / 填 写 商 品 编 号 商 品 编 号 填 写 模 块 / 填 写 实 际 出 库 数 量 实 际 出 库 数 量 填 写 模 块 / 充 减 库 存 数 量库 存 数 量 充 减 模 块 END / 保 管 员 签 字 ? ? ? / 填 写 出 库 日 期OutputDate := NowEND 逐 条 填 写 出 库 明 细C2.4.1.2.1 商 品 编 号 填 写 模 块A2.4.1.2.实 际 出 库 数 量
