软件构架思考（1）--软件系统和软件构架

walkcamel 2003-08-22 03:07:40

涉及软件构架有大半年的时间了，期间也看了不少的资料，渐渐的有了一点点想法，由于还在学生阶段，没有很多的实践机会，也不知道自己的这些想法是对是错。而且总是在看，没有整理，渐渐的自己也陷入很迷茫的境界，所以就想把自己想的东西写出来，与大家一起讨论。由于还在学习的过程，可能是想到了什么就写什么了，不成条理。请大家见谅，希望大家积极的提出批评意见，谢谢！

首先我们先定义一下关于系统和构架的概念。这里引用IEEE 1471-2000中的定义：
system:a collection of components organized to accomplish a specfic function or set of functions.
Architecture:the fundamental organization of a system emboided in its components,their relationships to each other,and to the
enviroment and the principles guiding its design and evolution.
在SEI的《软件构架实践》中将软件构架定义为：
某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构，他们组成软件的各个部分，形成这些组件的外部可见属性
及相互间的联系。
总的来说，关于软件构架的目前来说并没有一个明确统一的定义。目前被采用比较多的关于构架的定义是IEEE 1471-2000的定义，以及SEI的关于软件构架的定义。到目前为止，这里有构架和软件构架两个定义，需要说明的上构架的含义并不只是软件构架，比如硬件系统也有其构架。但由于构架包含了软件构架，所以关于构架的定义完全使用于软件构架。在文章的以后部分，如果没有特别的说明，构架就特指软件构架。关于软件构架的定义还有很多，具体的可参考《软件构架实践》中的第二章“什么是软件构架”。
现在来分析定义中的一些概念，无论是IEEE还是SEI的定义中，都提到了component，这里将其称为组件。在IEEE中关于系统（system）的定义也是由一些的
组件组织而成的，用来完成某一特别的或者一些功能。我们可以认为组件是系统的基本单位，系统的功能分解于各个组件之间，组件通过共同协作来完成整个系统的动能。那么究竟什么样的东西可以被认为是组件，组成系统的个程序模块，运行系统的进程，子系统，对象？从某种意义上来说，这些都可以是,但很明显，我们没法用一个统一的标准来划分这些。事实上退一步来说，软件系统是什么，是只包含程序实体吗，还是包含运行该系统所
要占用的资源，很显然，从要完成功能的角度来说，两者都是，甚至还包括一些别的东西。我们可以看到构成系统的组件的标准不是一维的，根据不同标准，我们可以化分出不同的组件，从程序实体的构成我们可以程序模块，对象等看成是组件，从系统的运行角度来看进程等可以被看成是组件。在《软件构架实践》中谈到组件的具体定义时也认为组件是多种的，是和系统结构相关的（这些我将会在以后的章节中讨论）。
另外一个和组件相联系的概念就是组件之间的相互联系，有的文章中称为连接件。由于组件存在着多种种类，其连接的类型也是多种多样的。比如，在模块和模块之间的连接方式是定义接口。分布式系统不同节点的相互联系是定义操作协议等。和组件一样，连接件的种类也是多样的。
最后一个需要分析的是principles，这个概念在SEI的定义中没有，是指指导构架设计和评估的一些原则，看起来似乎不应该被包括在构架之中，但这个确实又是和
构架是紧密相关的，一个好的构架必须能够满足这些原则。在SEI种类似的概念是质量属性，更接近的概念可以参考TOGAF 8中的构架原则一章节。关于principles以及相
关的概念将在以后进行讨论。
到目前为止，我们解释了关于软件构架中的一些概念。相对具体的系统来说，构架是抽象的。我们可以把构架比喻为人体的骨骼，系统的构架在很大程度上决定了系统的能力。我们知道每个人都有一付骨骼，无论高低胖瘦，同样的，每个软件系统都有自己的构架，不过有的是好的，有的是不好的。在关于构架的定义中也没有任何地方涉及构架优劣的评价。同样构架的定义也没有涉及以下的内容：我们为什么需要进行构架设计，构架设计涉及到那些方面，关于构架设计的原则有那些，构架设计和软件过程的联系是什么。在以后的系列文章中我将逐步的对这些的问题进行讨论，欢迎大家指教。

