下载文档原格式
概要设计与详细设计的区别概要设计就是设计软件的结构，包括组成模块，模块的层次结构,模块的调用关系，每个模块的功能等等。
同时，还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据,这些数据是什么样的结构，它们之间有什么关系.详细设计阶段就是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述.概要设计阶段通常得到软件结构图详细设计阶段常用的描述方式有：流程图、N—S图、PAD图、伪代码等概要设计和详细设计在软件设计中，大家经常问到的一个问题是:概要设计应该怎样一个概要法，详细设计应该怎样一个详细法？这个问题在公司内部经常有人问。
现在陈述一下.我们公司的研发流程是瀑布型的，这个模型中的分析、设计阶段是基于经典的结构化方法。
结构化设计方法的基本思路是：按照问题域，将软件逐级细化，分解为不必再分解的的模块，每个模块完成一定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。
模块的概念，和编程语言中的子程序或函数是对应的。
这样一来，设计可以明显地划分成两个阶段：概要（结构）设计阶段：把软件按照一定的原则分解为模块层次，赋予每个模块一定的任务，并确定模块间调用关系和接口。
详细设计阶段：依据概要设计阶段的分解，设计每个模块内的算法、流程等。
概要设计阶段:在这个阶段，设计者会大致考虑并照顾模块的内部实现，但不过多纠缠于此.主要集中于划分模块、分配任务、定义调用关系。
模块间的接口与传参在这个阶段要定得十分细致明确,应编写严谨的数据字典，避免后续设计产生不解或误解。
概要设计一般不是一次就能做到位，而是反复地进行结构调整。
典型的调整是合并功能重复的模块，或者进一步分解出可以复用的模块.在概要设计阶段，应最大限度地提取可以重用的模块,建立合理的结构体系，节省后续环节的工作量.概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。
概要设计和详细设计的内容1. 概要设计：俯瞰全局的那把钥匙概要设计，听起来是不是有点高大上的感觉？其实，它就像是一个厨师在准备大餐之前的菜单，先把大致的框架搞清楚，再逐步细化。
这个阶段，咱们主要是从整体上把握项目，确定目标和范围。
就像给一幅画打底，得先画出大致的轮廓，才好慢慢添上细节。
你想啊，如果一开始就去画眼睫毛，最后可能连鼻子都没画出来，那可就闹笑话了。
1.1 确定需求：买菜清单的重要性首先，概要设计的重中之重就是需求分析。
就像逛超市前先写个买菜清单，知道自己需要什么，才能买得心应手。
在这个阶段，团队会和客户沟通，听听他们的需求，确保咱们的产品能满足他们的期望。
这就好比和朋友商量去旅行，得先问清楚大家想去哪里，才好安排路线。
总之，需求分析就是为了把那些模糊不清的想法变得清晰明了。
1.2 设计架构：搭个框架，稳稳的接下来，咱们就进入了设计架构的阶段。
这部分就像搭建一个房子的框架，必须得坚固才能支撑起整个建筑。
概要设计不仅要考虑技术架构，还要关注系统的可扩展性和可维护性。
想象一下，如果一个房子的基础不牢固，后面再加上几层楼，那可就危险了。
所以，概要设计的关键是要有一个好的基础，确保后续的开发能够顺利进行。
2. 详细设计：画龙点睛的过程详细设计，顾名思义，就是在概要设计的基础上，把每个细节都给补充上去。
这个阶段就像是给刚刚搭好的房子装修，选择每一扇窗户、每一扇门，甚至每一盏灯的样式。
详细设计的目标是让系统在技术层面上更加完善，确保每个模块都能高效运行。
2.1 模块划分：分工明确，合作无间详细设计的第一步就是模块划分。
想象一下，一个足球队，前锋、中场、后卫，每个位置都有不同的任务，大家各司其职，才能赢得比赛。
在软件设计中，模块化可以让团队成员明确自己的职责，提高工作效率。
通过划分模块，大家可以并行开发，像打篮球一样，快速传球，互相配合，效率杠杠的。
2.2 接口设计：沟通的桥梁接下来就是接口设计，这就好比是在建造桥梁，确保不同模块之间可以顺畅沟通。
(完整)系统设计：详细设计和概要设计主要内容编辑整理：尊敬的读者朋友们：这里是精品文档编辑中心，本文档内容是由我和我的同事精心编辑整理后发布的，发布之前我们对文中内容进行仔细校对，但是难免会有疏漏的地方，但是任然希望 ((完整)系统设计：详细设计和概要设计主要内容) 的内容能够给您的工作和学习带来便利。
同时也真诚的希望收到您的建议和反馈，这将是我们进步的源泉，前进的动力。
本文可编辑可修改，如果觉得对您有帮助请收藏以便随时查阅，最后祝您生活愉快业绩进步，以下为(完整)系统设计：详细设计和概要设计主要内容的全部内容。
(完整)系统设计：详细设计和概要设计主要内容设计过程包括 2 个主要的规程:概要设计，详细设计。
1. 概要设计：收集相关资料，确定设计目标，完成系统的架构设计。
2. 详细设计：在概要设计基础上，确定接口的详细规格说明。
概要设计模板引言(项目背景、系统任务、设计依据)；总体设计 (设计原则、总体结构、关键技术) ;系统功能设计说明；数据库设计；界面设计；系统安全设计 ;开发工具；系统运行环境1 选择设计方法学：比如使用面向对象设计方式或者结构化设计方式，并且有一个成熟的方法论作为指导。
1 子系统分解:对系统进行分层、分区等处理 ,得到组成系统的子系统 , 降低系统复杂度。
1 确定子系统的服务：定义子系统提供的服务，以及对其他子系统服务的使用情况。
此处的服务不需要对接口做详细地规格说明 .1 设计对象模型：对需求分析中产生的对象模型进行整理，添加解决域实体，根据一些设计模式或者解决问题的需要，对系统中的实体以及它们之间的关系进行整理。
1 确定系统的构件模型：比如有哪些动态库，哪些 COM 组件等；确定哪些类或者文件属于这些构件；确定构件之间的依赖关系 .1 确定系统硬件分布情况：比如是客户机 /服务器,还是分布式系统 ,并且用模型建立它们的关系。
1 确定软件和硬件的映射关系：哪些构件放到哪些机器上 .1 确定系统的数据管理策略:确定对实体的管理是利用内存对象、文件还是数据库方式，并进行建模。
概要设计与详细设计如何做软件工程项目开发分工1.需求分析--产生软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。
不涉及具体实现方法。
用户能看得明白，开发人员也可据此进行下面的工作（概要设计）。
2.概要设计--产生软件概要设计说明书，说明系统模块划分、选择的技术路线等，整体说明软件的实现思路。
并且需要指出关键技术难点等。
3.详细设计--产生软件详细设计说明书，对概要设计的进一步细化，一般由各部分的担当人员依据概要设计分别完成，然后在集成，是具体的实现细节。
理论上要求可以照此编码。
一、概要设计写什么结构化软件设计说明书结构（因篇幅有限和过时嫌疑，在此不作过多解释）1、任务：目标、环境、需求、局限；2、总体设计：处理流程、总体结构与模块、功能与模块的关系；3、接口设计：总体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面）数据结构：逻辑结构、物理结构，与程序结构的关系；4、模块设计：每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；5、运行设计：运行模块组合、控制、时间；6、出错设计：出错信息、处错处理；7、其他设计：保密、维护； OO软件设计说明书结构二、系统设计想（详细设计）格式1.引言1.1编写目的[说明编写这份详细设计说明书的目的，指出预期的读者。
]1.2背景a.[待开发系统的名称；]b.[列出本项目的任务提出者、开发者、用户。
]1.3定义[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
]1.4参考资料[列出有关的参考资料。
]2. 系统的结构[给出系统的结构框图，包括软件结构、硬件结构框图。
用一系列图表列出系统内的每个模块的名称、标识符和它们之间的层次结构关系。
]3．模块1（标识符）设计说明[从本章开始，逐个地给出各个层次中的每个模块的设计考虑。
以下给出的提纲是针对一般情况的。
概要设计与详细设计的区别概要设计就就是设计软件的结构,包括组成模块,模块的层次结构,模块的调用关系,每个模块的功能等等。
同时,还要设计该项目的应用系统的总体数据结构与数据库结构,即应用系统要存储什么数据,这些数据就是什么样的结构,它们之间有什么关系。
详细设计阶段就就是为每个模块完成的功能进行具体的描述,要把功能描述转变为精确的、结构化的过程描述。
概要设计阶段通常得到软件结构图详细设计阶段常用的描述方式有:流程图、N-S图、PAD图、伪代码等概要设计与详细设计在软件设计中,大家经常问到的一个问题就是:概要设计应该怎样一个概要法,详细设计应该怎样一个详细法？这个问题在公司内部经常有人问。
现在陈述一下。
我们公司的研发流程就是瀑布型的,这个模型中的分析、设计阶段就是基于经典的结构化方法。
结构化设计方法的基本思路就是:按照问题域,将软件逐级细化,分解为不必再分解的的模块,每个模块完成一定的功能,为一个或多个父模块服务(即接受调用),也接受一个或多个子模块的服务(即调用子模块)。
模块的概念,与编程语言中的子程序或函数就是对应的。
这样一来,设计可以明显地划分成两个阶段:概要(结构)设计阶段:把软件按照一定的原则分解为模块层次,赋予每个模块一定的任务,并确定模块间调用关系与接口。
详细设计阶段:依据概要设计阶段的分解,设计每个模块内的算法、流程等。
概要设计阶段:在这个阶段,设计者会大致考虑并照顾模块的内部实现,但不过多纠缠于此。
主要集中于划分模块、分配任务、定义调用关系。
模块间的接口与传参在这个阶段要定得十分细致明确,应编写严谨的数据字典,避免后续设计产生不解或误解。
概要设计一般不就是一次就能做到位,而就是反复地进行结构调整。
典型的调整就是合并功能重复的模块,或者进一步分解出可以复用的模块。
在概要设计阶段,应最大限度地提取可以重用的模块,建立合理的结构体系,节省后续环节的工作量。
概要设计文档最重要的部分就是分层数据流图、结构图、数据字典以及相应的文字说明等。
软件概要设计、详细设计、软件设计、用户手册说明1 简介1.1 目的这部分要描述文档的目的。
应该指明读者。
1.2 范围1.2.1 软件名称对软件命名1.2.2 软件功能解释软件产品将完成或不完成的功能（可以直接描述也可以参考相关文档）1.2.3 软件应用描述软件的应用领域（可直接描述也可以参考其他软件文档）2 第0层设计描述2.1 软件系统上下文定义本节描述待开发软件系统与外部实体的关系，可以使用系统结构图来描述系统结构和交互关系。
外部实体属性描述只限于软件设计和描述相关的属性。
考虑到描述的完整性，可参考相关软件实体文档，如OS程序员手册。
2.2 设计思路(可选)2.2.1 设计可选方案对本软件系统的几种设计方案进行分析、比较，并确定所采用的方案。
2.2.2 设计约束1. 遵循标准描述本软件所遵循的标准、规范2. 硬件限制描述本软件系统实现的硬件限制3. 技术限制描述本软件的技术限制2.2.3 其他描述其他有关的设计考虑3 第一层设计描述3.1 系统结构如果本文档是针对增强开发/小特性的设计，继承了原有的系统结构，那么应拷贝原有的系统结构说明，如系统结构图和相应的文字说明，然后在一层设计中明显标识出新增功能在原有系统结构中的位置（属于原来哪一个模块的新增功能，与原有各模块之间有什么交互）。
在后续的业务流程说明、模块分解描述、依赖性描述和接口描述中，如果与本次增强开发/小特性无关的，可以不再重复描述，如果有关联的，应该拷贝原有的设计说明，在此基础上再说明更改的内容。
3.1.1 系统结构描述这里要描述软件系统的总体结构，可以使用结构图、层次分解图或包图来描述，并应说明系统结构划分的原则（例如，基于标准、协议所规定的体系结构，来自于分析模型的结果，或者基于原有体系结构的结果）。
对于使用分析模型的体系结构，应说明分析类的职责及相互关系。
3.1.2 业务流程说明描述系统架构模块/分析类之间的动态交互，来说明用例模型中的典型用例场景，以体现系统功能是如何实现的。
软件设计的步骤及原理软件设计的步骤及原理可以分为以下几个方面：1. 需求分析：在软件设计的起始阶段，需求分析是非常关键的一步。
通过与客户或用户沟通，了解他们的需求和期望，收集、分析和整理用户需求，明确软件要解决的问题。
2. 概要设计：在需求分析的基础上，进行概要设计。
主要包括对软件系统的整体结构和模块划分，以及模块之间的接口设计等。
概要设计的目标是为软件的详细设计提供一个框架。
3. 详细设计：在概要设计的基础上，进行详细设计。
详细设计主要涉及到各个具体的模块的设计，包括确定模块的数据结构、算法、界面设计等。
详细设计需要遵循一些设计原则，如高内聚低耦合、模块化、可重用性等。
4. 编码和测试：在详细设计完成后，进行编码和测试。
编码是实现设计的过程，需要根据设计文档进行编写代码。
测试是为了验证代码的正确性和功能的实现，包括单元测试、集成测试和系统测试等。
5. 验收和维护：软件开发完成后，进行验收，与用户进行交互，收集用户反馈并修正问题。
一旦软件交付用户使用，就需要进行维护，包括修复错误、优化性能和功能扩展等。
在软件设计的过程中，有一些基本原理需要遵循：1. 模块化原则：将复杂的系统分解为多个模块，模块之间有清晰的接口定义，各模块之间相互独立，易于编码和调试。
2. 高内聚低耦合原则：模块内部的元素彼此关联紧密，实现单一的功能，而模块之间的依赖关系尽可能少，以减少模块之间的影响。
3. 可重用性原则：设计和编写可重用的模块，提高代码的复用性，减少开发工作量。
4. 抽象和封装原则：将系统的复杂性隐藏在模块内部，对外提供简单的接口，方便使用和维护。
5. 设计模式：使用设计模式可以提供一种在设计过程中常见问题的解决方案，提高代码的可读性和可维护性。
总之，软件设计的步骤和原理旨在确保软件系统能够满足用户需求、具有良好的设计结构、易于维护和扩展。
概要设计与详细设计的区别概要设计就是设计软件的结构，包括组成模块,模块的层次结构,模块的调用关系，每个模块的功能等等。
同时,还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。
详细设计阶段就是为每个模块完成的功能进行具体的描述,要把功能描述转变为精确的、结构化的过程描述。
概要设计阶段通常得到软件结构图详细设计阶段常用的描述方式有：流程图、N—S图、PAD图、伪代码等概要设计和详细设计在软件设计中，大家经常问到的一个问题是：概要设计应该怎样一个概要法,详细设计应该怎样一个详细法?这个问题在公司内部经常有人问。
现在陈述一下。
我们公司的研发流程是瀑布型的，这个模型中的分析、设计阶段是基于经典的结构化方法。
结构化设计方法的基本思路是：按照问题域，将软件逐级细化，分解为不必再分解的的模块，每个模块完成一定的功能，为一个或多个父模块服务(即接受调用），也接受一个或多个子模块的服务(即调用子模块）。
模块的概念，和编程语言中的子程序或函数是对应的.这样一来，设计可以明显地划分成两个阶段：概要（结构)设计阶段:把软件按照一定的原则分解为模块层次,赋予每个模块一定的任务，并确定模块间调用关系和接口。
详细设计阶段：依据概要设计阶段的分解，设计每个模块内的算法、流程等。
概要设计阶段：在这个阶段，设计者会大致考虑并照顾模块的内部实现，但不过多纠缠于此.主要集中于划分模块、分配任务、定义调用关系。
模块间的接口与传参在这个阶段要定得十分细致明确，应编写严谨的数据字典，避免后续设计产生不解或误解。
概要设计一般不是一次就能做到位，而是反复地进行结构调整。
典型的调整是合并功能重复的模块，或者进一步分解出可以复用的模块.在概要设计阶段,应最大限度地提取可以重用的模块，建立合理的结构体系，节省后续环节的工作量。
概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。
1.1 软件的概要设计1.1.1 概要设计在交通局和开发者双方认可的《需求分析报告》基础上，开发者进行下——步的工作。
首先，开发者需要对软件系统进行概要设计，即系统设计。
概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。
1.1.2 编写概要设计的要求a．一致性概要设计的要求应该与需求分析报告所描述的需求一致。
同时，概要设计的各项要求之间也应该一致。
b．合理性概要设计所提出的设计方法和标准应该是合理的、恰当的。
c．可追踪性对概要设计所提出的各项要求应该可以得到它的清晰的源流，即在需求分析报告客户有明确的需求描述。
d．可行性根据概要设计进行详细设计、操作和维护应该是可行的。
1.1.3 概要设计报告的编写者概要设计报告由开发者根据需求分析报告的要求进行编写。
1.1.4 概要设计和需求分析、详细设计之间的关系和区别需求分析不涉及具体的技术实现，而概要设计注重于从宏观上和框架上来描述采用何种技术手段、方法来实现这些需求。
详细设计相对概要设计更注重于微观上和框架内的设计，是编码的依据。
概要设计是指导详细设计的依据。
1.1.5 概要设计的评审在软件概要设计工作完成后，软件开发者应向交通提交《软件系统概要设计报告》。
在交通局对《概要设计报告》评审通过后，即可进入详细设计阶段。
1.1.6 概要设计格式《软件系统概要设计报告》需按一定的格式进行编写，具体的《软件系统概要设计报告》文档编写模板请见附录B。
1.2 软件的详细设计1.2.1 详细设计在概要设计的基础上，开发者需要进行软件系统的详细设计。
在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。
应当保证软件的需求完全分配给整个软件。
前段时间在项目上因为阅读某公司的软件详细设计说明书，引发了我的一些思考，这既是自己多年来感悟的一次梳理，也作为我从事企业模型咨询工作的一次总结。
因为涉及的内容太广泛，以下尽量用简洁的语言来叙述。
传统的面向结构的设计，概要设计主要是给出系统整体功能菜单，模块之间的调用关系描述，还有软件系统工作环境的说明；详细设计则主要针对一个模块的算法设计，屏幕界面设计，按钮操作设计等等。
面向结构的软件设计缺点主要有以下两点：1、从业务逻辑到功能菜单的跳跃太大，导致需求及变更的追溯性难以保证；2、结构化开发方法不区分内外，不区分层次，编码语句会把信息全部平铺暴露，使用不当会形成太多的耦合点，修改起来牵一发而动全身，所以应变性很差。
软件行业发展变化太快，上世纪颁布的国家标准都不适应了现在的工程实践。
特别是从软件工程转到面向对象的设计，还有所谓的快速迭代开发方法，完全打乱了原来面向结构的设计步骤。
但是，越是变化快，就越需要理出“变中不变”的约束和规范来。
因此，如何才能划分好概要设计与详细设计的界限，明确其设计的基本思想和原则具有至关重要的意义。
从概要到详细，首先就是要贯彻由整体到局部、由概括到细节，由概念模型到物理模型，由业务逻辑到IT技术实现，由“做什么”的描述到“如何做”的可执行步骤，这是一个由表及里、抽丝剥茧、层层深入的分析过程。
要体现企业架构的思想，既要把业务架构与应用架构平滑过渡，无缝连接，需求分析可追溯不跳跃不中断；又要整体架构可扩充，可伸缩，具有松耦合的特点，这样就便于发生需求变动进行修改。
要体现出概要设计与详细设计之间的“松耦合”和“可验收”的两大特点，就必须找到这两者之间的不变量，就是设计的提交物应该达到可检验的颗粒度，形成成果物体现出“变中不变”的抽象关系。
这样从不变量的角度讲，可以说明概要设计书的确完成了任务，作为详细设计的输入起到了约束条件的作用；从可变的角度讲，就明确了在详细设计阶段必须补充的需求调研，这也是设计者具有的主观能动性可以有所作为的部分。
要体现模型驱动的思想，把模型定义描述与它的编码执行区分开，采用SOA的架构思想，参见前面“模型驱动，最重要的顶层设计思想”一文，尽量用业务的语言来描述表达相应的业务需求，比如采用服务组合的方式，把真正的可执行编码放在最后的部分；要采用面向对象的技术方案来落实以上设计原则，首先，离散组件（模块）就是对象，从一个元件的角度，它有对象的封闭性特点，就是区分（划分）出一个元件的内部和外部，这就是面向对象的封装性特点。
所有属性都是对象的属性展开，没有脱离对象的属性。
柏拉图所说独立的“共相”并不存在。
不存在一般的白，只存在白的东西。
任何统计指标总是离不开统计对象，它是一切数据的来源。
封装性的黑盒方法：对象通信接口方法的具体方法，对象互交的接口研究，所谓组件就是区分了内外，组件内的信息只在接口显示，这个方法或者称为对象内在属性的逐步暴露方法，有限信息方法，对象属性的暴露是通过动词（职能域）来完成的，详细论述请参考“实体对象与企业建模的关系”一文。
可以说组件就是面向对象方法的一个特例。
在对象协作中可以采用角色的岗位职责方法来分担系统要求的各项功能，平衡负载，协同调度，这是从组件结构设计到整体系统功能转换的精彩之处，即对象岗位职责分配法：把一个新的任务分配给各个部门岗位，即结构功能法，用结构实现功能的方法，因为对象方法具有黑盒的封装性，它通过接口技术屏蔽对象内部信息的过多暴露、把对象协作和其间的传递函数都简单化。
最简单的接口就是函数，传递函数的方法，IPO的数学表达。
组件之间的通信和互交则是通过接口来完成的，这是组件要进行相互协作的一个前提。
通过组合来完成协作，不仅是共时同步的协作，也可以是流程顺序的协作。
因为组件如何通过组合来完成一个特定的功能，就是组件的一个基本的任务，也是从结构设计到功能实现的典型案例。
正是在这些点上，组件和面向对象有着共同的逻辑。
以下是企业架构几个重要的连接点与不变量的关系：业务逻辑的设计，严格说这属于管理咨询的内容。
制度以文本文件的方式书写了管理要素，其中包括：岗位、事件、记录、场景、系统、角色、授权、风险、术语、活动、客户、服务、绩效等因素，制度形成了企业的各项管理要求，其中有部门岗位职责、管理办法，实施细则、操作规程、作业标准等等，它论述了业务管理的原则与目标，各个部门的分工与职责，对于业务“做什么”和“如何做”给出了描述，并对业务的作业标准给出了说明指导。
业务逻辑就是要表达出以上各项管理要素，流程设计就是要把它们融汇并落实到流程的各个环节中。
值得注意是：制度文件为了能够在企业中明确执行，总是明确以现行的组织部门及岗位来确定职责。
所以，一旦组织部门岗位发生了变动，流程相关执行者也会重新界定。
因此，在企业模型中，业务模型（业务架构）中职能域体现的业务原逻辑，应该是技术实现（计算机或者手工）和部门岗位的不变量，这是它形成企业模型具有稳定性的重要因素。
因此也称它为业务原逻辑，它具有原型的意义，通常就是以业务流程的形式来表达。
流程是业务架构与应用架构最重要的衔接点。
面向对象的设计优于面向结构的设计首先体现在这里。
从业务需求角度，必须描述到流程角色协作的泳道图。
过去面向结构设计的功能菜单就于此连接不上，找不到具体的使用者，跳跃太大。
只是通过系统管理员来分配功能菜单的使用权限的方式来衔接业务逻辑显然是不够的明确，这远没有UML（统一模型设计语言）的用例图表达的清晰准确。
在UML语言中，角色对象的互交图，表达了一个流程参与角色的职责，但是它并没有展开流程更多的细节，它的进一步展开就可以得到泳道图。
互交图的展开是泳道图，互交图是人物关系，泳道图是事件的展开。
这其实也是长篇小说的写作方法，先思考人物关系，然后才是跌宕起伏的情节展开。
因为正是人物关系的演变推动了剧情的进展。
正如《共产党宣言》所论述的：迄今为止的一切人类的历史都是阶级斗争史。
它是符合一阶逻辑的表达方法。
因为人物也是对象，只是他是有灵魂动机的对象实体。
可见人物关系的角色互交是一个重要的表达层次。
在泳道图中，可以得到各个角色在流程中的工作内容。
比如，如下的合同管理泳道图，一般说来，在泳道图里业务逻辑得到了概要的表达，它是业务调研阶段需求分析应该提交的基本内容，也是应用架构必须能与之衔接的关键之处。
那么，应用架构是什么？一般的回答是应用系统，功能模型和程序模块。
这其实是面向结构设计的回答。
对于面向对象的设计，应用架构就是工作流模型（概念模型）。
因为应用架构应该能解决以下几个最关键的问题：其一是与上层的业务架构无缝衔接，这是通过流程来实现的；其二是与下层的技术架构相衔接，比如与服务架构、企业云等应用支撑层相部分，其三要与数据架构相衔接，所以它才是整个企业架构的关键所在。
但是不知道为什么，现在关于企业架构的理论对工作流架构都闭口不谈，好像生怕泄密似的。
工作流模型与业务模型的衔接，最精彩的就是把企业所有的活动，区分为两种类型：一种是岗位之间的协作，是传统MIS的管理活动，另外一种是一个岗位上进行的作业活动。
在质量管理体系上，它们分别对应的是程序文件与作业指导书。
其中流程文件的重点是流程中不同角色的业务协作，它以传递性动词为特点，而不是主谓或者动宾词语为特点；相反，作业指导书是一个节点上的加工（IPO加工）动作，可以视为一个函数，可以是主谓或者动宾结构的语言来表达。
为了更进一步的细化功能菜单，我们必须与使用功能菜单的角色相结合，这就是UML的用例图。
用例图总是要事先明确是那个角色来使用。
所以，用例图显然是面向对象的。
它是按照角色来进行屏幕设计的划分。
但是，“活动”一词还有更为精妙的意思。
其中“活”强调流程的触发逻辑。
因为术语“活动”混淆了状态（state）和动作（action）之间的差异。
在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。
在流程运行时，这意味着流程引擎必须等待，直到外部参与者通知工作流管理系统指定的状态完成了。
比如，等待可进一步运行的认可。
动作是在流程运行过程中，工作流系统为响应指定事件（event）运行的一段程序逻辑（programming logic）。
当流程运行过程中指定的事件发生时，工作流系统启动并执行这些动作。
比如，当状态分配给一个参与者时，发一封Email。
你也能看出，状态和动作是如此不同，因此使用同样的术语去描述这些概念是一个坏习惯。
我的建议是避免使用术语“活动”，使用“状态”或者“动作”代替它。
如果要更加详细的描述泳道图到底是在什么情况被触发运行的，就必须用更为精确的触发逻辑来表达触发的条件。
比如这就是带有事件的流程图。
由此可见，泳道图是静态图，是流程运行轨道的拓扑图，而事件触发逻辑是列车运行的信号灯，它是动态流程图，决定流程运行的时机和实际分叉动态情况。
由此可见，流程的静态可以是概要设计，而流程的动态则是详细设计。
从这里我们可以知道，从业务逻辑到用例图是很遥远的。
用例图表达的只是一个岗位在流程中需要完成的动作。
所以，结构化开发方法直接从功能菜单引入应用功能，其中中断了许多关联的逻辑关系。
值得注意；一个岗位上的用例图的方法也是一种封装方法，就是界面方法，只描述岗位角色与系统外部（屏幕）的信息互交，并不涉及系统内部的任何技术实现信息。
用例图的进一步展开，才是系统内部典型的三层设计架构：即所谓界面显示、服务器（业务逻辑）和数据库（存取模型）。
这是一种由表及里的设计方法，非常清晰，是面向对象信息的层层展开方法。
正是从用例图引出软件详细设计的开始，从内外分界的方法看，系统理论也是一种面向对象的方法，形成一个系统就是形成一个对象。
从以上讨论可知，一个岗位与系统屏幕的互交是用例图。
它基本上就是为实现一个系统功能的屏幕界面操作说明，也就是计算机时代的岗位作业指导书，这无疑应该就是关于屏幕界面上的各种按钮的操作步骤进行说明，也就是所谓的软件操作说明书的内容。
但是到了按钮设计，这就涉及到屏幕界面的详细设计部分。
应该说系统操作说明书这个文件的很多内容应该是对如何使用界面功能按钮的详细说明，这个操作界面设计是否友好方便应该对于操作人员的意见征求，比如对于批量数据录入应该采取什么方式，对于零星修改数据采取什么方式，这是需求分析调研需要在详细设计阶段进行补充的重要一环。
由此可见，正是在这个软件详细设计说明书中，它真正把业务逻辑要求“做什么”的要求进行了技术落实，完成了系统内部对象（界面的内部结构，服务器和数据库）的互交设计，比如完成了人机互交（用例）的界面内部的按钮功能设计，这些屏幕界面设计如同是电影中的分镜头剧本设计一样，这就是软件详细说明书的内容和任务。
值得注意的是，用例图并不涉及屏幕界面内部的按钮设计。
