标签：
自己在工作当中经常会遇到需要快速并且完整地了解一个软件系统的事情。本来想写一写如何快速了解一个系统，但想着想着就想到了软件的架构。本文以一个软件业务分析师的视角阐述本人理解的软件架构。目的是提供一个适用的，易用的方法，帮助业务分析师或软件架构师系统地，快速的分析和了解软件系统。如有技术性错误，还请各位大牛指正。
首先来了解一下什么是架构，架构就是为了组织部件和资源，让部件及资源发挥单体所无法发挥的作用，从而实现架构所要达到的战略目标。（有点类似于一个组织存在的目的，说明世界上许多知识都是通用的，只是应用的场景不同）不同的架构本质和目的都一样，甚至架构方法的思想来源都一样，只是所被组织的部件和资源不一样，从而牵引出不同的架构形式。例如企业架构就是为了将企业的人，财，物，流程进行整合，并用IT来实现整合目标，一个软件的架构也类似，就是将数据，功能，网络，流程整合，实现软件的价值。而整合的方法多种多样，不同的方法达到的效果也有差异。架构的目的就是研究如何去整合，协调这些资源，为品质高的系统奠定基础。
这里想说说我为什么推荐自顶而下的分析方法而不推荐自底而上的分析方法。首先解释一下什么叫自顶而下，简单说就是从大到小，从粗到细，例如企业预算的制定：从公司到部门再科室再到成本中心。软件的自顶而下就是从业务到功能到数据，再到基础架构。自底而上就是反过来。那么我为什么推荐自顶而下呢，原因如下：
要想了解一个系统或分析一个系统，首先最重要的就是要了解这个系统存在的价值，是为了提高客户满意度，为了增加企业利润，还是市场发展需要，或是老板睡了一觉，拍拍脑袋想出一个点子。这决定了这个系统或软件在企业当中的地位以及高层对这个系统的支持程度。了解系统存在的价值及系统实现的目标，可以帮助架构师把握核心问题，不在以后的分析过程当中走弯路。虽然这些看似很虚无飘渺，对系统的开发没有实质性的帮助，但却是一个合格的分析师不得不首要考虑的事情。
这一步我们将整个系统作为个体看待。主要是分析这个系统与现有系统之间的依赖关系，会不会对其它系统产生影响。这样也可以初步分析出系统可能会涉及到的外部接口。另外在这一步也要定义出主要的系统功能，不必要太细，但不能遗漏主要功能。
这一步需要分析的内容是最多的，主要包括功能性需求，非功能性需求。功能性需求里分主要业务功能和数据分析及运营要求。功能性需求可以是一个模块实现，也可以是单一的功能点实现。识别出功能块后，要分析功能的完备性和功能之间的联系。如基础的用户管理，权限管理，物流及销售的订单管理，仓储的物料管理，财务的记账等。
数据分析及运营要求包括基础数据维护，运营数据的报表及分析。
非功能性需求指的是保证功能的正确性，支持功能更好地发挥作用的需求。包括常见的安全性，易用性，灾备，也包括一些系统独有的如跨域，单点登录等具体问题。
分析完功能性需求后，就需要着手设计数据库表结构。作为业务分析师，我认为只要能识别及设计出对业务有主要作用的表结构，包括每个字段的含义及作用。分析各表之间的关系即可。当然，数据库表设计是一门专业的知识，要想做得好还得深入研究。这一步的工作与Step3可同时并行。
基础架构即系统运行的环境，包括网络，服务器和数据库系统。一般公司里基本都有一个固定的架构，常用的系统在此基础上就可以完成开发。基础架构是软件运行的基础，却也常常会成为系统技术的瓶颈。分析及了解这些的主要作用就是对系统环境有个大概的了解，避免给客户承诺一些根本实现不了的功能。
以上内容只给出简单描述，不涉及具体的技术分析，详细技术请参考其它资料，虽然内容比较多，但如果能够理清楚，有条理，有针对性地去分析，便能够快速了解一个系统。也能够有目的地去分析还未实现的系统。希望本文可以帮助到系统分析师们。
来自：http://www.cnblogs.com/frank498/p/4487367.html
标签：
原文地址：http://www.cnblogs.com/panmy/p/5635661.html
