软件概要设计和详细设计精要

前段时间在项目上因为阅读某公司的软件详细设计说明书，引发了我的一些思考，这既是自己多年来感悟的一次梳理，也作为我从事企业模型咨询工作的一次总结。因为涉及的内容太广泛，以下尽量用简洁的语言来叙述。

传统的面向结构的设计，概要设计主要是给出系统整体功能菜单，模块之间的调用关系描述，还有软件系统工作环境的说明；详细设计则主要针对一个模块的算法设计，屏幕界面设计，按钮操作设计等等。

面向结构的软件设计缺点主要有以下两点：

1、从业务逻辑到功能菜单的跳跃太大，导致需求及变更的追溯性难以保证；

2、结构化开发方法不区分内外，不区分层次，编码语句会把信息全部平铺暴露，使用不当会形成太多的耦合点，修改起来牵一发而动全身，所以应变性很差。

软件行业发展变化太快，上世纪颁布的国家标准都不适应了现在的工程实践。特别是从软件工程转到面向对象的设计，还有所谓的快速迭代开发方法，完全打乱了原来面向结构的设计步骤。但是，越是变化快，就越需要理出“变中不变”的约束和规范来。因此，如何才能划分好概要设计与详细设计的界限，明确其设计的基本思想和原则具有至关重要的意义。

从概要到详细，首先就是要贯彻由整体到局部、由概括到细节，由概念模型到物理模型，由业务逻辑到IT技术实现，由“做什么”的描述到“如何做”的可执行步骤，这是一个由表及里、抽丝剥茧、层层深入的分析过程。

要体现企业架构的思想，既要把业务架构与应用架构平滑过渡，无缝连接，需求分析可追溯不跳跃不中断；又要整体架构可扩充，可伸缩，具有松耦合的特点，这样就便于发生需求变动进行修改。要体现出概要设计与详细设计之间的“松耦合”和“可验收”的两大特点，就必须找到这两者之间的不变量设计应用，就是设计的提交物应该达到可检验的颗粒度，形成成果物体现出“变中不变”的抽象关系。这样从不变量的角度讲，可以说明概要设计书的确完成了任务，作为详细设计的输入起到了约束条件的作用；从可变的角度讲，就明确了在详细设计阶段必须补充的需求调研，这也是设计者具有的主观能动性可以有所作为的部分。

要体现模型驱动的思想，把模型定义描述与它的编码执行区分开，采用SOA的架构思想，参见前面“模型驱动，最重要的顶层设计思想”一文，尽量用业务的语言来描述表达相应的业务需求，比如采用服务组合的方式，把真正的可执行编码放在最后的部分；

要采用面向对象的技术方案来落实以上设计原则，首先，离散组件（模块）就是对象，从一个元件的角度，它有对象的封闭性特点，就是区分（划分）出一个元件的内部和外部，这就是面向对象的封装性特点。所有属性都是对象的属性展开，没有脱离对象的属性。柏拉图所说独立的“共相”并不存在。不存在一般的白，只存在白的东西。任何统计指标总是离不开统计对象，它是一切数据的来源。封装性的黑盒方法：对象通信接口方法的具体方法，对象互交的接口研究，所谓组件就是区分了内外，组件内的信息只在接口显示，这个方法或者称为对象内在属性的逐步暴露方法，有限信息方法，对象属性的暴露是通过动词（职能域）来完成的，详细论述请参考“实体对象与企业建模的关系”一文。

可以说组件就是面向对象方法的一个特例。在对象协作中可以采用角色的岗位职责方法来分担系统要求的各项功能，平衡负载，协同调度，这是从组件结构设计到整体系统功能转换的精彩之处，即对象岗位职责分配法：把一个新的任务分配给各个部门岗位，即结构功能法，用结构实现功能的方法，因为对象方法具有黑盒的封装性，它通过接口技术屏蔽对象内部信息的过多暴露、把对象协作和其间的传递函数都简单化。最简单的接口就是函数，传递函数的方法，IPO的数学表达。组件之间的通信和互交则是通过接口来完成的，这是组件要进行相互协作的一个前提。通过组合来完成协作，不仅是共时同步的协作，也可以是流程顺序的协作。因为组件如何通过组合来完成一个特定的功能，就是组件的一个基本的任务，也是从结构设计到功能实现的典型案例。正是在这些点上，组件和面向对象有着共同的逻辑。

以下是企业架构几个重要的连接点与不变量的关系：

