本文目录
如何做好架构设计与写好架构设计的文档
2 一下是我的写文档的一些心得： 现代架构设计文档的编写 4+1 视图与 UML 软件架构设计已经逐渐成为现代软件开发过程的核心，然而能够清晰表明架构设计并不是一件容易的事，就面向对象开发而言， RUP 的 4+1 视图已在架构设计的撰写中得到了广泛的应用和认可。 对于 4+1 view 的描述有几个不同版本（或包含的视图不同，或视图的名称不同），文中以 Philippe Kruchten, November 1995 提出的 4+1 视图为准。 4+1 视图包括：逻辑视图（ Logic View ），开发视图（ Develop View ），进程视图（ Process View ），物理视图（ Physical View ）和场景视图（ Scenarios ）。 视图间的关系 4+1 视图不仅便于我们记录架构设计，实际上它也指导了我们进行架构设计活动的部分过程。 通常我们选择 UML 来表现各种视图，以下列出了 UML 和各视图的对应关系 4+1 视图 UML 场景视图 use case 逻辑视图 类图 开发视图 类图，组件图 进程视图 无完全对应 部署视图 部署图 在架构设计稳定中通常不会给出较多的用例描述，这些是在需求稳定中定义。但是往往架构文档会选择一些用例，列入文档中，这些用例和一些非功能性需求一起用以证明架构的有效和正确性。在逻辑视图中用例的实现是必不可少的一节，尽管架构设计更关注非功能性需求。 融入 MDA 的思想 对于逻辑视图和开发视图所应包含的内容常常会觉得很难区分两者间的明显界限。逻辑视图包含更多的分析模型与实现技术本身相关性应该较少，如业务对象模型及其扩展。而开发视图则会与实现技术紧密相关。 随着 MDA 思想的推广，在架构设计文档的撰写方面也产生了影响，我们不难把 MDA 的 PIM 和逻辑视图联系起来，而把 MDA 中的 PSM 和开发视图联系起来。 在编写逻辑视图是我们应该描述与技术平台无关的模型，而开发视图则描述与实现技术平台相关的模型。 如在逻辑视图中表现的某些实体类，我们会在开发视图中转换为 EJB 组件（实体 Bean ）。 这种做法不仅有利于我们编写架构设计文档，同时更是一种好的架构设计思考流程。
如何编写软件架构文档
有文档的架构可以提供追溯其他工作产品的上下文。 有文档的架构可以传达可供选择的架构解决方案。 有文档的架构有助于从一个现有架构转换到一个新架构计划的计划编制。 有文档的架构通常能通过识别组成架构的元素及它们之间的依赖性来帮助编制计划。 有文档的架构可以提醒架构师在其所作的某些决定背后的基本原理。 有文档的架构有助于架构的评估。 选择视点。 创建工作产品。 给架构描述打包。 （1）功能性视点：它关注支持系统功能性的元素。 （2）部署视点：它关注支持系统分布的元素。 （3）需求视点：为形成架构的系统需求提供说明，它包括功能性需求、品质和约束。 （4）确认视点：为系统提供必需的功能、展示必需的品质和适应定义的约束提供说明。 交叉视点是从某一特定功能的视点出发，与基础视点交叉综合关注的元素，下图为一交叉视点的例子。 实现层级。 交叉关注。 逻辑视图是设计的对象模型。 过程视图获取设计的并发和同步方面的信息。 开发视图描述的是软件开发环境中的软件静态组织。 物理视图描述了软件与硬件之间的映射，还反映了它在分布式方面的信息。
软件设计的设计文档
在任何系统中，开发文档都是有价值的东西。当下已经有许多不同的经过发展的文档计划可供您在创建系统时候进行选择。软件设计的输出文档包括架构设计文档、详细设计文档、单元测试文档和集成测试文。其中相当不错的一种模型就是所谓的设计规范。第一部分展示了源自于系统说明和其他定义文档的设计成果的总体范围。第二部分展示的是涉及支持文档的详细说明。第三部分的内容又称作设计描述，在初步设计阶段完成。第四、五部分的内容将初步设计阶段的内容发展至详细设计阶段。第六部分展示了确保以下两条原则的交叉参考矩阵：1、用软件设计满足所有的需求。2、指出实现特定需求的关键模块。第七部分在开发测试程序（步骤）的第一步对系统的功能性和正确性进行测试是必要的。如果在开发设计规范的同时已经并行开发了详细的测试程序规范的话，本部分可以删除。第八部分详细说明了将系统打包传送至用户站点的考虑和要求。在文档剩下的第九、十部分中包括了算法描述、选择程序、列表数据、流程图、伪代码、数据流图表、以及所有在设计规范开发时所用到的相关信息都可以放在此处。
架构设计文档如何编写求答案
软件架构设计已经逐渐成为现代软件开发过程的核心，然而能够清晰表明架构设计并不是一件容易的事，就面向对象开发而言，RUP 的4+1视图已在架构设计的撰写中得到了广泛的应用和认可。对于4+1 view的描述有几个不同版本（或包含的视图不同，或视图的名称不同），文中以Philippe Kruchten, November 1995提出的4+1视图为准。4+1视图包括：逻辑视图（Logic View），开发视图（Develop View），进程视图（Process View），物理视图（Physical View）和场景视图（Scenarios）。4+1视图不仅便于我们记录架构设计，实际上它也指导了我们进行架构设计活动的部分过程。通常我们选择UML来表现各种视图，以下列出了UML和各视图的对应关系4+1视图 UML场景视图 use case逻辑视图 类图开发视图 类图，组件图进程视图 无完全对应部署视图 部署图在架构设计稳定中通常不会给出较多的用例描述，这些是在需求稳定中定义。但是往往架构文档会选择一些用例，列入文档中，这些用例和一些非功能性需求一起用以证明架构的有效和正确性。在逻辑视图中用例的实现是必不可少的一节，尽管架构设计更关注非功能性需求。融入MDA的思想对于逻辑视图和开发视图所应包含的内容常常会觉得很难区分两者间的明显界限。逻辑视图包含更多的分析模型与实现技术本身相关性应该较少，如业务对象模型及其扩展。而开发视图则会与实现技术紧密相关。随着MDA思想的推广，在架构设计文档的撰写方面也产生了影响，我们不难把MDA的PIM和逻辑视图联系起来，而把MDA中的PSM和开发视图联系起来。在编写逻辑视图是我们应该描述与技术平台无关的模型，而开发视图则描述与实现技术平台相关的模型。如在逻辑视图中表现的某些实体类，我们会在开发视图中转换为EJB组件（实体Bean）。这种做法不仅有利于我们编写架构设计文档，同时更是一种好的架构设计思考流程。
如何写软件设计文档
按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~详细设计文档规范1.0概述这部分提供对整个设计文档的概述。描述了所有数据，结构，接口和软件构件级别的设计。1.1 目标和对象描述软件对象的所有目标。1.2 陈述范围软件描述。主要输入，过程功能，输出的描述，不考虑详细细节。1.3 软件内容软件被置于商业或者产品线中，讨论相关的战略问题。目的是让读者能够对“宏图”有所了解。1.4 主要系统参数任何商务软件或者产品线都包含软件规定、设计、实现和测试的说明和规范。2.0 数据设计描述所有数据结构包括内部变量，全局变量和临时数据结构。2.1 内部软件数据结构描述软件内部的构件之间的数据传输的结构。2.2 全局数据结构描述主要部分的数据结构。2.3 临时数据结构为临时应用而生成的文件的描述。2.4 数据库描述作为应用程序的一部分，描述数据库结构。3.0 结构化和构件级别设计描述程序结构。3.1 程序结构详细描述应用程序所选定的程序结构。3.1.1 结构图图形化描述结构。3.1.2 选择性讨论其它可供考虑的结构。选定3.1.1中结构类型的原因。3.2 构件描述详细描述结构中的每个软件构件。3.2.1 构件过程叙述(PSPEC)描述构件的过程。3.2.2 构件接口描述详细描述构件的输入和输出。3.2.3 构件执行细节每个构件的详细演算描述。3.2.3.1 接口描述3.2.3.2 演算模型(e.g., PDL)3.2.3.3 规范/限制]3.2.3.4 本地数据结构3.2.3.5 在3.2.3.6设计中包含的执行结果3.3 软件接口描述软件对外界的接口描述3.3.1机器对外接口与其他机器或者设备的接口描述。3.3.2系统对外接口对其它系统、产品和网络的接口描述。3.3.3与人的接口概述软件与任何人的界面。4.0 用户界面设计描述软件的用户界面设计。4.1 描述用户界面详细描述用户界面，包括屏幕显示图标、图片或者类型。4.1.1 屏幕图片从用户角度描述界面。4.1.2 对象和操作所有屏幕对象和操作的定义。4.2 界面设计规范用户界面的设计和实现的规范和标准。4.3 可见构件实现的GUI可见构件说明。4.4 UIDS描述用户界面开发系统描述。5.0约束、限制和系统参数会影响软件的规格说明、设计和实现的特殊事件。6.0测试标准测试策略和预备测试用例描述。6.1 测试的类别规定实施测试的类别，包括尽量详细的描述。这里是针对黑盒测试现象的描述。6.2期待软件反馈测试期待的结果描述。6.3执行界线特殊执行需要的说明。6.4 重要构件确认决定性构件或者需要特殊注意的构件的测试确认。7.0附录设计说明的补充信息。7.1系统可跟踪矩阵一个定期回归系统规格跟踪软件需求的矩阵。7.2 产品战略如果规格说明书是为一个产品设计的，描述相关的产品战略。7.3 使用分析算法描述所有分析活动所使用到的分析算法。7.4 补充信息 (如果有需要特别说明的)
软件的架构与设计模式之什么是架构
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。具体地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心“砖瓦“，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行具体设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。所有的数字都如日历般严谨，风格雄浑。难以想象这是石器时代的建筑物。 图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。（摄影：作者）软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是“方“、“面“。政党起源的要害就是建筑物对人的影响。在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（Forms follows function）。几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为闻名的，当然就是模式理论和XP理论。架构的目标是什么正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。软件系统对于用户的商业经营和治理来说极为重要，因此软件系统必须非常可靠。·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。·可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。 ·可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。·可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当答应导入新技术，从而对现有系统进行功能和性能的扩展·可维护性（Maintainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费·客户体验（Customer Experience）。软件系统必须易于使用。·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。架构的种类根据我们关注的角度不同，可以将架构分成三种：·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有Html服务元件、session服务元件、安全服务元件、系统治理元件等。·物理架构、软件元件是怎样放到硬件上的。比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。 图3、一个物理架构的例子·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。 首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。 架构师软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。
做软件项目设计文档怎么写啊
按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~ 详细设计文档规范 1.0概述 这部分提供对整个设计文档的概述。描述了所有数据，结构，接口和软件构件级别的设计。 1.1 目标和对象 描述软件对象的所有目标。 1.2 陈述范围 软件描述。主要输入，过程功能，输出的描述，不考虑详细细节。 1.3 软件内容 软件被置于商业或者产品线中，讨论相关的战略问题。目的是让读者能够对“宏图”有所了解。 1.4 主要系统参数 任何商务软件或者产品线都包含软件规定、设计、实现和测试的说明和规范。 2.0 数据设计 描述所有数据结构包括内部变量，全局变量和临时数据结构。 2.1 内部软件数据结构 描述软件内部的构件之间的数据传输的结构。 2.2 全局数据结构 描述主要部分的数据结构。 2.3 临时数据结构 为临时应用而生成的文件的描述。 2.4 数据库描述 作为应用程序的一部分，描述数据库结构。 3.0 结构化和构件级别设计 描述程序结构。 3.1 程序结构 详细描述应用程序所选定的程序结构。 3.1.1 结构图 图形化描述结构。 3.1.2 选择性 讨论其它可供考虑的结构。选定3.1.1中结构类型的原因。 3.2 构件描述 详细描述结构中的每个软件构件。 3.2.1 构件过程叙述(PSPEC) 描述构件的过程。 3.2.2 构件接口描述 详细描述构件的输入和输出。 3.2.3 构件执行细节 每个构件的详细演算描述。 3.2.3.1 接口描述 3.2.3.2 演算模型(e.g., PDL) 3.2.3.3 规范/限制 ]3.2.3.4 本地数据结构 3.2.3.5 在3.2.3.6设计中包含的执行结果 3.3 软件接口描述 软件对外界的接口描述 3.3.1机器对外接口 与其他机器或者设备的接口描述。 3.3.2系统对外接口 对其它系统、产品和网络的接口描述。 3.3.3与人的接口 概述软件与任何人的界面。 4.0 用户界面设计 描述软件的用户界面设计。 4.1 描述用户界面 详细描述用户界面，包括屏幕显示图标、图片或者类型。 4.1.1 屏幕图片 从用户角度描述界面。 4.1.2 对象和操作 所有屏幕对象和操作的定义。 4.2 界面设计规范 用户界面的设计和实现的规范和标准。 4.3 可见构件 实现的GUI可见构件说明。 4.4 UIDS描述 用户界面开发系统描述。 5.0约束、限制和系统参数 会影响软件的规格说明、设计和实现的特殊事件。 6.0测试标准 测试策略和预备测试用例描述。 6.1 测试的类别 规定实施测试的类别，包括尽量详细的描述。这里是针对黑盒测试现象的描述。 6.2期待软件反馈 测试期待的结果描述。 6.3执行界线 特殊执行需要的说明。 6.4 重要构件确认 决定性构件或者需要特殊注意的构件的测试确认。 7.0附录 设计说明的补充信息。 7.1系统可跟踪矩阵 一个定期回归系统规格跟踪软件需求的矩阵。 7.2 产品战略 如果规格说明书是为一个产品设计的，描述相关的产品战略。 7.3 使用分析算法 描述所有分析活动所使用到的分析算法。 7.4 补充信息 (如果有需要特别说明的)
软件架构的设计
为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软件构架文档记录有这种描述。架构描述语言(ADL)用于描述软件的体系架构。已有多种架构描述语言，如Wright (由卡内基梅隆大学开发)，Acme (由卡内基梅隆大学开发)，C2 (由UCI开发)， Darwin (由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。 构架构架视图的图形描述称为构架设计图。对于以上描述的各种视图，设计图由以下统一建模语言图组成 ：逻辑视图：类图、状态图和对象图。进程视图：类图与对象图（包括任务 - 进程与线程）。实施视图：构件图。部署视图：配置图。用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。 软件设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。但是，越来越多的公司体会到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。
