阿东的小蝴蝶
UIDesigner是腾讯用户研究与体验设计部（CDC）设计研发的一款设计类软件，打造一款可以让设计师统一平台和团队协作的平台型设计工具，经过1.0和2.0版本的经验沉淀，我们决定对3.0版本进行全新的架构设计。
开发一个软件系统，前期的架构设计承载着整个软件的设计思想和关键决策，可以说是重中之重。
根据软件架构设计思想，关注分割和交互，好的架构必须使每个关注点相互分离。我们进行了最基本的需求分析，得出两个关注点：一是工具，二是设计绘图，关系如图1所示。
得到最基本的两个关注点后，接着将提取关键需求（包括：关键功能需求、关键质量需求和关键商业需求），根据两个关注点进行架构的细化设计。
一、关注点——工具
这里我们结合UIDesigner的实际需求，提取出属于“工具”范畴的关键功能需求、关键质量需求和关键商业需求。
首先，“工具”的关键功能需求，必须包括：磁盘文件读写、异常捕捉、日志记录、安全性管理；非工具所必须，但是UIDesigner本身所要求的，包括：配置管理、缓存管理、线程服务、服务器和客户端通讯管理、国际化服务。
其次，“工具”的关键质量需求，质量需求包括开发期质量需求和运行期质量需求两部分，经过分析和权衡，UIDesigner的性能主要取决于设计绘图，而稳定性、可扩展性和可维护性才是决定“工具”本身发展的质量需求，因此，对“工具”的质量需求设计将以稳定性、可扩展性和可维护性为主。
最后，“工具”的关键商业需求，因为UIDesigner本身并没有很复杂的业务需求，因此关键商业需求是在设计流程的优化和规范上得到体现，这方面的设计已经属于高层模块和使用流程的设计，对架构的影响非常小，可以暂时性的忽略。
经过关键需求的提取，我们得到了“工具”的设计目标——可以提供通用功能（关键功能需求）的高稳定性、扩展性和维护性的客户端应用。根据此目标，我们采取了DI（Dependency-Injection）和MVP（Model-View-Presenter）结合的架构，概念架构设计如图2所示。
如何进行软件架构设计？
软件系统架构设计方法步骤
基于体系架构的软件设计模型把软件过程划分为体系架构需求、设计、文档化、复审、实现和演化6个子过程，现逐一简要概述如下。
体系架构需求。即将用户对软件系统功能、性能、界面、设计约束等方面的期望（即“需求”）进行获取、分析、加工，并将每一个需求项目抽象定义为构件(类的集合)。
体系架构设计。即采用迭代的方法首先选择一个合适的软件体系架构风格(如C/S、B/S、N层、管道过滤器风格、C2风格等)作为架构模型，然后将需求阶段标识的构件映射到模型中，分析构件间的相互作用关系，最后形成量身订做的软件体系架构。
体系架构文档化。即生成用户和研发人员能够阅读的体系架构规格说明书和体系架构设计说明书。
体系架构复审。即及早发现体系架构设计中存在的缺陷和错误，及时予以标记和排除。
体系架构实现。即设计人员开发出系统构件，按照体系架构设计规格说明书进行构件的关联、合成、组装和测试。
体系架构演化。如果用户需求发生了变化，则需相应地修改完善优化、调整软件体系结构，以适应新的变化了的软件需求。
软件架构师主要是做什么啊？
主要是管理与技术两方面的能力，管理与技术两手都要硬，而技术是基础。技术不行、退化了，那只好做 PPT 架构师、首席布道师之类的。
技术能力
软件架构师是一位具有一定技术、产品、项目和团队等管理能力的高级程序员（编程高手），通常是一个开发团队里面技术最牛（或者比较牛）的少数几个人之一。架构师自身的技术水平和管理水平不行，常常会把团队带沟里，重要性可想而知。
成为架构师需要较长时间的一线开发经验的积累。单纯看工作年限，一般 3-5 年可成为初级架构师，5-8 年可成为中级架构师，8-10 年以上可成为高级软件架构师，当然这只是大致的估计，具体达到何种水平还要看架构师的实际能力。
经年累月，摸爬滚打，一位优秀的软件架构师需要掌握的技术能力很多，先说几个最基本的。
建模
软件开发领域的建模能力，主要是指抽象的思考能力。
普通码农通常用代码思考，负责一个系统中的几个小模块，所以思维常常局限在低层（low-level）、战术（tactic）的层面，考虑的基本上大多是某个功能、某个模块实现的具体细节与技巧。这是应该而且正常的，是团队合理分工的结果。
而架构师，顾名思义，要负责整个系统的架构，尤其是涉及到一个系统（或子系统）全局的整体设计，所以往往需要高层、上层（high-level）的战略（strategic）层面的思考，这样就必然需要架构师经常进行建模（Modeling），对代码、模块、子系统和系统中的各种静态结构、关系和动态行为、交互等等进行抽象。所以，在架构师的日常工作中，经常看到各种各样的图表、图形符号和模型，是很正常的。
可以说，不会建模，不习惯于用模型思考的程序员，是很难成为一名称职的软件架构师的。这里不得不推荐一下动力节点，他们的教学方式和其他机构截然不同：
这里以全栈教学为主，精通前段后端，程序设计思想，并且培养真实企业项目开发经验
系统分析与设计
前面已经说了，系统分析与设计（System Analysis and Design）的主要技术手段是建模，两者是高度重合的。
编程的四门功课
上图画的是任何软件开发、软件工程必然离不开的四门基本功课（四项基本活动或任务）：
1、需求分析
2、设计实现
3、测试验证
4、调试纠错
把这四项活动连起来正好组成一个菱形，所以我也把它们叫作“编程之钻”（The Programming Diamond）。
这四门功课既可以看作是一个团队在整个项目开发过程中所连续从事的必不可少的四项基本活动（团队层面），也可以看作是一名程序员在日常开发中为了实现一个需求而需要完成的必不可少的四项基本任务（个体层面）。
从一个功能的需求分析，到程序设计、编码实现，再到测试确认这个功能的完成，以及发现错误后进行调试定位、代码修改、设计重构或优化，再次进行测试和确认，通过后再选择下一个需求进行分析，如此周而复始。。。这四个基本动作正好构成一个功能开发的小循环，也是每个程序员日常工作的标准核心动作。
那么，为什么普通码农的开发不如编程高手，总是比别人慢，往往也不如别人的好？可能有许多种原因。有一个比较简单的办法能帮你找到开发的瓶颈：评估一下以上这四项任务在你的日常开发中的时间占比。
我这 20 年的观察是，国内许多码农的开发效率低、质量不高，是因为他们往往在 Coding、Debugging 上花去了大量时间（人称 code-and-fix），而在“编程之钻”的需求分析、自动测试、架构设计等其他几个重要方面往往草草带过，占比明显不平衡。
什么原因？因为许多人不知道怎么有效率、高质量地去做需求分析、自动测试、架构设计以及调试除错，以为只有 Coding（编程语言的语法技巧和框架 API 如何使用等）最重要，忽视了其他的软件工程关键实践，于是导致个人整体的开发速度和质量降低，老是提不上去。
而这又是什么原因造成的？因为一方面“软件工程无用论”长期存在，加上浮躁和急功近利的社会风气，影响了人们的观念和意识，导致追求短平快、糙快猛；而另一方面仅通过大学短短的四年，常常很难全面、扎实地学到并掌握“编程之钻”的关键技术，而工作以后又常常忙于加班应付、各种赶工期，缺少足够的时间来学习提高自己的开发水平。
软件项目管理 软件架构设计两个方向有什么区别和联系??哪个更好点??
对，我自己认为软件项目管理比软件架构设计能高级一些，
一个软件编程方面的 一个软件质量管理方面的
如何成为软件架构师
【原创回答】我本人是一名软件架构师，这个问题非常大，不太好回答。我总结一下，软件架构师的能力大概分为三个方面：1.技术，这个应该没悬念，如果没有过硬的开发技术，就不要期望做架构师了；设计模式，系统模式，架构模型，系统理论，甚至编程语言，算法，操作系统，网络，数据库，都需要有扎实的掌握。 2.是业务知识，也即领域知识。软件架构师实际上是把业务需求落实成开发蓝图的总设计师，如果你对业务一窍不通，空有一身技术也只能望业务兴叹。3.就是沟通表达的能力，架构师需要推进自己的架构设计理念给开发团队，所以也需要这方面的能力，当然最重要的还是前两部分的能力。
软件架构和设计模式有什么区别
设计模式是架构的手段（之一）。
具体一点说，设计模式可以在某些情况帮助架构软件的静态结构。
而架构的范围要大一些，更高层一些，考虑的更多的是非常重要的全局性的design decision。一般好的（静态）架构可以尽量使变化发生在局部（模块内）而不影响整个系统。架构上的变化往往成本会非常高。
而且设计模式只有一些是适用于架构的，还有一些只是用于具体的类设计的，剩下的一些则只是克服编程语言的限制而已。
打个不恰当的比方，有点像挡拆和战术的关系。
在合适的情况下用好挡拆可以很好的执行战术，
但战术不只有挡拆，
而且有的战术不需要挡拆，
最重要的是盲目的用挡拆有时候反而会起反作用。
面对客户哔哔时，我们用需求分析架构。
面对整个软件或系统时，我们谈论架构分析。
面对软件模块设计时，我们使用设计模式。
面对模块实现时，我们应用特定编程语言的特性。
软件架构 ：一般场景下拥有设计的选择权
设计模式 ：选择后特定场景下的最佳实践
软件架构是软件的一种搭建形式，往往规定了软件的模块组成，通信接口（含通信数据结构），组件模型，集成框架等等。往往规定了具体的细节。
设计模式是一种软件的实现方法，是一种抽象的方法论，是为了更好的实现软件而归纳出来的有效方法。
实现一种软件架构，不同组成部分可能用到不同的设计模式，某一部分也可能可以采用不同的设计模式实现。
程序员，架构师，软件工程师的区别
1、程序员，架构师，软件工程师的能力要求不同，程序员是从事程序开发、程序维护人员，但是不擅长写文档。软件工程师的技术要求比较全面，会熟练的写语言代码，也会写一些项目的文档。架构师是软件开发过程中的重要人物，主要负责大系统项目的架构设计。
2、程序员，架构师，软件工程师级别不同，程序员分为初级程序员、中级程序员，软件工程师是从事软件职业的人员的一种职业能力的认证，架构师是团队领导型人物，是需要从资深软件工程师里面提升为架构师。
3、程序员，架构师，软件工程师平均年薪不同，美国谷歌程序员的工资最低年薪平均水平为12.8336万，软件工程师平均工资较高，谷歌软件工程师年薪平均水平为25-30万美元，架构师的工资水平是最高的，谷歌大数据架构师年薪为50-60万美元。
参考资料：百度百科—软件架构师
架构师必看：谈软件架构师如何做好架构设计（
此文转载至：帐前卒
1 前言
软件架构设计是软件设计的一部分，相当于总体设计，是软件设计过程中一个决定性的环节，架构确定了，软件基本也就定型了。而软件架构师则是软件项目的领军人物，是软件设计过程中最具挑战性的角色，从技术角度来讲，他承担了项目的成败责任。
EEEC给“架构师”的定义为“软件架构师是技术主管”，这就意味着他不仅要有高超的技术才能，还要有很好的领导才能，他的领导能力在团队中和软件质量控制中起着十分重要的作用。作为一个架构师，他要掌握整个软件项目的前景，调节各小组间关系，要让所有的项目组成成员了解大家共同的目的和目标，并发布标准和章程；要能正确理解软件过程，要在宏观上拥有专业知识，应该拥有很好的设计技巧；要是一个很好的沟通员和谈判代表，要能做出正确的决策等，除此，还有许多他要具备的其它素质。
2. 做好需求调研和分析
为保证软件的可用性，要从需求出发设计架构，即：做软件先做需求，这是软件业内人士的共识，但这项工作做得好的却很少。根据调查，属于需求分析和软件设计错误与缺陷的约占软件错误与缺陷的64%；而属于程序代码错误的仅占36%；而因软件错误积累与放大效应，造成整个软件项目拖延或失败情况的高达20%～60%。这些数据表明，搞好需求调研和分析是软件设计和开发的第一步。架构师必须要在需求调研的初期就介入，以保证需求获取的及时、可靠、准确，并对下步工作起指导作用。进行需求调研，不能就事论事，对用户的需求调研要全面、细致。需求要进行全局性的分析，需要有全局的观点，而不是分散地、根据具体的应用开发而进行的调研，这样才能系统地、本质地、概括地把握软件的功能结构。在调研过程中，自始至终都要有用户方的业务人员参加，尤其是强调高层管理人员的重视和亲自参与，架构师及其相应的工作小组要有足够的沟通和理解能力，要能使业务人员在需求调研阶段起主导作用，架构师仅起协助和引导作用，并提供需求调研的科学方法和过程。
2.1 熟悉建设单位，定义职能域
在需求调研阶段，架构师首先要全面了解用户中所有人员的需求，首先要了解建设单位的组织机构、业务关系，并根据建设单位中的一些主要业务活动领域，研究定义职能域，这是第一重要任务。职能域是用户功能规划的抽象，应符合建设单位内部各种业务的逻辑关系，而不是现行机构部门的翻版，一经识别，就要保持相对稳定。研制职能域模型时，需要特别注意，要自顶向下规划，并把握好设计职能域的数目；注意用户需求的主次关系，按照重要性、优先级进行权衡取舍。
2.2 详细调研各项业务过程及其功能分解
每个职能域都包括一定数目的业务过程，业务过程可以继续分解为业务活动（对应于未来的软件功能），每个功能再分解为更低层的功能，逐级向下分解，直到产生最基本的、不可再分的最小功能单元。
职能域和业务过程都要独立于当前的组织机构，因为组织机构可能变化，部门的分工也会变化，但整个单位的基本职能和业务相对稳定。职能域或业务过程可能横跨两个或多个业务部门。业务过程的确定可以对照组织机构中各部门负责人的职责来考虑，这样，也可能获得未来软件的操作权限、数据权限的分配和功能模块的划分，这些业务过程是一个单位运作的基本工作，不受报告层次和具体负责人变动的影响。
调研前，架构师要对调研的内容事先准备，针对不同管理层的用户询问不同的问题，列出问题清单，将操作层、管理层、决策层的需求既联系又区分开来，形成一个金字塔，使下层满足上层的需求。调研时，要收集用户工作中涉及的所有内容，如各种单据、报表、处理规则，再将其串成流程图，以流程图为主线，同时把握以下方面：
（1）该流程中是否存在不必要的环节；
（2）流程是否可以简化，是否可以省略一些环节；
（3）流程中的每个处理环节是否起到了增值提效的作用；
（4）哪些流程可以并行处理。
2.3 在调研具体业务时工作小组要把握的重点
（1）平均频度
业务发生的频繁程度称为频度，这个数字可以是一个平均值或统计值。频度越高，数据量越大，对响应时间、易操作性等要求就越高。在数据存储时，对大频度的业务或单据要进行充分的考虑。
（2）高峰期的频度
必须保证软件在高峰期的响应时间，对软件进行测试时，要模拟高峰期的业务频度。
（3）单据要求
单据上的内容也就是单据的属性，它是进行数据结构设计的最基本依据。数据的精度是定义数据库中字段长度的依据；计算生成方法是设计算法的依据；取值范围与计算生成方法是数据完整性检测的依据。
（4）利于减轻工作量
减轻人员的工作量是采用新软件的一个目的，花费时间最多、处理方法最复杂的地方往往是软件最关键的地方，也是用户将来验收时最关心的地方。实际上有很多报表由于工作量相当大，用户没有足够的人力与时间来进行处理，这时他便想到了计算机。
（5）单据报表流程
要了解单据或报表的来源、单据联数、每联用途、送交单位、送交时间，对来源与去向的追踪可以调查出各个业务、各个单据、各个报表及各个部门之间的联系。
（6）特殊情况的处理与纠错
对于特殊情况的处理，体现了软件灵活性，但这其中也隐含着安全危机。用户领域中有很多“合理但不合法，不合理也不合法”的特殊情况，它们出现的机会比较少，在调研时要将这些易遗漏的问题挖掘出来，这些特殊情况有时是软件必须要处理的。
当用户在某个作业环节出现失误时，手工软件有的采用正规的手续进行纠错，有的则相当随便，这些情况出现的概率也很小，在调研时，可采用穷举的方法，假定在每一个环节都出现失误，逐个环节询问用户的处理方法，防止遗漏。这些细节如果不调研清楚，往往会对软件产生深远的影响。
（7）考虑长远
将来用户需求的变化是很正常的现象，如果仅仅着眼于现在，而不对将来有所考虑，软件的寿命便不会长久，要将以后可能的变化考虑在内。需求获取后，务必要将调研的成果编制为文档，可视化需求调研，提供不同的图给不同层次的用户进行确认。对高层领导，可提供总体职能域图或业务流程图，对业务管理人员可提供业务流程图或业务活动图，甚至可以画出用户界面的草图。
3 需求分析与设计
架构师所带领的团队做出的关于软件体系结构的决策，将直接影响软件开发的难度和软件维护的难易度，最终决定软件开发的成败。
作为一个架构师，在进行架构设计时，必须具备以下基本能力：
（1）他要把整个团队组织在架构周围，并积极地投入到计划活动上，要把架构转化完成任务的先后顺序，这样才能及时地确定在什么位置用什么技术。
（2）架构师要在技术上做宏观决策，不必关心细节化的事情，由于技术的变化过于频繁，架构师要时与这些变化同步；架构师必须至少能对各种技术有一个整体上的了解，能够熟知每种技术特点及优缺点，只有这样，架构设计师才能在特定的应用场景下，正确地选择各种技术来设计软件架构。
（3）架构师要能预测最小化项目中可能出现的风险，因为这直接影响到软件架构的稳定性。
（4）架构师要能与开发人员保持良好的沟通，确保软件设计的实现。
转载请注明出处51数据库 » 软件架构设计第二 用什么工具画软件架构设计图
