a
软件体系结构风格
软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来
一、数据流体系结构风格（Data Flow Style）
数据流风格包括批处理和管道过滤器；
关于批处理风格，批处理风格的每个处理步骤是一个独立的程序，并且每一步必须在前一步结束后才能开始，还有数据必须是完整的，以整体的方式传递；
构件：独立的应用程序 连接件：某种类型的媒质 拓扑结构：连接件定义数据流图
优点：处理是全部的，输入时可随时存取
缺点：无并发性，实时性差，数据格式不统一
关于管道过滤器风格，管道过滤器风格递增的读取和消费数据流，数据到来时便被处理，不是收集然后处理，即在输入被完全消费之前，输出便产生了。
构件：过滤器 连接件：管道 拓扑结构：连接件定义数据流图
应用实例：Compiler (编译器) 、Unix pipes (Unix管道)、Image processing (图像处理)、Signal processing (信号处理)、Voice and video streaming (声音与图像处理)
优点：高内聚低耦合，支持软件复用，维护简单，有并发性，实时性好
缺点：不适合处理交互，系统性能差
二、调用/返回体系结构风格（Call/Return Style）
调用/返回风格包括主程序/子程序风格、面向对象、层次风格；
关于主程序/子程序风格，单线程控制，划分为若干处理步骤，功能模块：把步骤集成至模块中；
关于抽象数据类型（ADT），操作和数据绑定在一起，隐藏实现和其他秘密
关于层次风格，每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层；大的问题分解为若干个渐进的小问题，逐步解决，隐藏了很多复杂度；修改一层，最多影响两层，而通常只能影响上层。接口稳固，则谁都不影响；上层必须知道下层的身份，不能调整层次之间的顺序；层层相调，影响性能
优点：层次分明，接口稳固，易于修改和维护
缺点：部分软件项目不方便划分层次，强行划分会使其功能混淆或者混乱
三、数据中心体系结构风格（Data-centered Style）
数据中心体系结构风格包括仓库体系结构风格和黑板体系结构风格
关于仓库体系结构风格；仓库是存储和维护数据的中心场所，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化
构件：中央数据结构，独立构件 连接件：仓库与独立构件之间的交互
应用实例：数据库
优点：善于管理数据信息，适合大量数据的应用场合；适用于复杂的逻辑系统
缺点：测试困难，开发效率低，成本高
关于黑板体系结构风格；黑板架构包括知识源、黑板和控制器三个部分；知识源对黑板进行修改，逐渐找到问题的解；黑板是一个全局数据库，包含解域的全部状态，是知识源互相作用的唯一媒介；控制器负责监视黑板状态，激活知识源
应用实例：人工智能领域
优点：知识源可以重用；规模伸缩性好（方便添加新数据）
缺点：测试困难，计算开销大（工作量可能比较大，浪费多）；增加了系统的复杂性；对黑板数据结构的修改较为困难
四、虚拟机体系结构风格（Virtual Machine Style）
虚拟机体系结构风格包括解释器和基于规则的系统，因为命令行处理器属于解释器，故属于虚拟机体系结构风格
关于解释器风格；构件：一个状态机和三个存储；连接件：数据访问和过程调用
优点：可以模拟非本机功能，可以用于安全测试，是用处非常广泛的工具
缺点：性能差
关于规则系统风格；包含工作存储、规则解释器和知识库
优点：因为规则系统风格可以区分业务逻辑和业务规则，故非常适合业务规则经常改变，业务繁杂，需要降低维护成本的项目
五、事件系统体系结构风格（Event System Style）
事件系统体系结构风格包括隐式调用和显式调用风格，事件系统体系风格的核心是事件，当事件发生后，由事件找到该事件对应的程序进行处理
关于隐式调用；事件触发者不知道哪些构件会被影响，相互保持独立；不能假定构件的处理顺序；各个构件通过对事件的发布和注册实现关联
优点：1、为软件重用提供了强大的支持；2、为改进系统带来了方便；
缺点：1、构件放弃了对系统计算的控制；2、数据交换的问题；3、正确性的推理存在问题
“4+1”视图
用例视图（Use Cases View），最初称为场景视图，关注最终用户需求，为整个技术架构的上线文环境.通常用UML用例图和活动图描述
逻辑视图（Logical view），主要是整个系统的抽象结构表述，关注系统提供最终用户的功能，不涉及具体的编译即输出和部署，通常在UML中用类图，交互图，时序图来表述，类似与我们采用OOA的对象模型——Sequence diagram，Class diagram
过程视图（Process view）处理视图关注系统动态运行时，主要是进程以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题，在UML中通常用活动图表述——Activity diagram
物理视图（Physical view ）物理视图通常也叫做部署视图(deploymentview)，是从系统工程师解读系统，关注软件的物流拓扑结，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
开发视图(Development View)，描述软件在开发环境下的静态组织，从程序实现人员的角度透视系统，也叫做实现视图(implementation view)。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件, 在UML中用组件图，包图来表述。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等——Component diagram
UML
类图（class diagram）
类图描述了具体的功能实现
序列图（sequence diagram）
序列图可以与协作图互相转换
活动图（activity diagram）
活动图常用于工作流和过程建模
对象图（object diagram）
质量属性
可用性（Availability）
提升可用性的策略有：Ping/echo，心跳（Heartbeat），异常（Exception），主动/被动冗余（Active/Passive redundancy），事务，进程监控（Process monitor），检查点/回滚
可用性的关注点：故障
可修改性（Modifiabilitiy）
提升可修改性的策略有：限制修改范围，高内聚低耦合，考虑可能的修改，让模块通用，使用中介，限制通信路径，限制执行时间（Bound execution times），语义连贯性（Semantic coherence）配置文件，发布——订阅模式，多态，命名服务器，Prevent ripple effects
可修改性的关注点：修改的成本，系统的哪些部分被修改，修改发生的时间和所有权
性能（Performance）
提升性能的策略有：提高计算效率（Reduce computational overhead），减少数据总量，限制执行时间（Bound execution times），利用并发机制（Introduce concurrency），增加可用资源，先来先服务，固定优先级调度，固定权限的调用，Control frequency of sampling，Manage event rate
性能的关注点：软件运行的速度
安全性（Security）
提升安全性的策略有：用户的证实、授权（Authenticate users），维持数据保密性，维持数据完整性，减少暴露（Limit exposure），限制访问，密保卡，验证码，恢复状态，攻击者的识别
安全性关注的点：保证合法用户使用系统的前提下，抵抗对系统的攻击
可测试性（Testability）
提升可测试性的策略有：记录/回放（Record/playback），接口和实现分离（Separate interface from implementation），提供专用的测试路径，内部监控（Built-in monitors）
可测试性关注的点：让BUG更容易被测试出来，验证产品是否符合规格，使用最小的工作量和成本来验证
易用性（Usability）
提升易用性的策略有：系统给用户适当的反馈，系统给用户提供一致的体验，支持撤销操作，把用户界面和系统分离，Maintain a model of the task
易用性关注的点：让用户使用软件的难度降低
ATAM软件评估（Architecture Trade-off Analysis Method）
风险决策，无风险决策，敏感点，权衡点（risk, non-risk, sensitivity point and tradeoffs）
系统架构风险：架构设计中潜在的、存在问题的架构决策带来的隐患
敏感点：为了实现某种特定的质量属性，一个或多个系统组件所具有的特性
权衡点：影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
