软件架构如何进行软件架构设计？

怎么区别软件架构，系统架构，解决方案架构，企业架构

不同的架构方法论，会将架构分为不同视图，每个视图侧重某一个方面、领域的问题。

比如希赛推的ADMEMS架构体系，分为以下几种视图： 1. 数据架构：描述数据的存储结构、格式等方面。

2. 物理架构：描述机器的物理部署、网络拓扑方面。

3. 运行架构：描述运行期线程、进程间的交互工作机制。

4. 逻辑架构：指如何将代码分成不同模块、组件，以及之间的职责分配、交互行为。

5. 开发架构：主要指开发工具的选择，程序单元的划分，开发管理规范流程等方面。

例如分为哪些工程、项目，源代码管理，自动化编译构建、测试、部署等。

目前国际上运用比较广泛的是TOGAF架构体系，他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。

想详细的了解这些架构视图，可以参考这些架构体系相关的书、资料。

另外有很多人无缘无故的抨击架构概念，不知道是出于调侃还是无知。

埃及的金字塔、神庙的建设，不是几个平常的泥瓦匠聚在一起就能够造出来的。

像SAP、Oracle ERP，国内的金蝶等大规模的系统，以及空间站、火箭的控制系统等，没有系统性的架构方法、规范、流程，结果只能是悲剧。

当规模、复杂度没有达到一定程度，比如在一些小的团队、产品中，架构过程可能融入到老板、经理、组长、资历较深的一些开发者中，融入在大家的日常工作中，以至于感觉不到架构的存在。

就算遇到一些问题，因规模不大、复杂度不高，也比较容易调整。

当这些前提条件发生变化时，架构的作用和必要性就逐步的体现出来。

总的来说，一说到架构，如果你懂软件，那么你会了解为一个软件系统，这个软件设计的组成结构，如哪些是基础支持组件，哪些是完成A业务，哪些完成B业务。

。

。

但说道企业架构的时候，就会问，该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构，以及他们如何链接在一起。

我倒觉得，一个企业确实需要这样的架构，但不要神话它，最主要的是业务如何最终体现到软件中和流程中。

而采取分离式设计时，最容易的错误就是各自为政，集成困难。

那么以数据为中心的架构设计，会自然提供集成的基础。

我提到过，企业最重要的资产是数据，甚至不是信息，是数据。

企业的业务流程会变，IT系统会变，所需要的信息与知识会变，唯有数据能够积淀下来。

这有点象自然演进，考古那种，啥都会消失，唐朝可以无比先进，但都会变，我们唯有找到反映当时情况的数据，才可以把握当思的面貌。

什么是软件架构师?

软件架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。

架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。

他必须对开发技术非常了解，并且需要有良好的组织管理能力。

可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。

软件架构师的职责是把需求转换为软件世界的模型。

4+1视图中以use case作为核心，其中功能性需求以及部分非功能性需求会被软件架构师通过分析和设计，映射为各种软件设计模型。

从OOA/OOD角度说，use case 在这个过程中是要转换为各种UML，其中类图，序列图，状态图是最常用到的。

这个转换过程是需要智慧的，use case是目的，各种OO的原则是指导，设计模式是经验，灵活运用是能力。

里面蕴涵了设计的美感，我觉得这个过程是衡量一个软件架构师的最重要的指标。

当然这个过程是迭代和反馈的，我觉得概要设计和详细设计只是思考同一个问题的粒度不同而已。

另外就是我们要熟悉语言，详细设计是要转换为代码的，而且跟语言是有关系的。

语言比如java/c++等，详细设计的模型是有很多不同的。

就需要软件架构师有过这个过程，并且是非常良好的映射。

除了语言就是要熟悉某个技术领域，比如J2EE/.从J2ee来说，可能需要了解比如jsp/servlet/ejb/jndi/jta/jdbc等。

还需要了解各种web framework,o/rmapping,ioc/aop容器等等。

还有的就是一些技术组件和业务组件，不如workflow,rules engine等等。

另外比如各种database.熟悉这些东西的目的，是把这些软件和组件合理并且有机的组织起来成为一个开发的架构。

这个过程是需要创造力和想象力的。

可能很多人认为这个地方正是软件架构师体现能力的地方。

软件架构和系统架构的区别是什么？

软件架构是系统架构的一个子集。

可以说，软件架构也是系统架构，但是系统架构不一定是软件架构，也可以是整个系统集成的网络架构。

因为一个系统可能包括很多部分，而软件仅仅是其中一部分。

如何进行软件架构设计？

软件系统架构设计方法步骤 基于体系架构的软件设计模型把软件过程划分为体系架构需求、设计、文档化、复审、实现和演化6个子过程，现逐一简要概述如下。

体系架构需求。

即将用户对软件系统功能、性能、界面、设计约束等方面的期望（即“需求”）进行获取、分析、加工，并将每一个需求项目抽象定义为构件(类的集合)。

体系架构设计。

即采用迭代的方法首先选择一个合适的软件体系架构风格(如C/S、B/S、N层、管道过滤器风格、C2风格等)作为架构模型，然后将需求阶段标识的构件映射到模型中，分析构件间的相互作用关系，最后形成量身订做的软件体系架构。

体系架构文档化。

即生成用户和研发人员能够阅读的体系架构规格说明书和体系架构设计说明书。

体系架构复审。

即及早发现体系架构设计中存在的缺陷和错误，及时予以标记和排除。

体系架构实现。

即设计人员开发出系统构件，按照体系架构设计规格说明书进行构件的关联、合成、组装和测试。

体系架构演化。

如果用户需求发生了变化，则需相应地修改完善优化、调整软件体系结构，以适应新的变化了的软件需求。