系统架构师-基础到企业应用架构系列之--介绍篇

什么是系统架构

软件架构的起源

      软件中的系统架构，其实是从建筑行业中的架构设计参考过来的，但是软件中的系统架构又有很大的特殊性。特殊性表现在，软件的架构可以在设计完毕后，项目进行的过程中进行相应的变化，或者可以推到重来，但是建筑行业中却不能这么做。软件行业有着很大的变化性。

什么是架构

架构总体来说就是实现需求功能的较复杂组件的设计与不能精简的较复杂组件。ISO与IEEE对系统架构的定义：一致认为软件密集型系统的架构分为主要模块，组织模块与支撑模块3部分。

系统架构的目标

 

功能：功能上必须满足需求。

可靠性：系统系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

可用性：系统必须可用。

可维护性：系统的维护包括两方面，一是排除现有的错误，二是将新的需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费

安全性：系统所承担的交易的商业价值极高，系统的安全性非常重要。

可扩展性：必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

系统架构师的职责

      系统分析员通过与项目干系人的沟通或者是与客户的沟通整理出来功能需求，形成需求文档，然后将文档交付给系统架构师，系统架构师负责将分析员整理的需求转换为详细设计说明书。这个详细设计书作为与开发人员沟通的主要工具。

      系统架构师可以通过使用UML建模工具,在详细设计说明书中书写每个组件的设计用力图或者流程图，或者是通过IBM的relations Rose工具来实现相应的建模。

      系统架构师在设计时遵循的原则是：

      1、低耦合：就是要求不同的组建之间的耦合度最低。每个组建的功能应尽量的分离，他们直接的调用关系进行把对象的引用转换为接口的引用。

      2、高内聚：功能相像的功能放在一个组件中，对外提供接口调用的方式来整理。

      系统架构师作为需求分析师与软件开发工程师之间的核心关键。好的系统架构不但可以满足软件的功能需求有更好的扩展性，可维护性，安全性，可靠性的等等。

      系统架构师必须参与到开发的全过程。

系统的需求

      一般来说。系统的需求分为：功能性需求与非功能性需求。

系统架构设计影响的原因

      系统架构师在进行系统设计的时候一般采用的方式是通过逻辑分层将功能相像的模块放在单独的层中，然后通过分层来实现系统的功能分离与低耦合、高内聚的原则。

      系统架构的设计与系统采用的开发方式有关，软件的开发方式可简单分为：传统方式与敏捷开发。

      传统方式：大家熟知的瀑布型模式，软件的过程严格的按照上级步骤执行完毕后开始下一步骤。

      敏捷开发：则是递增需求的迭代开发。每个阶段都会新增一个需求，完成这个需求之后变发布软件，虽然软件的功能不全，但是至少是可以使用的。

      系统架构师的设计方案，最后由项目干系人进行确定，确定采用哪个设计方案，当然最后也可能不采用，造成这样的结果，可能的原因是非功能性需求的原因。非功能性的需求：例如与之前系统的继承，硬件设备，网络环境等等。

 

系统架构的设计方案

      系统架构可以简单的分为隐式架构与显示架构，例如：盖一个小狗的棚子，有经验的架构师在自己的脑海中就已经有了如何去架构。这就是隐式架构。有些情况下：系统的功能比较复杂和细化，我们不可能在脑海中就能想出来如何架构，需要通过做demo或者模块化的划分来设计，这就是显示架构。

      系统的架构设计，必须考虑设计的可行性，可扩展性，健壮性，可用性，高效性，安全性等方面，还要考虑软件所处的环境等等，各方面的因素都要考虑，否则等软件开发的过程中发现系统架构设计中的不足再去修改，代价是很昂贵的。

 

系统架构说明

因为本人初次写博。部分描述不清楚的部分在所难免，错字方面还请见谅，还请大家多多提出交流意见，大家共同提高。

 

下一篇将对系统架构的具体实践展开讲解

 

最后CallHot 会尽心尽力写好这个系列，同时由于是自己对这些知识的使用总结和心得体会，错误之处在所难免,所以希望大家能够多多指点，这样在使一部分人受益的同时也能纠正我的错误观点，以便和各位共同提高，后续文章敬请关注！