业务逻辑的设计，严格说这属于管理咨询的内容。制度以文本文件的方式书写了管理要素，其中包括：岗位、事件、记录、场景、系统、角色、授权、风险、术语、活动、客户、服务、绩效等因素，制度形成了企业的各项管理要求，其中有部门岗位职责、管理办法，实施细则、操作规程、作业标准等等，它论述了业务管理的原则与目标，各个部门的分工与职责，对于业务“做什么”和“如何做”给出了描述，并对业务的作业标准给出了说明指导。业务逻辑就是要表达出以上各项管理要素，流程设计就是要把它们融汇并落实到流程的各个环节中。值得注意是：制度文件为了能够在企业中明确执行，总是明确以现行的组织部门及岗位来确定职责。所以，一旦组织部门岗位发生了变动，流程相关执行者也会重新界定。因此，在企业模型中，业务模型（业务架构）中职能域体现的业务原逻辑，应该是技术实现（计算机或者手工）和部门岗位的不变量，这是它形成企业模型具有稳定性的重要因素。因此也称它为业务原逻辑，它具有原型的意义，通常就是以业务流程的形式来表达。

流程是业务架构与应用架构最重要的衔接点。面向对象的设计优于面向结构的设计首先体现在这里。从业务需求角度，必须描述到流程角色协作的泳道图。过去面向结构设计的功能菜单就于此连接不上，找不到具体的使用者，跳跃太大。只是通过系统管理员来分配功能菜单的使用权限的方式来衔接业务逻辑显然是不够的明确，这远没有UML（统一模型设计语言）的用例图表达的清晰准确。

在UML语言中，角色对象的互交图，表达了一个流程参与角色的职责，但是它并没有展开流程更多的细节，它的进一步展开就可以得到泳道图。互交图的展开是泳道图，互交图是人物关系，泳道图是事件的展开。这其实也是长篇小说的写作方法，先思考人物关系，然后才是跌宕起伏的情节展开。因为正是人物关系的演变推动了剧情的进展。正如《共产党宣言》所论述的：迄今为止的一切人类的历史都是阶级斗争史。它是符合一阶逻辑的表达方法。因为人物也是对象，只是他是有灵魂动机的对象实体。可见人物关系的角色互交是一个重要的表达层次。

在泳道图中，可以得到各个角色在流程中的工作内容。比如，如下的合同管理泳道图，一般说来，在泳道图里业务逻辑得到了概要的表达，它是业务调研阶段需求分析应该提交的基本内容，也是应用架构必须能与之衔接的关键之处。

那么，应用架构是什么？一般的回答是应用系统，功能模型和程序模块。这其实是面向结构设计的回答。对于面向对象的设计，应用架构就是工作流模型（概念模型）。因为应用架构应该能解决以下几个最关键的问题：其一是与上层的业务架构无缝衔接，这是通过流程来实现的；其二是与下层的技术架构相衔接，比如与服务架构、企业云等应用支撑层相部分，其三要与数据架构相衔接，所以它才是整个企业架构的关键所在。但是不知道为什么，现在关于企业架构的理论对工作流架构都闭口不谈，好像生怕泄密似的。

工作流模型与业务模型的衔接，最精彩的就是把企业所有的活动，区分为两种类型：一种是岗位之间的协作，是传统MIS的管理活动，另外一种是一个岗位上进行的作业活动。在质量管理体系上，它们分别对应的是程序文件与作业指导书。其中流程文件的重点是流程中不同角色的业务协作，它以传递性动词为特点，而不是主谓或者动宾词语为特点；相反，作业指导书是一个节点上的加工（IPO加工）动作，可以视为一个函数，可以是主谓或者动宾结构的语言来表达。为了更进一步的细化功能菜单，我们必须与使用功能菜单的角色相结合，这就是UML的用例图。用例图总是要事先明确是那个角色来使用。所以，用例图显然是面向对象的。它是按照角色来进行屏幕设计的划分。

但是，“活动”一词还有更为精妙的意思。其中“活”强调流程的触发逻辑。因为术语“活动”混淆了状态（state）和动作（action）之间的差异。在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。在流程运行时，这意味着流程引擎必须等待，直到外部参与者通知工作流管理系统指定的状态完成了。比如，等待可进一步运行的认可。动作是在流程运行过程中，工作流系统为响应指定事件（event）运行的一段程序逻辑（programming logic）。当流程运行过程中指定的事件发生时，工作流系统启动并执行这些动作。比如，当状态分配给一个参与者时，发一封Email。你也能看出，状态和动作是如此不同，因此使用同样的术语去描述这些概念是一个坏习惯。我的建议是避免使用术语“活动”，使用“状态”或者“动作”代替它。 如果要更加详细的描述泳道图到底是在什么情况被触发运行的，就必须用更为精确的触发逻辑来表达触发的条件。比如这就是带有事件的流程图。由此可见，泳道图是静态图，是流程运行轨道的拓扑图，而事件触发逻辑是列车运行的信号灯，它是动态流程图，决定流程运行的时机和实际分叉动态情况。由此可见，流程的静态可以是概要设计，而流程的动态则是详细设计。

