1,265
社区成员
发帖
与我相关
我的任务
分享构架思考（3）-构架的原则
在讨论这些原则之前，我们先讨论一下什么是构架需求，我们都知道有系统需求，那么系统需求和构架需求之间有什么联系和差别，什么是构架需求。根据RUP的定义：
A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.
构架需求指的是指对构架层次上有重要意义的需求，任何高风险，高优先级别和不稳定的需求都可以看成是对构架有重要意义的需求。在《Capturing Architectural Requirements》一文中对什么是构架需求和如何捕获构架需求进行了一个详细的描述，这里就不多加说明了。关于软件质量属性的描述可以参见《软件构架实践》中质量属性一章，SEI网站上的ATA方面的文章论述了如何将用户需求归纳整理为不同的质量属性，更为明确的路径是用户需求->构架需求->质量属性。归纳的目的是希望能够有更为一致的方法来进行构架设计的指导，同样在《软件构架实践》中的单元操作一章说明了不同的操作是如何的影响构架最终对不同的质量属性的满足程度。
我一直认为构架的原则就是在构架需求上整理总结出来的对系统的质量属性要求，包括技术上的要求和一些商业上的要求。这些的要求最终影响构架的设计。
另外一个需要进行讨论的是构架原则的表述，在描述系统需求的时候，我们经常会看到这样的话：“系统要求有良好的可扩展性和可更改性。”，包括在一些电子政务的需求说明书中也是这样。基本上来说，这句话说了等于没说，谁也不知道到底什么才算是良好可扩展性。在构架原则描述中有很多的时候就会涉及到诸如这中可扩展性等的质量属性问题，我个人认为在描述一个构架原则的时候必须包含以下的部分：原则的名称，选择该原则的原因说明，重新描述过的归属于该原则的构架需求。
A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.
构架需求指的是指对构架层次上有重要意义的需求，任何高风险，高优先级别和不稳定的需求都可以看成是对构架有重要意义的需求。在《Capturing Architectural Requirements》一文中对什么是构架需求和如何捕获构架需求进行了一个详细的描述，这里就不多加说明了。关于软件质量属性的描述可以参见《软件构架实践》中质量属性一章，SEI网站上的ATA方面的文章论述了如何将用户需求归纳整理为不同的质量属性，更为明确的路径是用户需求->构架需求->质量属性。归纳的目的是希望能够有更为一致的方法来进行构架设计的指导，同样在《软件构架实践》中的单元操作一章说明了不同的操作是如何的影响构架最终对不同的质量属性的满足程度。
我一直认为构架的原则就是在构架需求上整理总结出来的对系统的质量属性要求，包括技术上的要求和一些商业上的要求。这些的要求最终影响构架的设计。
另外一个需要进行讨论的是构架原则的表述，在描述系统需求的时候，我们经常会看到这样的话：“系统要求有良好的可扩展性和可更改性。”，包括在一些电子政务的需求说明书中也是这样。基本上来说，这句话说了等于没说，谁也不知道到底什么才算是良好可扩展性。在构架原则描述中有很多的时候就会涉及到诸如这中可扩展性等的质量属性问题，我个人认为在描述一个构架原则的时候必须包含以下的部分：原则的名称，选择该原则的原因说明，重新描述过的归属于该原则的构架需求。
...全文
请发表友善的回复…
发表回复
sevenn 2003-11-12
- 打赏
- 举报
to jeffyan77(jeffyan77):
系统架构是不是系统分析师们的一部分工作？
系统架构是不是系统分析师们的一部分工作？
tonyathome 2003-11-11
- 打赏
- 举报
具体的提出一个案例，看各位如何来运用上面所说的理论来分析，并提出方案：
本公司有5个办事处，总部有四十号人，其他四个分部各有五号人，都安装了宽带。因为从事物流行业，所以对于数据要求集中，格式要求严格，各办事处均需要报表打印的功能，有一定的安全措施，还有成本低（主要指硬件），希望系统的扩展性高，即不管谁负责系统，都能方便地增加或删除其中的功能。
向各位讨教，如何用理论来解决实际问题！
本公司有5个办事处，总部有四十号人，其他四个分部各有五号人，都安装了宽带。因为从事物流行业，所以对于数据要求集中，格式要求严格，各办事处均需要报表打印的功能，有一定的安全措施，还有成本低（主要指硬件），希望系统的扩展性高，即不管谁负责系统，都能方便地增加或删除其中的功能。
向各位讨教，如何用理论来解决实际问题！
sxzz 2003-11-06
- 打赏
- 举报
如何架构你的构架？我想这里有两个方面的讨论：
1、构架是个什么样子？它有什么基本特征？基本概念？作用是什么？构架应该是个目标、是个结果，最后以图纸的形式表现。
2、架构属于设计的方面，有什么方法？模式？用到什么工具？
我想构架的基本特征应该是一样的，只是通过你的架构，可以有不同的表现形式，就如同建筑：可以是钢结构、木结构、石结构等（这样说可能也不准确）。
而架构也应该有基本的方法、步骤等。
1、构架是个什么样子？它有什么基本特征？基本概念？作用是什么？构架应该是个目标、是个结果，最后以图纸的形式表现。
2、架构属于设计的方面，有什么方法？模式？用到什么工具？
我想构架的基本特征应该是一样的，只是通过你的架构，可以有不同的表现形式，就如同建筑：可以是钢结构、木结构、石结构等（这样说可能也不准确）。
而架构也应该有基本的方法、步骤等。
nblueguy 2003-11-05
- 打赏
- 举报
个人觉得软件架构设计目的是为了能符合人思维模式。
软件架构能从比较高层次来抽象模型。使人有个总体的概念。就如同书目录一样，勾画出主题，把握方向。相对于底层复杂模型而言，人更易接受简单和全局的东西。而对于软件架构分类如应用架构，信息架构......那是思维和应用的多样化（把它们分类了，可能更加容易理解）对于复杂的东西，我们希望抽象，分解他们，变成我们容易理解的东东。
这几天在看设计模式（elements of reusable oo software）和doctor yan
（jeffyan77(jeffyan77)）的java 和模式。虽然不是很明白具体模式，其实说实在的，我也没有打算都明白每个模式，但是我觉得收益非浅。OO把问题域与解域的距离拉近，oo解决问题的思维与我们的思维模式相近。而设计模式可以说是许许多多软件应用领域设计思维的一种抽象。细细品，还真是那个味。
谈谈建筑和软件关系。我觉得没有必要牵扯太多。软件和建筑有许多相近的东西。只是思维的一种碰撞。但可以借助建筑学的东西来理解软件领域的内容，同样软件的发展是极其快的，（是时尚？活力？）也会影响建筑业的！
//（注释）在众多高手面前，瞎说！
软件架构能从比较高层次来抽象模型。使人有个总体的概念。就如同书目录一样，勾画出主题，把握方向。相对于底层复杂模型而言，人更易接受简单和全局的东西。而对于软件架构分类如应用架构，信息架构......那是思维和应用的多样化（把它们分类了，可能更加容易理解）对于复杂的东西，我们希望抽象，分解他们，变成我们容易理解的东东。
这几天在看设计模式（elements of reusable oo software）和doctor yan
（jeffyan77(jeffyan77)）的java 和模式。虽然不是很明白具体模式，其实说实在的，我也没有打算都明白每个模式，但是我觉得收益非浅。OO把问题域与解域的距离拉近，oo解决问题的思维与我们的思维模式相近。而设计模式可以说是许许多多软件应用领域设计思维的一种抽象。细细品，还真是那个味。
谈谈建筑和软件关系。我觉得没有必要牵扯太多。软件和建筑有许多相近的东西。只是思维的一种碰撞。但可以借助建筑学的东西来理解软件领域的内容，同样软件的发展是极其快的，（是时尚？活力？）也会影响建筑业的！
//（注释）在众多高手面前，瞎说！
sxzz 2003-11-04
- 打赏
- 举报
建筑构架：门、窗、墙（柱）、顶（梁）、基、梯（如多层），任你千变万化，管他怎么用途。
车构架：轮子、驱动器、轮驱连接器，任你千变万化，管他怎么用途。
软件构架：？？？？？？？任你千变万化，管他怎么用途。
车构架：轮子、驱动器、轮驱连接器，任你千变万化，管他怎么用途。
软件构架：？？？？？？？任你千变万化，管他怎么用途。
寒若辰 2003-11-04
- 打赏
- 举报
支持！
f3611018 2003-09-30
- 打赏
- 举报
好！好！好！
学习！
学习！
digital1 2003-09-13
- 打赏
- 举报
开了一个讨论架构的话题，没有人理我，放到这里，请大家看看
在总结前人的基础上给出了整体描述一个系统的7个架构
应用架构：从使用视角看架构。系统实现的功能，以及各功能模块间的关系。
业务架构：业务模型，流程模型，组织模型等企业本身
信息架构：企业的信息系统规划
体系架构：三层或N层体系
系统架构: 软硬件部署
安全架构：安全了
软件架构：此部分主要描述各个应用软件间的关系结构，如数据库，was，portal等
在用这个架构去描述一个大系统的时候感觉非常清楚，
其中信息架构，我给出的说明实际上是信息系统架构，有没有对信息架构专门有研究的同行详细说明一下，对信息架构还是不很把握
在总结前人的基础上给出了整体描述一个系统的7个架构
应用架构：从使用视角看架构。系统实现的功能，以及各功能模块间的关系。
业务架构：业务模型，流程模型，组织模型等企业本身
信息架构：企业的信息系统规划
体系架构：三层或N层体系
系统架构: 软硬件部署
安全架构：安全了
软件架构：此部分主要描述各个应用软件间的关系结构，如数据库，was，portal等
在用这个架构去描述一个大系统的时候感觉非常清楚，
其中信息架构，我给出的说明实际上是信息系统架构，有没有对信息架构专门有研究的同行详细说明一下，对信息架构还是不很把握
水风云 2003-09-12
- 打赏
- 举报
软件的构架与设计模式的关系如何？
swinging 2003-09-12
- 打赏
- 举报
很深刻，
好像有点跑题，
我觉得，大家都不否认建筑业同软件业很有相同点，
结论是，软件业和建筑业很相似。
那么大家在讨论什么？
我想，对于力于阐明软件项目和建筑项目相似的朋友，
主要还是想把一些用于建筑的好的东西引入软件，
或者说，大家可以借鉴建筑领域的东西来进行软件开发，
我想到了软件模式，
其实说白了，三人行必有我师，
对于不同的领域，到了高处，很多东西也都是可以相互借鉴的吧。
好像有点跑题，
我觉得，大家都不否认建筑业同软件业很有相同点，
结论是，软件业和建筑业很相似。
那么大家在讨论什么？
我想，对于力于阐明软件项目和建筑项目相似的朋友，
主要还是想把一些用于建筑的好的东西引入软件，
或者说，大家可以借鉴建筑领域的东西来进行软件开发，
我想到了软件模式，
其实说白了，三人行必有我师，
对于不同的领域，到了高处，很多东西也都是可以相互借鉴的吧。
jeffyan77 2003-09-12
- 打赏
- 举报
swinging(山不在高)说：想把一些用于建筑的好的东西引入软件
这已经在发生了，只是大部分人没有察觉而已。软件架构设计有一个Layers模式（分层模式），这本就来自于建筑学，参见
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
那里对Layers模式的描述比我见过的所有软件著作都精辟得多。
这已经在发生了，只是大部分人没有察觉而已。软件架构设计有一个Layers模式（分层模式），这本就来自于建筑学，参见
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
那里对Layers模式的描述比我见过的所有软件著作都精辟得多。
jeffyan77 2003-09-12
- 打赏
- 举报
To gg007(赵gg):
软件的架构设计有一些规律可循，有经验的人经过综合，发现了一些模式。这些模式称作架构模式，它们都是架构设计的范例。
软件模式可以分成架构模式、设计模式和代码模式，它们的尺度不同。
一般地讲，软件架构与设计模式没什么关系。有关系的是架构模式。
软件的架构设计有一些规律可循，有经验的人经过综合，发现了一些模式。这些模式称作架构模式，它们都是架构设计的范例。
软件模式可以分成架构模式、设计模式和代码模式，它们的尺度不同。
一般地讲，软件架构与设计模式没什么关系。有关系的是架构模式。
LiwuxLiang 2003-09-09
- 打赏
- 举报
各位楼上的思想都好深邃，我只能到‘明确需求，双方签字’，‘需求变动，掏钱’的层次，而不会去考虑time-friendly。看了你们的发言之后，就觉得你们追求的境界会更加有成就感，甚至‘使命感’。谢谢大家，我要向大家学习，要在工作的时候时时考虑这个问题。
fita 2003-09-03
- 打赏
- 举报
imafool的话反映了另外一个事实：建筑的需求变化速度要远远慢于软件的变化速度。
为什么会这样呢，我想也许是因为软件的制造比建筑的制造要容易得多，房子的设计很大程度上需要遵守自然规律，比如说承重结构等，人们对于房子的需求也是很大程度上受到这些限制的，提需求的人也接受了这一点，建筑的需求变化慢，自然建筑的建造方法、架构也能够保持相对稳定，管理起来也就容易得多。
与建筑相比，软件制造的限制要小得多，人们的需求实现得快，自然也就变化得快了（人真是一个不容易满足的动物）。jeffyan77提出的Time Friendly概念，我想对于软件来说，已经远远超出Friendly的要求了，也许应该说Timeless, 或Change Critically。
为什么会这样呢，我想也许是因为软件的制造比建筑的制造要容易得多，房子的设计很大程度上需要遵守自然规律，比如说承重结构等，人们对于房子的需求也是很大程度上受到这些限制的，提需求的人也接受了这一点，建筑的需求变化慢，自然建筑的建造方法、架构也能够保持相对稳定，管理起来也就容易得多。
与建筑相比，软件制造的限制要小得多，人们的需求实现得快，自然也就变化得快了（人真是一个不容易满足的动物）。jeffyan77提出的Time Friendly概念，我想对于软件来说，已经远远超出Friendly的要求了，也许应该说Timeless, 或Change Critically。
tonyathome 2003-09-02
- 打赏
- 举报
Menliwxj的想法很正常，而且现在也出现了这样的公司。我想menliwxj碰到的问题在于：可能企业本身的IT人员能力不强，或者企业政治的因素影响了系统的进展。所以对于大型的系统来说，可能面临的不仅仅是技术的问题，还有管理的问题，公关的问题，企业文化的问题。所以技术人员会感觉很无助。如何根本地解决这种现状呢？我认为，只有更多的技术人员进入核心管理层以后，整个软件业的发展才会有更大的提高。这就需要兄弟姐妹们多努力，成为“又红又专”的精英！
爱编程的老五 2003-09-02
- 打赏
- 举报
zhuma(竹马):
我自己一直从事的企业类的软件系统设计,因此出发点主要是从企业类的信息管理角度出发来考虑的.至于如电信等领域我就不太清楚了.我的这个想法也是刚才在看了上面各位的讨论之后想到的.目前还无法更进一步地陈述.
我自己一直从事的企业类的软件系统设计,因此出发点主要是从企业类的信息管理角度出发来考虑的.至于如电信等领域我就不太清楚了.我的这个想法也是刚才在看了上面各位的讨论之后想到的.目前还无法更进一步地陈述.
zhuma 2003-09-02
- 打赏
- 举报
但是它应该存在于哪种类型的软件中呢？
消费类？
企业类？
专业类？
都挺难切入的
希望 menliwxj(有缘) 进一步阐述
消费类？
企业类？
专业类？
都挺难切入的
希望 menliwxj(有缘) 进一步阐述
zhuma 2003-09-02
- 打赏
- 举报
软件服务公司
menliwxj(有缘)的观点很有意思
menliwxj(有缘)的观点很有意思
爱编程的老五 2003-09-02
- 打赏
- 举报
对于软件的构造,我来谈几句.
在经历了数个软件项目之后,我发现包括自己在内,都曾说过太多次数的一句:客户无法准确地提出需求来.这就让我们的工程进度一拖再拖,甚至到最后双方无法忍受而放弃了.我们再来看看建筑方法的:不论是商业建筑还是住宅,请问最终用户提出过需求吗?这里就存在一个明显的不同之处,建筑不是最终用户在提需求,而是中间服务商在提需求.
我在想,如果软件工程也采用这种思路,即最终客户并不是直接找软件公司来构建他自己的软件系统,而是找软件服务公司(与现在的管理咨询公司有些相同的功能,但内涵更深)来为其提供最恰当的系统.对软件开发公司,提需求的不再是客户,而是咨询服务公司.那么无论是从专业的深度,还是业务领域的精通,我想咨询公司都要比我们现在面对的最终客户要准确\恰当得多.我们构建的系统也将会如建筑一样,在局部调整时不会伤筋动骨了.
在经历了数个软件项目之后,我发现包括自己在内,都曾说过太多次数的一句:客户无法准确地提出需求来.这就让我们的工程进度一拖再拖,甚至到最后双方无法忍受而放弃了.我们再来看看建筑方法的:不论是商业建筑还是住宅,请问最终用户提出过需求吗?这里就存在一个明显的不同之处,建筑不是最终用户在提需求,而是中间服务商在提需求.
我在想,如果软件工程也采用这种思路,即最终客户并不是直接找软件公司来构建他自己的软件系统,而是找软件服务公司(与现在的管理咨询公司有些相同的功能,但内涵更深)来为其提供最恰当的系统.对软件开发公司,提需求的不再是客户,而是咨询服务公司.那么无论是从专业的深度,还是业务领域的精通,我想咨询公司都要比我们现在面对的最终客户要准确\恰当得多.我们构建的系统也将会如建筑一样,在局部调整时不会伤筋动骨了.
imafool 2003-09-02
- 打赏
- 举报
一、人们不要求房子能放音乐……就象人们不要求作图软件能处理音乐。如果你说未来的智能化建筑其实也可以要求房子放音乐，那么，房子其实还是不能音乐，这其实是一个系统集成的问题，就象作图软件里可以处理音乐一样。…这由需求推动，但需求是分层次的，前一个需求没有达成时，后面的需求不会提出，或者不会表现得太过迫切，诚如：饱暖思淫欲…
二、对于软件和建筑的差别，其很大一个原因是来自于人这个物种自身的渺小，人的生命太短，假如从遮风避雨到智能通讯这个需求变化过程在一个月之内经历，那你会发现建筑和软件有更多的相似，——其实不只是建筑。再来一个其实吧……你看到现在的人住在一个古老的住房里，没有太多不便，就好象WORD升级到XP之后，写一句留言还是可以用“记事本”，这只是说明我做“留言”这件事时并无我办公时的需求，就好象住古老建筑的朋友最终还是得跑到写字楼去办公。死抱正版的人们还会出于成本考虑……去使用免费，这是另一话题。
二、对于软件和建筑的差别，其很大一个原因是来自于人这个物种自身的渺小，人的生命太短，假如从遮风避雨到智能通讯这个需求变化过程在一个月之内经历，那你会发现建筑和软件有更多的相似，——其实不只是建筑。再来一个其实吧……你看到现在的人住在一个古老的住房里，没有太多不便，就好象WORD升级到XP之后，写一句留言还是可以用“记事本”，这只是说明我做“留言”这件事时并无我办公时的需求，就好象住古老建筑的朋友最终还是得跑到写字楼去办公。死抱正版的人们还会出于成本考虑……去使用免费，这是另一话题。
加载更多回复（25）
