软件架构风格 - welfear
- - 博客园_我所说的，都是错的文档名称：软件架构风格(software architecture style). 文档维护：Xuefeng Chang([email protected]). 文档创建：2013.07.27. 如果说设计模式是从代码角度为系统降低耦合度，那么架构风格便是从数据角度解耦. 架构是更加宏观和全面的视角，它不再是解决单一的技术问题，而是为系统提供更加.
软件架构风格 - welfear
标签：
软件架构
welfear
| 发表时间：2013-07-27 17:27 | 作者：welfear
出处：
文档名称：软件架构风格(software architecture style)
文档维护：Xuefeng Chang([email protected])
文档创建：2013.07.27
如果说设计模式是从代码角度为系统降低耦合度，那么架构风格便是从数据角度解耦。
架构是更加宏观和全面的视角，它不再是解决单一的技术问题，而是为系统提供更加
完整的解决方案。
架构风格是一种粗粒度的软件模式，为常见软件问题提供解决方案，促进软件的重用。
常见的软件架构风格如下:
1.Pipe & Filter
2.Batch
3.VM
4.Layered Architecture
5.MVC, PAC
6.MicroKernel
7.Event System
8.Blackboard System
9.Broker, C/S, P2P, SOA
参考http://www.infoq.com/news/2009/02/Architectural-Styles-Patterns
每种架构风格适用于某种特定的问题域，比如第九项全部是分布式计算领域的架构风格。
从用户最常见的GUI和CUI环境视角看：
CUI常常是具有单一输入和单一输出，比较擅长处理有机械性、重复性和规律性的问题。
GUI更擅长有交互性的任务，它的输入和输出之间时常会变化并加以排列组合。
CUI和GUI是一种演化的关系：
1.当输入是单一流或者多个单一流时，架构风格往往是Pipe & Filter/Batch/N Layered。
2.当输入是多个流时，架构风格通常是MVC/PAC。
3.当需要合并多个输入流时，则会使用Event System/MicrosKernel。
4.当需要合并多个输出流时，则会使用Blackboard System。
对于1，在Linux中系统管理员和程序员常用Pipe & Filter处理文本流；而在流媒体系统中，
Pipe & Filter用来demux视频流和音频流。这种固定输入流的任务很容易实现批量功能而
变成Batch状态。VM虚拟机可以简单看作是复杂输入而没有相应输出的任务。Layed Arch
是一种存在依赖的Pipe & Filter，它的处理顺序和流程已经事先设定好。
对于2，MVC不仅仅是设计模式，当它能解决多个输入流问题时，它成为为一种架构风格。
MVC以及其衍生的MVVC, MVP, PAC将输入模块，数据模块和协调控制模块分解开来。类似的
模型比较强调Control的作用。
对于3和4，它们常常和MVC共同使用。3, 4代表一种处理更复杂问题的一般思路。数据可能
是输入或输出，也可能是一种解耦的方式。比如实现接口的虚表就是一种解耦数据。直接
传递数据会降低系统性能，上下文情景分析和有效数据分离都会增加计算时间开销。
Event System往往会维护原始的上下文和当前变化数据的信息，这些数据出现在输入流的
最开始处理阶段或着是前后处理模块的衔接过程。Blackboard System强调了Model的作用，
拥有共同的Model特别是Domain Model可以在更宏观的层面上为系统解耦或接入更多的
生产者与消费者。
文档维护：Xuefeng Chang([email protected])
文档创建：2013.07.27
如果说设计模式是从代码角度为系统降低耦合度，那么架构风格便是从数据角度解耦。
架构是更加宏观和全面的视角，它不再是解决单一的技术问题，而是为系统提供更加
完整的解决方案。
架构风格是一种粗粒度的软件模式，为常见软件问题提供解决方案，促进软件的重用。
常见的软件架构风格如下:
1.Pipe & Filter
2.Batch
3.VM
4.Layered Architecture
5.MVC, PAC
6.MicroKernel
7.Event System
8.Blackboard System
9.Broker, C/S, P2P, SOA
参考http://www.infoq.com/news/2009/02/Architectural-Styles-Patterns
每种架构风格适用于某种特定的问题域，比如第九项全部是分布式计算领域的架构风格。
从用户最常见的GUI和CUI环境视角看：
CUI常常是具有单一输入和单一输出，比较擅长处理有机械性、重复性和规律性的问题。
GUI更擅长有交互性的任务，它的输入和输出之间时常会变化并加以排列组合。
CUI和GUI是一种演化的关系：
1.当输入是单一流或者多个单一流时，架构风格往往是Pipe & Filter/Batch/N Layered。
2.当输入是多个流时，架构风格通常是MVC/PAC。
3.当需要合并多个输入流时，则会使用Event System/MicrosKernel。
4.当需要合并多个输出流时，则会使用Blackboard System。
对于1，在Linux中系统管理员和程序员常用Pipe & Filter处理文本流；而在流媒体系统中，
Pipe & Filter用来demux视频流和音频流。这种固定输入流的任务很容易实现批量功能而
变成Batch状态。VM虚拟机可以简单看作是复杂输入而没有相应输出的任务。Layed Arch
是一种存在依赖的Pipe & Filter，它的处理顺序和流程已经事先设定好。
对于2，MVC不仅仅是设计模式，当它能解决多个输入流问题时，它成为为一种架构风格。
MVC以及其衍生的MVVC, MVP, PAC将输入模块，数据模块和协调控制模块分解开来。类似的
模型比较强调Control的作用。
对于3和4，它们常常和MVC共同使用。3, 4代表一种处理更复杂问题的一般思路。数据可能
是输入或输出，也可能是一种解耦的方式。比如实现接口的虚表就是一种解耦数据。直接
传递数据会降低系统性能，上下文情景分析和有效数据分离都会增加计算时间开销。
Event System往往会维护原始的上下文和当前变化数据的信息，这些数据出现在输入流的
最开始处理阶段或着是前后处理模块的衔接过程。Blackboard System强调了Model的作用，
拥有共同的Model特别是Domain Model可以在更宏观的层面上为系统解耦或接入更多的
生产者与消费者。
本文链接： http://www.cnblogs.com/welfear/p/3219788.html，转载请注明。
相关 [软件架构 welfear] 推荐：
管理风格 - welfear
- - 博客园_我所说的，都是错的文档名称：管理风格(management style). 文档维护：Xuefeng Chang([email protected]). 文档创建：2013.07.28. 《门后的秘密》一书提供了极其生动的范例. 书中介绍了解决各种实际问题. 的方法和一般项目管理的常见做法，在技术层面上给出了足够多的专业建议.
软件架构
- - 研发管理 - ITeye博客 对于外包业务类型的项目，软件架构设计的目的与产品类型的项目有所不同，在这里主要讨论外包类型项目的软件架构设计目的. 1、为大规模开发提供基础和规范，并提供可重用的资产，软件系统的大规模开发，必须要有一定的基础和遵循一定的规范，这既是软件工程本身的要求，也是客户的要求. 架构设计的过程中可以将一些公共部分抽象提取出来，形成公共类和工具类，以达到重用的目的.
软件架构设计
- - 企业架构 - ITeye博客软件架构设计尚没有万灵的方法论支持，还是个非常新兴的行业，给出个人理解的行业软件架构设计过程，受个人水平有限，仅供参考：. 1.业务分析：针对目标行业的业务战略、蓝图、业务功能及流程进行分析，提出其中部分功能可以使用信息化进行处理，通过分析可以得出信息化要解决的问题. 2.解决方案设计：根据业务战略，形成行业信息化解决方案.
软件架构师的沟通修炼
- - 博客 - 伯乐在线在架构师的角色中，沟通是要求有效果的必备技能与工具. 换句话说，沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段. 架构师通常没有对为其项目工作的他人的直接管理权. 他们的项目往往是跨部门的，也可能会跨好多个行业单位. 由于不能直接管理他人，所以架构师指示别人或群体完成特定行动的能力就受到限制.
软件架构师的职责
- - 研发管理 - ITeye博客架构师需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调. 在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可. 架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求.
【译】软件架构师之路
- - 掘金架构今天给大家带来一篇自己翻译的干货《软件架构师之路》. 本周Github上升很快的项目. 其内容对致力于成为软件架构师（不论前后端）的同学应该都会有极大的帮助. 中文地址 github.com/gamedilong/…. 原文地址 github.com/justinamill…. 如果有看完英文原文，发现本文翻译内容中存在问题或者错误的欢迎到中文Git地址PR，如能够对大家起到一定的帮助也欢迎star.
软件架构设计（二）——软件架构设计过程
- - BlogJava-首页技术区 一般来讲，涉众包括客户（资方）代表、承接方（劳方）代表、用户代表. 对于要明确实现某种标准的软件系统，通常确定边界非常容易，直接按标准圈定的scope分析即可，比如像SIPServlet容器，是要求遵从JSR168规范的，那么软件系统的Scope就是JSR168规定的Scope，但是也有例外，比如客户或者劳方明确指定要复用一个现有的实现了部分功能的系统或组件，那么Scope就不同了.
软件架构师不等同于资深程序员
- - 研发管理 - ITeye博客本文的作者Armel Nene是ETAPIX Global公司的首席架构师，他居住在伦敦，他参与过的开源项目包括 Apache Lucene,，Apache Nutch， Liferay 和 Pentaho等. 如今很多的公司的IT部门仍然认为招聘一个资深的程序员，他同样也能承担软件架构师的角色. 资深程序员对整个软件生命周期很了解，他们可以经过培训成为架构师，但他们不等同于架构师.
如何开展软件架构之需求分析
- - CSDN博客架构设计推荐文章如何开展软件架构之需求分析. 在开始讨论如何开展软件架构之前,先让我们来看一张漫画. 相信大家看到这漫画的时候，总会不自主地会心一笑，客户希望得到礼物，我们却给了他一骨头. 一）：未进行充分地需求分析. 解析：架构师未能初别用户群及使用环境约束因素，也许在接到项目时，他还在想着上一个为狗开发的项目，在这个项目中自然而然地认为用户是狗.