架构设计如何做好架构设计与写好架构设计的文档？

为什么做结构设计的我，不止一次想到转行

作为一个刚刚从事结构设计2年多一点的fresh man 来说，或许，我并没什么资格大谈特谈结构设计。

不过我要说的也并不是什么关于结构设计的设计理论，只是想谈谈现在设计为什么经常会出现问题的客观原因罢了。

1毕业生专业基础差 首先肯定是学生自身的原因，有的没努力学习，有的对土木没有兴趣，导致了自己学习成绩差； 然后，和老师有着必然的联系，并不是想说老师的水平不高，只是他们的教学方向是考出好成绩，并不是培养出适应社会需要的学生，而且大部分老师并没又从事过结构设计就直接步入大学殿堂教书了，这样他们根本就缺乏结构设计的实际经验，自然即使努力也没办法让学生掌握他们真正应该掌握，并且能投入实践的知识。

就拿我毕业设计时候的导师来说把，他是北大力学毕业的研究生，他的力学知识在整个教研室具有相当的权威，只是在本专业，结构设计中是完全一窍不通，所以我的毕业设计完全是自己做的，完全凭着自己的发挥，不知何为对，何为错。

这必然为我以后的结构设计带来许多不必要的麻烦。

2当毕业生们抱着满腔的热血投入工作的时候，却发现事实上他们什么也做不了。

毫不夸张的说或许他们连什么是一个完整的结构设计都不知道。

这时候他们是多么的渴望有一个想老师一样的师傅来告诉他们该从哪里入手。

然而可悲的是，几乎很少设计院有这么好的结构负责人（并不想否认他们的能力，只是他们多数没有好脾气，即使有好脾气也没有足够的时间，即使有了足够的耐心去给一个什么都不会的新手。

） 更糟的是：即使在这种情况下，迎接他们的是堆积如山的工作等待他们去做。

试想：一个什么都不会的人直接去从事结构设计，怎么能不出问题。

尽管有校对，又审核，又专业负责人，但实际上，这些人里会真正去看认真图纸的人，恐怕只有在图纸上盖章的那个结构注册师。

但他毕竟不是神，即使他在厉害，也不可能看出所有的问题，一旦出现了一点纰漏，工程问题就直接产生了，小问题就那么地了，但是大问题，恐怕就不知要如何了！ 3在一年两年的煎熬中，这个新手终于稍微不在那么生了，他稍微有了一点点能力，这时候面临的问题更加严重了，注册师审图没那么认真了，更大胆的放手让他去做了，可实际上他们还并没有具备这种能力，此刻他更没人问了。

而且此时的他们已经能意识到工程问题的严重性了，尽管他们十分谨慎，但能力十分有限的他们是在是没又任何办法。

4现在的甲方真的是萝卜荟萃，什么样的都有。

这一点也是我最想强调的，就是甲方总是为了满足市场或者个人的心里需求，不断的修改着建筑方案，一次有一次的修改，现在网上："死了都要改"的这重歌曲比比皆是，有着各种各样的版本，我也不必在罗列了。

如果面对有个性又水平的稍微还稍微好一些，毕竟他的调整虽然也无理，但至少你跟他说这个地方结构不能实现的时候他还懂，至少你跟他说如果这样改动了，方案就全废了需要更多的时间画图，他能理解，尽管他仍旧会每天不停的催促。

如果遇见了一个什么也不懂的，而且没有主心骨的甲方，那你就算彻底倒霉了，不到房子已经交付使用之前，你就天天改吧，往死力改，而且都是免费的。

你的设计费会由原来的50分一直降到连2分都不值，而且还要继续改。

更糟糕的是遇到一个不通情理的结构负责人，他的任务就是代替甲方每天往死力催图，不顾你的休息与健康。

也奉劝朋友们一句，如果遇到了这样的领导，你却没有必死的决心，那么在他们榨干你的最后一滴血前趁早放弃吧。

5干私活，国家又没有明令规定结构设计者禁止干私活，我是不确定的，能确定的就是几乎每个有能力的，甚至没能力的却有关系的都在干私活。

或许有人会问，干私活有什么不好的呢，如果水平高的人干私活，不是可以减少工程的问题吗。

那我想问的是，如果给你比别人3倍的奖金，但却不给你别人同等的时间，而且这个活出了问题又有别人替你承担，你有没有那么大的主观能动性能抽出去别人一样的时间，投入一样的精力来完成这项工作呢。

我想大多数人是没有的，即使有这样的决心，也没这样的精力。

从事这行的人本来就要加班熬夜才能按时完成自己的本职工作，又到哪里能抽出更多的时间与精力投入到私活中啊，只是大家谁也舍不得这份丰厚的收入而已。

这样的结果呢，就是无数的问题随之而产生了。

当然其实除了施工队遭殃，工程质量的不到保证。

在那张图纸上签字的‘设计者’是最不幸的了。

因为钱没赚到，却赚到了一身的责任，时刻要担心着工程出了问题，下半辈子就要在铁窗里度过了！！！ 而且他还要为那张又问题的图纸不停的做修改工作，尽管没有任何费用，而且还要受负责任的气，所有的问题所有的责任就在你签名的一瞬间全部转移到你身上了。

软件的架构，设计和实现是什么概念

软件架构是一个系统的草图。

软件架构描述的对象是直接构成系统的抽象组件。

各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

在面向对象领域中，组件之间的连接通常用接口来实现。

软件体系结构是构建计算机软件实践的基础。

与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

软件设计中系统架构设计包括哪些内容

架构师的职责主要有如下4条： 1、确认需求 在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。

架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。

2、系统分解 依据用户需求，架

如何做好架构设计与写好架构设计的文档？

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 ）。

这种做法不仅有利于我们编写架构设计文档，同时更是一种好的架构设计思考流程。