从这里我们可以知道，从业务逻辑到用例图是很遥远的。用例图表达的只是一个岗位在流程中需要完成的动作。所以，结构化开发方法直接从功能菜单引入应用功能，其中中断了许多关联的逻辑关系。值得注意；一个岗位上的用例图的方法也是一种封装方法，就是界面方法，只描述岗位角色与系统外部（屏幕）的信息互交，并不涉及系统内部的任何技术实现信息。用例图的进一步展开，才是系统内部典型的三层设计架构：即所谓界面显示、服务器（业务逻辑）和数据库（存取模型）。这是一种由表及里的设计方法，非常清晰，是面向对象信息的层层展开方法。正是从用例图引出软件详细设计的开始，从内外分界的方法看，系统理论也是一种面向对象的方法，形成一个系统就是形成一个对象。

从以上讨论可知，一个岗位与系统屏幕的互交是用例图。它基本上就是为实现一个系统功能的屏幕界面操作说明，也就是计算机时代的岗位作业指导书，这无疑应该就是关于屏幕界面上的各种按钮的操作步骤进行说明，也就是所谓的软件操作说明书的内容。但是到了按钮设计，这就涉及到屏幕界面的详细设计部分。应该说系统操作说明书这个文件的很多内容应该是对如何使用界面功能按钮的详细说明，这个操作界面设计是否友好方便应该对于操作人员的意见征求，比如对于批量数据录入应该采取什么方式，对于零星修改数据采取什么方式，这是需求分析调研需要在详细设计阶段进行补充的重要一环。由此可见，正是在这个软件详细设计说明书中，它真正把业务逻辑要求“做什么”的要求进行了技术落实，完成了系统内部对象（界面的内部结构，服务器和数据库）的互交设计，比如完成了人机互交（用例） 的界面内部的按钮功能设计，这些屏幕界面设计如同是电影中的分镜头剧本设计一样，这就是软件详细说明书的内容和任务。

值得注意的是，用例图并不涉及屏幕界面内部的按钮设计。它们是把屏幕视为一个整体对象，在其上的操作流程总结起来可以大致分为两类，一类是正常操作步骤，就是由输入数据经过计算得到输出结果的过程；还有一类是异常操作，就是应该退回或者放弃的操作。通过这种分析，我们可以不再区分屏幕内部的按钮结构，从而得到了用例图的一般表达方法，用例操作的流程表达方法（千万不要把它与前面工作流的流程相混淆）。如果我们继续运用面向对象的方法，对上述用例做进一步的抽象，不去纠缠具体操作的流程细节，只关注这个岗位完成作业加工所需数据和所产生数据，这就是所谓的实质用例分析，也就是IRP（信息资源规划）方法中的C－R矩阵分析方法。由此可见，用例分析给出了屏幕设计的不变量，就是C－U矩阵所表达的IPO函数加工关系，它是屏幕界面详细设计的不变量，即一个岗位角色的所需数据与所产生的数据，这是进行系统验证和验收的重要依据，也是概要设计和详细设计的分水岭。

正是在流程平台上，统一解决功能模型和程序模块的调用关系，特别是体现了“软连接”的特点，随时随地完成“组织岗位、功能程序与数据共享”的风云聚会，解决了解耦程序模块之间硬连接的问题，所以传统概要设计的内容，关于各个功能模块和程序模块的相互调用的关系设计，应该都在流程平台上统一解决了，这样就完成了系统集成架构。同时，工作流平台完成了与技术架构的连接问题，通过流程平台与应用支撑平台衔接，与云平台技术架构等技术平台衔接，与服务总线、标准组件的衔接（程序共享，数据共享），等等

所有这些都大大降低了编码的工作量，建立了一个可以充分共享、可组合服务、可伸缩的可扩展的技术平台框架；比如下面的服务架构就是一个例子：