...全文

154 15 打赏收藏转发到动态举报

写回复

用AI写文章

15 条回复

切换为时间正序

请发表友善的回复…

发表回复

termite 2003-09-29

打赏
举报

抽象的概念

f3611018 2003-09-29

打赏
举报

学习中……

梦回童年001 2003-09-29

打赏
举报

這不抽象
沒有面對一個項目時，就沒有所謂的架構。
我現在什麼都不知道，請你給我一個軟件架構，這真是開玩笑了，玩空手道。
當你面對一個項目時，那麼，架構的原型就從腦袋中開始浮出來了。

karach 2003-09-03

打赏
举报

来到这里才发现自己的渺小！向各位大哥学习

Panr 2003-09-03

打赏
举报

to jian_fish(小与):
我觉得：
一个业务对象在运行时会需要四个数据对象来支持
1.业务逻辑的实现构件，EJB对象或COM对象
2.业务逻辑的使用构件，JavaBean 或COM 接口句柄
3.业务接口描述，EJBObject 或COM 接口定义
4.业务对象工厂，Home Interface 或IFactory 实现

Component View 是程序中业务对象清单，这四个数据对象则是一个Component 的运行时分布
至于“构件和连接件组成的”，应该是指实现构件和接口描述，只是Component View 的一部分，也许把它称为架构有些不全面

［接口描述也许会被“统一消息格式”取代，于是对象工厂也可能退休］

> 题外话
> 在COM 中“使用构件”没有被明确地描述（就像你也不认为这是Component 的一部分）
> 但“使用构件”和“接口”肯定是不同的对象
> 如果接口描述被“统一消息格式”取代，“使用构件”将被明确研究
> 所以JavaBean 的概念是必要的

jian_fish 2003-09-02

打赏
举报

我觉得我理解得还是比较清晰的：
构架由构件和连接件组成的。
首先你必须搞清楚面向对象的概念，一般再建模过程中先建立类图
然后对类图进行三层分割，最后是构件图。
构件可能是一个类的一部分，也可能是进个类的合成，
最基本的原则是构件是稳定的，不变的部分。
之所以提出购架，构件就是针对软件复用来的。

gmc007 2003-08-30

打赏
举报

MARK

jacket1127 2003-08-29

打赏
举报

jiangnanrain 2003-08-29

打赏
举报

架构可以决定一个产品的外形

fita 2003-08-28

打赏
举报

什么是软件构架，谈谈我的看法。在软件刚出现的时候，它的规模都很小，我想大家刚开始编写软件程序的时候，只要一行行编码就行了，也不需要考虑什么软件构架的。就象我有一团泥巴，可以随意捻成我要的形状。但是随着程序的规模越来越大，开发的难度就增加了，就好像要我捻一个5米高的泥人，光用泥巴一定站不起来，必须给这个泥人做一个骨架，再把泥巴顺着骨架放上去才可以成为一个大的泥人。但这个骨架做好后，想捻成为其他的形状，比如说一条狗，就不行了，这就说，为了提高健壮性而牺牲了灵活性。大规模的软件需要一个软件架构也是这个道理，通过建立一个架构，使得整个软件系统大体成型，再进行编码就容易多了。

go_my_sky 2003-08-28

打赏
举报

walkcamel 2003-08-28

打赏
举报

自己再顶一下。：）

walkcamel 2003-08-24

打赏
举报

本来构架就是是一个比较抽象的概念，对构架的定义肯定是更为抽象的了，太具体的就变的有太多的限制了。古人有“吾道一以贯之”的传统，我看这个构架的定义很多的时候也就是这个“一”。具体是什么很多的时候也就是仁者见仁，智者见智了。也许你经过一系列的构架的方法，遵守描述的标准等操作后，你出来的东西就是符合规定的了。目前关于构架的研究主要是集中于需求一套标准化的构架设计过程和方法。