软件工程——系统架构

最近老师把师兄们以前做的Android项目发给我和其他同学，让我们把这个项目写成实训教材，说要让一个不会Android的人看了我们的教材就可以做出这个项目。我当时就无语了……（心想不会的人首先想看的是基础教材绝对不会是什么实训教材，而且谁会看我们写的教材啊，除了我们学校的学生，是个人都会选择一些出名的教材）其实，最让我愣一下的是，老师居然让我来写实训教材的项目架构部分，当时都无语了，这个学期学习的Android，才半个学期！自己都还是个菜鸟。无奈吧，做就做吧。我只能说我尽力做，至于做成什么样子就不敢保证了。于是乎，我把上个学期学习的《软件工程》拿来看。当时，因为在做网站（真实项目，我大一上册学的C，我大一下册学的.net，大二上册做的网站，现在都大二下册了），而且客户的要求也一直在变，还熬了几次通宵，各种伤不起啊。上课都在想怎么做，根本都没听老师讲。哎，出来混迟早是要还的，于是我便果断的复习了《软件工程》的系统架构部分。因为，老师要得比较急，前天看书看到凌晨2点。

现在，总结一下自己学到的相关知识：

对于软件系统来说，描述系统架构一般涉及两个方面的内容：业务架构和软件架构。这两个方面的内容分别针对于人们对业务领域的理解和对系统领域的理解。前者是从业务需求的角度出发，理清物理结构图和逻辑结构图，划分出每个子模块，确定为什么这么划分，各个子模块之间如何交互，每个子模块具有哪些接口；后者从技术上着重讨论采用什么样的技术，如何分层，采用哪些好的技术特征，会带来什么好处，为什么要这么做等。

 

业务架构：

　　业务架构描述了业务领域主要的业务模块及其组织结构。

　　

　　业务架构的目的是为业务领域建立一个维护和扩展的结构，描述业务的结构。业务架构对我们理解客户业务，尤其是对软件开发行业确定解决方案有着非常重要的作用。

　　用例模型和领域模型是业务架构的基础。用例模型、领域模型所描述的业务过程，通过抽象可得到业务架构。反过来，业务架构对用例模型和领域模型有着重要的指导作用。

 　　

软件架构：

　　软件架构是一种思想，一个系统的蓝图，是对软件结构组成的规划和职责进行设定。

　　软件架构的意义就在于将这些可逻辑划分的部分独立出来，用约定的接口和协议将他们有机地结合到一起，形成职责清晰、结构明朗的软件结构。

　　软件架构是一个逻辑性的框架结构描述，他可能并无真正的可执行的部分。事实上，大部分的软件架构都是有一个设计思想，加上若干设计模式再规定一些列的规范、传输协议、实现标准等文档构成的。

　　软件架构需要在业务架构的基础上引入计算机环境，计算机环境包括硬件环境和软件环境。硬件环境包括网络拓扑结构、服务器及其他设备等，而软件环境指的是操作系统、应用服务器、中间件、数据库等。

　　一个典型的软件架构包括两个视角：广度视角和深度视角。广度视角即我们常说的软件层次结构，它关注软件的分层，规定每一层的职责以及曾与层之间的通信标准，一般使用包元素来描述；深度视角，是指广度视角中每一层的详细说明，它关注每一层以及每个部分的具体实现架构。

 

软件架构与框架：

　　现实中，很多人把框架和架构搞混，有的人认为架构就是框架，两者是一个东西。其实这是一种不正确的认识。

　　从语言的角度来说，架构的英文原文为：architecture,框架是framework，显示是两个完全不同的词。另外，架构是一种思想，一个系统蓝图，是对系统高层次的定义和描述。框架是针对某个问题领域的通用解决方案，它通常集成了最佳实践和可复用的基础结构，对开发工作起到减少工作量、指导和规范的作用。