当然，数据模型的设计是功能模型设计的前提条件。因为程序设计最终可以用C-U矩阵进行表达。就是在数字化转型的今天，为了完成本岗位的工作，必须需要使用U哪些数据来支撑，从而能输出（创造C）工作目标所要求的数据。由此可见，功能模型与数据模型有着密不可分的关系。

什么是数字化转型？一句话：如果企业的每个工作岗位都能自动得到他所需要的数据来源，这就实现了企业的数字化转型。所需数据和所能提供的数据，这就是资源目录体系。它的重要表达形式，职能域之间的所需数据和所产生的数据，就是IRP中的数据流程图DFD，它全局表达了数据来龙去脉的可追溯关系，应该是数据模型概要设计中最重要的内容之一；

作为概念主题数据模型的表达E-R图，也是实体关系模型，也是面向对象都一种表达方式。它利用主外键关系表达了数据的组织关系，比如实体与属性，实体与实体之间的联系关系。这种关系并不仅仅是客观中事物存在的关系，同时也是通过主外键为手段，设计出来的数据检索通道。正因为如此，它同时也为物理存储创造了条件。可以直接由E－R图导入生成物理表结构的数据库。物理表的数量很多，可能有成千上百个，如果我们没有E－R图的直观表达，我们就无法利用这些物理表，无法把它们在概念层面组织起来进行工作。由此可见，ER图也是概要设计应该提交的重要设计内容。

主题数据库的设计是面向对象的。因为主题数据库最基本的内容就是主数据，它正是行业中最具特征的基本对象，因此也称为主数据。比如对于海事业务，有船舶、港口、泊位、航道、货物等基本对象。一个是UML中的实体状态图，这是一个与流程图相结合的使用的，表达在流程中实体状态的变化，是面向对象设计的数据模型的重要体现。这也应该是在主数据分析最基本和最重要的提交物，也是概要设计应该给出的具有统揽全局的内容。其实，微分方程、自控理论的状态方程等，都是用对象的状态来表达物理世界的一般数学方法，它在科学上具有普遍的方法论意义。至于用有限状态机模型来表达动态的世界。这个在前面关于物理语言方案的讨论中已经多次谈过了，详细请参见《表达的探究》“计算机状态变量的指称模型”

另外在UML中的数据建模中，还有一个实体的特化与泛化关系图，这是关于实体分类的属性分析图示。就像学生这个实体对象，其下位概念有本科生，研究生、博士生、函授生等等分类，它们除了具有共同的学生属性，也有各自不同的特化属性。再如，合同的写作模板，也是根据不同的合同分类，制定了不同的文档格式，这是一个显而易见的常识。在软件设计中，这里体现出上下位之间的“继承”关系。这是在数据建模中的一种常见内容，这里就不做过多的论述了。

最后是数据字典。一个行业的数据字典，一般具有三千左右的数据元素构成。数据字典的作用就是给出每一个数据元素的语义定义或者解释。给出这些数据元素之间的千丝万缕的联系，这就是建立行业术语体系的任务。数据字典是进行数据治理最重要的工具。比如当企业新出现一个数据元素的时候，通过数据字典的辅助核查，就可以找到这个新的数据元素应该安置的位置，重新调正它与之前所有数据元素的关系。其实数据字典（结合数据模型），还有一个最重要的问题，是回答数据的语义是如何完成升层次问题，它是如何完成了从事务、到流程、到战略的语义转换。这就是我将在行业术语体系研究中要回答的问题。

但是，对于一个行业而言，现阶段各部门系统之间的对接缺乏统一的数据标准体系和框架，部门和部门之间无法实现大批量的数据交换和实时传递，对接多采用一对一的方式实现数据交换，部门内部和部门之间的数据无法合理的交换使用，各部门系统的数据源也分布不均，无法形成一个统一合理的共享数据源头，大大降低各部门的工作效率，增加各部门的使用成本。所以，在异构系统的环境下，数据模型设计的任务就是要完成主题数据库的设计，即统一数据采集的设计，从而完成保障数据源头唯一，进行多处共享使用的原则。所以，数据字典的当务之急就是：厘清各自为政的异构系统的命名和语义，为它们建立一个概念完整的术语体系，从而来进行数据共享和数据交换。

比如，对于屏幕录入的所有数据定义都有数据字典的支撑，这也是所谓的数据业务逻辑校验的功能：

以上是数据模型设计应该有的提交物。在这个号称大数据的时代，一个据说是完成了数字化转型的时代，除了那些空洞的口号炒作，我们在设计文档应该认真给出的成果物。

（编辑：92站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!